Date: Thu, 25 Feb 93 04:30:13 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 #53
To: tcp-group-digest
TCP-Group Digest Thu, 25 Feb 93 Volume 93 : Issue 53
Today's Topics:
Fixes to R: line processing
Further proposals for AX.25 replacement
help
ICMP ECHO OFF
Net 44 connected status
New ax25
New ax25? (3 msgs)
New BM release
Open Squelch SCC (2 msgs)
Zip etc (2 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: Wed, 24 Feb 1993 22:49:36 -0800
From: Lyndon Nerenberg <Lyndon.Nerenberg@ns.unbc.edu>
Subject: Fixes to R: line processing
To: nos-bbs@hydra.carleton.ca
The enclosed patch, relative to WG7J version 1.07b, addresses the
following problems with R: headers:
1) JNOS (and others?) does not include the BID in the headers.
With the recent proliferation of munged BIDs we need this
information to track down the culprits. The patch adds a
$:BID field to the header when forwarding. Note: this field
is *not* optional - please don't make it optional!
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.
3) The current code for building the R: line could generate an
extra space at the end of the header (just before the \n).
Yes, I'm paranoid, but for good reason after some of the
messages I've seen come through lately. This is fixed.
4) This one's completely gratuitous :-) Messages with no
subject have the subject set to "(none)" rather than
"None" so's to emulate the various internet mail/news
gateways.
5) Every non-NOS BBS I've come across puts the location inside
the square brackets, followed by the (optional) software
identifier. I have changed the code to conform with that
convention.
--lyndon
*** forward.old Wed Feb 24 22:20:13 1993
--- forward.c Wed Feb 24 22:30:44 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,157 ----
/* 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);
! /* 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)
--- 331,337 ----
{
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:
--- 435,441 ----
while(*cp == ' ' || *cp == '\t')
cp++;
if(*cp == '\0')
! strcpy(subj,"(none)");
}
break;
case FROM:
------------------------------
Date: Thu, 25 Feb 93 09:52:41 +1100
From: wkt@csadfa.cs.adfa.oz.au (Warren Toomey)
Subject: Further proposals for AX.25 replacement
To: tcp-group@ucsd.edu
[ Looks like this got lost somewhere ]
Ok, to continue on with my suggestion yesterday about a set of amateur
protocols analogous to the IEEE 802 LAN protocols, here's some more ideas
for you to shoot down :-)
To quickly summarise what I proposed:
+ One link layer access protocol, used by upper layers
+ One or more Medium Access Control layers, depending on
the properties of the network and media involved
+ One or more Physical layers - we already have enough of
these :-)
Following on....
The Link Layer Access Point
---------------------------
Provides an unreliable packet service between two stations. Unicast,
multicast and broadcast data transmission. Needs to be able to support
multiple upper layers.
Medium Access Control Layers
----------------------------
Give the station access to the medium. Checksums, forward error
correction belong here.
Proposal for a Link Layer Access Point
--------------------------------------
Addresses:
A station has at least two addresses: its normal address, and the
broadcast address for the network. In addition, it can have zero or more
multicast addresses.
Services: send packet
receive packet (asynchronously)
add a new multicast address
remove a multicast address
Packet format:
Upper layers pass data by sending/receiving packets of the
following format to the Link Layer:
Destination Address - 8 octets
Source Address - 8 octets
Protocol - 2 octets
Data length - 2 octets
Data - 0 to 2048 octets
Notes on this:
+ No checksums! The MAC layer should use CRCs or FECs. In fact,
the MAC and physical layers will wrap the above packet with
MAC-specific and physical-specific stuff, like checksums,
sync bits etc.
+ Why a 2-octet protocol field? This allows 65,536 upper layer
protocols, which is a lot. It could be trimmed down to 1-octet.
+ Why 8-octet addresses? So that, using ASCII characters, we can
encode nearly all amateur addresses. Where an address is <8 octets,
pad the final octets with zeroes (0x00).
Broadcast address: all one bits.
Multicast addresses: First bit on, leaving 2^63 - 1 multicast
addresses. Should be enough.
Note that for those who are worried that this is a lot of
overhead, not for high speeds (e.g 56kbps), and a MAC
layer can do nasty things to the packet (a la CSLIP), as
long as the Link Layer doesn't find out.
+ Data length, I don't know if this is needed, but I'll
suggest it anyway. I think a Maximum Transmission Unit of
2048 will make life a lot easier. You don't have to use it
if you don't want to.
Ok, enough from me. We can use something like the AX.25 MAC for one MAC layer
-- someone mentioned a DAMA AX.25 yesterday, where can information on that
be found? I think other MAC layers need designing, too
So what does this sound like? Do we need a connection service in the
Link Layer? Other fields in the Link Layer packet? Should CRC/FEC be
brought up from the MAC layers? Do the sizes of the fields need fixing?
Should I just nip out & shoot myself now :-)
Food for thought, anyway...
Cheers,
Warren vk1xwt
------------------------------
Date: Wed, 24 Feb 93 15:09:03 MEZ
From: silva@Black.telenet.de (Elias da Silva)
Subject: help
To: tcp-group@ucsd.edu (Forum for NOS developers at UCSD.EDU)
HELP
------------------------------
Date: 24 Feb 93 13:32:22 CST
From: Jack Snodgrass <kf5mg@vnet.ibm.com>
Subject: ICMP ECHO OFF
To: <TCP-Group@UCSD.Edu>
What is the ICMP ECHO OFF command supposed to do? I assumed that
it would tell NOS to not answer an ICMP ECHO request, but that's not.
the case. I receive an ICMP Echo Request, and I respond with an ICMP Echo
reply. Is the ICMP ECHO OFF function broke, or does it do something
else? I'm using JNOS 1.07b. Thanks.
73's de Jack - kf5mg
AMPRnet - kf5mg@kf5mg.ampr.org - 44.28.0.14
AX25net - kf5mg@kf5mg.#dfw.tx.usa.na - work (817) 962-4409
Internet - kf5mg@vnet.ibm.com - home (817) 488-4386
------------------------------
Date: Wed, 24 Feb 1993 13:12:16 -0500
From: chk@alias.com (C. Harald Koch)
Subject: Net 44 connected status
To: tcp-group@ucsd.edu
I've been corrected, thank you. Apparently I haven't been paying attention
for a year or so; that's what happens when you change jobs and lose Internet
access (sniff!).
--
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: Thu, 25 Feb 93 10:55:22 GMT
From: Alan Cox <iiitac@pyr.swan.ac.uk>
Subject: New ax25
To: tcp-group@ucsd.edu
Some of this discussion hits one of the real issues. If there is a ROM
for the standard tnc boxes that can do a new protocol thats much better
than AX.25 , preferably as well as being able to do AX.25 too, then
people will use it providing its cheap and easy. The installed network
base is sufficiently large that there has to be an upgrade to any new
superprotocol. It may be that getting AX.25, new-super-protocol and telnet
+ ip layers into a 16K eprom is a little impractical, but if you can
get AX.25 new-super-protocol and a standard TNC interface using that
protocol into the standard TNC AND its a measurable improvement people
will use it.
Alan
------------------------------
Date: Wed, 24 Feb 93 08:26:05 -0600
From: sbrown@charon.dseg.ti.com (Steve Brown)
Subject: New ax25?
To: goldstein@carafe.tay2.dec.com
Small soapbox mode ON
fred k1io writes:
> Kiddiecomms BBSs are, indeed, time-sharing systems, and so are RBBSs.
> That's how they support the C-64s with the TNCs. That crew will never
> upgrade their protocols. It's not even interesting to try.
I would humbly suggest that there is a place in the world for C-64s,
etc. For example, my father, a retired masonry contractor, is having
a ball using his C-64 to get his feet wet in the world of packet
radio. The alternative to this approach in his case would be that he
does _not_ learn about this fascinating aspect of our hobby.
I would further humbly suggest that the experiences my father and
others like him have in learning about packet radio, while using obsolete
techniques and appliances, has fully as much to do with advancing the
cause of science in general as the experiences we have at the TCP/IP
level and higher.
Small soapbox mode OFF
*********************************************
| Steve Brown, WD5HCY | Simplicate |
| sbrown@charon.dseg.ti.com | and add |
| wd5hcy@kf5mg.#dfw.tx.usa.na | lightness. |
| (214) 575-3597 | |
| MSG:SBRN | - Bill |
| MS 8496, PSK0 | Stout |
*********************************************
------------------------------
Date: Wed, 24 Feb 93 14:29:38 CST
From: andyw@aspen.cray.com (Andy Warner)
Subject: New ax25?
To: tcp-group@ucsd.edu (TCP Group)
Steve stepped up on his soapbox & wrote:-
> [...]
> I would humbly suggest that there is a place in the world for C-64s,
> etc. For example, my father, a retired masonry contractor, is having
> [...]
> cause of science in general as the experiences we have at the TCP/IP
> level and higher.
Which is all well & good, but has nothing to do with what
tcp-group is here for.
--
andyw. N0REN/G1XRL
andyw@aspen.cray.com Andy Warner, Cray Research, Inc. (612) 683-5835
------------------------------
Date: Wed, 24 Feb 93 17:55:27 PST
From: @motgate.mot.com:jackb@mdd.comm.mot.com (Jack Brindle)
Subject: New ax25?
To: andyw@aspen.cray.com (Andy Warner)
>Steve stepped up on his soapbox & wrote:-
>
>> [...]
>> I would humbly suggest that there is a place in the world for C-64s,
>> etc. For example, my father, a retired masonry contractor, is having
>> [...]
>> cause of science in general as the experiences we have at the TCP/IP
>> level and higher.
>
>Which is all well & good, but has nothing to do with what
>tcp-group is here for.
Ah, perhaps not. After all, the "real" world has found need for a PAD
to interface "dumb" devices. Perhaps it would be worthwhile for us to
design and construct a PAD for telnet, etc. that would allow the C-64
users of the world to "play" in the system. It would be ironic that
such a device would have considerably more horsepower than the terminal
it was connected to...
This isn't to be argumentative, by the way. I really believe that a
PAD would be very useful in the packet world. A small system built
around a 68302 wouldn't take very many components, and could be quite
useful!
Jack Brindle
------------------------------------------------------------------------------
ham radio: wa4fib internet: jackb@mdd.comm.mot.com
------------------------------
Date: Wed, 24 Feb 1993 12:22:14 +0200
From: Costas Krallis SV1XV <kkrallis@leon.nrcps.ariadne-t.gr>
Subject: New BM release
To: tcp-group@ucsd.edu
The new release of BM.EXE, with some new features added by
Jerzy Tarasiuk <jt@fuw.edu.pl>, is being uploaded to the
incloming directory at "ucsd.edu" under the filename bm332c.zip.
73 Costas SV1XV
------------------------------------------------------------------
| Dr. K. Krallis, SV1XV *
| ------
| Internet: kkrallis@leon.nrcps.ariadne-t.gr
| Packet radio: sv1xv@sv1uy.ath.grc.eu
| AMPRnet: sv1xv@sv1xv.ampr.org [44.154.1.11]
| Snail Mail: P.O.BOX 3066, GR-10210 Athens, GREECE
------------------------------------------------------------------
------------------------------
Date: Wed, 24 Feb 93 11:02:05 EST
From: barry@dgbt.doc.ca (Barry McLarnon)
Subject: Open Squelch SCC
To: tcp-group@ucsd.edu
> Several users of various flavours of NOS in the London area have asked me
> whether it is possible to run their SCC cards with open squelch (software
> DCD). The version of SCC.C that is included in most NOS versions (most of
> us are running JNOS 108) doesn't allow this.
>
> Has anyone done any work in this area?
> At present a few people are using the G8BPQ switch code beneath NOS as this
> =does= support open squelch for SCC cards- however this eats up 80k or so of
> memory, and memory is one thing we don't exactly have spare!
>
> My Pac-Comm TNC-220 has an 8530 SCC chip in it, and =that= can do software
> DCD [ but not in KISS mode ;-( ].. what I'm looking for is a solution that
> =doesn't= involve me disassembling 32k of Z80 code to see how it's done.
>
> (I've looked in the 8530 Technical Manual, and I've an inkling of how to do
I would think a hardware solution would be preferable, since NOS already has
enough to do. It would be nice if the clock recovery DPLL in the SCC had a
lock detector that was accessible to the outside world as a DCD indicator...
alas, it doesn't. How about getting one of those TAPR 'DCD upgrade' kits
with the built-in state machine DCD, and marrying it up to the SCC card?
Not the cheapest or most elegant solution, but it should work...
> Andrew Benham
Barry VE3JF
--
Barry McLarnon | Internet: barry@dgbt.doc.ca
Communications Research Center | AMPRnet: barry@bbs.ve3jf.ampr.org
Ottawa, Canada K2H 8S2 | PBBSnet: ve3jf@ve3jf.#eon.on.can
------------------------------
Date: Wed, 24 Feb 93 13:56:21 -0800
From: "Dana H. Myers" <dana@phad.la.locus.com>
Subject: Open Squelch SCC
To: barry@dgbt.doc.ca, tcp-group@ucsd.edu
Barry VE3JF wrote:
> I would think a hardware solution would be preferable, since NOS already has
> enough to do. It would be nice if the clock recovery DPLL in the SCC had a
> lock detector that was accessible to the outside world as a DCD indicator...
> alas, it doesn't. How about getting one of those TAPR 'DCD upgrade' kits
> with the built-in state machine DCD, and marrying it up to the SCC card?
> Not the cheapest or most elegant solution, but it should work...
The DPLL in the SCC does not appear to have any Lock Detect function; the
DPLL simply attempts to recover a clock from the data transitions. I do
not believe the DPLL ever cares whether it has a valid "lock" on the
data clock.
The TAPR DCD State Machine sounds like an excellent idea to me.
Dana
* Dana H. Myers KK6JQ | Views expressed here are *
* (310) 337-5136 | mine and do not necessarily *
* dana@locus.com DoD #466 | reflect those of my employer *
* This Extra supports the abolition of the 13 and 20 WPM tests *
------------------------------
Date: Wed, 24 Feb 93 10:04:55 GMT
From: Alan Cox <iiitac@pyr.swan.ac.uk>
Subject: Zip etc
To: tcp-group@ucsd.edu
I'll try not to start a flamewar this time. There is a very good unix and
amiga , even windows NT and vms zip floating around the net, and it works well
It doesnt have the crypt facility (I think thats the good old no exporting
encryption technology problem).
As a side issue unix compress is now old technology its not as good
a compressor, its got patent problems and gnu are now supporting something
called gzip (which as far as I can tell bears no resemblance to zip).
Stick to zip, its convenient.
ALan
------------------------------
Date: Wed, 24 Feb 93 11:49:46 PST
From: Ron Henderson <root@hpcvscrh.cv.hp.com>
Subject: Zip etc
To: iiitac@pyr.swan.ac.uk (Alan Cox)
> I'll try not to start a flamewar this time. There is a very good unix and
> amiga , even windows NT and vms zip floating around the net, and it works well
> It doesnt have the crypt facility (I think thats the good old no exporting
> encryption technology problem).
Encryption is available, but it's available as separate zip file that
must retrieved. zcrypt19.zip can usually be found in the same places as
unzip50p1 and zip19.
> Stick to zip, its convenient.
Agreed.
Ron WA7TAS (crh@cv.hp.com)
------------------------------
End of TCP-Group Digest V93 #53
******************************
******************************