| |
PA2AGA > TCPDIG 24.08.96 21:36l 156 Lines 6736 Bytes #-10909 (0) @ EU
BID : TCP_96_168A
Read: GUEST
Subj: TCP-Group Digest 96/168A
Path: DB0AAB<DB0MWS<DB0KCP<DB0CZ<DB0LX<DB0RBS<DB0SEL<DB0ZDF<DB0GV<DB0SIF<
DB0NHM<DB0SHG<DB0OBK<DB0ACC<PI8DRS<PI8DAZ<PI8APD<PI8GCB<PI8MBQ<PI8VNW
Sent: 960824/1528Z @:PI8VNW.#ZH2.NLD.EU #:54799 [Hoek v Holland] FBB5.15c
From: PA2AGA@PI8VNW.#ZH2.NLD.EU
To : TCPDIG@EU
Received: from pa2aga by pi1hvh with SMTP
id AA16031 ; Sat, 24 Aug 96 14:10:07 UTC
Received: from pa2aga by pa2aga (NET/Mac 2.3.61/7.1) with SMTP
id AA00003291 ; Fri, 23 Aug 96 20:24:20 MET
Received: from pa2aga-1 by pa2aga with SMTP
id AA00003251 ; Fri, 23 Aug 96 20:14:25 MET
Received: from pa2aga-1 by pa2aga-1 (NET/Mac 2.3.61/7.5.4) with SMTP
id AA00007890 ; Fri, 23 Aug 96 20:14:24 MET
Date: Fri, 23 Aug 96 20:04:04 MET
Message-Id: <tcp_96_168A>
From: pa2aga
To: tcp_broadcast@pa2aga-1
Subject: TCP-Group Digest 96/168A
X-BBS-Msg-Type: B
TCP-Group Digest Thu, 22 Aug 96 Volume 96 : Issue 168
Today's Topics:
DLPI, SLIP, etc. (Re: PPP/SLIP in connected AX25?)
Gracilis Packet Ten
PPP/SLIP in connected AX25? (5 msgs)
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 ftp.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: Wed, 21 Aug 1996 12:28:47 -0700 (PDT)
From: "Dana H. Myers" <myers@bigboy.West.Sun.COM>
Subject: DLPI, SLIP, etc. (Re: PPP/SLIP in connected AX25?)
[Phil Karn wrote:]
> > The over-the-air interface would then be PPP or SLIP in connected-mode
> > AX25 with PID F0. To distinguish this mode from conventional "dumb
> > terminal" (e.g., BBS) mode, the NOS router could either set aside a
> > separate AX25 SSID. Or it could get clever and look for the
> > distinguishing characteristics of a SLIP or PPP frame in the incoming
> > data, e.g., the leading C0 or 7E flag character. I understand that
> > some dialup IP routers/terminal servers already do this.
[Alan Cox replied:]
> It produces abominable results unless the TNC is very very smart and
> sends packets broken on the SLIP/PPP framing boundary only. If you do
> it connected mode you get horrible congestion problems as well. Routing
> the stuff when users keep reconnecting to the nearest site that looks
> the fastest becomes horrible as well.
>
> If you can get a windoze box talking SLIP to a serial port then the code
> in the TNC to do SLIP->AX.25 UI is not exactly difficult and that would
> seem a better path.
Last April, I prototyped a DLPI to AX.25 multiplex driver (DLPI is the
System V STREAMS interface to network devices) on Solaris 2.5 (SunOS 5.5).
Most of the work was not too difficult, as a DLPI driver receives the data
payload portion of a frame and creates the MAC header portion and
sends the frame out - on receive, the reverse happens. The primary
challenge I encountered had to do with ARP; in Solaris, there's an
ARP module that implements a generic ARP mechanism over DLPI drivers.
There were two main issues - (1) Solaris ARP currently assumes that
all network media uses 6 octet (byte) physical addresses and 2 octet
frame types and (2) the contents of an ARP frame are different for
AX.25 than Ethernet. So, I had to write functions that translate an
Ethernet ARP request into an AX.25 request and translate an AX.25
ARP reply into an Ethernet ARP reply. Not difficult, but a consideration
in using protocol stack that attempts to provide ARP services in a
media independent manner.
The other ARP problem is that the Solaris ARP module uses a fixed
timeout of 500mS with no way (that I could find) to tune it. So,
at speeds less that 9600 baud, I'd flood the channel with numerous
ARP requests until the answering station got a foot in the door - then
I'd get back a flood of answers. At 9600 baud this still happens but
it isn't as bad. At 56kbaud, it would not be an issue. To address
this, I add static ARP entries for stations I'm working, which defeats
the idea of ARP.
In order to handle the 7 octet AX.25 addresses as Ethernet addresses,
I take the 4 SSID bits and put them in the LSB of the first four address
octets (the address extension bits). When converting an Ether-form
address to AX.25, I construct the SSID octet from the LSBs, setting
the LSBs to 0.
So, this experience might help someone that wants to attach AX.25 to
an existing TCP/IP stack. There already is a paper from one of the
CNCs that describes a BSD implementation of the same idea, so a look
at that would be useful.
The prototype worked well, using another STREAMS module to do
KISS encoding/decoding of the raw frames from the DLPI driver, all
of this stacked onto the standard Solaris x86 asy driver. I sent
email and stuff, I ran netscape for giggles.... I have a local
9600 baud internet gateway.
I'm looking at how I can implement things like net/rom as layered
STREAMS modules on top of the AX.25 STREAMS driver, and, after a little
cleaning up of the prototype, publish this stuff in a CNC and make
the code available freely. If you're interested, please drop me a
note.
[Hint: any DLPI experts out there want to help me decide how to deal
with the connection-oriented services and AX.25?]
Dana KK6JQ
Dana@Source.Net
------------------------------
Date: Wed, 21 Aug 1996 19:42:43 +0800 (HKT)
From: "Victorio O. Ochave" <jojo@asti.dost.gov.ph>
Subject: Gracilis Packet Ten
I am involved in a project to put up mountain-top, stand-alone packet
switches/routers for research and academic institutions here in the
Philippines. I would like to hear about anybody's experiences with the
Gracilis Packet Ten switch, good or bad. I would also welcome any advice.
The network involves linking mountain-top relay sites with distances from
10 km. to 40 km. We intend to use P10's and GRAPES modems with DownEAst
Microwave transverters, but have also heard that spread-spectrum radios
may be an option, if these can handle the distances.
As an option to spectrum/allocation problems related to the use of GRAPES
modems and transverters (we do not have the 100 Khz, 220 Mhz channel
allocation here), we are also considering the use of Cylink
spread-spectrum radios to be driven by the P10's. Will we not have
interfacing problems with this set-up?
Feedbacks/advice will be most appreciated.
---------------------------------------------------------------
Victorio A. Ochave, Jr.
Communications Engineering Division
Advanced Science and Technology Institute (ASTI)
Department of Science and Technology (DOST)
4/F NEC Bldg., University of the Philippines
To be continued in digest: tcp_96_168B
Read previous mail | Read next mail
| |
