Date: Wed, 3 Feb 93 04:30:15 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 #34
To: tcp-group-digest
TCP-Group Digest Wed, 3 Feb 93 Volume 93 : Issue 34
Today's Topics:
FAQ
MAIL
Multi-Port RSPF
rcs and source
route lookup
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: Wed, 03 Feb 1993 09:03:28 EST
From: Khaled BOUAZIZ (IRSIT/TUNISIE) <bouaziz@spiky.rsinet.tn>
Subject: FAQ
To: tcp-group@ucsd.edu
hello Networkers,
I am looking for the Frequently Asked Questions in this list
Can anyone help me getting them.
Thank you very much.
khaled.... bouaziz@spiky.rsinet.tn
------------------------------
Date: Tue, 2 Feb 93 06:23:00 -0600
From: steve.williams@aquila.com
Subject: MAIL
To: trout.nosc.mil!ucsd!TCP-Group@netcom.com
Please discontinue mailing services for baxter to our address. We do
not have anyone by that name in our organization.
Thank you.
Steve
Aquila BBS
----
+-----------------------------------------------------------------------+
| Aquila BBS * Aurora, IL * 32 Nodes and Still Growing |
| 708-820-8344 (12/2400) 708-898-5672 (USR HST) 708-820-8805 (V32BIS)|
+-----------------------------------------------------------------------+
------------------------------
Date: Tue, 2 Feb 1993 20:29:37 -0500
From: goldstein@carafe.tay2.dec.com (k1io, FN42jk)
Subject: Multi-Port RSPF
To: tcp-group@ucsd.edu
The only captive implementations of RSPF do not handle multi-port
correctly. These are (what you might call) loose interpretatations
of the RSPF 2.1 spec.
Version 2.2 of the protocol spec explicitly handles multiple ports.
However, KA9Q's IP layer software gets in the way, so there have
been no straightforward implementations. In fact, none are complete.
I would sure like to see some C whiz finish an RSPF2.2.
THe "trouble" is that radio isn't like a LAN, so you can't simply
assume that a link is good because it's nominally within a subnet.
So RSPF tests the links. BUt you can't test the link unless it's
in the IP ROUTE table, in KA9Q, and you shouldn't put it on the
ROUTE table unless it has been tested... A valid implementation
has to get around that. I consider RSPF to be within the network
layer, with IP, and thus allowed to bypass IP Route. But that's
not the way NOS assumes layering.
fred k1io
------------------------------
Date: Tue, 2 Feb 93 17:25 GMT
From: <DEVANS%COLOLASP.BITNET@CORNELLC.cit.cornell.edu>
Subject: rcs and source
To: tcp-group@ucsd.edu
I can see why Phil likes RCS. However, it seems an awful lot of duplication
of effort for a bunbch of us all to have to build RCS on our systems
and then individually apply it to Phil's files to generate the source code
to build NOS. Surely one kind person could do that and then upload the
most recent version of Phil's code after it has passed through RCS? Then
the rest of us could simply download the source without having to
bother about RCS.
Doc NQ0I
SPAN: ORION::DEVANS
Internet: devans@orion.colorado.edu
BITNET: devans@cololasp.bitnet
Snail: Radiophysics, Inc., 5475 Western Ave., Boulder, CO 80301
Analogue switching network: +1 303 447 9524
Digital picture switching network: +1 303 447 8632
Non work related may go to:
TCP/IP: nq0i @ nq0i.ampr.org; nq0i @ [44.20.0.3]
AX.25: NQ0I @ NQ0I.#NECO.CO.USA.NA
------------------------------
Date: Wed, 3 Feb 93 10:05:43 GMT
From: A.D.S.Benham@bnr.co.uk
Subject: route lookup
To: TCP-Group@UCSD.Edu
I've noticed something strange in JNOS 107b - if I do a "route lookup g9zzz"
where 'g9zzz' is reached by my default route it displays:
ult tnc0 P 1 man
rather than starting 'default'.
A quick wander through the code this morning shows that (comparing with
JNOS 1.01) 4 bytes have been added to the routing entries (is this to do
with sorting the routes ..--..) and that this is taken into account in the
various routines.... *except* in 'dumproute' (IPCMD.C) for the default route.
I =think= the (a ?) fix is to replace
cp = "default"; by
cp = " default";
in 'dumproute', but I didn't get time to try this before leaving for work.
I'm now wondering if a similar problem lurks elsewhere - a few of us have
tried RSPF with 1.07b over the past few days. Every so often a route "ult"
appears at the head of the display produced by "route" (in addition to the
"default" entry at the tail of the list. More importantly, once RSPF is
enabled (and routing messages are received) our versions of JNOS become very
fragile- one version reboots (with 'usvprintf' buffer overruns), my version
just hangs after an hour or so.
I'll investigate further, but if anyone has any experiences with RSPF I'd be
pleased to hear of them.
73,
Andrew Benham
--------------------------------------------------------------------
adsb@bnr.co.uk BNR Europe Ltd, London Road, Harlow, Essex CM17 9NA
+44 279 402372 Fax: +44 279 402100
Home: g8fsl@g8fsl.ampr.org [44.131.19.195] G8FSL@GB3XP
--------------------------------------------------------------------
------------------------------
End of TCP-Group Digest V93 #34
******************************
******************************