Date: Tue, 26 Oct 93 04:30:02 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 #278
To: tcp-group-digest
TCP-Group Digest Tue, 26 Oct 93 Volume 93 : Issue 278
Today's Topics:
Convers Cacophony (5 msgs)
Dynamic IP Addressing (3 msgs)
Network Standards
packet driver, nos.lpd.1.13 and pcnfs.4.recent
TCP-Group Digest V93 #274
While we're at it
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, 25 Oct 1993 09:03:47 -0600
From: bob@ke9yq.ampr.org (Bob Van Valzah, ke9yq)
Subject: Convers Cacophony
To: tcp-group@UCSD.EDU, gateways@mpg.phys.hawaii.edu,
I've been searching for a good convers server to run on a Unix machine. So
far, I've found four people who publish such servers. Each server seems to
have features to recommend it over the others. At least one is at least
partially protocol incompatible with the others. Is there a protocol spec?
If so, please forward details to me.
This is a sad state of affairs in my opinion, especially considering the
size (100+ hosts) of the growing convers network run through the Internet
gateway system. Is anybody making an effort to bring these divergent bits
of convers back together so that it's easier for us all to benefit from the
technology? If so, please contact me.
Assuming that there is no spec and no convergence effort yet under way,
I'll try to at least review the different versions and detail what they
offer and where to get them. If I get really wrapped up in this (and if
the publishers are willing to cooperate) I may try to facilitate the
production of a merged version and perhaps even someday a spec.
If you have any "convers technology" to offer and you name isn't on this
list, then please drop me a note.
dl1bjl@df0od.et-inf.fho-emden.de (Matthias Wermann),
andyw@aspen.cray.com (Andy Warner),
wkt@csadfa.cs.adfa.oz.au (Warren Toomey),
Dieter Deyke <deyke@mdddhd.fc.hp.com>
Thanks & 73, Bob, ke9yq
------------------------------
Date: Mon, 25 Oct 93 10:04:59 MDT
From: Dieter Deyke <deyke@mdddhd.fc.hp.com>
Subject: Convers Cacophony
To: bob@ke9yq.ampr.org
> I've been searching for a good convers server to run on a Unix machine. So
> far, I've found four people who publish such servers. Each server seems to
> have features to recommend it over the others. At least one is at least
> partially protocol incompatible with the others. Is there a protocol spec?
> If so, please forward details to me.
>
> This is a sad state of affairs in my opinion, especially considering the
> size (100+ hosts) of the growing convers network run through the Internet
> gateway system. Is anybody making an effort to bring these divergent bits
> of convers back together so that it's easier for us all to benefit from the
> technology? If so, please contact me.
>
> Assuming that there is no spec and no convergence effort yet under way,
> I'll try to at least review the different versions and detail what they
> offer and where to get them. If I get really wrapped up in this (and if
> the publishers are willing to cooperate) I may try to facilitate the
> production of a merged version and perhaps even someday a spec.
>
> If you have any "convers technology" to offer and you name isn't on this
> list, then please drop me a note.
>
> dl1bjl@df0od.et-inf.fho-emden.de (Matthias Wermann),
> andyw@aspen.cray.com (Andy Warner),
> wkt@csadfa.cs.adfa.oz.au (Warren Toomey),
> Dieter Deyke <deyke@mdddhd.fc.hp.com>
>
> Thanks & 73, Bob, ke9yq
I have to leave for a business trip in a few minutes. I will try to
send an answer as soon as I am back.
Dieter
------------------------------
Date: Mon, 25 Oct 93 23:09:50 GMT
From: ron@chaos.eng.wayne.edu (Ron Atkinson N8FOW)
Subject: Convers Cacophony
To: tcp-group@ucsd.edu
At least the ping/pong convers author includes a file that has the
linking protocol information. A simple place to start is to go through
the source code for them and look for all the \377\200 lines and see
what convers server has what linking info and protocol. I did this
with JNOS after the ping/pong convers was running here on a Sun SPARC
so I could see what JNOS supports and doesn't support. Also since TNOS
has a lot of convers features I sent the author a list of the linking
commands, but I still havn't received the TNOS list from him yet to
try to add in JNOS or ping/pong. Oh well....
------------------------------
Date: Mon, 25 Oct 93 14:43:44 HST
From: Antonio Querubin <tony@mpg.phys.hawaii.edu>
Subject: Convers Cacophony
To: bob@ke9yq.ampr.org (Bob Van Valzah, ke9yq)
Sounds like convers needs something like an RFC written up :-).
Tony
------------------------------
Date: Tue, 26 Oct 93 10:51:22 +1000
From: wkt@csadfa.cs.adfa.oz.au (Warren Toomey)
Subject: Convers Cacophony
To: Antonio Querubin <tony@mpg.phys.hawaii.edu>,
In atricle by Antonio Querubin:
>
> Sounds like convers needs something like an RFC written up :-).
Please!
Warren vk1xwt
------------------------------
Date: Mon, 25 Oct 93 07:40:54 GMT
From: kf5mg@kf5mg.ampr.org
Subject: Dynamic IP addressing
To: tcp-group@ucsd.edu
Filename Size Date Time Device:Path
------------ ------- -------- -------- ----------------------------------------
FORWARD .ZIP 11485 10/14/93 17:46:29 \
110X3 .ZIP 1192136 07/08/93 12:08:14 \110X3
MYSRC104.ZIP 1308847 07/01/93 17:17:20 \SRC104
GNUINDNT.ZIP 163128 10/04/93 13:44:20 \FILES
JN110X3 .ZIP 944278 06/24/93 17:41:17 \FILES
MGNOS107.ZIP 965426 07/18/93 14:59:13 \FILES
BM332C .ZIP 52889 07/22/93 02:17:12 \FILES
NEW110X7.ZIP 166737 07/10/93 22:32:27 \FILES
JN110X5 .ZIP 936018 07/01/93 13:53:26 \FILES
MGNOSOBJ.ZIP 589559 07/18/93 15:05:07 \FILES
JN110X6 .ZIP 974249 07/08/93 11:29:08 \FILES
GREP15 .ZIP 269665 10/04/93 13:46:00 \FILES
JN110X10.ZIP 1001609 10/04/93 13:12:18 \FILES
POP3LZW .ZIP 10800 10/09/93 15:59:01 \FILES
NEW11 .ZIP 155083 10/08/93 02:21:12 \FILES
BUGFIX .ZIP 2738 10/08/93 02:22:28 \FILES
NEWX11 .ZIP 244365 10/12/93 12:30:01 \FILES
NEWX12 .ZIP 183983 10/21/93 11:30:16 \FILES
COMPRESS.ZIP 91060 10/18/93 07:21:22 \COMPRESS
FTPLZW .ZIP 4341 10/22/93 12:46:11 \X12
"\*.ZIP" matched 20 file(s).
Search Complete, 20 total files found.
73's de Jack - kf5mg ( running JNOS in a 735K - OS/2 2.1 Dos Box! )
Internet - kf5mg@kf5mg.ampr.org - 44.28.0.14
AX25net - kf5mg@kf5mg.#dfw.tx.usa.noam - home (817) 488-4386
Worknet - kf5mg@vnet.ibm.com - work (817) 962-4409
-------------------------------------------------------------------------
| "I am Homer of Borg.... Prepare to be assim.... oooo Donuts." |
-------------------------------------------------------------------------
------------------------------
Date: Mon, 25 Oct 93 11:59:35 GMT
From: kf5mg@kf5mg.ampr.org
Subject: Dynamic IP Addressing
To: tcp-group@ucsd.edu
Let me try this again.... upload the wrong file last time.
Someone suggested we look at doing some sort of dynamic IP Addressing
for a new, radio network project that we're starting to work on. A
majority of the users on the network will be part time users and will be
running nntp, smtp, and ftp clients. It seems like these users could be
assigned an IP Address each time they start a session with the network.
When the user terminates the session, the IP Address would go back
into the pool of temporary IP Addresses. I think that this would address
two problems. 1) New, part-time users on our network and 2). mobile IP
users that want to access the network from different locations.
Am I re-inventing the wheel looking at doing dynamic IP addressing?
Is there an RFC that covers stuff like this? Has anyone implemented this
in NOS yet? Does my reasoning seem flawed at all? Any info would be
appreciated.
73's de Jack - kf5mg ( running JNOS in a 735K - OS/2 2.1 Dos Box! )
Internet - kf5mg@kf5mg.ampr.org - 44.28.0.14
AX25net - kf5mg@kf5mg.#dfw.tx.usa.noam - home (817) 488-4386
Worknet - kf5mg@vnet.ibm.com - work (817) 962-4409
-------------------------------------------------------------------------
| "I am Homer of Borg.... Prepare to be assim.... oooo Donuts." |
-------------------------------------------------------------------------
------------------------------
Date: Tue, 26 Oct 1993 0:44:13 -0400 (EDT)
From: MIKEBW@ids.net (Mike Bilow)
Subject: Dynamic IP Addressing
To: kf5mg@kf5mg.ampr.org, tcp-group@UCSD.EDU
You might look at bootp, since the code for it is nominally already in
NOS. I don't know if the code works or not, but it might.
-- Mike
------------------------------
Date: Tue, 26 Oct 1993 0:30:49 -0400 (EDT)
From: MIKEBW@ids.net (Mike Bilow)
Subject: Network Standards
To: vk4grl@vk4grl.clayfield.ampr.org, tcp-group@UCSD.EDU
As has been pointed out many times before, the vc mode setting in NOS
really does not work right. Part of this is that the TCP layer does
error recovery much too aggressively, especially when using linear
instead of exponential backoff. However, it is impossible to know
much about the reliability of a path involving more than a trivial
number of relays, and these various relays may differe a great deal
in reliability from one to the next.
There are also some bugs in the AX.25 state machine code that affect
vc mode and also netrom. For example, NOS responds to a REJ frame
by resending the oldest unacknowledged frame immediately, which
might be appropriate for a RR frame but not for a REJ frame.
The ideal solution to this would be a routing protocol that measured
the end-to-end performance of a link in use and adapted its behavior
according to the results. Such a routing protocol does not exist.
Another problem with vc mode over a bad link is that it will cause
wide variations in the measured rtt for the link, screwing up the
use of Karn's Algorithm in the TCP layer. Since Karn's Algorithm
works by assuming that a frame will either be received in short
time or lost, and vc mode ruins this assumption, the measured mean
deviation will likely grow quite large.
-- Mike
------------------------------
Date: Mon, 25 Oct 93 16:27:06 PDT
From: efb@suned1.nswses.navy.mil (Everett F Batey)
Subject: packet driver, nos.lpd.1.13 and pcnfs.4.recent
To: tcp-group@UCSD.EDU
We have been trying to use a 286 Vectra ES12, pc-clone with
tcp-ip/lpd software known as KA9Q NOS 930507a ( included in
lpd.1.13 ) as a print server.
Our PC clients are running Sun PCNFS 4.recent.
When we load LPD we get a free: WARNING! invalid pointer (0x7a860010)
proc LPD listener lpd: spool directory (d) may not exist.
Any attempts to print from a PC complain that this PC Printhost IS not
running Sun PCNFSD Server.
Any / all bright ideas are real welcome.
/Ev/
------------------------------
Date: Tue, 26 Oct 1993 0:38:43 -0400 (EDT)
From: MIKEBW@ids.net (Mike Bilow)
Subject: TCP-Group Digest V93 #274
To: louie@uunet.uu.net, tcp-group@UCSD.EDU
I can't see why the assumption of a "fairly relaible link-level
protocol with minimal loss" required for VJ header compression
is not met by existing 1200 bps AFSK packet links.
Either a frame is correctly received or it isn't. If it isn't,
the FCS will cause rejection of the frame with extremely high
probability. Any frame which passes the FCS check is almost
certainly correctly received, and would therefore have a
perfectly good compressed header to be decoded.
I doubt that VJ header compression would give results any worse
than the existing systems which do not use it.
-- Mike
------------------------------
Date: Tue, 26 Oct 93 13:31:31 +1000
From: wkt@csadfa.cs.adfa.oz.au (Warren Toomey)
Subject: While we're at it
To: tcp-group@UCSD.EDU
Does anybody have/know of something like an RFC for the XLZW data compression
as used by many NOS flavours for SMTP mail transmission. Seems to me that
this is useful throughout the whole Internet, and not just the Amprnet. Patches
to sendmail for this also appreciated :-)
Warren vk1xwt
------------------------------
End of TCP-Group Digest V93 #278
******************************
******************************