Date: Wed, 15 Dec 93 04:30:02 PST
From: Advanced Amateur Radio Networking Group <tcp-group@ucsd.edu>
Errors-To: TCP-Group-Errors@UCSD.Edu
Reply-To: TCP-Group@UCSD.Edu
Precedence: Bulk
Subject: TCP-Group Digest V93 #323
To: tcp-group-digest
TCP-Group Digest Wed, 15 Dec 93 Volume 93 : Issue 323
Today's Topics:
data radios
How to get routing to a new packet-Ham bbs
NNTP client ( with source ) needed.
NOS IP router in a Windows Dos box question
UDP Locking Things Up
VC vs Datagram
VC vs DG (not Viet Cong)
X-1 Routing 101
Send Replies or notes for publication to: <TCP-Group@UCSD.Edu>.
Subscription requests to <TCP-Group-REQUEST@UCSD.Edu>.
Problems you can't solve otherwise to brian@ucsd.edu.
Archives of past issues of the TCP-Group Digest are available
(by FTP only) from UCSD.Edu in directory "mailarchives".
We trust that readers are intelligent enough to realize that all text
herein consists of personal comments and does not represent the official
policies or positions of any party. Your mileage may vary. So there.
----------------------------------------------------------------------
Date: Tue, 14 Dec 1993 09:41:09 -0600 (CST)
From: "Bill Walker" <bw@uecok.ecok.edu>
Subject: data radios
To: tcp-group@ucsd.edu
A friend asked me what I would recommend for a data radio on 440 mhz.
I have looked at the Kantronics, and the TEKK, but both require
rocks, and my friend wanted to use the radio for other than packet
operations on occasion.
Since 9600 bauds are in the offing, direct FM is probably a must.
Any recommendations?
73 de Bill W5GFE
--
Bill Walker Ph.D.
Chairman, Dept. of Computer Science
East Central University
Ada, Oklahoma 74820-6899
e-mail: bw@cs.ecok.edu
phone: 405 332 8000 ext. 594
FAX: 405 332 1623
------------------------------
Date: Tue, 14 Dec 1993 20:43:30 -0500
From: <castonj@ireq.hydro.qc.ca> (Jacques Castonguay)
Subject: How to get routing to a new packet-Ham bbs
To: tcpgroup@ucsd.edu
Hi there,
A friend of mine is planning to install an Packet-Ham-Radio (JNOS) Internet
gateway in
early January 94. He will then have a dedicated SLIP link from a MSYS BBS
and Mc Gill
University, Montreal Canada.
He want his BBS system (or whatever else needed) to be enlisted by your
organisation
(or another suitable one) for the routing of tcpip messages addresses to
it. He will
get soon his Internet address. He will also get immediately a Ham IP
address, since
I am the IP address coordinator for the province of Quebec (VE2-land).
Please indicate to me what are the informations you need and the procedure
to follow
to register such a new tcpip Ham BBS to be recognize by Internet routing system.
I am not sure, but this system wil be the first one of its kind in Quebec.
I heard
that few more (1 or 2) are comming.
Thanks.
Jacques.
P.S. Please tell me who to contact if this is not of your concern.
____________________________________________________________________
/ Jacques Castonguay (chercheur) \ / castonj@ireq.hydro.qc.ca \
\ IREQ Hydro-Quebec / \ ve2esm@ve2csc.pq.can.na /
/ 1800 Montee Ste-Julie \ / \
\ Varennes, Quebec, CANADA / \ Tel: (514) 652-8393 /
/ J3X 1S1 \ / Fax: (514) 652-8424 \
\_________________________________/__\_______________________________/
------------------------------
Date: 14 Dec 93 15:06:09 CST
From: Jack Snodgrass <kf5mg@vnet.IBM.COM>
Subject: NNTP client ( with source ) needed.
To: <TCP-Group@UCSD.Edu>
Does anyone know where I can find a decent, NNTP client that has
source available? Preferably DOS or Window's based. Thanks.
73's de Jack - kf5mg
Internet - kf5mg@kf5mg.ampr.org - 44.28.0.14
Worknet - kf5mg@vnet.ibm.com - work (817) 962-4409
AX25net - kf5mg@kf5mg.#dfw.tx.usa.na - home (817) 488-4386
------------------------------
Date: 14 Dec 93 14:57:20 CST
From: Jack Snodgrass <kf5mg@vnet.IBM.COM>
Subject: NOS IP router in a Windows Dos box question
To: <TCP-Group@UCSD.Edu>
Has anyone figured out how you can run a program like WINQVT and have
it talk to a NOS, IP Router on the same box in a different Windows,
Dos session? I know that you can run WINQVT on one box and use a
second, separate box as a NOS router, but can you do it using a
single box under Windows?
I can get this to work on OS/2 if I use 2 ethernet cards and have them
talk to each other. Is that what you'd need to do with WINQVT and NOS
on the same windows box? Any help would be appreciated.
73's de Jack - kf5mg
Internet - kf5mg@kf5mg.ampr.org - 44.28.0.14
Worknet - kf5mg@vnet.ibm.com - work (817) 962-4409
AX25net - kf5mg@kf5mg.#dfw.tx.usa.na - home (817) 488-4386
------------------------------
Date: Tue, 14 Dec 93 10:42:07 CST
From: jwhite@cuscus.mecc.mn.org (Jeff White)
Subject: UDP Locking Things Up
To: crompton@NADC.NADC.NAVY.MIL (D. Crompton)
D. Crompton Said:
>
>What you are seeing is perfectly normal in a DOS nos enviroment. The
>resolve code waits while it is getting a reply from either the local
>domain cache, the domain.txt file or a remote DNS. If you send a mail
>message or messages the lookup of the names can take a considerable
>amount of time if the names are at the end of a long domain.txt file
>OR if the DNS response time is long.
>
>This does not tie up nos. It just ties up the command session. Because
>the resolve int this case is not done in a seperate session. In contrast
>most other resolves, such as those in ping,ftp,telnet, are done in sessions.
>While the resolve is going on you can hit F10 and go back to the command
>session.
No, this is not what happens. I'll describe it more detail. Let's
say I have four messages in the mail queue read to get fired out.
I'll kick the smtp server, or the timer goes off. It immediately
hoses up. Only the first message gets a lock file, the timer
processes stops running. This is easy to see as all session never
completely close, and all AT jobs have their scheduled time move
forward constantly. (Since they have a delta time from the current
time, and they're never decremented, the scheduled time continues to
move forward with the system time.)
The console and all other sessions seem to block output until either a
change in session screens is made or the output queue gets full. For
example, I could enter a command on the console screen, say mbox past.
Keystrokes do not echo, and the command does not appear to run.
Pressing say the F9 key and then F1 back to the console shows the
command did run, and output is their. A long command, such as socket,
will show all be the last couple of lines of the socket output, until
the F9/F1 shift is made.
NOS never recovers from this state. It continues to work, but since
sessions never completely close, the memory is never freed. Even the
exit command exits NOS, but it never drops to the DOS prompt.
The above problem happens sporadically. I've been able to repeat the
problem on the same email message several times (each reboot). Then
suddenly it will work as it should. I am reasonably sure that the
problem is a smtp/dns issue that stops the timer process.
>I have not looked at the smtp/bbs mail code but I do not see why this could
>not be done in a session also, so that the command session could still run.
>I never gave it much priority here. I have a fast system and the delays even
>to my internet DNS are minor.
I have NOS running on a 386SX and I'm 9600bps into the Internet. It's
not DNS delays on lookups.
>
>For speed the key points are to keep you domain.txt file short and to have
>the most used entries FIRST in the file. Also running the domain.txt file
>in a ramdisk helps. To do this in JNOS, in your config.sys/autoexec.bat
>configure a ramdisk, copy domain.txt to it, and tell nos in the nos.cfg
>file to use the new disk for domain lookups.
I've seen DNS queries that put garbage into the domain cache as well.
FYI, I'm using the domain server at NIC.MR.NET and the DNS at the
University of Minnesota.
>If you are using a DNS and the lookup times are very long or unreliable
>perhaps you should pick up the master domain file from ucsd and select out
>the entries you use most often, keeping them in a local domain.txt file. Just
>remember that the lookup is in your local cache and file first.
>
>On the subject of domain.c, I have added a 'domain query <DNS> <HOSTID>'
>which allows lookup at any DNS of a name which DOES NOT update the local
>cache (or domain file). This is handy to see what a particuliar site
>returns for a name.
This sounds useful. Will it look up MX records as well?
>
>Also a request was made to be able to 'ping' from a bbs login. I added this
>and K2MF added pinging from the sysop exit of the BBS. You can now SEE the
>response.
>
73
--
Jeff White, N0POY MECC Senior Programmer
INTERNET: jwhite@hydra.n0poy.ampr.org ICBMNET: 45^2', 93^13'
SKIPNET: n0poy@tcman.#msp.mn.usa.noam USENET: jwhite@cuscus.mecc.mn.org
PHONENET: 612-569-1714
------------------------------
Date: Tue, 14 Dec 1993 11:56:13 -0400 (EDT)
From: "Brian A. Lantz" <BRIANLANTZ@delphi.com>
Subject: VC vs Datagram
To: TCP-Group@UCSD.Edu
Let me just preface this that there are no flames, holy war feelings, or
religion in these notes. Just a different opinion and different experiences.
(Steve Sampson) writes:
> This doesn't work over
> Net/Rom (Net/Rom is obsolete so we don't care) but does over Rose. Rose can't
> handle very many fragments though. It can handle about two, and after that
> it falls on it's [expletive]ing face (as normal). AX.25 segmentation is too
> slow, so it's not a design issue any more.
I beg to differ with these opinions, from long-term, personal experience.
First, fragmentation over ROSE does NOT die after a few frames. We have
(for about a year) been using 1K frames fragmented by NOS, passed by ROSE,
and getting excellent results.
NOTE: ROSE 3.4 has a bug with one of it's timers that crept in, which CAN
effect timing. Anyone who needs me to look in my notes as to WHICH one of
the timers it is, send me a note. (or W2VY@RAM.COM).
As for it being slow, that has not been the case with our usage. Not only
is it AS fast, but by placing the IP headers in only the first frag, the
data % is much higher.
> My personal experiance with datagram
> is that I wouldn't hessitate to send a 1 Meg file over 9600, but I don't even
> send 2k over a VC path.
Well, yesterday we passed 2 files over ROSE, in VC mode, over one of our
WORMHOLES (which runs between Tampa and Dallas). The WORMHOLE piece is FAST,
but most of the other (about 24 switches, if memory serves me correctly)
is 1200 baud. The first file was over 300K, the second over 700K.
The first file transferred (not at a lightning speed) with no problem at all.
The second one had a problem which brought down the link at about 450K. It
was resumed (with the FTP "rput" command) and completed with no problems at
all.
Like all things worthwhile, it takes time and patience to get the desired
goals. ROSE is far from perfect, but at the present time it seem to be the
best overall solution, at least for the needs of the Tampa Local Area
Network. Tom promises datagram support in the future and is very responsive
to making ROSE and IP work together as efficiently as possible.
(Karl Klarsen) writes:
> The guys using ROSE could use netrom and should, but the sysops of nodes
> never could figure out how to control the route part of The Net.
In order to support NETROM/THENET, etc. it takes roughly 40K of NOS
support code. To support ROSE it takes 0K. No special code necessary.
I disagree that ROSE users SHOULD use netrom. Why use something that
requires additional programming when you have something available that
is invisible to the programmer?
> So when you hams that tell me my network is crummy and should be
> replaced come up with time and money to change it I will be pleased. In
> the mean-time stop running down what we have!
Here, here!! Diversity leads to changes, changes lead to better things.
Stagnation leads to the current state of packet radio. Let's re-start
experimentation, exploration, and innovation. Let's find inexpensive
ways to increase speed, efficiency, ease of use, and flexibility!
73 from Brian A. Lantz KO4KS@KO4KS.#TPAFL.FL.USA.NA 3100813105
Internet: brianlantz@delphi.com
Amprnet: ko4ks@ko4ks.ampr.org [44.98.0.167]
------------------------------
Date: Tue, 14 Dec 1993 19:46:49 -0600 (CST)
From: ssampson@sabea-oc.af.mil (Steve Sampson)
Subject: VC vs DG (not Viet Cong)
To: TCP-Group@UCSD.Edu
> I beg to differ with these opinions, from long-term, personal experience.
> First, fragmentation over ROSE does NOT die after a few frames. We have
> (for about a year) been using 1K frames fragmented by NOS, passed by ROSE,
> and getting excellent results.
I still wonder what the difference would be by putting a 386bsd (the free
Unix version) or Net386, or NOS box at each end of the Wormhole and just
passing IP packets instead of connecting, sending a packet, acknowledging a
packet, and disconnecting. The TCP layer seems a better place for all that
connection stuff I would think?? Rose need not even be in the picture if
NOS to NOS is what you're trying to achieve.
> NOTE: ROSE 3.4 has a bug with one of it's timers that crept in, which CAN
> effect timing. Anyone who needs me to look in my notes as to WHICH one of
> the timers it is, send me a note. (or W2VY@RAM.COM).
That version has been giving alot of problems locally. Nodes are locking up
and acting more of a sink than a source of packets :-) Hopefully the 512k ROM
version will be out soon and fix these problems. After working with a switch
for a while and seeing all the stuff you have to do to configure these things,
It would be nice just to burn them into ROM rather than reload-reload-reload
every time they crash. (I don't mean they crash often, but they don't reset
themselves, you have to reload them). This is a long awaited change.
> As for it being slow, that has not been the case with our usage.
OK, slow is a bad term - I would quantify slow as anything greater than 1.7
seconds to ship 256 bytes per node at 1200 bps. Given this formula, your 700k
file should have taken an hour and twenty minutes times 24 nodes, or 32 hours.
Anything longer would be overhead time. (this is off the cuff - your mileage
may vary...) So 32 hours and one minute would be slow :-) 9600 bps would be .21
seconds per node or 10 minutes times 24 nodes or four hours. So anything over
four hours is slow.
> Well, yesterday we passed 2 files over ROSE, in VC mode, over one of our
> WORMHOLES (which runs between Tampa and Dallas). The WORMHOLE piece is FAST,
> but most of the other (about 24 switches, if memory serves me correctly)
> is 1200 baud. The first file was over 300K, the second over 700K.
Well yes, telephone packeting is faster than radio. Let me rephrase by
saying I wouldn't hesitate to send a 1 Meg file over 9600 DG mode, or by
full duplex telephone at any speed in VC or DG mode :-)
---
Steve
------------------------------
Date: Tue, 14 Dec 1993 07:45:10 -0600 (CST)
From: ssampson@sabea-oc.af.mil (Steve Sampson)
Subject: X-1 Routing 101
To: TCP-Group@UCSD.Edu
> The question is: From those who have practical experience in configuring
> X1J and using its various features, how would one configure the nodes
> in such a network?
The way I would do it is to create a subnet scheme for the whole state
(probably already done) where you can route all packets N, S, E, W based
on the first three bytes of the address at each node. For example on the
9600 regional node you would have an ARP and route to the 1200 node connected
serially, and on the 1200 node, an ARP and route to ship EVERYTHING to the
co-located 9600 node (route add 44/8). The 9600 node 44.XX.2.1 then would
have an ARP and route to the next 9600 neigbor nodes in the system (for
example one north 44.XX.1/24 and one south 44.XX.3/24, and one east
44.XX.10/24. The object here is to NOT have 20 routes in each node, but a
couple routes which point IP packets in the right direction.
At most large towns you can find one user to run a JNOS and substitute them
for X-1 nodes. These can be used for more sophisticated features such as DNS
and mail using a simple KISS TNC. But you could just stick an X-1 on the NOS
box also. The way I experimented was to have 2 X-1's tied together on a diode
matrix, and the NOS box tied into the junction. The X-1 was run in KISS mode
rather than NRS, and the X-1 was set to pass all packets not destined for its
own callsign. In this way my NOS could go down and not interfere with packet
routing of the X-1 switches (9600<->1200 switch). This opens up a weird
possibility that a person could actually connect to the 9600 switch from the
1200 side without first connecting to the 1200 switch (since the 1200 passes
all packets not addressed to it). I don't see any advantage here though.
In summary, the ARP and route design is the only important design problem, as
you want to minimize the entries. As IP users pop up, they just put a route
add default in to the nearest switch, and the switches have subnet schemes
that use 24 bits to decide which switch should be the next hop.
---
Steve
------------------------------
End of TCP-Group Digest V93 #323
******************************
******************************