Date: Thu, 21 Oct 93 04:30:01 PDT
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 #273
To: tcp-group-digest
TCP-Group Digest Thu, 21 Oct 93 Volume 93 : Issue 273
Today's Topics:
NetRom standard
Network Standards (3 msgs)
slip/ppp problems in ka9q nos 930622? (2 msgs)
wd8003 & packet driver
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, 19 Oct 1993 17:38:38 PDT
From: "Jeffrey D. Angus" <jangus@skyld.tele.com>
Subject: NetRom standard
To: tcp-group@UCSD.EDU
> So, we translate the source comments. Du sollst wirklich eine
> zweite oder dritte Sprache lernen, mein Freund!
>
> Cheers,
> Fred "Hacker Alert" NL0WLT
But I already know a second or third language. And that other quote was Danish.
(I think) But Danish ain't in there with number 1-3.
Hummm, that "callsign" looks familiar, weren't you just involved in an, ahem,
pissing contest with Gerard recently?
73 es GM from Jeff, who at least left sexual preferences out of this posting.
--
Amateur: WA6FWI@WA6FWI.#SOCA.CA.USA.NA | "It is difficult to imagine our
Internet: jangus@skyld.tele.com | universe run by a single omni-
US Mail: PO Box 4425 Carson, CA 90749 | potent god. I see it more as a
Phone: 1 (310) 324-6080 | badly run corporation."
------------------------------
Date: Wed, 20 Oct 93 20:05:15 GMT
From: g4klx@g4klx.demon.co.uk (Jonathan Naylor)
Subject: Network Standards
To: TCP-Group@UCSD.EDU
In message <199310171130.EAA21574@ucsd.edu> you write:
> Date: Fri, 15 Oct 1993 14:18:17 -0500 (CDT)
> From: Steve Sampson <ssampson@sabea-oc.af.mil>
> Subject: Packet Radio Standards
> To: TCP-Group@ucsd.edu
>
> Since Net/Rom isn't marketed any longer, maybe the people
> involved in the X-1 and X-2 software can produce a The/Net
> specification, or at least commission those interested in
> it to build the specs from the current source code. Maybe
> the BPQ boys can take the same challenge. It would be nice
> to have it for historical purposes. I think a lot of the
> problems stem from holding any information close to the chest
> so others can't get ahead. The/Net, BPQ, and ROSE all suffer
> from closed development and mass popularity. The developers
> are basically programmers and not very good technical writers.
> A technical writer will probably need to approach them and offer
> their services.
For the sake of the standards I'll try and remember what the additional bytes
are in the BPQ NET/ROM Connect Request and Connect Acknowledge frames are.
>
> I say historical purposes because hams certainly don't want to
> be locked into these protocols 10 years from now. The connection-
NET/ROM and TCP/IP are both datagram protocols, that have an unreliable
Network Layer and have the reliability at the Transport Layer. I do hope you
are talking about AX25 and not NET/ROM. NET/ROM would quite happily ride on
top of UI frames if it were programmed that way.
> oriented protocols have been interesting experiments, they do work,
> but they fail the test of response speed, operation over range, and
> provide no solutions to common RF problems (gomers with talkies and
> antenna's on top of their refridgerator).
Does everyone remember how poor digi-peating was ? Do people remember the
bulletin from Tom Clarke W3IWI in 1988 (?) with the title similar to "Using
more that three digi-peaters doesn't work". With TCP/IP over a connectionless
Level 2 you have no advantage over digi-peating. I can only see use of a
connectionless Level 2 being an advantage on dedicated frequencies with very
few stations active, or on full duplex systems. I think AX25 or a variation
thereof, like having a byte each for the send and receive sequence numbers, to
allow large window sizes, as being with us for a long time.
> ---
------------------------------
Date: Wed, 20 Oct 93 20:05:15 GMT
From: g4klx@g4klx.demon.co.uk (Jonathan Naylor)
Subject: Network Standards
To: TCP-Group@ucsd.edu
In message <199310171130.EAA21574@ucsd.edu> you write:
> Date: Fri, 15 Oct 1993 14:18:17 -0500 (CDT)
> From: Steve Sampson <ssampson@sabea-oc.af.mil>
> Subject: Packet Radio Standards
> To: TCP-Group@ucsd.edu
>
> Since Net/Rom isn't marketed any longer, maybe the people
> involved in the X-1 and X-2 software can produce a The/Net
> specification, or at least commission those interested in
> it to build the specs from the current source code. Maybe
> the BPQ boys can take the same challenge. It would be nice
> to have it for historical purposes. I think a lot of the
> problems stem from holding any information close to the chest
> so others can't get ahead. The/Net, BPQ, and ROSE all suffer
> from closed development and mass popularity. The developers
> are basically programmers and not very good technical writers.
> A technical writer will probably need to approach them and offer
> their services.
For the sake of the standards I'll try and remember what the additional bytes
are in the BPQ NET/ROM Connect Request and Connect Acknowledge frames are.
>
> I say historical purposes because hams certainly don't want to
> be locked into these protocols 10 years from now. The connection-
NET/ROM and TCP/IP are both datagram protocols, that have an unreliable
Network Layer and have the reliability at the Transport Layer. I do hope you
are talking about AX25 and not NET/ROM. NET/ROM would quite happily ride on
top of UI frames if it were programmed that way.
> oriented protocols have been interesting experiments, they do work,
> but they fail the test of response speed, operation over range, and
> provide no solutions to common RF problems (gomers with talkies and
> antenna's on top of their refridgerator).
Does everyone remember how poor digi-peating was ? Do people remember the
bulletin from Tom Clarke W3IWI in 1988 (?) with the title similar to "Using
more that three digi-peaters doesn't work". With TCP/IP over a connectionless
Level 2 you have no advantage over digi-peating. I can only see use of a
connectionless Level 2 being an advantage on dedicated frequencies with very
few stations active, or on full duplex systems. I think AX25 or a variation
thereof, like having a byte each for the send and receive sequence numbers, to
allow large window sizes, as being with us for a long time.
> ---
> Steve N5OWK
Jonathan
+-------------------------------------+---------------------------------------+
| Internet: g4klx@g4klx.demon.co.uk | The three branches of Government: |
| Amprnet: g4klx@g4klx.ampr.org | Money, Television and Bullshit. |
| BBS: G4KLX @ GB7HMZ.GBR.EU | P.J.O'Rourke |
+-------------------------------------+---------------------------------------+
------------------------------
Date: Wed, 20 Oct 1993 22:20:23 -0400 (EDT)
From: MIKEBW@ids.net (Mike Bilow)
Subject: Network Standards
To: g4klx@g4klx.demon.co.uk, tcp-group@UCSD.EDU
I am not sure I would agree with your characterization of NET/ROM as a
datagram protocol. In theory, yes, you could send NET/ROM inside UI
frames, but you don't. Furthermore, every existing implementation of
NET/ROM would fail to operate with a system which embedded NEt/ROM
data inside UI frames.
Maybe it would be more accurate to say that NET/ROM is a virtual
circuit protocol with all the overhead of a datagram protocol? :-)
-- Mike Bilow, mikebw@ids.net
N1BEE @ WA1PHY.#EMA.MA.USA.NA
------------------------------
Date: Wed, 20 Oct 93 01:28 PDT
From: bob@nyssa.wa7ipx.ampr.org (Bob Finch)
Subject: slip/ppp problems in ka9q nos 930622?
To: tcp-group@ucsd.edu
I'm trying to get slip or ppp to work with ka9q nos version 930622.
It works for a while (30 seconds to a half a day or so) and then
hangs. I've tried various combinations of machines, serial ports,
both slip and ppp, and baud rates without any success.
It seems related to the amount of asy output -- If I telnet from the
remote end of the slip link through nos to a Unix box on the ethernet
and cat /etc/termcap, nos usually dies after a few seconds.
Most of the time it is a hard crash -- Ctrl Alt Del does not work.
Very rarely, the slip link hangs but nos is still alive. Poking
around with asystat shows no change in any of the tx stats when
pinging from nos out the slip link, but the rx stats do change with
pinging the other way.
Has anyone else found or fixed this problem?
Other irrelavent info:
Ethernet and 1200 baud kiss work fine
Used generic serial card and STB 4 port card (both with 16550s)
Tried it on a 16MHz 386SX and a 40MHz 386DX
Thanks in advance...
73 -- Bob
------------------------------
Date: Wed, 20 Oct 93 18:22:46 -0700
From: karn@qualcomm.com (Phil Karn)
Subject: slip/ppp problems in ka9q nos 930622?
To: bob@nyssa.wa7ipx.ampr.org
For what it's worth, I've had a dedicated NOS machine (first a 286-10,
now a 486-33) acting as a demand-dialed ethernet to SLIP router at
home for several years. It routinely stays up for months at a time,
despite daily use and heavy traffic (lots of file transfers, remote X
windows sessions, etc).
The most common cause of the box going down is me taking it down to
bring up a new revision. The second most common cause is a power
failure. I can't remember the last time it crashed.
One warning: if you use any kind of DMA driver in NOS along with QEMM,
you *must* specify LOCKDMA in the QEMM command line. Otherwise the
system will quickly hang. For some totally stupid reason, QEMM assumes
by default that when you disable interrupts, you really don't mean it.
Not a good assumption in my code.
Phil
------------------------------
Date: Mon, 18 Oct 93 09:26:00 EDT
From: "Patterson, Gary" <patterso@anser.org>
Subject: wd8003 & packet driver
To: tcp-group@ucsd.edu
What happens in a wd8003/packet driver environment when the wd8003 on board
packet buffers are full of incoming packets. Does the packet driver turn
"receive" off while the application processes the buffers or are the buffers
overwritten as another packet comes in (ie. the oldest buffered packet is
overwritten and lost), or none of the above? Thanks in advance for any help
on this. 73's
Gary M. Patterson AA4UR
patterso@anser.org
------------------------------
End of TCP-Group Digest V93 #273
******************************
******************************