Date: Wed, 19 May 93 04:30:21 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 #129
To: tcp-group-digest
TCP-Group Digest Wed, 19 May 93 Volume 93 : Issue 129
Today's Topics:
Any ***phunnies*** with JNOS1.09???
BPQ
BPQ406f Released
CD ROM with NOS
gateway list
KA9Q Flavor Supporting CD-ROMs??
New WAMPES version
NOS support for other drives (2 msgs)
RE: BPQ
WAMPES ported to SVR4
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, 18 May 93 21:36:12 mdt
From: ka7oei@uugate.wa7slg.ampr.org
Subject: Any ***phunnies*** with JNOS1.09???
To: tcp-group@ucsd.edu
Here at UUGATE (The Salt Lake Gateway) we are testing JNOS1.09
(Yes, we know: No warranties of any kind, either expressed or implied...)
and (at least I) have noticed something *strange* that happens occasionally.
Randomly, and for no apparent reason, the gateway will suddenly close the
connection.
I have 'memory threshold' set to 10240, but I don't think that that would
cause it since I didn't think it would affect already-running
processes...
I'm not sure, but it seems to happen most when it "get" memory from
"coreleft"... That is, if "coreleft" is already near the bottom,
it won't do it...
This would mean that when memory "avail" hit rock-bottom and more was
grabbed from "coreleft" it sometimes blows things up...
Any thoughts?
===========================================================================
"Me thinks, therefores me is..."
KA7OEI - Clint Turner, Salt Lake City, Utah
ka7oei@ - uugate.aim.utah.edu or - uugate.wa7slg.ampr.org
***
------------------------------
Date: Tue, 18 May 1993 10:27:11 -0400 (EDT)
From: MIKEBW@ids.net (Mike Bilow, <MIKEBW@ids.net>)
Subject: BPQ
To: iiitac@pyr.swan.ac.uk, tcp-group@ucsd.edu
The whole point about netrom is that there is no spec. If someone wants
to add a couple of bytes to the end of a connect request, who has the
standing to tell him he can't? It's not like TCP/IP, where there are
formal standards documents. Where conflicts occur in netrom, there is
no objective way to determine which side is at fault.
This problem is far more serious in hidden issues, such as acknowledgment
protocol or timer variation, than it is with frame structure. However, I
often find incompatibilities that depend on frame structure. For example,
NOS often had a habit of not bothering to set "don't care" fields to any
particular value, assuming they would be ignored. It turns out that every
other implementation of netrom that I tested actually sent "don't care"
fields set to zero. Naturally, somebody decided to program one of the
TheNet revisions to require that "don't care" fields be zero, breaking it
for use with NOS. By any reasonable measure, NOS is in the right, since
"don't care" ought to mean what it says, but the user perception is that
the network works with everything except NOS -- and it is only within my
control to fix this in NOS rather than TheNet.
These problems of "Oops! We didn't think of that!" have occurred in other
settings. The way AX.25v2 frames are distinguished from AX.25v1 frames
depends on an implementation kludge using the C bits. Phil Karn came up
with the clever observation that there were some implementations of AX.25v1
where the C bit were 00 and others where the C bit were 11, but no one ever
set them to 10 or 01. As a result, you assume that you are dealing with
AX.25v2 when the C bits are complementary. Of course, once the idea was
developed, it was writted into the protocol standard, so now we are
obliged to follow it. These kinds of things happen in netrom time and
time again, but there is no protocol document to use for an arbiter.
-- Mike Bilow, <mikebw@ids.net> (Internet)
N1BEE @ WA1PHY.#EMA.MA.USA.NA (AX.25)
------------------------------
Date: Mon, 17 May 93 22:17:19 GMT
From: g4klx@g4klx.demon.co.uk (Jonathan Naylor)
Subject: BPQ406f Released
To: TCP-Group@ucsd.edu
I'm sorry if you've already seen this, but I posted this a few days ago and it
never appeared in any TCP Group that I have received since.
John has produced a new version of his code 4.06f. This is the relevant entry
from CHANGES.BPQ:
:
:Fixes a bug in 4.06e which prevented access to the node via a digipeater.
:
:Adds a driver to allow two or more BPQ nodes to be linked via Ethernet (see
:section on ODIDRV in DRIVERS.DOC)
:
I have uploaded it into the incoming directory at ucsd.edu.
73's
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: Tue, 18 May 93 18:27:11 EDT
From: ron@chaos.eng.wayne.edu (Ron Atkinson - N8FOW)
Subject: CD ROM with NOS
To: tcp-group@ucsd.edu
The code that was used for the Buckmaster CD ROM with NOS has a CDROM
command that's used to designate the drive designator. When the code was
first put into JNOS you were able to FTP into the CD ROM, but later, for
some mysterious reason, the code to allow that was removed. If the
drive was S: then you can have something like:
anonymous * s: 59
n8lfj ian /pub;s: 59
in the ftpusers file. The first would allow you to FTP directly into
the CD ROM. The second would put the user in the /pub directory of their
hard disk (or floppy or whatever) and they would have to enter cd s: to
change to the CD ROM. I used to set up another hard drive on my
system and put a message of the day on the ftp that told how to access it.
Still a mystery why the code was removed from the latter JNOS releases
since it was handy.
Ron N8FOW
------------------------------
Date: 19 May 93 09:09:00 GMT
From: Jon Jagger <J.R.Jagger@sheffield-hallam.ac.uk>
Subject: gateway list
To: tcp-group@ucsd.edu
Cna anyone tell me if there is a list dedicated to packet gateways
(radio <-> internet is the area of interest), and if so what it
is called.
Thanks
JJ
:: Jon Jagger J.R.Jagger@shu.ac.uk
:: Sheffield Hallam University, Pond Street, SHEFFIELD S1 1WB
:: Tel 0742 533802/432889 (work/home) Fax 0743 533840
:: Newspaper ad: Men wanted for expanding contracting company!
------------------------------
Date: Tue, 18 May 93 10:22:54 EDT
From: tegra!vail@uunet.UU.NET (Johnathan Vail)
Subject: KA9Q Flavor Supporting CD-ROMs??
To: uunet!UCSD.Edu!TCP-Group@uunet.UU.NET, moore@email.ncsc.navy.mil
moore@email.ncsc.navy.mil (Moore) writes:
Someone pointed me to this list as the folk to ask for a flavor of
KA9Q-NOS that supports a change drive command under FTP, so that (for
instance), I can hook up a CD-ROM to the KA9Q server and let people
pull files off the CD-ROM disc. Is this a FAQ? Can someone point me
to a compiled version that'll handle this? I'm interested in Ethernet
interface, don't really care about mail or pop.
I have hacked a couple of NOS files to allow a DOS drive specification
to be used. It allows you to specify a CDROM drive or even a floppy
for use with FTP, etc. I can post the diffs or ftp an executable
somewhere if there is interest. I used a N1BEE version of GRI NOS.
jv
_____
| | Johnathan Vail vail@tegra.com (508) 663-7435
|Tegra| jv@n1dxg.ampr.org N1DXG@448.625-(WorldNet)
----- MEMBER: League for Programming Freedom (league@prep.ai.mit.edu)
------------------------------
Date: Tue, 18 May 93 11:08:06 MDT
From: Dieter Deyke <deyke@mdddhd.fc.hp.com>
Subject: New WAMPES version
To: tcp-group@ucsd.edu
I have uploaded a new version of WAMPES (wampes-930518.tar.Z) to
UCSD.EDU. This version should solve the Net/Rom compatibility problems
of WAMPES.
Please keep this distribution for reference, my plans are to distribute
new versions of WAMPES as patches to this 930518 base code.
This is the README file:
------------------------------------------------------------------------
wampes-930518.tar.Z is a compressed tar archive of WAMPES, which is a
NET/NOS port to HP-UX. It currently supports HP 9000 series 300, 400,
700, and 800 computers, running HP-UX 08.xx or HP-UX 09.xx.
I also ported the software to SunOS 4.1.2 and to 386BSD 0.1.34, and it
compiles there, but I do not have enough time to really test it.
Feedback is welcome.
WAMPES was also ported to Linux running on a 386 by Olaf Erb, dc1ik. He
also ported it to ULTRIX 4.2A on a Decstation 5000 with gcc 2.3.3, but
it wasn't tested properly, too. Comments and questions about the Linux
and Ultrix port of WAMPES please to Olaf Erb,
<erb@insu1.etec.uni-karlsruhe.de>.
To unpack this archive you should create the directory /tcp and cd to
it. After unpacking please read the file /tcp/doc/intro.txt.
wampes-930518.tar.Z and all followups should go into
/hamradio/packet/tcpip/wampes on UCSD.EDU.
73,
Dieter Deyke, DK5SG / N0PRA, <deyke@fc.hp.com>
-------------------------------------------------------------------------------
Now it's here!
This is the documentation for the RISC iX (Acorn R260 etc) port of
DK5SG's Wampes.
To install it, unpack the archive in a directory named /tcp. Then copy
the files *.R into /usr/lib (you must be root of course). Then cd to
/tcp/src, run make (without arguments...) and ignore the compiler
warnings...
To compile convers, cd to /tcp/convers and run make.
I hope, the port is 100 percent correct. It works here at least :-)
Have fun with it.
73 de Felix, dl6sdc. For bug reports and questions related to the RISC
iX port please mail to
BBS-Net: dl6sdc@db0sao.deu.eu
Amprnet: dl6sdc@db0sao.ampr.org
Bitnet: uk1o@DKAUNI2
Internet: uk1o@ibm3090.rz.uni-karlsruhe.de or
s_schroeter@irav1.ira.uka.de
For questions related to Wampes in general please mail to Dieter
although i would really try to answer such a question too.
------------------------------
Date: Tue, 18 May 1993 21:34:43 +1000
From: Terry Dawson <terryd@extro.ucc.su.OZ.AU>
Subject: NOS support for other drives
To: tcp-group@ucsd.edu
>Someone pointed me to this list as the folk to ask for a flavor of
>KA9Q-NOS that supports a change drive command under FTP, so that (for
>instance), I can hook up a CD-ROM to the KA9Q server and let people
>pull files off the CD-ROM disc. Is this a FAQ? Can someone point me
>to a compiled version that'll handle this? I'm interested in Ethernet
>interface, don't really care about mail or pop.
Actually, I'd quite like to see an implementation of the approach that
has been taken by some companies that produce pc based NFS servers,
that being for the drive to be prepended to the filepath as top level
directory.
for example:
c:\pub\filename.txt
becomes
/c/pub/filename.txt
much more elegant in my opinion, and it doesn't break any existing
software at all.
Terry
------------------------------
Date: Tue, 18 May 93 10:03:59 -0700
From: karn@qualcomm.com (Phil Karn)
Subject: NOS support for other drives
To: tcp-group@ucsd.edu, terryd@extro.ucc.su.OZ.AU
>that being for the drive to be prepended to the filepath as top level
>directory.
>for example:
>c:\pub\filename.txt
>becomes
>/c/pub/filename.txt
>much more elegant in my opinion, and it doesn't break any existing
>software at all.
>Terry
For ordinary local DOS drives, you can use the DOS "join" command to
do exactly this. Unfortunately, CD-ROM drivers are implemented as
network drives, and you can't join this (at least under DOS 5.0).
Anybody know if this same restriction exists in 6.0?
Phil
------------------------------
Date: Tue, 18 May 93 20:24:10 MST
From: w6swe@w6swe.tapr.org (Bob Nielsen)
Subject: RE: BPQ
To: tcp-group@ucsd.edu
In message <930518102711.63d3@ids.net> mikebw@ids.net writes:
>The whole point about netrom is that there is no spec. If someone wants
>to add a couple of bytes to the end of a connect request, who has the
>standing to tell him he can't? It's not like TCP/IP, where there are
>formal standards documents. Where conflicts occur in netrom, there is
>no objective way to determine which side is at fault.
>
>This problem is far more serious in hidden issues, such as acknowledgment
>protocol or timer variation, than it is with frame structure. However, I
>often find incompatibilities that depend on frame structure. For example,
>NOS often had a habit of not bothering to set "don't care" fields to any
>particular value, assuming they would be ignored. It turns out that every
>other implementation of netrom that I tested actually sent "don't care"
>fields set to zero. Naturally, somebody decided to program one of the
>TheNet revisions to require that "don't care" fields be zero, breaking it
>for use with NOS. By any reasonable measure, NOS is in the right, since
>"don't care" ought to mean what it says, but the user perception is that
>the network works with everything except NOS -- and it is only within my
>control to fix this in NOS rather than TheNet.
>
>These problems of "Oops! We didn't think of that!" have occurred in other
>settings. The way AX.25v2 frames are distinguished from AX.25v1 frames
>depends on an implementation kludge using the C bits. Phil Karn came up
>with the clever observation that there were some implementations of AX.25v1
>where the C bit were 00 and others where the C bit were 11, but no one ever
>set them to 10 or 01. As a result, you assume that you are dealing with
>AX.25v2 when the C bits are complementary. Of course, once the idea was
>developed, it was writted into the protocol standard, so now we are
>obliged to follow it. These kinds of things happen in netrom time and
>time again, but there is no protocol document to use for an arbiter.
About three years ago I visited John Wiseman, G8BPQ and he told me that he
had put some hooks in his code which would allow some improved functionality
if we ever got to a point where only his code was being used, but it would
not be compatible with NetRom. Could it be that he may have used some of
the "don't care" bits for this? He didn't pass on any details (not that I
would have understood them anyway).
------------------
Bob Nielsen, W6SWE Internet: w6swe@tapr.org
Tucson, AZ Amateur IP: 44.124.12.16
AX.25: w6swe@wb7tls.az.usa.na
------------------------------
Date: Tue, 18 May 93 9:09:03 CDT
From: dave@holl.com (David Vrona)
Subject: WAMPES ported to SVR4
To: tcp-group@UCSD.EDU
Hi all,
Just a notification to let you know that I have WAMPES running on my SVR4 box.
I'm putting together a list of changes for the author. Hopefully he will
incorporate them in a future release.
dave
--
David Vrona N9QNZ +1 708 680 2829 (voice)
Hollister Incorporated +1 708 918 3860 (fax)
2000 Hollister Drive Internet: dave@hp1.holl.com
Libertyville, IL 60048-3781 UUCP: {well connected}!ddsw1!hp1!dave
Opinions expressed are my own and not those of Hollister Incorporated.
------------------------------
End of TCP-Group Digest V93 #129
******************************
******************************