Date: Wed, 10 Feb 93 04:30:11 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 #39
To: tcp-group-digest
TCP-Group Digest Wed, 10 Feb 93 Volume 93 : Issue 39
Today's Topics:
?? WAMPES ??
AmigaNOS help needed.
ANSI stat()
Book on NOS!
Death of AX.25
G3RUH modem vs Direct FSK modems
Gaithesburg Md
New ax25? (4 msgs)
new firmware?
nos bug query (3 msgs)
PE1CHL
Problem??
stat (5 msgs)
Wampes
Wampes latest version
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, 9 Feb 93 9:48:07 MST
From: Dieter Deyke <deyke@mdddhd.fc.hp.com>
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 ?
92/11 is in fact the latest "released" WAMPES version. I am making a
lot of changes to WAMPES right now, and I won't "release" the new
version until it is stable enough.
Dieter, N0PRA / DK5SG
------------------------------
Date: Tue, 9 Feb 93 13:47:08 CST
From: andyw@aspen.cray.com (Andy Warner)
Subject: AmigaNOS help needed.
To: tcp-group@ucsd.edu (TCP Group)
If there are any AmigaNOS gurus who are willing to help
an Amiga ignoramus, please email me. I have a few
questions to ask.
Thanks,
--
andyw.
andyw@aspen.cray.com Andy Warner, Cray Research, Inc. (612) 683-5835
------------------------------
Date: Tue, 9 Feb 1993 10:32:03 -0600 (CST)
From: MSgt S. Sampson <ssampson@sabea-oc.af.mil>
Subject: ANSI stat()
To: TCP-Group@UCSD.Edu
Re: STAT, pg 482 Borland C++ 2.0, stat is available on Unix systems and is
defined in ANSI C. I must have missed something, but stat() works fine on
Unix, Coherent, and DOS. I uploaded a message and file that offered a fix
for that (ftpserv.c%v) but now I'm wondering if I'm missing something?
Is stat() not available on some operating system?
------------------------------
Date: Tue, 09 Feb 1993 11:24:13 EST
From: "Russell Nelson" <nelson@crynwr.com>
Subject: Book on NOS!
To: tcp-group@ucsd.edu
Yeah! Finally! Ian Wade, g3nrw, wrote a book on NOS. I don't know
enough about amateur radio to say if it adequately describes the
AX.25, PBBS, and NET/ROM stuff. I can say for sure that it explains
things I never understood before.
-- quoting Ian Wade:
Re promoting the book, I am talking with a couple of potential
distributors in the US right now. In the meantime, it's available
by mail order (VISA/Mastercard/Eurocard) at the following prices:
UK 12.85 GB pounds
Europe 14.42 GB pounds
Americas, Africa 16.73 GB pounds
Rest of world 17.34 GB pounds
With the present depressed value of the pound, the Americas
price works out at about $24.00 plus credit card company currency
conversion charges.
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* Ian Wade Email: ianwade @ dircon.co.uk. *
* Dowermain Ltd g3nrw @ dircon.co.uk. *
* Maxet House, Liverpool Road AX.25: G3NRW @ GB7BIL.#27.GBR.EU. *
* LUTON, Beds LU1 1RF, UK AMPRnet: g3nrw.ampr.org. [44.131.5.2] *
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
-- end quoting Ian Wade:
--
-russ <nelson@crynwr.com> What canst *thou* say?
Crynwr Software Crynwr Software sells packet driver support.
11 Grant St. 315-268-1925 Voice | LPF member - ask me about
Potsdam, NY 13676 315-268-9201 FAX | the harm software patents do.
------------------------------
Date: Tue, 9 Feb 1993 10:33:17 -0600 (CST)
From: MSgt S. Sampson <ssampson@sabea-oc.af.mil>
Subject: Death of AX.25
To: TCP-Group@UCSD.Edu
Dave VK2XPX states:
> Yes, I think most of us agree AX25 needs replacing, lets experiment! with
> something new.
I did, I call it SLIP over TNC (TNCSLIP). It basically bypasses AX.25 and
does raw IP over the air. Is it useful? Probably not.
The problem is that you cannot have third party traffic on unspecified codes
in the US. There is a precedent that we can use to do this anyway though.
Pactor is an unspecified code, but the FCC doesn't care. So my feeling is
that we go ahead and use whatever we want (Ethernet, JTIDS, TDMA, CSMA, etc).
When we decide how we want the rules to read we just let the FCC know and
they'll publish it. Until then I don't think they really give a damn nor
should we. I'm not totally radical on this sort of anarchy, but in this case
changing an useless protocol to something better (as in the Pactor case)
improves communication and is therfore more important than waiting for the
ARRL to get off their RTTY ass.
---
Steve, N5OWK
------------------------------
Date: 10 Feb 1993 11:22:10 -0500 (Wed)
From: Steve_Wright@kcbbs.gen.nz (Steve Wright)
Subject: G3RUH modem vs Direct FSK modems
To: tcp-group@ucsd.edu
Since there isn't a group specifically for packet RF bits (yet), may I ask
this question in this excellant forum ...
ahem ..
what are the pro's and con's of direct FSK modems (G3RUH compatible)
compared to the original RUH design which uses an EPROM lookup table.
regards,
Steve - ZL1BHD <- 'Big Hard Disk'
------------------------------
Date: Tue, 9 Feb 93 14:27:52 EST
From: kz1f@RELAY.WESTBORO.LEGENT.COM
Subject: Gaithesburg Md
To: tcp-group@ucsd.edu
Hi all, sry for the out of band request but does anyone know of
amateur tcp activity in the Gaithesburg Md/Rockville Md/Hearndon Va area.
I will need to know who to get in touch with down there, as that will (should
soon be home. Well, if you must know, Sterling, Va. tnx, Walt
Walt Corey - kz1f@kz1f.legent.com
------------------------------
Date: Tue, 9 Feb 1993 13:43:50 -0500
From: chk@alias.com (C. Harald Koch)
Subject: New ax25?
To: CCDRW@cc.newcastle.edu.au
> 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.
While that may be easy for you and me (Australia/Canada), the US FCC has
stupid regulations about only allowing AX.25 packets in many situations. I
don't remember the details; could some knowledgable American fill in the
details?
--
Main's Law: For every | C. Harald Koch Alias Research, Inc. Toronto, ON
action, there is an equal | chk@alias.com (work-related mail)
and opposite goverment | chk@gpu.utcs.utoronto.ca (permanent address)
program. | VE3TLA@VE3OY.#SCON.ON.CA.NA (AMPRNet)
------------------------------
Date: Wed, 10 Feb 93 14:15:49 +1100
From: wkt@csadfa.cs.adfa.oz.au (Warren Toomey)
Subject: New ax25?
To: CCDRW@cc.newcastle.edu.au, tcp-group@ucsd.edu
In atricle by CCDRW@cc.newcastle.edu.au:
>
> 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...
Ok, well start by replacing the CSMA Medium Access Control. How about
some form of Token Ring?
Next, modify the packet format to have no repeater fields, just source
and destination. How easy would it be to `pack' a callsign into 32 bits?
This means about 5 bits per char, plus two bits leftover (4 SSIDs?)
Sounds impossible.
If anyone's interested, I typed out some ideas on a Token Ring-ish MAC.
These can be picked up via anon ftp to minnie.cs.adfa.oz.au, cd gateways,
bin, get pktcircl.ps or get pktcircl.tar. The latter should have the LaTeX
source, so if you can't read PostScript you can live with the ASCII.
73,
Warren vk1xwt
------------------------------
Date: Wed, 10 Feb 93 16:47:03 +1100
From: wkt@csadfa.cs.adfa.oz.au (Warren Toomey)
Subject: New ax25?
To: CCDRW@cc.newcastle.edu.au, tcp-group@ucsd.edu
In atricle by CCDRW@cc.newcastle.edu.au:
>
> 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.
Ok, well start by replacing the CSMA Medium Access Control. How about
some form of Token Ring?
Next, modify the packet format to have no repeater fields, just source
and destination. How easy would it be to `pack' a callsign into 32 bits?
This means about 5 bits per char, plus two bits leftover (4 SSIDs?)
Sounds impossible.
If anyone's interested, I typed out some ideas on a Token Ring-ish MAC.
These can be picked up via anon ftp to minnie.cs.adfa.oz.au, cd gateways,
bin, get pktcircl.ps or get pktcircl.tar. The latter should have the LaTeX
source, so if you can't read PostScript you can live with the ASCII.
73,
Warren vk1xwt
------------------------------
Date: Wed, 10 Feb 93 09:11:33 GMT
From: Alan Cox <iiitac@pyr.swan.ac.uk>
Subject: New ax25?
To: CCDRW@cc.newcastle.edu.au, tcp-group@ucsd.edu
We _DONT_ have to use callsigns for physical routing. We have to
carry callsign information, it would be quite valid to send it
as a tcp option field. Carrying that kind of information properly
as opposed to netrom which fails to regularly identify the true
source/destination user (only source/dest node) of a link.
Not only that but all the BBS traffic can easily get hold of
the callsign tcp option , or more likely extra tacked onto ip
field.
Alan
------------------------------
Date: Tue, 09 Feb 1993 10:37:23 PST
From: "Jeffrey D. Angus" <jangus@skyld.tele.com>
Subject: new firmware?
To: tcp-digest@ucsd.edu
> Date: 09 Feb 1993 10:10:17 +1100
> From: CCDRW@cc.newcastle.edu.au
> Subject: New ax25?
> To: tcp-group@ucsd.edu
>
> 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.
KISS Mode? The only things that would have to stay constant while re-using
existing TNCs are the BELL-202 modem and the 8530 HDLC. Everything else is
firmware and can be done in a more suitable manner. The biggest problem you
will face is convincing those who are resistant to change. (An example of
this are those that somehow connect the Coast Guard's dropping of CW as the
death of Amateur Radio) If you really want to stir things up and "push the
envelope" have it written up in the new spec to have the "old" ax.25 phased
out over a 2 year period. This would accomplish two things. First it would
force the issue, and secondly, the manufacturers would love it.
73 es GM from Jeff
--
netcom!bongo!jangus@skyld.tele.com "Als ik Kan", Gustav Stickley
US Mail: PO Box 4425 Carson, CA 90749-4425 1 (310) 324-6080
------------------------------
Date: Mon, 8 Feb 93 14:12:28 -0800
From: Phil Karn <karn@qualcomm.com> (Phil Karn)
Subject: nos bug query
To: 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: 9 Feb 93 09:17:07 CST
From: "Chris Cox W0/G4JEC" <CHRISC@ramrod.lmt.mn.org>
Subject: nos bug query
To: erik@marge.phys.washington.edu, tcp-group@ucsd.edu
> 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.
I have seen similar results. I compiled the new nos using Turbo C
2.0, and so I suspect the problem lies in Phil's super-duper
replacement for the standard TC file table.
I haven't verified this, however. I too would like a solution
because, in terms of performance (at least over ethernet), it blows
the socks off of the older releases. The symptoms I saw was that
after running for a while and having about 17 file descriptors open
(according to the status display), I would soon be unable to access
any file from a new session. Therefore, the mailbox, ftp, smtp, etc.
sessions would fail (you couldn't login, as /ftpusers became
unreadable).
Anyone come up with a solution?
Chris W0/G4JEC
Twin Citieas Metro Area Network
tcman.ampr.org
Chris Cox W0/G4JEC chrisc@lmt.mn.org
Network Administrator NIC handle: CC345
LaserMaster Technologies Tel: (612) 944-6069
7156 Shady Oak Road Fax: (612) 944-5544
Eden Prairie, MN 55344
----- For mail of a more social nature, please use -----
Internet: chrisc@moron.vware.mn.org
Amprnet: chrisc@biggus.g4jec.tcman.ampr.org
------------------------------
Date: Tue, 9 Feb 93 09:57:12 PST
From: "Erik Olson" <erik@marge.phys.washington.edu>
Subject: nos bug query
To: karn@qualcomm.com, tcp-group@ucsd.edu
Okay, more details, since it choked on me again.
>"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.
The "files" command shows only 4 open files at time of choking for me.
I'm going to try debugging open/close pairs or the like to see if there's a
noticable error in either.
Erik
---
Erik Olson (at work) erik@marge.phys.washington.edu
University of Washington olson@phys.washington.edu
Cosmic Ray Lab, Phys. 405
------------------------------
Date: Tue, 09 Feb 1993 08:39:06
From: ccmcgone@mtu.edu (Charles McGonegal - N8OKM)
Subject: PE1CHL
To: tcp-group@ucsd.edu
I'm looking for the 921018 version of PE1CHL.Net for both PC and Atari ST.
I was told they used to be on ucsd.edu in the hamradio\packet\tcpip\incoming
directory, but I coundn't find them there, or in the \pe1chl directory.
Any idea where they went, or if they are available elsewhere?
Charles McGonegal
ccmcgone@mtu.edu
------------------------------
Date: 09 Feb 1993 10:44:30 -0500 (EST)
From: "Brian A. Lantz" <BRIANLANTZ@delphi.com>
Subject: Problem??
To: tcp-group@ucsd.edu
> My question is why does this happen. It is very consistent. The
The first thought off the top of my head is that the usflush is probably
terminating a "mbuf", causing a separate mbuf structure to be allocated
for each character.
I can't verify this. I have not "poked" around in mbufs that much.
If gut feelings count, give it extra consideration.
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, 9 Feb 93 12:11:17 EST
From: crompton@NADC.NAVY.MIL (D. Crompton)
Subject: stat
To: kz1f@legent.com
Walt,
The reason I would like to use the stat function is to determine if
a pathname is a directory or file. The access() funtion will determine
if a name is valid but not if it is a file or directory. Also without
stat the only way to determine a filesize is to actually open the file
I think? Phil is using the stat function in his code. Johan removed all
occurences from his a few months ago. My question was were is the blame
and why can't it be made to work - is it a Borland problem?
Doug
------------------------------
Date: Tue, 9 Feb 1993 10:42:53 -0800 (PST)
From: Bruce Perens <bruce@pixar.com>
Subject: stat
To: tcp-group@ucsd.edu
On Mon, 8 Feb 1993 kz1f@RELAY.WESTBORO.LEGENT.COM wrote:
>
> What I consider almost the paramount issue is that stat() is not an ansi
> function.
There is no ANSI C _standard_ function that provides information
equivalent to that provided by stat(). ANSI C does not provide any
standard for system calls, only for the simple file I/O that would be
done by "operating system naive" programs.
POSIX provides a standard for operating system calls. I don't have a
reference for the POSIX standard here, but I suspect it specifies
fstat(). This is a common source of confusion - many people expect
services from ANSI C that are actually a part of POSIX.
Phil Karn started working on NET before ANSI C and POSIX were standards.
For NOS, he took as his standard the Berkeley Unix system calls, since
that was a well-known and reasonably well-designed interface to
networking. ANSI C and POSIX themselves borrow heavily from Berkeley Unix.
There are several ports of NOS to actual ANSI/POSIX-compliant
environments. I assure you that stat() was not a problem in those ports.
Bruce Perens
------------------------------
Date: Tue, 9 Feb 93 14:20:56 EST
From: kz1f@RELAY.WESTBORO.LEGENT.COM
Subject: stat
To: crompton@NADC.NADC.NAVY.MIL, kz1f@LEGENT.COM
Doug, I said that because,its true, stat() is not ansi and as such probably
wont be supported much longer in any compiler version. I would suggest a
findfirst() and see if the dir flag is set. I acknowledge its not ansi either
but does support a different flag settings field. Walt
Walt Corey - kz1f@kz1f.legent.com
@kz1f.legent.com
------------------------------
Date: Wed, 10 Feb 93 09:18:25 GMT
From: Alan Cox <iiitac@pyr.swan.ac.uk>
Subject: stat
To: crompton@NADC.NAVY.MIL, kz1f@legent.com
stat can be a bit funny on Borland 3.0 - stat of a drive root fails
for example. Also stat on a novell directory reports both the file
and directory bits being set. You just trust the directory one.
I don't know if 3.1 fixed these odd cases.
Thats my experience anyway with straight BC3.0 and no patches or
upgrades on it.
Alan
------------------------------
Date: Wed, 10 Feb 93 10:51:39 GMT
From: Alan Cox <iiitac@pyr.swan.ac.uk>
Subject: Stat
To: tcp-group@ucsd.edu
stat() I somehow think will stay in all of the compilers for a long time
its in POSIX, and its unix since somewhere near day 1. I'd also suggest not
using findfirst() but using opendir() closedir() and readdir() which are
_standard_ directory reading facilities.
ALan
------------------------------
Date: Wed, 10 Feb 93 09:15:39 GMT
From: Alan Cox <iiitac@pyr.swan.ac.uk>
Subject: Wampes
To: tcp-group@ucsd.edu
Having to use another machine for the job isn't the answer. The real
answer is decent kernel layer AX.25 and related support, or failing
that at least decent user layer support, rather than a prehistoric
version of NET.
Alan
------------------------------
Date: Tue, 09 Feb 93 16:41:05 CET
From: BARRY TITMARSH <BTITMARS%ESOC.BITNET@vm.gmd.de>
Subject: Wampes latest version
To: TCP-GROUP <TCP-GROUP@ucsd.edu>, pernici@mammolo.cnuce.cnr.it
As far as i can see local to me the laters version being used on a number
of official bbs's and local user to these bbs's is WAMPES-300193
But in contacting the Authors and proters of the code I have not had a
reply.
In direct mail to the Author and a German Ham who ports the code to Linux
I have only had short meaningless comments, which have given no indication
of If and or Ever the wampes 930130 version will or will not be released.
I had assumed that it had been infact released due to the Large number of
'Trusted users' in Germany actually seen on line with W-930130. The short
responce i recived was 'Its not for me to decide when to release the code,
Ask Deter the Author'
Personaly if you like to wast email bandwidth then Do that.
I have never had Any replies regarding Wampes.
For me as a Linux user I stopped useing it months ago as the UNIX offers far
more in the way of mail nntp smtp telnet and ftp and much much more.
Just use jnos wnos karn-nos your favorite-nos in a PC slip or ether to the UNIX
box.. Easy.
Barry.
------------------------------
End of TCP-Group Digest V93 #39
******************************
******************************