Date: Tue, 9 Feb 93 04:30:10 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 #38
To: tcp-group-digest
TCP-Group Digest Tue, 9 Feb 93 Volume 93 : Issue 38
Today's Topics:
?? WAMPES ??
BM conflict with 386MAX?
ISOLAN Cards under packet drivers.
Multi-Port RSPF (3 msgs)
New ax25?
nos bug query (2 msgs)
Nos for a Data General 1
NOS TEXT
Problem??
RE: Multi-Port RSPF (2 msgs)
RSPF
stat
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: Mon, 8 Feb 93 19:52:31 MET
From: "Giancarlo Pernici" <PERNICI@mammolo.cnuce.cnr.it>
Subject: ?? WAMPES ??
To: tcp-group@ucsd.edu
I am searching the latest wampes version... where could I find it ?
at ucsd.edu there is only version 92/11: is it the last ?
Thank you for your response
Regards
Giancarlo
+----------------------------------------------------+------------------+
|Internet : PERNICI@MAMMOLO.CNUCE.CNR.IT (preferred)| |
| IW5CZT@RADIO-GW.CNUCE.CNR.IT | SPACE FOR RENT |
|AmprNet : IW5CZT@IW5CZT.AMPR.ORG | HERE! |
|PacketMail: IW5CZT@IW5CMM.#PI.ITA.EURO | |
+----------------------------------------------------+------------------+
------------------------------
Date: Tue, 9 Feb 1993 07:17:27 -0500 (EST)
From: pascoe@rocky.ndhm.gtegsc.com (Dave Pascoe)
Subject: BM conflict with 386MAX?
To: tcp-group@ucsd.edu
Has anyone else seen a conflict between BM.EXE and the 386MAX memory
manager? Every time the notifier "New mail for km3t has arrived
from..." appears on the screen, my machine hangs up. I don't have
this problem when running EMM386 and I've stripped all TSR's out for
testing but the problem persists. Can anyone suggest a fix or where
to look next?
--
Dave Pascoe KM3T
Internet: pascoe@rocky.ndhm.gtegsc.com
------------------------------
Date: Mon, 8 Feb 1993 13:37:15 +0000 (GMT)
From: kelvin@thed.uk22.bull.com (Kelvin J. Hill)
Subject: ISOLAN Cards under packet drivers.
To: tcp-group@ucsd.edu
Hi all,
I've just been given a couple of ISOLAN 4110 boards to play with
and I've found the packet driver software for them.
What I don't have, is any information about the cards jumper settings etc.
Is there anyone out there with a user manual for the boards that could
e-mail me the configuration settings and any other information that I
would need to get these boards running up under NOS. Failing that, does
anyone have a contact point with BICC (the manufacturers) that I could
use to get the required info.
All/Any help very welcome.
Kelvin. (G1EMM)
------------------------------
Date: Sun, 7 Feb 93 22:06:00 -0800
From: Phil Karn <karn@qualcomm.com> (Phil Karn)
Subject: Multi-Port RSPF
To: tcp-group@ucsd.edu
At 7 Feb 1:39 -0500 (EST), MIKEBW@ids.net (Mike Bilow, ) wrote:
|RSPF actually doesn't fit into the layering model very well. Network
|routing is really at least a Network layer function, and it can be
|debated as to whether it should be considered a Transport layer function.
|However, a routing protocol is necessarily bound to the Network layer,
|in that RSPF becomes non-sensical unless it is used to route IP frames.
Well, maybe it doesn't fit into the ISO layering model very well,
but that doesn't mean it can't be done in a simple and elegant fashion.
Lots of real networks (one might say all!) don't fit into the ISO layering
model very well!
All you need is multiple network layers. That's the core idea of the Internet.
The upper network layer in the Internet is IP. Below IP you can have simple
links, or you can have entire complex networks. All IP expects (at least
traditionally) is a virtual subnet that appears to be fully connected. How
that network provides that internal connectivity is irrelevant. It could be
inherent, as in an Ethernet, or it could be an ARPANET, with its own
internal routing and network management algorithms. IP knows (or knew)
nothing about ARPANET, and ARPANET knew nothing about IP. They're distinct.
There's already precedent for this in AMPRNET: running IP atop NET/ROM. The
only problem is that NET/ROM itself is broken. All you have to do is to throw
it away and reinvent it properly.
The remainder of your post is simply a proof by contradiction (though you
may not realize it) that packet radio needs a distinct network layer.
Forget for the moment about IP and ARP. Just build a connectionless packet
radio network with callsigns as addresses, a link state algorithm for
routing, and in the end you'll actually support IP that much better.
Phil
------------------------------
Date: Mon, 8 Feb 93 9:59:09 CST
From: andyw@aspen.cray.com (Andy Warner)
Subject: Multi-Port RSPF
To: goldstein@carafe.enet.dec.com (k1io, FN42jk 07-Feb-1993 0016)
Fred wrote:
> Andy Warner asks,
> >> The RSPF problem is not restricted to multi-homed hosts, where the host
> >> [...]
> >> getting permanently locked and such.
>
> >So, the only currently available platform that would want or need
> >RSPF can't have it, is that the abridged version ?
>
> It's not _only_ useful on multi-homed hosts. Because radio networks are
> never "fully connected" like Ethernets, it's possible for one station to
> hear two others who don't hear each other. RSPF allows that kind of
> one-channel routing. That part actually works halfway decently in the
> existing V2.1 code.
The fact that it won't work on multi-homed hosts pretty much breaks it.
There is some suggestion that if the various ports of a switch use
different addresses the RSPF should work as-is, my experience says
otherwise (but that could be my fault).
--
andyw.
andyw@aspen.cray.com Andy Warner, Cray Research, Inc. (612) 683-5835
------------------------------
Date: Mon, 8 Feb 93 16:37:57 GMT
From: Michael Chace <mikec@praxis.co.uk>
Subject: Multi-Port RSPF
To: tcp-group@ucsd.edu
>>>>> Regarding RE: Multi-Port RSPF; Phil Karn <karn@qualcomm.com> (Phil Karn) said:
Phil> The remainder of your post is simply a proof by contradiction (though you
Phil> may not realize it) that packet radio needs a distinct network layer.
Phil> Forget for the moment about IP and ARP. Just build a connectionless packet
Phil> radio network with callsigns as addresses, a link state algorithm for
Phil> routing, and in the end you'll actually support IP that much better.
As far as I can see, most of that in its basic form has
already been done. It's called FlexNet and is prevelent
(over NET/ROM) in Germany and other middle European
countries. Pity that they seem to be TCP/IP haters though :-)
Mike
****
------------------------------
Date: 09 Feb 1993 10:10:17 +1100
From: CCDRW@cc.newcastle.edu.au
Subject: New ax25?
To: tcp-group@ucsd.edu
Phil says:
>................ that packet radio needs a distinct network layer.
>Forget for the moment about IP and ARP. Just build a connectionless packet
>radio network with callsigns as addresses, a link state algorithm for
>routing, and in the end you'll actually support IP that much better.
>
Yes, I think most of us agree AX25 needs replacing, lets experiment! with
something new.
I guess we have to define our problem a bit more and then we can start working
on it.
We want to reuse existing TNC's (KISS mode)
We (due to regulations) need to use callsigns as our Physical Address.
We know a link state algorithm would be better for routing.
etc...
Dave VK2XPX.
Internet | ccdrw@cc.newcastle.edu.au
Amprnet | vk2xpx@vk2xpx.ampr.org
------------------------------
Date: Mon, 8 Feb 93 10:48:02 PST
From: "Erik Olson" <erik@marge.phys.washington.edu>
Subject: nos bug query
To: karn@ucsd.edu, tcp-group@ucsd.edu
Hi again,
I'm noticing while running nos 930104 (plus nifty-new-alpha-test-lpd, and
same-old-pop3 server, added in myself) that eventually all files will appear
(according to nos) to vanish! The only way to make them "come back" is to
exit and restart NOS.
I'm wondering if anyone else has started playing with the new code and
reported similar problems...the reason being that if someone has then I
don't have to be worryin' about lpd or pop3.
Thanks for any help you can give here.
Erik Olson
---
erik@marge.phys.washington.edu at home via ReptarNet(tm)
------------------------------
Date: Mon, 8 Feb 93 14:12:28 -0800
From: Phil Karn <karn@qualcomm.com> (Phil Karn)
Subject: nos bug query
To: karn@ucsd.edu, tcp-group@ucsd.edu,
"All files will eventually "disappear"? What do you mean by that, exactly?
You might try the "files" command to see if somehow stdio file descriptors
are being gobbled up and not released before they run out.
By the way, I generally configure DOS to allocate LOTS of file handles.
A busy NOS machine can use plenty of them, especially now that each
session opens a temporary file for screen scrollback.
Phil
------------------------------
Date: Mon, 8 Feb 93 11:26:05 PST
From: marv%trnet2@dot.ca.gov (Marv Hanely)
Subject: Nos for a Data General 1
To: tcp-group@ucsd.edu
Does anyone know where I can get a copy of NOS which will run on an old
Data General 1 (512K & duel 720kb floppy drives). I just can't get myself to
throw away something that still works.
Also can anyone provide any insight on a device driver which will allow
standard modem software to access the non-standard serial port of same.
Marv Hanely, N6XML
Internet address marv%trnet2@dot.ca.gov
------------------------------
Date: Mon, 8 Feb 93 09:48:31 EST
From: crompton@NADC.NAVY.MIL (D. Crompton)
Subject: NOS TEXT
To: arne@hppcgelo.grenoble.hp.com
Arne,
Yes I think it would be good to look into. I had in mind using a
ramdisk with code optimized to read the always openned file FAST -
randomly.
Doug
------------------------------
Date: Mon, 8 Feb 93 10:08:57 EST
From: crompton@NADC.NAVY.MIL (D. Crompton)
Subject: Problem??
To: tcp-group@ucsd.edu
I discovered something whn I was porting the Xmodem code into NOS that
has me scratching my head....
I have a socekt that is in binary mode with no automatic flushing. So
in the code I did this..
for(...,...,...){ /* do this 128 times (1 block) */
read a byte from a sector array
put_one(the byte);
}
put_one(...){
usputc(...);
usflush(...);
}
In doing this I discovered that a large chuck of core was engulfed
when this segment was executed. The answer and the proper way was to
not flush the socket on each character but instead at the end of the
for loop. Running the former code more than 50K of core was taken. Using
the code below no or little additional core was taken. The memory taken
from core is returned to available and the next time it is run it does
not take more core but it just seems strange for this to happen. It
would seem that this could possibly happen in other cases in NOS.
for(...,...,...){
read a byte from array
usputc(...,byte);
}
usflush(...);
My question is why does this happen. It is very consistent. The
repeat command allows dynamic viewing of this happenning! This
is WG7J107B with my added repeat.
Doug
------------------------------
Date: Mon, 8 Feb 93 09:07:45 EST
From: kz1f@RELAY.WESTBORO.LEGENT.COM
Subject: RE: Multi-Port RSPF
To: andyw@aspen.cray.com, tcp-group@ucsd.edu
I had verified with Fred my contention that to establish a multi-channel switch
(gateway) with seperate IP addresses with for each port would work. Yes, there
could be problems is a station appeared on two freqs at abt the same time. The
solution there is simple, dont do that. If the switch is set properly to handle
the n number of ports, an individual station need not switch freq to contact
the other station. Something else to consider is that all stations should not
be running it either, this would be akin to all workkstations providing their
own routing. Generally there is a gateway machine chosen to handle that
function and all others add route through it. Walt
Walt Corey - kz1f@kz1f.legent.com
----------------------------------
| |
| Space for Rent apply within |
| |
----------------------------------
------------------------------
Date: Mon, 8 Feb 93 09:07:45 EST
From: kz1f@RELAY.WESTBORO.LEGENT.COM
Subject: RE: Multi-Port RSPF
To: andyw@aspen.cray.com, tcp-group@ucsd.edu
I had verified with Fred my contention that to establish a multi-channel switch
(gateway) with seperate IP addresses with for each port would work. Yes, there
could be problems is a station appeared on two freqs at abt the same time. The
solution there is simple, dont do that. If the switch is set properly to handle
the n number of ports, an individual station need not switch freq to contact
the other station. Something else to consider is that all stations should not
be running it either, this would be akin to all workkstations providing their
own routing. Generally there is a gateway machine chosen to handle that
function and all others add route through it. Walt
Walt Corey - kz1f@kz1f.legent.com
----------------------------------
| |
| Space for Rent apply within |
| |
----------------------------------
------------------------------
Date: Mon, 8 Feb 93 09:30:27 EST
From: kz1f@RELAY.WESTBORO.LEGENT.COM
Subject: RSPF
To: tcp-group@ucsd.edu
I think there are two issues here.
1) Was/is Fred's model correct/workable/feasable. This falls into some
particularly esoteric stuff.
2) Is RSPF usable? On a single node station? On a multi-node station?
This is the issue I have been pursuing. There has been a long standing
"conventional wisdom" that rspf doesnt work on a multinode switch/gateway.
I disagree (within some bounds). If one takes the Comer/Stevens approach where
each freq is functionally equivalent to multiple networks than each needs its
own addr. With this approach I can route to a station on the other band by
using the other half/third/whatever of the gateway as a hop. My experience has
been that most people stay put on a band, perhaps there are those that switch
bands like stations on a TV. If so they are in trouble, until someone devises
quantum routing. There has also been the charge that rspf takes up an
inrodinate amt of bandwidth. If every individual station runs it, it does. In
the RI area I would guess rspf traffic accounts for abt 80% of the traffic
sent, NETROM advertisments take most of the rest of it. With the foolish "Mail
for" broadcasts one has a near saturated freq, (I digress) If rspf where
relegated to only switch/gateway stations this traffic would be
dramatically reduced. Each individual station would then do a route default to
the switch. So anyways, I dont think the dialog surrounding topic 1 negates the
usability issues of topic 2. Walt
Walt Corey - kz1f@kz1f.legent.com
----------------------------------
| |
| Space for Rent apply within |
| |
----------------------------------
------------------------------
Date: Mon, 8 Feb 93 11:06:11 EST
From: kz1f@RELAY.WESTBORO.LEGENT.COM
Subject: stat
To: tcp-group@ucsd.edu
Doug writes -
> Here we go again.... can someone summarize the status of the STAT function.
> I.E. where it works where it does not and possibly why? If I remember the
> blame was never squarely placed with Borland? It sure would make life a lot
> easier if it could be used in NOS.
What I consider almost the paramount issue is that stat() is not an ansi
function. With all the compiler vendors falling all over themselves to be ansi
compliant I wouldnt write any code that depended on non-ansi functions. What
needs to be looked at is what the infomation desired really is. The domain
code's use of stat() info is different than is needed elsewhere. Depending on
what info is required there should be a "standard" method of obtaining it. And
if not standard certainly safe. Walt
------------------------------
End of TCP-Group Digest V93 #38
******************************
******************************