Date: Tue, 2 Mar 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 #58
To: tcp-group-digest
TCP-Group Digest Tue, 2 Mar 93 Volume 93 : Issue 58
Today's Topics:
Defining the link bits
GRI 2.0m and multiple FTP drives
Link Layer replacement (2 msgs)
New GothaMail Release
packet driver terminal program
RCS 5.6 available for MS-DOS
Uncle! UNCLE! (Problem with FTP on NET)
USCC Baycom Card
Use of fixed-length data fields considered harmful.
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, 1 Mar 1993 11:07:42 -0600 (CST)
From: Steve Sampson <ssampson@sabea-oc.af.mil>
Subject: Defining the link bits
To: TCP-Group@UCSD.Edu
Dave Horsfall says:
>> Host address length: 1 Octet
>> Destination address length: 1 Octet.
>
>Hmmm... What about following the length field with its complement,
>in case it gets corrupted?
That sort of reminds me of the Xmodem complements. In actual use they are
never used. If there was an error you need to resend the packet anyway,
so a CRC or FEC word will accomplish the same thing.
I don't know if I like all that callsign stuff in there. It's basically a
rider that only has to be sent on initial connect. Why send it over and over?
The Ethernet 48 bit address required a lot of administration of issuing and
assigning addresses to circuit cards. The designer stated he wished he would
have chosen 64 bits and they could have avoided all that bo-jive. Some have
proposed 256 bits, but that seems extreme and most of the bits will be zero
for the next 200 years. I think for speed that 64 bits should be sufficient.
I also don't want ascii characters flying around at the link layer. Move that
human oriented stuff up the stack. Maybe each end will pick a 64 bit random
number with their callsign and SSID as the key, and use that to identify the
computer for eternity... Speaking of random numbers, you could also start off
with that address and then run it through DES to get the next address. Maybe
a good way for authentication.
FEC Preamble: 8 octets (maybe more, I don't know)
Destination Address: 8 octets
Source Address: 8 octets
Packet type: 2 octets
Packet data: 0-65535 octets
---
Steve N5OWK
------------------------------
Date: Mon, 1 Mar 93 13:47:25 PST
From: "Jerzy Tarasiuk" <JT@zfja-gate.fuw.edu.pl>
Subject: GRI 2.0m and multiple FTP drives
To: RON MURRAY <NMURRAYR@cc.curtin.edu.au>
> Date: 26 Feb 1993 23:36:08 +0800
> Message-Id: <01GV715A0EOU9ODFQC@cc.curtin.edu.au>
> fred blahblah c:/files 127 d:/morefile 3 a: 1 b: 1
> and take the mailbox permissions from the first permissions field.
> It's quite possible that the code already does this; I must admit that I
As I remember my code does it. The extra permission fields are used for
file accesses only. And first matching directory is used, since cannot
set different permission for subdirectory of primary directory, e.g.
I use directory guest for anonymous login and want it to be read-only,
I cannot put read/write subdirectory guest/incoming in it, use ../in.
(if permcheck would look for longest match instead first, it would be
possible, but I had no time for coding it).
I don't see reason to make floppies accessible for FTP. If they weren't
specified in ftpusers, NOS wouldn't try to access them. 73's, JT
------------------------------
Date: Mon, 1 Mar 93 08:28:10 -0800
From: brian (Brian Kantor)
Subject: Link Layer replacement
To: tcp-group
Those packets seem kinda long to me. Remember, people, this isn't a
cable; very few bits in a row can get through before something hits them.
FEC is well and good, but depending on it to fix more than a few errors
per packet will demand a high price in bandwidth and complexity. We can
afford some of that, but let's not make it too 'expensive'.
- Brian
------------------------------
Date: Mon, 1 Mar 1993 13:49:41 -0800 (PST)
From: Bruce Perens <bruce@pixar.com>
Subject: Link Layer replacement
To: bsimpson@morningstar.com
On Sun, 28 Feb 1993, William Allen Simpson wrote:
> My suggestion for a header format would be 4 to 6
> octets shorter, by eliminating the length fields and re-arranging
> ...
> The Address fields would be comprised of octets in the range 32 to 122
> (blank to z). Other values might be legal, but would be escaped during
> transmission using standard procedures (see RFC-1331).
This seems to be a lot of trouble just to save two bytes. The proposal
also assumes that we want to use ASCII for addresses. I'd like to be
able to use "binary" information in addresses without a space penalty.
In this case, there would be a penalty of one escape character for each
byte that was outside of the range 32-122, and we would end up with
longer addresses rather than shorter ones. I also feel that the scheme
to vary the length of the protocol field is over-complicated for the
space it might save.
I'm curious as to why you think the framing information belongs in the
link-layer packet, and not the lower levels. We would like to use this
same packet with several different MAC layers tailored to different
radio environments, rather than just FEC transmission followed by a
16-bit checksum. Placing the frame termination and checksum at the link
level would be redundant if the MAC layer did more elaborate error
correction.
It is, however, a good idea for us to investigate the use of PPP over
radio. It may be that this pre-existing protocol fills our needs. Since
you, Bill, are an expert on the subject, perhaps you'd like to present
some more information on it.
Thanks
Bruce Perens
------------------------------
Date: Mon, 1 Mar 93 08:44:23 CST
From: anderson@cat.ATK.COM (Dean S. Anderson)
Subject: New GothaMail Release
To: tcp-group@ucsd.edu
I have uploaded a new version of GothaMail for Microsoft
Windows into ucsd incoming directory. It fixes several problems
in the handling of mail files. It still has a 10K-13K message
length limitation, however. If you are running any version
of GothaMail other than this one, get this one as soon as
possible. The file is gmail.zip.
73 de Dean Anderson, KA0MCM
anderson@cat.atk.com
or
ka0mcm%ka0mcm@skeggi.vware.mn.org
------------------------------
Date: 01 Mar 1993 23:35:47 -0500 (Mon)
From: Steve_Wright@kcbbs.gen.nz (Steve Wright)
Subject: packet driver terminal program
To: tcp-group@ucsd.edu
I'm looking for a simple Terminal Program that will attach a packet driver.
I can attach the device using NOS without any trouble, but I want a simple
terminal program to use for testing.
Has anyone heard of such a program ? Could someone XXmail it to me...
Also, what ever happened about the packet driver for centronics parallel
ports someone mentioned ?
Thanks in advance.
Steve - ZL1BHD
------------------------------
Date: Mon, 1 Mar 93 13:41:05 PST
From: "Jerzy Tarasiuk" <JT@zfja-gate.fuw.edu.pl>
Subject: RCS 5.6 available for MS-DOS
To: Stuart G. Phillips <stu@tandem.com>
> Date: Sat, 27 Feb 93 10:05:47 PST
> Message-Id: <9302271805.AA18739@suntan.Tandem.com>
I remember someone tried the RCS 5.6 for DOS and had some problems
with it, one if them being CR CR LF as end of line - Phil's NOS RCS
files contains CR LF and RCS 5.6 adds one more CR, second Phil used
names with %v and RCS 5.6 doesn't remove it. Can use RCS 5.6 when
Phil puts NOS sources in its format - now it isn't compatible.
------------------------------
Date: Mon, 1 Mar 93 12:50 CST
From: prg@mgweed.att.com
Subject: Uncle! UNCLE! (Problem with FTP on NET)
To: TCP-Group@UCSD.Edu, att!qualcomm.com!karn
Phil Karn and Group,
Sorry to post this to the group, but Phil, I don't seem to be able
to reach you directly. Can you please let me know if you get tihs
test message via karn@qualcomm.com?
Now back to your normal programming..
Phil - WB9AAX/WA9DNZ - 44.72.41.2
------------------------------
Date: Tue, 2 Mar 93 0:39:44 EET
From: "Demetre Ch. Valaris - SV1UY" <dvalar@leon.nrcps.ariadne-t.gr>
Subject: USCC Baycom Card
To: nos-bbs@hydra.carleton.CA
Hello,
Just got a BAYCOM USCC card with 4 ports and I cannot make it work with
NOS. It works fine with the Baycom program, but this is not what I want.
I want it to work with JNOS of course.
Has anyone got any idea on how to attach it? It has 2 X 8530 chips.
Any help would be much appreciated.
73 Demetre Valaris SV1UY
E-mail dvalar@leon.nrcps.ariadne-t.gr
------------------------------
Date: Mon, 1 Mar 1993 14:04:20 -0800 (PST)
From: Bruce Perens <bruce@pixar.com>
Subject: Use of fixed-length data fields considered harmful.
To: Dave Horsfall <dave@eram.esi.com.au>
On Mon, 1 Mar 1993, Dave Horsfall wrote:
> As we in Australia discovered (with 8 character callsigns), any limit
> imposed today won't be enough tomorrow.
Thanks for the validation. I have a lingering fear that we'll eventually
find that 254 bytes wasn't enough :-)
> Hmmm... What about following the length field with its complement,
> in case it gets corrupted?
It seems that I haven't communicated effectively that the link layer
packet lives on top of an error-corrected unreliable datagram service.
In other words, you get a packet of correct data, or no packet at all.
It is more economical to error check the entire packet at once than to
provide redundant information that is good only for one field. A simple
thing like a checksum for the entire packet would be more reliable than
a complement of the length field alone. This requires that the lower
layer know the length of the packet and provide error checking for the
packet. We are calling that layer the Media Access Control or MAC layer.
The idea is to engineer different MAC layers for HF, microwave, etc.
The HF MAC layer, for instance, would probably have a higher emphasis on
forward error correction than the MAC layer used on a point-to-point
microwave link.
> You'd want the size of the data to be negotiable, of course.
Yes. Currently IP negotiates the MTU (Maximum Transfer Unit), doesn't it?
I think this belongs at the MAC layer too, but I could be wrong.
> Broadcast? Hmmmmmm... We have a long way to go yet; a packet LAN is
> not like a wired LAN; hidden transmitters etc.
Well, even on a wired LAN broadcast is not reliable. There is no
guarantee that anyone will hear your broadcast on an Ethernet. Broadcast
is, however, a very important feature of the current AX.25 systems, so I
saw fit to mention it.
Bruce
------------------------------
End of TCP-Group Digest V93 #58
******************************
******************************