Date: Fri, 26 Feb 93 04:30:08 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 #54
To: tcp-group-digest
TCP-Group Digest Fri, 26 Feb 93 Volume 93 : Issue 54
Today's Topics:
Fixes to R: line processing
Headers
looooooooooooooooong messages
looooooooooooooooooooooooooooooooooooong messages (2 msgs)
Lyndon's "Fixes to R: line processing"
Multiple drive FTP code
PC-LAN cards -- ARRGH!
Protocls
stat()
Updated R: patch (2 msgs)
Use of fixed-length data fields considered harmful. (4 msgs)
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: Thu, 25 Feb 93 11:33:58 PST
From: Lyndon Nerenberg <Lyndon.Nerenberg@ns.unbc.edu>
Subject: Fixes to R: line processing
To: nos-bbs@hydra.carleton.CA
>>
>> 2) The headers are limited to 80 characters. I have seen a
>> number of bulletins come through my system lately that
>> exceeded the limit. (I was guilty of generating some,
>> too.) Since the patch for 1) makes the headers dangerously
>> long I have removed the #:MsgNum field from the header.
>> It's value in debugging forwarding problems seems questionable.
>NNNNNNOOOOOOOOOOO, aaaaaaaahhhhhhhhhhhh, DON'T do this!!!!! Many if not
>all BBS (except NOS) software use the #:MsgNum and @:BBScall fields to
>reconstruct lost BIDs. Taking this field out will do more harm than good.
>If you want to leave something out drop the [] they are only decoration
Sorry, but I disagree completely. What prompted me to make these changes
was the latest Spacenews bulletin. It was sent with a BID of $SPC0222.
How on earth is a #: field going to regenerate *that* ??? Three of the
four bad copies of the bulletin I saw were flotaing around *because*
they had incorrectly regenerated the BID using the #: field.
If the message comes in without a BID, DROP IT! With the number of
redundent feeds we have, a second, good, copy will show up before
long.
--lyndon
------------------------------
Date: Thu, 25 Feb 93 08:41:57 PST
From: "Roy Engehausen (8-457-2712)" <enge@almaden.ibm.com>
Subject: Headers
To: TCP-GROUP@UCSD.EDU
The #:xxxxx field in the header is NOT optional. If the message
goes thru a W0RLI header censor, ZERO will be substituted and this
may cause REPLY to fail for AA4RE systems.
I will be happy to send a copy of the header spec to anyone who asks.
Roy, AA4RE
enge@almaden.ibm.com
------------------------------
Date: Fri, 26 Feb 93 12:23:12 +0100
From: jt@fuw.edu.pl
Subject: looooooooooooooooong messages
To: tcp-group@ucsd.edu
Hello, all
I suggest stop talking which compressor is most suitable.
Otherwise the talking can use more net bandwidth than the long msg itself.
BTW, seems most files on ucsd are compressed by PKZIP. Some disadvantage
of compress: needs *large* memory, I needed to unload sidekick to use the
compress on DOS (for decompressing I updated DOS decomp to reduce amount
of memory it needs and can use it being shelled out from NOS :-).
73's, JT
------------------------------
Date: Thu, 25 Feb 93 10:56:26 EST
From: tegra!vail@uunet.UU.NET (Johnathan Vail)
Subject: looooooooooooooooooooooooooooooooooooong messages
To: uunet!ucsd.edu!tcp-group@uunet.UU.NET
beacker@tomahawk.asd.sgi.com writes:
>I fully agree with the request to compress things that are so long.
>What I disagree with is the method. It appears that the most universal
>compression system is unix compress. This utility has been implemented
>across almost all systems. Unfortunately PKZip has not. So, please,
>if the file you wish to send is real long, use compress first...
The thought that unix compress is the most universal is really
unix-centric. The largest population of computers on this planet is
the PC-Clone, and the package in use on that platform is typically
PKZip.
Now just for your information there are a pair of packages,
unzip and zip, available for Unix systems. These will do the same
thing that PKZip will do, and allow people to transfer between these
platforms. These packages are readily available from simtel20.
A better compression tool in terms of compatibility is ZOO. It is
free software that runs on PCs, Amgias, Unix, Ataris and just about
anything else. Since the source code is free and there are no
licensing fees you can share the software over amateur radio without
breaking the rules like you can with shareware.
Zoo is the standard tool used in comp.binaries.ibm.pc and can be found
on most archive sites.
Zip may ubiquitous on PCs and some compatible programs are available
on unix but its not quite the same as having the same program running
on different platforms.
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: Thu, 25 Feb 93 10:56:26 EST
From: tegra!vail@uunet.UU.NET (Johnathan Vail)
Subject: looooooooooooooooooooooooooooooooooooong messages
To: uunet!ucsd.edu!tcp-group@uunet.UU.NET
beacker@tomahawk.asd.sgi.com writes:
>I fully agree with the request to compress things that are so long.
>What I disagree with is the method. It appears that the most universal
>compression system is unix compress. This utility has been implemented
>across almost all systems. Unfortunately PKZip has not. So, please,
>if the file you wish to send is real long, use compress first...
The thought that unix compress is the most universal is really
unix-centric. The largest population of computers on this planet is
the PC-Clone, and the package in use on that platform is typically
PKZip.
Now just for your information there are a pair of packages,
unzip and zip, available for Unix systems. These will do the same
thing that PKZip will do, and allow people to transfer between these
platforms. These packages are readily available from simtel20.
A better compression tool in terms of compatibility is ZOO. It is
free software that runs on PCs, Amgias, Unix, Ataris and just about
anything else. Since the source code is free and there are no
licensing fees you can share the software over amateur radio without
breaking the rules like you can with shareware.
Zoo is the standard tool used in comp.binaries.ibm.pc and can be found
on most archive sites.
Zip may ubiquitous on PCs and some compatible programs are available
on unix but its not quite the same as having the same program running
on different platforms.
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: Thu, 25 Feb 93 8:24:27 cst
From: Clarke Diekmann <cdiekman@ftsmhstn-hsc.army.mil>
Subject: Lyndon's "Fixes to R: line processing"
To: tcp-group@UCSD.EDU
I may be jumping into the middle of things but the suggestion to remove the
"#:<msgno>" field from the R:header could have BAD effects. If the system is
using R: headers that include the originating BBS and message number in the
form "<msgno>@BBS_call+haddress" the n the "#:" field is redundant. BUT if the
system is using the other convention where the BBS places it's call/haddress in
the field "@:BBS_call+haddress" then the matching "#:<msgno>" field is
MANDATORY to keep some system software from regenerating a new message at the
receiving BBS. The message number and BBS_callsign are required fields in
addition to the R:date/time field for proper operation of most BBS packages.
Clarke
------------------------------
Date: Thu, 25 Feb 93 14:11:21 PST
From: "Jerzy Tarasiuk" <JT@zfja-gate.fuw.edu.pl>
Subject: Multiple drive FTP code
To: RON MURRAY <NMURRAYR@cc.curtin.edu.au>
> Date: 25 Feb 1993 20:41:23 +0800
> Message-id: <01GV5HB826K29ODAXP@cc.curtin.edu.au>
>
> Did you ever port your multiple-drive FTP code to GRI 2.0m? I had a
Try get nos/pa0gri/local/ftpd-20m.zip (26kB) from zfja-gate.fuw.edu.pl
(148.81.6.100) by guest ftp or mail to listserv@zfja-gate.fuw.edu.pl,
I did it few months ago, but it was never tested if works correctly.
To all: if it works OK somewhere, please let me and tcp-group know it.
73's, JT
------------------------------
Date: Fri, 26 Feb 1993 04:26:30 JAN_TIME_ZONE
From: NOWLIN@ksuvxb.kent.edu
Subject: PC-LAN cards -- ARRGH!
To: tcp-group@ucsd.EDU
Anybody have any ideas on this one?:
I have a IP LAN set up using the PC-LAN cards that IBM sold around 1985 or
so. (The ones from Sytek). I'm running NOS 1.06, with the NetBIOS packet
driver (v4) out of the Clarkson set. The two commands I'm using to
start the cards are:
nb.com 0x61 44.70.5.13
attach packet 0x61 lan 10 512
(In their appropriate files, of course.)
The problem I'm running into is that the source computer is sending out
a packet (during a Telnet attempt) that looks like:
Ether: len 60 00:00:2c:46:05:0d -> 00:00:2c:46:05:0e type IP
but the other computers are actually receiving
Ether: len 60 00:00:2c:46:05:0d -> 00:00:c4:c3:cc:c2 type IP
Notice the change in destination addresses? I'm not doing anything
fancy that would trigger that. I'm not sure if the problem is in the
source or destination systems, but it's universal. The incorrect address
in the received packet is always the same -- doesn't matter what IP address
I try to Telnet to. Everything LOOKS OK on the source CPU, but I can't
be completely sure of that.
Actually, maybe I can be sure of it -- I tried NCSA Telnet, and the receiving
computer picked up the same incorrect address.
Somebody help me!!!! I need this to work so I can get my serial ports back!
Thanks... Mike nowlin@ksuvxb.kent.edu
------------------------------
Date: Thu, 25 Feb 93 12:46:39 GMT
From: Alan Cox <iiitac@pyr.swan.ac.uk>
Subject: Protocls
To: tcp-group@ucsd.edu
Actually another idea to throw into the pot. Since bandwidth is so expensive
and tx/rx swithcing causes a lot of the packet losses, maybe the protocl
should allow multiple messages to different destinations with one
source header containing all the constant information followed by
a set of blocks containing destination address and data areas.
Alan
------------------------------
Date: Thu, 25 Feb 1993 10:20:37 -0600
From: miltonm@inetnode.austin.ibm.com (Milton Miller)
Subject: stat()
Last time I looked, realloc #ifdef' out because no one was using it :-)
milton
------------------------------
Date: Thu, 25 Feb 1993 12:24:34 -0800
From: Lyndon Nerenberg <Lyndon.Nerenberg@ns.unbc.edu>
Subject: Updated R: patch
To: nos-bbs@hydra.carleton.ca
OK, enough people have sent mail to convince me removing #: is a bad idea.
The uses for #: in all the examples I was given seem EXTREMELY contrived,
however it appears that AA4RE and W0RLI BBS code will break if this
field is not present.
Once again, I strongly suggest that BBS implementations be modified to
simply drop any bulletin that a remote BBS tries to forward without
an explicit BID on the SB command line.
--lyndon
*** forward.old Wed Feb 24 22:20:13 1993
--- forward.c Thu Feb 25 12:19:01 1993
***************
*** 32,39 ****
#define ISPROMPT(s) (strlen(s) > 1 && s[strlen(s)-2] == '>')
static struct timer fwdtimer;
static struct proc *FwdProc = NULLPROC;
-
static char *findident __ARGS((char *str, int n, char *result));
static void sendmsg __ARGS((struct mbx *m,int msgn));
static char *mbxtime __ARGS((char *line));
--- 32,39 ----
#define ISPROMPT(s) (strlen(s) > 1 && s[strlen(s)-2] == '>')
static struct timer fwdtimer;
static struct proc *FwdProc = NULLPROC;
+ static char bid[LINELEN];
static char *findident __ARGS((char *str, int n, char *result));
static void sendmsg __ARGS((struct mbx *m,int msgn));
static char *mbxtime __ARGS((char *line));
***************
*** 144,159 ****
/* If exists, send H-address */
if(Mbhaddress != NULLCHAR)
usprintf(m->user,".%s ",Mbhaddress);
! else
! usputc(m->user,' ');
! /*if there is info, put it next */
! if(Mbfwdinfo != NULLCHAR)
! usprintf(m->user,"[%s] ",Mbfwdinfo);
! /* location, if any */
if(Mbqth != NULLCHAR)
! usprintf(m->user,"%s ",Mbqth);
! /* number of the message */
usprintf(m->user,"#:%u ",msgid);
/* zip code of the bbs */
if(Mbzip != NULLCHAR)
usprintf(m->user,"Z:%s",Mbzip);
--- 144,159 ----
/* If exists, send H-address */
if(Mbhaddress != NULLCHAR)
usprintf(m->user,".%s",Mbhaddress);
! /* next comes the QTH */
if (Mbqth != NULLCHAR)
! usprintf(m->user, " [%s]", Mbqth);
! if(Mbfwdinfo != NULLCHAR)
! usprintf(m->user," %s",Mbfwdinfo);
! /* add msgid */
usprintf(m->user, " #:%u", msgid);
+ /* Tack on the BID */
+ if (strlen(bid) > 1)
+ usprintf(m->user," $:%s", &bid[1]);
/* zip code of the bbs */
if(Mbzip != NULLCHAR)
usprintf(m->user," Z:%s",Mbzip);
***************
*** 333,339 ****
{
int bulletin = *bul;
int foundbid = 0;
! char bid[LINELEN], to[LINELEN], atbbs[LINELEN], from[LINELEN],
buf[LINELEN], *cp;
if(m->mfile == NULLFILE)
--- 333,339 ----
{
int bulletin = *bul;
int foundbid = 0;
! char to[LINELEN], atbbs[LINELEN], from[LINELEN],
buf[LINELEN], *cp;
if(m->mfile == NULLFILE)
***************
*** 437,443 ****
while(*cp == ' ' || *cp == '\t')
cp++;
if(*cp == '\0')
! strcpy(subj,"None");
}
break;
case FROM:
--- 437,443 ----
while(*cp == ' ' || *cp == '\t')
cp++;
if(*cp == '\0')
! strcpy(subj,"(none)");
}
break;
case FROM:
------------------------------
Date: Thu, 25 Feb 1993 12:24:34 -0800
From: Lyndon Nerenberg <Lyndon.Nerenberg@ns.unbc.edu>
Subject: Updated R: patch
To: nos-bbs@hydra.carleton.ca
OK, enough people have sent mail to convince me removing #: is a bad idea.
The uses for #: in all the examples I was given seem EXTREMELY contrived,
however it appears that AA4RE and W0RLI BBS code will break if this
field is not present.
Once again, I strongly suggest that BBS implementations be modified to
simply drop any bulletin that a remote BBS tries to forward without
an explicit BID on the SB command line.
--lyndon
*** forward.old Wed Feb 24 22:20:13 1993
--- forward.c Thu Feb 25 12:19:01 1993
***************
*** 32,39 ****
#define ISPROMPT(s) (strlen(s) > 1 && s[strlen(s)-2] == '>')
static struct timer fwdtimer;
static struct proc *FwdProc = NULLPROC;
-
static char *findident __ARGS((char *str, int n, char *result));
static void sendmsg __ARGS((struct mbx *m,int msgn));
static char *mbxtime __ARGS((char *line));
--- 32,39 ----
#define ISPROMPT(s) (strlen(s) > 1 && s[strlen(s)-2] == '>')
static struct timer fwdtimer;
static struct proc *FwdProc = NULLPROC;
+ static char bid[LINELEN];
static char *findident __ARGS((char *str, int n, char *result));
static void sendmsg __ARGS((struct mbx *m,int msgn));
static char *mbxtime __ARGS((char *line));
***************
*** 144,159 ****
/* If exists, send H-address */
if(Mbhaddress != NULLCHAR)
usprintf(m->user,".%s ",Mbhaddress);
! else
! usputc(m->user,' ');
! /*if there is info, put it next */
! if(Mbfwdinfo != NULLCHAR)
! usprintf(m->user,"[%s] ",Mbfwdinfo);
! /* location, if any */
if(Mbqth != NULLCHAR)
! usprintf(m->user,"%s ",Mbqth);
! /* number of the message */
usprintf(m->user,"#:%u ",msgid);
/* zip code of the bbs */
if(Mbzip != NULLCHAR)
usprintf(m->user,"Z:%s",Mbzip);
--- 144,159 ----
/* If exists, send H-address */
if(Mbhaddress != NULLCHAR)
usprintf(m->user,".%s",Mbhaddress);
! /* next comes the QTH */
if (Mbqth != NULLCHAR)
! usprintf(m->user, " [%s]", Mbqth);
! if(Mbfwdinfo != NULLCHAR)
! usprintf(m->user," %s",Mbfwdinfo);
! /* add msgid */
usprintf(m->user, " #:%u", msgid);
+ /* Tack on the BID */
+ if (strlen(bid) > 1)
+ usprintf(m->user," $:%s", &bid[1]);
/* zip code of the bbs */
if(Mbzip != NULLCHAR)
usprintf(m->user," Z:%s",Mbzip);
***************
*** 333,339 ****
{
int bulletin = *bul;
int foundbid = 0;
! char bid[LINELEN], to[LINELEN], atbbs[LINELEN], from[LINELEN],
buf[LINELEN], *cp;
if(m->mfile == NULLFILE)
--- 333,339 ----
{
int bulletin = *bul;
int foundbid = 0;
! char to[LINELEN], atbbs[LINELEN], from[LINELEN],
buf[LINELEN], *cp;
if(m->mfile == NULLFILE)
***************
*** 437,443 ****
while(*cp == ' ' || *cp == '\t')
cp++;
if(*cp == '\0')
! strcpy(subj,"None");
}
break;
case FROM:
--- 437,443 ----
while(*cp == ' ' || *cp == '\t')
cp++;
if(*cp == '\0')
! strcpy(subj,"(none)");
}
break;
case FROM:
------------------------------
Date: Thu, 25 Feb 1993 11:59:24 -0800 (PST)
From: Bruce Perens <bruce@pixar.com>
Subject: Use of fixed-length data fields considered harmful.
To: Warren Toomey <wkt@csadfa.cs.adfa.oz.au>
On Thu, 25 Feb 1993, Warren Toomey wrote:
>
> Destination Address - 8 octets
> Source Address - 8 octets
> Protocol - 2 octets
> Data length - 2 octets
> Data - 0 to 2048 octet
A good start, but I submit that fixed-length fields should be avoided
for addresses. I am in favor of a _lot_ of flexibility in the address
fields.
Eight octets are better than six, but still not enough. The address
fields should be of variable length, to at least 255 bytes maximum. This
would provide the option of using a hierarchical addresses, forwarding
chains, etc. Remember, one of the goals of the Amateur service is
experimentation - thus we should develop a format that would allow
experimentation and grow with us, not another AX.25 .
How about:
Host address type: 1 Octet
Host address length: 1 Octet
Destination address type: 1 Octet
Destination address length: 1 Octet.
Protocol 2 Octets
Data length: 2 Octets
Host address: 0-255 Octets
Destination address: 0-255 Octets
Data: 0-65535 Octets
The address type field enumerates different address types such as
callsigns, hierarchical addresses, multicast groups, forwarding chains,
etc. This gives us some room to experiment.
Zero-length address fields are legal. A zero-length destination address
may be used for broadcast.
The minimum overhead at this layer is 8 bytes, for a packet
in which both address fields are empty.
One problem I see here is that an odd-length address could cause the
data to begin on an odd boundary. We probably want to pad the start of
the data field to a two or four byte boundary, so that we can treat the
data as words or longwords without alignment problems.
Bruce
------------------------------
Date: Thu, 25 Feb 1993 11:59:24 -0800 (PST)
From: Bruce Perens <bruce@pixar.com>
Subject: Use of fixed-length data fields considered harmful.
To: Warren Toomey <wkt@csadfa.cs.adfa.oz.au>
On Thu, 25 Feb 1993, Warren Toomey wrote:
>
> Destination Address - 8 octets
> Source Address - 8 octets
> Protocol - 2 octets
> Data length - 2 octets
> Data - 0 to 2048 octet
A good start, but I submit that fixed-length fields should be avoided
for addresses. I am in favor of a _lot_ of flexibility in the address
fields.
Eight octets are better than six, but still not enough. The address
fields should be of variable length, to at least 255 bytes maximum. This
would provide the option of using a hierarchical addresses, forwarding
chains, etc. Remember, one of the goals of the Amateur service is
experimentation - thus we should develop a format that would allow
experimentation and grow with us, not another AX.25 .
How about:
Host address type: 1 Octet
Host address length: 1 Octet
Destination address type: 1 Octet
Destination address length: 1 Octet.
Protocol 2 Octets
Data length: 2 Octets
Host address: 0-255 Octets
Destination address: 0-255 Octets
Data: 0-65535 Octets
The address type field enumerates different address types such as
callsigns, hierarchical addresses, multicast groups, forwarding chains,
etc. This gives us some room to experiment.
Zero-length address fields are legal. A zero-length destination address
may be used for broadcast.
The minimum overhead at this layer is 8 bytes, for a packet
in which both address fields are empty.
One problem I see here is that an odd-length address could cause the
data to begin on an odd boundary. We probably want to pad the start of
the data field to a two or four byte boundary, so that we can treat the
data as words or longwords without alignment problems.
Bruce
------------------------------
Date: Thu, 25 Feb 1993 11:59:24 -0800 (PST)
From: Bruce Perens <bruce@pixar.com>
Subject: Use of fixed-length data fields considered harmful.
To: Warren Toomey <wkt@csadfa.cs.adfa.oz.au>
On Thu, 25 Feb 1993, Warren Toomey wrote:
>
> Destination Address - 8 octets
> Source Address - 8 octets
> Protocol - 2 octets
> Data length - 2 octets
> Data - 0 to 2048 octet
A good start, but I submit that fixed-length fields should be avoided
for addresses. I am in favor of a _lot_ of flexibility in the address
fields.
Eight octets are better than six, but still not enough. The address
fields should be of variable length, to at least 255 bytes maximum. This
would provide the option of using a hierarchical addresses, forwarding
chains, etc. Remember, one of the goals of the Amateur service is
experimentation - thus we should develop a format that would allow
experimentation and grow with us, not another AX.25 .
How about:
Host address type: 1 Octet
Host address length: 1 Octet
Destination address type: 1 Octet
Destination address length: 1 Octet.
Protocol 2 Octets
Data length: 2 Octets
Host address: 0-255 Octets
Destination address: 0-255 Octets
Data: 0-65535 Octets
The address type field enumerates different address types such as
callsigns, hierarchical addresses, multicast groups, forwarding chains,
etc. This gives us some room to experiment.
Zero-length address fields are legal. A zero-length destination address
may be used for broadcast.
The minimum overhead at this layer is 8 bytes, for a packet
in which both address fields are empty.
One problem I see here is that an odd-length address could cause the
data to begin on an odd boundary. We probably want to pad the start of
the data field to a two or four byte boundary, so that we can treat the
data as words or longwords without alignment problems.
Bruce
------------------------------
Date: Fri, 26 Feb 93 16:17:00 +1100
From: wkt@csadfa.cs.adfa.oz.au (Warren Toomey)
Subject: Use of fixed-length data fields considered harmful.
To: Bruce Perens <bruce@pixar.com>, Warren Toomey <wkt@csadfa.cs.adfa.oz.au>
In atricle by Bruce Perens:
>
> A good start, but I submit that fixed-length fields should be avoided
> for addresses. I am in favor of a _lot_ of flexibility in the address
> fields.
Ok, but don't have a separate field for address type, just use the first
address octet as address type. Thus, the following fields:
> Protocol 2 Octets
> Destination address length: 1 Octet.
> Host address length: 1 Octet
> Data length: 2 Octets
> Destination address: 0-255 Octets
> Host address: 0-255 Octets
> Pad: 0-3 Octets
> Data: 0-65535 Octets
Comments from others? The pad is to ensure the data starts on a 4-octet
boundary.
Warren vk1xwt
------------------------------
End of TCP-Group Digest V93 #54
******************************
******************************