World of Ham Radio 1994 January/AMSOFT_1994.iso/packet/docs/pd198712.doc

Text File | 1993-12-31 | 159.4 KB | 3,580 lines

1-Dec-87 03:01:48-EST,1629;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 1 Dec 87 03:01-EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Tue, 1 Dec 87 01:59:11 EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Tue, 1 Dec 87 01:59:01 EST
Message-Id: <[e-mail]>
Received: from relay2.cs.net by RELAY.CS.NET id aa04397; 1 Dec 87 1:53 EST
Received: from pitt by RELAY.CS.NET id aa15631; 1 Dec 87 1:49 EST
Received: by pitt (5.51/4.7)
    id AA23187; Mon, 30 Nov 87 11:24:14 EST
From: Bob Hoffman <[e-mail]>
To: [e-mail]
Date: Mon, 30 Nov 87 11:24:11 EDT
Subject: PBBSes and Philosophy
Cc: [e-mail]
Reply-To: Bob Hoffman <[e-mail]>
X-Mailer: ELM [version 1.2a]

I agree completely with your views on publicly available source code
with the exception of one ripe nit to harvest:

> From: [e-mail] (Bob Clements, K1BC)
>
> ...
> Consider as a counterexample the hoarding of source code for the
> TNC-1 which held us all back for years.
> ...

If I recall correctly, Harold Price, NK6K, offered the TNC-1 source
code to anyone who would send him a couple of diskettes, return
postage, and a statement that it would not be used for commercial
gain.  This offer was made at least 3 years ago, right after TAPR 3.3
came out.  It may have been seen only on CompuServe; I can't remember
right now.

    ---Bob.
__
Bob Hoffman, N3CVL       {allegra, bellcore, cadre, idis, psuvax1}!pitt!hoffman
Pitt Computer Science    [e-mail]

 1-Dec-87 07:50:07-EST,1629;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 1 Dec 87 07:50-EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Tue, 1 Dec 87 07:09:23 EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Tue, 1 Dec 87 07:09:13 EST
Message-Id: <[e-mail]>
Received: from relay2.cs.net by RELAY.CS.NET id ar06564; 1 Dec 87 6:53 EST
Received: from pitt by RELAY.CS.NET id aa17049; 1 Dec 87 6:49 EST
Received: by pitt (5.51/4.7)
    id AA23187; Mon, 30 Nov 87 11:24:14 EST
From: Bob Hoffman <[e-mail]>
To: [e-mail]
Date: Mon, 30 Nov 87 11:24:11 EDT
Subject: PBBSes and Philosophy
Cc: [e-mail]
Reply-To: Bob Hoffman <[e-mail]>
X-Mailer: ELM [version 1.2a]

I agree completely with your views on publicly available source code
with the exception of one ripe nit to harvest:

> From: [e-mail] (Bob Clements, K1BC)
>
> ...
> Consider as a counterexample the hoarding of source code for the
> TNC-1 which held us all back for years.
> ...

If I recall correctly, Harold Price, NK6K, offered the TNC-1 source
code to anyone who would send him a couple of diskettes, return
postage, and a statement that it would not be used for commercial
gain.  This offer was made at least 3 years ago, right after TAPR 3.3
came out.  It may have been seen only on CompuServe; I can't remember
right now.

    ---Bob.
__
Bob Hoffman, N3CVL       {allegra, bellcore, cadre, idis, psuvax1}!pitt!hoffman
Pitt Computer Science    [e-mail]

 1-Dec-87 15:54:53-EST,2507;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 1 Dec 87 15:54-EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Tue, 1 Dec 87 11:44:31 EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Tue, 1 Dec 87 11:44:04 EST
Message-Id: <[e-mail]>
To: Bob Hoffman <[e-mail]>
Cc: [e-mail], [e-mail]
Subject: Re: PBBSes and Philosophy
In-Reply-To: Your message of Mon, 30 Nov 87 11:24:11
Date: Tue, 01 Dec 87 11:43:58 -0500
From: [e-mail]

> From: Bob Hoffman <[e-mail]>
>
> I agree completely with your views on publicly available source code
> with the exception of one ripe nit to harvest:
>
> > From: [e-mail] (Bob Clements, K1BC)
> > ...
> > Consider as a counterexample the hoarding of source code for the
> > TNC-1 which held us all back for years.
> > ...
>
> If I recall correctly, Harold Price, NK6K, offered the TNC-1 source
> code to anyone who would send him a couple of diskettes, return
> postage, and a statement that it would not be used for commercial
> gain.  This offer was made at least 3 years ago, right after TAPR 3.3
> came out.  It may have been seen only on CompuServe; I can't remember
> right now.
>
>         ---Bob.
> Bob Hoffman, N3CVL       {allegra, bellcore, cadre, idis, psuvax1}!pitt!hoffman
> Pitt Computer Science    [e-mail]

Bob,

I accept your nit.  That offer was made, and I did get those sources
from Den Connors, KD2S, some time after that.

My statement was consciously weasle-worded.  I didn't say that TNC-1
sources were NEVER released.  In fact they were released after a
huge amount of clamor and delay, years after the first TNC-1's were
shipped and after we had suffered with their bugs and been repeatedly
promised software updates from TAPR.

The reasons nobody then fixed the TNC-1 code were 1) the lack of
tools (Pascal compiler for 6809 object machine) and 2) the fact
that nobody but the original authors could possibly understand
that code which was almost totally uncommented and generally
incomprehensible.  I tried, and so did some others.

I was trying to avoid the impoliteness of that last statement when
I made my posting.  So I was accurate but misleading.  We were held
back for years, but the sources were eventually released.

Sorry.

73, Bob, K1BC    [e-mail]
 1-Dec-87 20:17:09-EST,3582;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 1 Dec 87 20:17-EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Tue, 1 Dec 87 19:10:22 EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Tue, 1 Dec 87 19:09:46 EST
Received: by june.cs.washington.edu (5.52.1/6.11)
    id AA15784; Tue, 1 Dec 87 16:09:48 PST
Return-Path: <delni.dec.com![e-mail]>
Message-Id: <[e-mail]>
Date: 1 Dec 87 15:16:08 GMT
From: delni.dec.com![e-mail] (Fred R. Goldstein dtn226-7388)
To: [e-mail]
Subject: Re: Trying to throw water on protocol flames (really Addressing)

Phil, I agree that a "better" address scheme isn't trivial.  But the use
of callsigns or other mnemonic IDs isn't impossible.  Roughly, here's the
idea I'm batting around (in the AmOSInet L3 paper).

You have LANs (I called them "section nets" out of deference to history)
in which the addressing is mnemonic/flat.  Everyone in the section net
uses his call sign as the L3 address, unless he has a reason to use
something else like NTS address (NTS021, R1TCC, whatever) or net name.
It doesn't matter since it's an alpha string.  All routers maintain
routing tables of everyone in their section.  It's flat but only locally.
Now you have the WAN ("region net") which binds them together.  I get
this from the ISO concept of heirarchical routing, btw, thanks to
Paul Tsuchiya of Mitre for sending it to me.  (Actually we do it in
DECnet too.)

The "region routers" which form the backbone give mnemonic section_IDs
to each LAN.  Now to address someone in _another_ section net,
you send an address that includes both the section-ID and the
station/service-ID.  You acquire your own region-ID from the router you're
linked to, btw, and it's only necessary for inter-section traffic.
For example, I'm "K1IO" within section FN42, but "FN42 K1IO" to you all
down in FN20.  I respond to both names.

So if you're mobile or portable, your callsign doesn't change, but when
you attach to a router (backbone site), you become visible to the whole net
by way of that router, which is reached by a mnemonic region address.
There may be many routers per section net.  The gating factors on size of
a section net are 1) size of flat routing table, and 2) amount of routing
information to be interchanged.  The second is more important since
routers will periodically inform each other of who's attached to whom.
(K1IO subtending W1MX within FN42, hence I'm reached as "FN42 K1IO" or
the like, with the section net routing to me via W1MX transparently to
the wide area.)

The details are much longer than this but that's the general flavor.
It's heirarchical, not flat, and handles portables nicely.  I tend to
like using Maindenheads for section-ID, but I suppose you could use
ARRL section, congressional district, or name_of_local_Bell_Operating_Co.
if you prefer, on a netwide basis.  Aliases are legal:  nearby squares
can be one section-net even and respond to different section names.
(How else to handle Alaska, Montana et al?)

I don't dislike IP; I'm looking into getting real live automatic routers
running on ham-IP.  But for the Long Haul with Lots of Users, it would
be nice to have a heirarchical mnemonic naming scheme.  Comments are
solicited (mail to [e-mail]).  The full AmOSInet paper
detailing it will be mailed on request (please, use Mail, not News, for
requests.)
     fred k1io


 1-Dec-87 20:45:37-EST,1808;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 1 Dec 87 20:45-EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Tue, 1 Dec 87 17:28:55 EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Tue, 1 Dec 87 17:28:21 EST
Received: from chem.span by VLSI.JPL.NASA.GOV with VMSmail ;
    Tue, 1 Dec 87 14:21:01 PST
Date:    Tue, 1 Dec 87 14:21:01 PST
From: [e-mail] (Bob Wood WA7MXZ, USU Chemistry)
Message-Id: <[e-mail]>
Subject: Quality of Sources
To: [e-mail]
X-St-Vmsmail-To: JPLLSI::"[e-mail]"

RE: Availability of sources:
>> Consider as a counterexample the hoarding of source code for the
>> TNC-1 which held us all back for years.

Bob Hoffman states:
> If I recall correctly, Harold Price, NK6K, offered the TNC-1 source
> code to anyone who would send him a couple of diskettes, return
> postage, and a statement that it would not be used for commercial
> gain.

     I receoved the 'SOURCE' to the TNC1 from Harold Price, NK6K. The
sources were an OLD release, 3.1, and buggy as Maine in June. 1/3 of the
code was tables, 1/3 was 6809 assembly by Margaret Morrison, and the last
1/3 was Harold's PASCAL. The program was developed on an HP64000
microprocessor development system and was not easily transported to any
other type of development system. When TNC1 software development stopped I
asked Harold for the latest software and was turned down flat. I was in a
position at that time to work on an upgraded release for the TNC1. Harold
was of NO help whatsoever in releasing the code for NEW development. Please
don't use NK6K as an example of RELEASING source code.
Bob Wood, WA7MXZ

 2-Dec-87 13:53:57-EST,3013;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 2 Dec 87 13:53-EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Wed, 2 Dec 87 12:48:49 EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Wed, 2 Dec 87 12:46:19 EST
Received: by LANL.GOV (5.54/1.14)
    id AA12058; Wed, 2 Dec 87 10:40:43 MST
Received: by MILNET-GW.GOV (5.54/5.17)
    id AA13753; Wed, 2 Dec 87 10:43:48 MST
Received: by a (5.51/5.17)
    id AA07152; Wed, 2 Dec 87 10:43:03 MST
Date: Wed, 2 Dec 87 10:43:03 MST
From: [e-mail] (Dave Wade)
Message-Id: <8712021743.AA07152@a>
To: [e-mail]
Subject: Lately, hardware is so much cheaper than software...
Cc: [e-mail], [e-mail]


This is going to make my ignorance obvious, but...

I understand that some of our "Bridge Boxes" (Bridge Communications, inc)
"learn" the routing to get to workstations.  I assume that they keep
trying "all" routings until they get an "ack", and then they use that
routing as long as it works.  Why shouldn't Packet be set up that way?

Some early software types were smart enough to realize that >75% of the
time you could send your response back along the path it had come and
the path the message traveled would have been optimized because of the
"rule of non-duplication of old messages" built into the software if every
station repeated the message to all other stations one-time only.  There
are lots of benefits to be gained by hiding entire lans behind gateways,
and one major benefit is that this wave theory will eventually get every
message to every place.

If the rule for trying the next routing was that you had to wait X time to
give the first routing a chance to respond so you could "learn" a path to
your recipient, the initial contact might take a long time, but your
machine would "learn" the paths to anyone, anywhere, without any geographical
data at all...  The machine would "teach itself" to talk with whomever you
wanted to talk to for "most" of your contacts.  The portable operation
would be trivial if it was initiated by the person who was portable, you
would merely follow the back-path and the regular path with the same
message and see which one got acknowledged.  Should you be looking for a
person who is portable, if you knew she was portable, you could tell your
software to "scan" for it's acknowledgement, or the software could begin
"scanning" after a "much longer" wait for acknowledgement than normal.

Isn't all of this built into tcp-ip and/or ethernet already?  Or is this
a mishmash of Usenet on top of tcp-ip?

Dave
WB5PFS

Still looking for a way to plug his Icom 02at into his Macintosh+ without
having to buy a "modified Color Computer (acting as a tnc)" so they can
talk to each other.  The serial port on the Mac has a signal which should
be adaptable as "push-to-talk", and my Mac is smarter than all three of
my CoCos...
 2-Dec-87 17:14:01-EST,1230;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 2 Dec 87 17:13-EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Wed, 2 Dec 87 14:47:13 EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Wed, 2 Dec 87 14:46:59 EST
Received: by june.cs.washington.edu (5.52.1/6.11)
    id AA16850; Wed, 2 Dec 87 11:47:12 PST
Return-Path: <uunet!mnetor![e-mail]>
Message-Id: <[e-mail]>
Date: 1 Dec 87 15:39:20 GMT
From: uunet!mnetor![e-mail] (Jim Stewart)
To: [e-mail]
Subject: SDLC cards for PC
Keywords: SDLC PC IBM

About 6 months ago, I believe that someone said IBM is no longer
making their 'dumb' SDLC card for the PC.  The person or the
discussion lead to a list of available SDLC cards for the PC.
I have lost that article, and it has fallen off the back end of
the news we keep around.

If someone has this information I would appreciate it if they
could send it to me, or post it to start a new discussion.

tnx...
--
Jim Stewart, VE3SRJ
UUCP:  {decvax|allegra|ihnp4|linus|utcsri}!utzoo!mnetor!jim
ARPA:  mnetor![e-mail]
BELL:  [phone] x303


 2-Dec-87 18:16:20-EST,15090;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 2 Dec 87 18:16-EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Wed, 2 Dec 87 14:45:33 EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Wed, 2 Dec 87 14:44:58 EST
Received: by june.cs.washington.edu (5.52.1/6.11)
    id AA16635; Wed, 2 Dec 87 11:45:11 PST
Return-Path: <cbosgd!gwspc!cbcsta!n8emr![e-mail]>
Message-Id: <[e-mail]>
Date: 27 Nov 87 18:29:18 GMT
From: cbosgd!gwspc!cbcsta!n8emr![e-mail] (Gary Sanders )
To: [e-mail]
Subject: gateway nov 20

Here is the lastes copy of the electronic edition of gateway
newsletter. I picked it up off of my local packet BBS.
Gateway and The ARRL letter were being distribued in rec.ham-radio
a number of months ago, but the source for the newsletter had dried up.
Now that it is back, Do you want me to continue gatwaying it into
the usenet network? If so please let me know.

Gary W. Sanders         {ihnp4|cbosgd}!n8emr!gws,  gws@n8emr
(cis) 72277,1325        (packet) N8EMR @ W8CQK
HAM/SWL BBS (HBBS) 614-457-4227.. 300/1200 bps


Relayed from W8CQK packet bbs by N8EMR
--------------------------------------

Gateway: The ARRL Packet Radio Newsletter
Stan Horzepa, WA1LOU, Editor
Volume 4 Number 5 - November 20, 1987 - Part 1 of 3

EASTERN AREA STAFF SUPPORTS ZIP ADDRESSING

Packet-based radiogram routing dominated the issues at the National Traffic
System's Eastern Area Staff (EAS) meeting October 24-25 in Virginia.  Area
Staffs, which comprise all NTS Officials above the section-level, serve to
advise the ARRL Field Services Manager (Rick Palm, K1CE) on major National
Traffic System (NTS) issues, and maintain the day-to-day long-haul
functions of the NTS.

The EAS passed two significant motions recommending 1) ZIP code addressing
for routing of radiograms through the emerging PBBS auto-forwarding
network, and 2) a study of specific proposals made by members of the
Northeast-based Radio Amateur Telecommunications Society (RATS) for NTS
user interface with the system.  The latter was referred to the EAS Region
Packet Managers; their report is due March, 1988.  (Region Packet Managers
are special advisors to EAS members.)

>from The ARRL Letter

NETWORK PERFORMANCE MONITORING SOFTWARE

Did you ever wonder how well your local packet-radio network is real
working (or not working)?  If you read the paper entitled "Performance
Monitoring -or- 'I Wanna Fix It, Is It Broke?'" that was presented by Skip
Hansen, WB6YMH, and Harold Price, NK6K, at the 6th ARRL Computer Networking
Conference, you know that Skip and Harold were developing software to
monitor received frames, accumulate data and periodically dump the data
into a log file that could be used to compile statistics concerning network
performance.  That software is now available from CompuServe's HamNet.  Its
file name is MONAX2.ARC and it is written in C for the IBM PC or a
compatible computer.  A TNC with KISS capability is necessary to use the
software.

{A description of new products available from Kantronics was included in
this section.  Since it COULD be considered commercial in nature, it was
deleted in this edition for Packet Distribution.}

220-MHz SPORADIC E STUDY VIA PACKET RADIO

In the November issue of QEX, editor Paul Rinaldo, W4RI, proposed that
a packet radio network be established to study sporadic E and other
propagation in the 220-MHz band.  Citing the automatic beaconing and
listening capabilities of packet radio, W4RI suggests that "receiving
stations can be set up to receive and store all beacon transmissions heard"
and "if transmitting stations use a simple computer program to send the
date and time in each packet transmission, receiving stations can store
the data for later analysis." Such detective work could solve some of the
riddles of 220-MHz propagation.  Is anyone willing to take up this
challenge?


TNC 2 MODIFICATION

Paul Williamson, KB5MU, has designed a modification to the TAPR TNC 2
which allows two EPROMs each containing different software to be installed
simultaneously, selectable from a front panel switch.  Paul wants somebody
to try out his instructions before they are published.  Any volunteers?

>from San Diego Packet Radio Association Newsletter

220-MHz PBBS PORT FOR NOVICES

Rob Marzili, KC3BQ, has activated a 223.58 MHz port for his Skaneateles,
New York (near Syracuse) KC3BQ PBBS in order that Novices may enjoy the
packet radio BBS operation.

>from The Upstate Packet News

(Gateway would like to publicize other Novice packet activities, so if you
know of any, please let me know - WA1LOU.)


SYSOPS FOR ZIPS?

I would like to run an idea around to my fellow PBBS SYSOPs.  I would like
to put forth the idea that perhaps we are going in the wrong direction with
our ever-expanding PBBS automatic forwarding system.  The present system
depends on a very well-maintained list of the other PBBSs and who you have
to go through to get to them.  We ask everybody to be listed in a white
pages system so we can keep track of where everyone's home PBBS is.
Changes are constantly being made, requiring a great deal of editing of
forwarding files by many SYSOPs.  Is there a different and, perhaps, a
better way?  Maybe.

Some of the NTS people have decided to use the US Postal System of ZIP
codes to route their traffic.  If this method will work for NTS, why not
for regular, non-NTS, ham-to-ham messages.  If a local here in the western
Michigan area wishes to send a note to a buddy ham of his in Dallas, Texas,
he would address it as: SP WA5ABC @ 752.  A local PBBS would figure out
immediately that it goes out of state, so it would be sent to Michigan's HF
gateway, WA1LRL in Brighton.  WA1LRL would look up 75* ZIP as going to
Texas and then the Texas HF station would drop it to the local PBBS that
covers the 752 ZIP.  Compared to the present method, no header editing
would be needed by any SYSOP to get the traffic into Texas.  Any changes in
an area would only be required by that area's local PBBSs.  A PBBS in
Florida would not need to know about any new, changed or deleted PBBS
stations in western Michigan.  At present, we either request a local user
to specify the destination PBBS or, we, as SYSOPs, have to look it up
ourselves.  Sources for the ZIP codes are easy to come by, indeed, here in
Grand Rapids I can call the local post office on a special line to get any
ZIPs for the largest 100 cities in each state.

To address the problem for our friends in other countries, who do not have
the same ZIP code system as the United States, we would put "DXxxx" in the
@-field, where xxx is the international telephone exchange country number.
Then, in the subject field, we would request that the originator put that
country's ZIP code, whatever its format might be.  Since Canada and Mexico
use the same telephone Area Code system as the United States, we could
either use "@ DXVE1" or "@DX514" for Montreal as an example.  Another
possibility would be for all United States non-NTS messages to be formatted
with a "@U49508."

Maybe I have overlooked a serious flaw in this proposed system, but, more
than once, I have had a local user either not have any idea who the local
PBBS was for his buddy or give me a call that his buddy said was valid for
a home PBBS, but I am unable to find any record of it.  In addition, we
have WA1LRL in Michigan, W0RLI in California, etc., so the number in the
call sign can not be depended upon to locate a station.

One more plus: check your existing forwarding file and see how much simpler
it would be with ZIP code routing.  Once the message came to stop at a
PBBS, we might have a minor modification to the PBBS's code to strip the @
>from the message header and then that PBBS could route it per local user
tables.

If you have any opinion, please feel free to send it back to western
Michigan.  If your existing file has me in it, fine, if not route to WA1LRL
or W9ZRX.  And, if the ZIP code system were operational, use WA8URE @
49508!

>from Tom Bosscher, WA8URE


BEWARE OF MEGA-PACKETS

I have been noticing a whole lot of "Mega-Packets" lately --- hand typed
packets which are longer than 80 or so characters --- many of them as high
as 255 characters.  I suspect those who are originating them do not realize
what is going on.

All modems have a bit error rate (BER) which is how many bits can be sent
(on the average) before an error occurs.  When an error occurs, we have to
retry.  Other factors that contribute to the BER in the real world are
propagation and collisions.  It is fairly easy to calculate the size of a
packet (7 bytes X 2 for call signs, + 1 control byte, +s the data, + a
2-byte checksum).  Assuming BER is a constant, an 80-character packet
consists of 97 bytes or 776 bits, while a 255-character Mega-Packet
consists of 272 bytes or 2176 bits.  As a result, a Mega-Packet is 2.8
times more likely to get damaged before reaching its destination.  So, not
only does it take 2.8 times as long to transmit, but it will (on the
average) take 2.8 more tries or something like 7.84 times as much network
time to transmit as it would if the message was broken into three saner
sized packets.

Also, these quick calculations do not take into account the actual value
for BER.  If the BER is 0.05% (1 in 2000), the 2716 bit Mega-Packet will
likely never get through.  Mathematics aside, the Flow parameter in the TNC
allows very comfortable QSO type operation in a full-duplex environment if
you just hit return after each 80-column line.  If your friend is using a
shorter screen display, try to hit return more often to accommodate him.
If you cannot remember to hit return after each line, at least set Paclen
to a lower value (say 75 or so) --- then the whole network will be more
efficient and we will be able to share the channel more effectively;
everything will work better.

>from Lynn Taylor, WB6UUT, via San Diego Packet Radio Association Newsletter

WA7MBL: NOT A TRAFFIC KILLER!

In our description of the KT command in Gateway, Volume 4, Number 3, it is
implied that all PBBS software supports the KT command, when, in fact, it
is supported by W0RLI PBBS software, but is not supported by WA7MBL PBBS
software (version 3 and higher).

TPRS ADDRESS CORRECTION

The address for the Texas Packet Radio Society (TPRS) as published in
Gateway, Volume 4, Number 1, was wrong.  The correct address is:

   Texas Packet Radio Society
   PO Box 831566
   Richardson, TX 75083-1566


 ZIP CODE DIRECTORY

To supplement the ongoing study and discussion concerning the use
of ZIP codes to route NTS traffic via the packet radio network,
Gateway presents the following list of ZIP code 2-digit prefixes
(the first two digits of a ZIP code).  The first list is sorted
alphabetically by location; the second list is sorted numerically
by ZIP code prefix.

List 1.  Alphabetically By Location

Location        ZIP Prefix
Alabama         35, 36
Alaska          99
Arizona         85, 86
Arkansas        72, 73
California      90, 91, 92, 93, 94, 95
Colorado        80, 81
Connecticut     06
Delaware        19
D of Columbia   20
Florida         32, 33, 34
Georgia         30, 31
Hawaii          96
Idaho           83
Illinois        60, 61, 62
Indiana         46, 47
Iowa            50, 51, 52
Kansas          66, 67
Kentucky        40, 41, 42
Louisiana       70, 71
Maine           04
Maryland        20, 21
Massachusetts   01, 02
Michigan        48, 49
Minnesota       55, 56
Mississippi     38, 39
Missouri        63, 64, 65
Montana         59
Nebraska        68, 69
Nevada          89
New Hampshire   03
New Jersey      07, 08
New Mexico      87, 88
New York        09, 10, 11, 12, 13, 14
North Carolina  27, 28
North Dakota    58
Ohio            43, 44, 45
Oklahoma        73, 74
Oregon          97
Pennsylvania    15, 16, 17, 18, 19
Puerto Rico     00
Rhode Island    02
South Carolina  29
South Dakota    57
Tennessee       37, 38
Texas           75, 76, 77, 78, 79
Utah            84
Vermont         05
Virginia        22, 23, 24
Washington      98, 99
West Virginia   25, 26
Wisconsin       53, 54
Wyoming         82

List 2.  Numerically By ZIP Prefix

ZIP Prefix      Location
00              Puerto Rico
01              Massachusetts
02              Massachusetts and Rhode Island
03              New Hampshire
04              Maine
05              Vermont
06              Connecticut
07, 08          New Jersey
09-14           New York
15-18           Pennsylvania
19              Delaware and Pennsylvania
20              District of Columbia and Maryland
21              Maryland
22-24           Virginia
25, 26          West Virginia
27, 28          North Carolina
29              South Carolina
30, 31          Georgia
32-34           Florida
35, 36          Alabama
37              Tennessee
38              Mississippi and Tennessee
39              Mississippi
40-42           Kentucky
43-45           Ohio
46, 47          Indiana
48, 49          Michigan
50-52           Iowa
53, 54          Wisconsin
55, 56          Minnesota
57              South Dakota
58              North Dakota
59              Montana
60-62           Illinois
63-65           Missouri
66, 67          Kansas
68, 69          Nebraska
70, 71          Louisiana
72              Arkansas
73              Arkansas and Oklahoma
74              Oklahoma
75-79           Texas
80, 81          Colorado
82              Wyoming
83              Idaho
84              Utah
85, 86          Arizona
87, 88          New Mexico
89              Nevada
90-95           California
96              Hawaii
97              Oregon
98              Washington
99              Alaska and Washington

Note that the following locations share the same 2-digit prefix:

Location                        Shared Prefix
Alaska and Washington                99
Arkansas and Oklahoma                73
Delaware and  Pennsylvania           19
District of Columbia and Maryland    20
Massachusetts and Rhode Island       02
Mississippi and Tennessee            38

Needless to say, submissions for publication in "Gateway" are welcome.
Submit material via the US mail to:

   Gateway
   Stan Horzepa, WA1LOU
   75 Kreger Drive
   Wolcott, CT 06716-2702

or electronically, via CompuServe to user ID 70645,247

REPRODUCTION OF GATEWAY MATERIAL

Material may be excerpted from Gateway without prior permission, provided
that the original contributor is credited and Gateway is identified as the
source.


--
Gary W. Sanders         {ihnp4|cbosgd}!n8emr!gws
(cis) 72277,1325        (packet) N8EMR @ W8CQK
HAM/SWL BBS (HBBS) 614-457-4227.. 300/1200 bps


 2-Dec-87 21:39:23-EST,1952;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 2 Dec 87 21:38-EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Wed, 2 Dec 87 19:58:34 EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Wed, 2 Dec 87 19:58:11 EST
Message-Id: <[e-mail]>
Received: from relay2.cs.net by RELAY.CS.NET id ac05189; 2 Dec 87 18:58 EST
Received: from pitt by RELAY.CS.NET id ab28008; 2 Dec 87 18:49 EST
Received: by pitt (5.51/4.7)
    id AA16056; Wed, 2 Dec 87 11:08:20 EST
From: Bob Hoffman <[e-mail]>
To: [e-mail]
Date: Wed, 2 Dec 87 11:08:17 EDT
Subject: Quality of Sources
X-Mailer: ELM [version 1.2a]

> From: "Bob Wood WA7MXZ, USU Chemistry" <[e-mail]>
>
> ...
> sources were an OLD release, 3.1
> ...  When TNC1 software development stopped I
> asked Harold for the latest software and was turned down flat.
> ... Please
> don't use NK6K as an example of RELEASING source code.

OK, I stand corrected.  I thought Harold was more reasonable than
that.  On the other hand, if the 'latest' was nonworking spaghetti
code, I might be a little reluctant to let anyone else see it, too!
As one person once put it, "A Real Programmer can write a FORTRAN
program in _any_ language!"

The last release I know about was TAPR 3.3, which differed from 3.1
by only a few bytes.  If those patches were in the assembly code, it
should have been easy to update the source, although one reply I
received by mail indicated that Margaret's assembly source wasn't
released at all.

I am thankful that WA8DED did his alternate ROM set for the TNC1
and that WB6ECE and PA0GRI did the KISS ROM for it.  I have enough
investment in TNC1s that I appreciate those efforts to keep them
usable.  While the 'DED command interpreter may not be for everyone,
I certainly like it.

    ---Bob.

 3-Dec-87 00:28:34-EST,3950;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 3 Dec 87 00:28-EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Wed, 2 Dec 87 21:51:13 EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Wed, 2 Dec 87 21:50:31 EST
Received: by june.cs.washington.edu (5.52.1/6.11)
    id AA04031; Wed, 2 Dec 87 17:17:25 PST
From: umunhum![e-mail]
Return-Path: <umunhum![e-mail]>
Message-Id: <[e-mail]>
To: [e-mail]
Subject: TANSTAAFP
Keywords: There Ain't No Such Thing As A Free Protocol...
Date: 2 Dec 87 06:34:41 GMT
Reply-To: [e-mail] (Paul Flaherty)

Well, it would appear that those enamoured with the OSI - COSI stack have
run out of substantive arguments, for now they attack my poetry.  Reminds me
of the quality of argumentation that I hear on weekends, judging high school
debates...:-)

Now, on more substantive matters...

    Assume the following exists (it probably will in five years):

    1. Groups of geographically close users will join to form subnets;
        Each subnet having one or more gateways used to communicate
        with other subnets.

    2. Communications between subnets which are geographically close
        will occur using terrestrial data links between gateways.

    3. The AMNET will provide long distance communications between a
        small number of subnets (about 10).


    The resulting dendrite network is fairly easy to manage, with respect
to address assignment.  In the first case, most users will probably want one
fixed station IP address, for their home machine.  Since this machine will
be used for mail reception, it is reasonable to assume that it is always
available to the subnet, excepting downtime, until the owner changes fixed
physical locations.  If he moves out out the area that is covered by the
subnet, he must obtain a new IP address which is consistent with the local
subnet.

    In a way, gateway ownership should develop in a way similar to
repeaters; that is, becoming group - owned entities.

    Of course, mobile / portable operation is also desirable, and this
raises the problem of how to use an IP address outside of a subnet.

    My solution to the address / naming problem is a roving protocol,
called PRRP (yes, that's Packet Radio Roving Protocol), which is used by
stations "not at their assigned subnet".  PRRP assumes that everyone has
a permanent IP address, for use at their "home" subnet.  Now, when one
operates out of that subnet (called "roving"; anybody who's familiar with
AUTOVON should get this), one requests a "roving" IP address from the
gateway.  Since it is assummed that only a very few stations will be roving
at any particular time, only a small number of IP subnet addresses need to
be reserved for the roving pool.  Also, the assignment only lasts for a
short period of time; if the gateway doesn't hear from the rover for a day
or two, the IP address goes back into the pool.

    Basically, a PRRP transaction goes something like this:

Rover Poweron: My Permanent IP address is 44.4.0.50, AX25 is N9FZX
Rover > Gateway: N9FZX/44.4.0.50 PRRP
Gateway > Rover: N9FZX/44.22.0.10 -PRRP
Rover: Change IP address to 44.22.0.10 until powerdown.

    This is a very simple scheme; however, I'd be willing to argue that it
will provide most of the desired functionality.  Security is one issue I
havn't addressed, although one should not base security on network addresses
anyway.  Also, I'd welcome any additions to this, since it will be a real
breathing protocol eventually.





-=Paul Flaherty, N9FZX           | "One Internet to rule them all,
Computer Systems Laboratory      |          One Internet to find them,
Stanford University              |  One Internet to bring them all
Domain: [e-mail]|          and in the ether bind them." -ToIH


 3-Dec-87 03:29:55-EST,817;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 3 Dec 87 03:29-EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Thu, 3 Dec 87 02:46:51 EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Thu, 3 Dec 87 02:46:33 EST
Posted-Date:  3 Dec 87  8:15 +0100
Received: by tor.nta.no (5.54/3.21)
    id AA10785; Thu, 3 Dec 87 08:18:55 +0100
Date:  3 Dec 87  8:15 +0100
From: Karl Georg Schjetne <[e-mail]>
To: <[e-mail]>
Message-Id: <597*[e-mail]>
Subject: GATEWAY

Dr om Gary,N8EMR,

Please go on distributing GATEWAY via this network!
It makes life easier for us SYSOPS, I can transfer it directly to
the local MBL mailbox.

Karl Georg Schjetne, LA8GE.
 3-Dec-87 15:17:35-EST,3412;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 3 Dec 87 15:17-EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Thu, 3 Dec 87 13:52:51 EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Thu, 3 Dec 87 13:52:36 EST
Received: from titan.rice.edu by rice.edu (AA02642); Thu, 3 Dec 87 12:49:07 CST
Received: by titan.rice.edu (AA01000); Thu, 3 Dec 87 12:48:57 CST
Date:     Thu,  3 Dec 87 11:07:33 CST
From: Paul Milazzo <[e-mail]>
Subject:  Re: TANSTAAFP
Cc: [e-mail]
To: [e-mail] (Paul Flaherty)
Message-Id: <[e-mail]>
In-Reply-To: <[e-mail]>
Summary:  It's a good idea, but it doesn't require a new protocol.

Paul:

I'm not a ham (yet?), but I'm interested in packet radio in general -
and have some experience with layering IP over X.25 - so I've been
trying to follow the amateur radio IP addressing discussions.

Your idea of hierarchic routing with "guest" addresses is interesting,
but your proposal does not describe any way to perform the inverse
mapping.  The mappings IP requires in the context of amateur packet
radio can be confusing because hams apparently use the amateur callsign
as both a link-layer address (your AX.25 address N9FZX) and a hostname
(N9FZX.whatever).  Since I'm among the confused, let me enumerate the
requirements:

The network's goal is to take the name of a resource (a host) and send
that resource packets.  Achieving this goal in an IP environment takes
at least the following forward mappings:

1) hostname -> IP address
2) IP address -> link-layer address

The first inverse mapping:

3) IP address -> hostname

is often convenient, and easy for the agent that performs (1) to
provide.  Additionally, any scheme which, like yours, relies on dynamic
IP address assignment must provide a service that maps:

4) link-layer address -> IP address

which your PRRP performs.  However, in your scheme that mapping is not
predictable; to achieve the primary goal of delivering packets to a
named host, the dynamic address assignment agent must inform the host
name translation agent of the host's new IP address.

Mechanisms that provide these functions in the Internet already exist.
The domain name service [RFC 1034/1035] performs mappings (1) and (3);
ARP [RFC 826] performs mapping (2).  Reverse ARP [RFC 903] and its
successor BOOTP [RFC 951] perform mapping (4).

PRRP appears to be a simplified, all-ASCII version of RARP.  Why not
just use RARP, or better yet BOOTP?  An AX.25 hardware type already
exists for ARP, and thus for RARP and BOOTP.  Besides, I believe
existing BOOTP implementations can interact with domain name servers to
provide dynamic hostname -> IP address mapping.

In summary, your proposal, like others we've seen, allows hierarchic
routing with an exception list for roving hosts.  Unlike previous
schemes, yours pushes the exception list up out of the IP layer,
eliminating the overhead of checking for exceptions on every packet.  I
like this advantage, but feel your proposal should:  (a) use existing
protocols, and (b) provide for dynamic hostname -> IP address mapping.

                Paul G. Milazzo <[e-mail]>
                Dept. of Computer Science
                Rice University, Houston, TX
 3-Dec-87 21:31:58-EST,6335;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 3 Dec 87 21:31-EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Thu, 3 Dec 87 19:43:16 EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Thu, 3 Dec 87 19:42:26 EST
Message-Id: <[e-mail]>
Received: by umunhum.stanford.edu; Thu, 3 Dec 87 16:40:56 PST
Date: Thu, 3 Dec 87 16:40:56 PST
From: Paul Flaherty <[e-mail]>
Subject: Re: TANSTAAFP
To: [e-mail], [e-mail]
Cc: [e-mail]

>Your idea of hierarchic routing with "guest" addresses is interesting,
>but your proposal does not describe any way to perform the inverse
>mapping.  The mappings IP requires in the context of amateur packet
>radio can be confusing because hams apparently use the amateur callsign
>as both a link-layer address (your AX.25 address N9FZX) and a hostname
>(N9FZX.whatever).  Since I'm among the confused, let me enumerate the
>requirements:

Nameserving is not really a major problem; it exists as a convenience to the
user, since some people find it easier to remember names than numbers.
Since nameserving exhibits locality, we only need to look at the "big list"
very sparsely, and specifically, for the sending of mail.  For most
applications, eg., telnetting, we seldom access oddball hosts.  Thus, the
net restriction on PRRP is that it really can't be used for receiving mail.
This is a very minor disadvantage for two reasons.  First of all, a machine
being used for mail reception shouldn't be moving anyway; it should be as
static as possible.  The DEC-20 mainframes here at Stanford (which I'm told
will disappear Real Soon Now) are used primarily as mail machines, simply
because they've been around forever, and people know how to get to them.
Secondly, a portable need only telnet to a fixed address to read mail, which
accomplishes the same purpose.

>Additionally, any scheme which, like yours, relies on dynamic
>IP address assignment must provide a service that maps:
>
>4) link-layer address -> IP address
>
>which your PRRP performs.  However, in your scheme that mapping is not
>predictable; to achieve the primary goal of delivering packets to a
>named host, the dynamic address assignment agent must inform the host
>name translation agent of the host's new IP address.

I'm afraid that you've missed my point, which is, "dynamic routing for
physically portable hosts is a losing proposition".  The goal of PRRP is
NOT to redirect IP packets from your home gateway to a remote.  Instead,
we allow mobile stations to request a local IP loaner address.

>Mechanisms that provide these functions in the Internet already exist.
>The domain name service [RFC 1034/1035] performs mappings (1) and (3);
>ARP [RFC 826] performs mapping (2).  Reverse ARP [RFC 903] and its
>successor BOOTP [RFC 951] perform mapping (4).

PRRP is probably most similar to BOOTP, since it accomplishes the
physical to IP bijective mapping, AND a local IP address assignment, in
one transaction.

>PRRP appears to be a simplified, all-ASCII version of RARP.  Why not
>just use RARP, or better yet BOOTP?  An AX.25 hardware type already
>exists for ARP, and thus for RARP and BOOTP.  Besides, I believe
>existing BOOTP implementations can interact with domain name servers to
>provide dynamic hostname -> IP address mapping.

Different protocols, different purposes.  We can't use ARP, since ARP doesn't
know about address loaning.  Ditto for RARP and BOOTP.

>In summary, your proposal, like others we've seen, allows hierarchic
>routing with an exception list for roving hosts.  Unlike previous
>schemes, yours pushes the exception list up out of the IP layer,
>eliminating the overhead of checking for exceptions on every packet.  I
>like this advantage, but feel your proposal should:  (a) use existing
>protocols, and (b) provide for dynamic hostname -> IP address mapping.
>
>>>>>Paul G. Milazzo <[e-mail]>
>>>>>Dept. of Computer Science
>>>>>Rice University, Houston, TX

On (a):

    Given that none of the existing protocols deal with address loaning,
it would be far simpler to define a new protocol than hack an old one.  At
the moment, I'm looking at hacking BOOTP into PRRP; BOOTP does almost
everything that I want it to, except handle loaning.  One final reason for
not using BOOTP would be the incompatibility with existing implementations,
when mixed on one network.

On (b):

    When I originally came up with the idea of loaning temporary IP
addresses, I encompassed the general problem of rerouting traffic from a
users's home gateway to the current one.  I eventually came to the conclusion
that this was necessarily a bad idea for a number of reasons, not limited to
the following:

    1) Efficiency.  If redirection occurs at the home gateway, then
    traffic winds up zigzagging through the network, gobbling up
    expensive bandwidth.

    2) Security.  IP address impersonation becomes a trivial matter;
    moreover, malicious redirects could easily swamp the net.

    3) Desirability.  What do people really want to be able to do with
    their portable machines?  Well, most of the things that they do
    with their fixed machines, EXCEPT mail reception. (And, if your
    mail is really THAT important, it is a fairly simple matter to
    tell the mailer on your fixed machine to forward it to your
    temporary address.)  Given that the vast majority of nameserving
    transactions are for mail messages (I can't prove that at the
    moment, but I'd wager), this is a pretty trivial limitation.


    Some people would argue that this necessarily makes portable nodes
second class citizens.  Some would argue that portable nodes SHOULD be
second class citizens.  Both are right as far as I can see.

    The idea of a network that is intellegent enough to find me whereever
I may be is novel, but is also hideously inefficient, and really of
questionable utility.

-=Paul Flaherty, N9FZX           | "One Internet to rule them all,
Computer Systems Laboratory      |          One Internet to find them,
Stanford University              |  One Internet to bring them all
Domain: [e-mail]|          and in the ether bind them." -ToIH


 5-Dec-87 13:53:28-EST,1196;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 5 Dec 87 13:53-EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Sat, 5 Dec 87 12:05:18 EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Sat, 5 Dec 87 12:04:56 EST
Received: by june.cs.washington.edu (5.52.1/6.11)
    id AA25774; Sat, 5 Dec 87 09:04:49 PST
Return-Path: <caseus![e-mail]>
Message-Id: <[e-mail]>
Date: 3 Dec 87 15:28:48 GMT
From: caseus![e-mail] (Daniel M. Frank)
To: [e-mail]
Subject: TCP/IP Stories Wanted
Keywords: amateur packet
Reply-To: [e-mail] (Daniel M. Frank)

   Can anyone who has set up an amateur packet network using
TCP/IP contribute a description of how they went about doing
so?  Details of technical issues encountered, network design
hints, administrative and organizational arrangements, and so
forth would be very much appreciated.

   Thanks!

--------
Dan Frank  (w9nk)
ARPA: [e-mail]   UUCP: ... uwvax!dan   PACKET: W9NK @ W9WI
Att'n ADA: {prosperity,freedom,work,responsibility,honesty,self-reliance}


 5-Dec-87 21:12:39-EST,1182;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 5 Dec 87 21:12-EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Sat, 5 Dec 87 20:13:03 EST
Received: from mc.lcs.mit.edu by EDDIE.MIT.EDU via Chaosnet with SMTP with sendmail-5.45/4.7 id <[e-mail]>; Sat, 5 Dec 87 20:12:51 EST
Resent-Message-Id: <[e-mail]>
Received: from SIMTEL20.ARPA (TCP 3200000112) by MC.LCS.MIT.EDU  5 Dec 87 20:05:04 EST
Date: Thursday, 3 December 1987  10:24-MST
Message-Id: <[e-mail]>
Sender: Tim Fennell <hadron!inco![e-mail]>
From: Tim Fennell <hadron!inco![e-mail]>
To: Keith Petersen <[e-mail]>
Subject:   KA9Q TCP/IP software for Turbo C
Resent-From: [e-mail]
Resent-To: [e-mail]
Resent-Date: Sat 5 Dec 1987 18:04-MST

I understand there is a version of the KA9Q TCP/IP software ported to
Turbo C.  Do you know how I could get a copy of the software?

Thanks ahead of time,

Tim Fennell     (inco!fennell)
McDonnell Douglas/ Inco.
McLean, Va.
(800)-368-4626
(703)-883-3837

 6-Dec-87 13:16:30-EST,2338;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 6 Dec 87 13:16-EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Sun, 6 Dec 87 12:23:39 EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Sun, 6 Dec 87 12:23:25 EST
Received: by june.cs.washington.edu (5.52.1/6.11)
    id AA12568; Sun, 6 Dec 87 09:23:10 PST
From: rutgers!clyde!burl!codas!mtune!petsd!pedsga!tsdiag![e-mail]
Return-Path: <rutgers!clyde!burl!codas!mtune!petsd!pedsga!tsdiag![e-mail]>
Message-Id: <[e-mail]>
Date: 3 Dec 87 19:43:55 GMT
To: [e-mail]
Subject: Re: Let's calm down the CONS/CLNS flames just a bit?
References: <[e-mail]> <[e-mail]>


Bill,
      Glad to hear you like the DR-200 and software.

The code you are running was an attempt to create a good programming
environment to work on the networking problems we face.  It was a
limited success.  I did a lot of work with Howie on the basic design
and structure of the internals and it worked but was not extendable
enough to fill our needs.

I started working on a rewrite in June of this year and expect to
start on-the-air testing this weekend.

What have I developed?

A Level 3 packet switch using the X.25 standard including routing functions
(using Area Code/Exchange for the addressing); Level 2 User interface that
can be used by all, Including BBS's and multi-level routing tables to support
routing alternatives, to by-pass down nodes if another path exists.

There will be an announcement going out shortly.

We expect to be able to send the code out in Jan. '88.

SIX Meters? Humm...

We have discussed using 6 for some local access channels to get around the
low rolling hills here in NJ...

It could be interesting having a 6M port...

Howie is alive and well in FLA, expecting to graduate in August,
that's part of why he has been keeping a low profile, he WANTS OUT!!! -:)

73,

--
Thomas A. Moulton, W2VY          Life is too short to be mad about things.
Home: (201) 779-W2VY             Packet: w2vy@kd6th  Voice: 145.190 (r)
Work: [phone] x3226       FAX:  [phone]
Concurrent Computer Corp.        uucp: ...!ihnp4!hotps!ka2qhd!w2vy


 6-Dec-87 13:16:58-EST,2922;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 6 Dec 87 13:16-EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Sun, 6 Dec 87 12:20:08 EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Sun, 6 Dec 87 12:19:56 EST
Received: by june.cs.washington.edu (5.52.1/6.11)
    id AA12454; Sun, 6 Dec 87 09:19:43 PST
Return-Path: <husc6!spdcc!k1bc![e-mail]>
Message-Id: <[e-mail]>
Date: 6 Dec 87 02:29:34 GMT
From: husc6!spdcc!k1bc![e-mail] (Bob Clements)
To: [e-mail]
Subject: W0RLI source code

Recently I was taken to task on this net by KA2BQE for a comment I
had relayed from W0RLI, complaining that Brian had taken Hank's
code and put his own copyright on it.
Brian said, in part:
>  Hank and/or Bob,
>
>  I would suggest that you verify your facts before you shoot
>  yourself where the "sun shineth not" !  I am the "2-lander
>  named Brian", the "something" is Riley, and the callsign is
>  KA2BQE.
>
>  The code in question started with a pre-release of
>  W0RLI's earliest posted version (on CompuServe) and at this
>  point contains less than 10% of the original code.  Further,
>  it has doubled in size, and quadrupled in function.
>  ANYONE who has used a PRMBS would take great exeception to
>  the phrase "modified it slightly". ...

I relayed this to Hank, by paper mail, as requested (though I don't
see why I have to be a postman in this matter).  I received the
following response from Hank:
>
>   1855 PY   654 K1BC   W0RLI         1205/0113 Interesting.
>    Path: W1ZHC!W1AW!WA2SNA!WB2RVX!N4QQ!W0RLI
>
>  Very interesting.
>  Thank you for sending.
>  Nice of Brian to send his response to you,
>  and not bother copying me.
>
>  His first source release was my code, EXACTLY,
>  with one change: he put his Copyright notice on it!
>
>  I have the disk here ... as he sent it out.
>
>  Have a good holidays ... and snow.
>
>     ...  Hank
>

So it is clear to me that someone has done something pretty
inexcusable. Either:
1) Brian did what Hank says (In which case Hank is fully
   justified in being annoyed), or
2) Someone sent Hank a disk as described, to make Hank THINK that
   Brian had done that (seems unlikely but possible), or
3) Hank is lying about having received such a disk.

I don't believe number 3.  I know Hank, and he has his character
flaws (he smokes tobacco, for example), but I don't believe he
would lie about such a thing.

So I invite Brian to figure out which of 1) and 2) is true and
report back to us.  I do it publicly here, since he made his
"sun shineth not" comment to me publicly here.  I have checked
my facts as he requested, and believe I am now out of the loop.

73, Bob, K1BC, [e-mail]   "It's just a hobby, right?"


 6-Dec-87 13:26:10-EST,7235;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 6 Dec 87 13:25-EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Sun, 6 Dec 87 12:26:23 EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Sun, 6 Dec 87 12:25:51 EST
Date: Sun, 6 Dec 1987  10:25 MST
Message-Id: <[e-mail]>
Sender: [e-mail]
From: Keith Petersen <[e-mail]>
To: [e-mail]
Cc: [e-mail] (Joe Hollingsworth)
Subject: Xmodem for 4.2/4.3 BSD Unix (and maybe Sys V)

In case you missed the update, Steve Grandi has an excellent Xmodem
for 4.2/4.3 BSD Unix.  It is available via standard anonymous FTP from
SIMTEL20 as:

Filename                        Type     Bytes   CRC

Directory PD2:<UNIX.XMODEM>
XMODEM34.SHAR.1                 ASCII    84452  D010H

The xmodem program implements the Christensen (XMODEM) file transfer
protocol for moving files between 4.2/4.3BSD Unix systems and
microcomputers.  The XMODEM/CRC protocol, the MODEM7 batch protocol,
the XMODEM-1K block protocol and the YMODEM batch protocol are all
supported by xmodem.  For details of the protocols, see the document
edited by Chuck Forsberg titled XMODEM/YMODEM Protocol Reference.

This program runs on 4.2/4.3BSD systems ONLY.  It has been tested on
VAXes and Suns against the MEX-PC program from Niteowl Software and
the ZCOMM and DSZ programs from Omen Technology.

The author tried to keep the 4.2isms (select system call, 4.2BSD/v7
tty structures, gettimeofday system call, etc.) confined to the source
file getput.c; but makes no guarantees.  Also, no attempt was made to
keep variable names under 7 characters.  A version of getput.c that
MAY work on Sys V Unix systems is included.  See notes on other
changes for Sys V.

----------------------------------------------------------------------
[From the author]

Program history:

Descended from UMODEM 3.5 by Lauren Weinstein, Richard Conn, and others.

Based on XMODEM Version 1.0 by Brian Kantor, UCSD (3/84) (Don't blame
him for what follows....)

Version 2.0 (CRC-16 and Modem7 batch file transfer) (5/85)

Version 2.1 (1K packets) (7/85)

Version 2.2 (general clean-ups and multi-character read speed-ups) (9/85)

Version 2.3 (nap while reading packets; split into several source
         files) (1/86)

Version 3.0 (Ymodem batch receive; associated changes) (2/86)

Version 3.1 (Ymodem batch send; associated changes) (8/86)

Version 3.2 (general cleanups) (9/86) (Released to the world 1/87)

Changes leading to version 3.3

1) "Better" handshaking for MODEM7 batch transfers (5/19/87).

2) If reception of a file is aborted due to errors, delete incomplete
file (5/19/87).

3) If an "impossible" tty speed is detected, assume 1200 bps (5/19/87).

4) Disallow CAN-CAN abort during file send or receive except at
beginning of file transfer (during batch transfers, CAN-CAN abort is
allowed at beginning of each file transfer) (5/19/87).

5) Uncouple total allowed errors during the reception of a single
packet (ERRORMAX, now made 10) and errors allowed when starting
transfer (STERRORMAX, set to 10) (5/19/87).

6) Fix some bugs when receiving an empty file and when a phase error
occurs during a file reception (5/19/87).

7) Portability fix in prtime and projtime; they also handle
pathological cases better (5/19/87).

8) During file reception an EOT is not believed unless it is sent
again in response to a NAK (5/25/87).

9) Modified cpm_unix and unixify so a filename without an extension
will not have a trailing dot in its filename after being received in a
MODEM7 or YMODEM batch transfer (5/25/87).

10) Allowable errors during transmission of a single packet now set to
ERRORMAX (5/27/87).

11) When transferring a binary file, the YMODEM file length field is
filled in on transmit and (if present) used to truncate the file on
reception.  A new truncate function (truncfile) added to getput.c to
do the deed (5/28/87).  The file mode field is also set but is ignored
on file reception.

12) In a batch receive (xmodem -rt), program can be forced into
checksum mode by specifying the "M" flag indicating a MODEM7 transfer
(5/30/87).

13) Changed the "B" option to "M" to indicate MODEM7 batch.  Made all
option flags case insensitive.  Command line is now recorded in the
log file (5/30/87).

14) The "KND/IMP" convention of using "CK" to invoke 1K packets during
YMODEM batch transfers was installed.  This code will be sent during a
batch recieve if "K" is included on the command line unless "M" is
also present.  This code will be recognized when sending under all
circumstances (5/30/87).

------------------------------------------------------------------------------

Changes leading to version 3.4

1) Fix usage message (10/2/87).

2) Sender will now try up to 10 times (EOTMAX) to send an EOT to
terminate a transmission.  Used to be 5 times, but Chuck Forsberg's
"official" minimum requirements for YMODEM mandate 10 (10/2/87).

3) Handle YMODEM file modification times if present in header on
reception of both binary and text files (10/2/87).  Retracted when
can't seem to get proper times whn playing with dsz (10/3/87).

4) Null bytes are now stripped out of files when received as text
files (MEX doesn't seem to want to put in the terminating control-Z)
(10/3/87).

5) Slightly modified terminal parameter setting to explicitly turn of
CRMOD and to flush read queue; ideas stolen from Kermit.  Will it fly
on Pyramid?  (10/3/87).

6) Decreased time between "startup" characters sent when starting a
file receive operation.  This should increase perceived response.  Now
waits only 2 seconds instead of 6 (waits for 5 seconds for subsequent
packets.  STERRORMAX now 30, CRCSWMAX now 15.  Timeouts on 1st sector
no longer reported in log (10/5/87).

7) Once again played with kernel sleeps in readbuf() (packet reading
routine).  On busy system could cause real problems.  Now supply flag
(t) to suppress sleeping on Too Busy systems.  No longer suppress
sleep when speeds are over 4800 bps.  Sleep kludge DOES help: on an
empty 750 running 4.3BSD, a file reception at 2400 bps used 6% of the
CPU with the sleep kludge and 24% without it (data transfer rates were
the the same) (10/5/87).

8) Actually count characters as they are being read for a file
reception.  When YMODEM file length is set, stop writing characters
when reach length.  This will allow YMODEM file lengths to work for
text files and the elimination of truncfile() in getput.c (which was
impossible for SYS V) (10/5/87).

9) Another attempt at tty modes.  Now do nothing but set speeds, set
mode to raw, and turn off echoing and tandem (10/6/87).

------------------------------------------------------------------------------

Thanks to Keith Peterson ([e-mail]), John Rupley
(arizona!rupley!root), Emmet Gray (ihnp4!uiucuxc!fthood!egray), Bob
Bickford (lll-crg!well!rab), Doug Moore ([e-mail]),
David Brown ([e-mail]) and Chuck Forsberg's documents and his
ZCOMM/DSZ programs for ideas, suggestions and comments.
 6-Dec-87 22:21:47-EST,4920;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 6 Dec 87 22:21-EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Sun, 6 Dec 87 21:28:25 EST
Received: from mc.lcs.mit.edu by EDDIE.MIT.EDU via Chaosnet with SMTP with sendmail-5.45/4.7 id <[e-mail]>; Sun, 6 Dec 87 21:28:11 EST
Received: from SIMTEL20.ARPA (TCP 3200000112) by MC.LCS.MIT.EDU  6 Dec 87 21:29:00 EST
Date: Sun, 6 Dec 1987  19:27 MST
Message-Id: <[e-mail]>
Sender: [e-mail]
From: Keith Petersen <[e-mail]>
To: [e-mail]
Cc: [e-mail]
Subject: Latest KA9Q TCP/IP for MSDOS now available from SIMTEL20

The latest version of KA9Q's TCP/IP for MSDOS is now available via
standard anonymous FTP from SIMTEL20...

Filename                        Type     Bytes   CRC

Directory PD1:<MSDOS.KA9Q-TCPIP>
NELSON.ARC.1                    BINARY    7385  1825H
NET_BM.ARC.2                    BINARY   23171  48BBH
NET_DES.ARC.2                   BINARY   18721  E18CH
NET_DOC.ARC.2                   BINARY  104826  B348H
NET_EXE.ARC.2                   BINARY  104944  244DH
NET_READ.ME.2                   ASCII     3381  9A51H
NET_SRC.ARC.2                   BINARY  233582  16A4H
PXX107.ARC.1                    BINARY   46952  3F49H
TNC_ASH.ARC.2                   BINARY   53998  9927H
TNC_LDR.ARC.2                   BINARY   15790  0D43H
TNC_TNC1.ARC.2                  BINARY   33058  1B49H
TNC_TNC2.ARC.2                  BINARY   47427  D326H

[Here is the NET_READ.ME file]

Welcome to the KA9Q Internet Package!
(Updated 25 November 1987 by KA9Q)

This file reflects the changes made up to version 870829.16.  The major
new feature since 870829.0 is the addition of full-blown support for
AX.25 Level 2.  It may be used to acknowledge IP datagrams on a
hop-by-hop basis and also to communicate with conventional (i.e.,
non-TCP) AX.25 stations from the keyboard.

A number of the commands relating to specific protocols (e.g., AX.25,
TCP, IP, UDP) have been restructured in a hierarchical fashion.  For
example, the "digipeat" and "mycall" commands have been made subcommands
under the "ax25" main command.  See useguide.doc for details.  NOTE: you
will have to change your autoexec.net with this release!

In addition to commands added to support the new AX.25 functions,
several utility commands have been added for your convenience.  "dir"
lists directories on the console without leaving net, "cd" (alias "pwd")
prints and changes the current working directory, and "shell" (alias
"!") allows you to suspent net.exe temporarily to run other commands
(note that this freezes any network activity in progress).  The "record"
command allows you to record your Telnet and AX.25 sessions in a file,
and "upload" allows you to send files as though they were typed at the
keyboard.

Lots of little bug fixes and enhancements have been made. TCP round trip
timing when sending into large windows has been fixed.

The .ARC files that make up the distribution are compressed archives that
were created with version 3.5 of the PKXARC archive program.  They may
not be compatible with the ARC program produced by System Enhancement
Associates, because the PKARC program knows more compression methods than
ARC.  For your benefit, a self-extracting archive PKX35A35.EXE has been
provided.  Run it to extract a program that can be used to extract the
archives.

The distribution is structured based on the directory structure used to
create the software:

NET_BM.ARC      .\BM    - sources to Bdale's Mailer, and Gerard's Gateway
NET_DES.ARC     .\DES   - an implementation of DES (Data Encryption Standard)
              for possible use in validating logins, etc.
NET_DOC.ARC     .\DOC   - all of the doc files
NET_EXE.ARC     .\EXE   - executable programs and config files
NET_SRC.ARC     .\SRC   - sources to NET.EXE
NELSON.ARC      .\SRC   - alternative assembler source files for net.exe
              not dependent on Aztec macros. Contributed by Russ
              Nelson ([e-mail]).

TNC_ASH.ARC     .\TNC\ASH       - KISS for the VADCG and ASHBY boards (AJ9X)
TNC_LDR.ARC     .\TNC\LDR       - N4HY's KISS downloader in Turbo Pascal
TNC_TNC1.ARC    .\TNC\TNC1      - KISS for the TAPR TNC-1 and clones (WB6ECE)
TNC_TNC2.ARC    .\TNC\TNC2      - KISS for the TAPR TNC-2 and clones (K3MC)


Whatever you do, *PLEASE* don't unpack all of the .ARC files in one directory,
as there are duplicate names all over the place... Makefiles, README files,
etc.

After unpacking, look for a README file in each archive.  Read this first,
before you do *anything* else.  Some are just informative, some are very
important.

Finally, we're constantly striving to improve this software, and the
distribution as a whole.  Comments may be forwarded to Bdale Garbee, N3EUA.
Several of the Doc files include info on how to reach me...

Above all, HAVE FUN!

73
Bdale, N3EUA
Phil, KA9Q

-----
--Keith Petersen
Arpa: [e-mail]
Uucp: {bellcore,decwrl,harvard,lll-crg,ucbvax,uw-beaver}!simtel20.arpa!w8sdz

 7-Dec-87 00:15:19-EST,2002;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 7 Dec 87 00:15-EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Sun, 6 Dec 87 23:34:00 EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Sun, 6 Dec 87 23:33:49 EST
Received: by june.cs.washington.edu (5.52.1/6.11)
    id AA05103; Sun, 6 Dec 87 20:33:26 PST
Return-Path: <bellcore!faline![e-mail]>
Message-Id: <[e-mail]>
Date: 6 Dec 87 22:29:12 GMT
From: bellcore!faline![e-mail] (Phil R. Karn)
To: [e-mail]
Subject: Re: Lately, hardware is so much cheaper than software...
Summary: bridging
References: <[e-mail]>

I am a big believer in bridging broadcast LANs (e.g., Ethernet).
Bellcore's internal network now consists of something like 4-5 dozen
Ethernets all joined by DEC Lan Bridge 100s and Vitalink TransLAN IIIs.
(There are some private cables not part of the main network, but they
are now in the minority).

The bridged cables appear to all be part of the same "virtual Ethernet".
I can move my workstation from one outlet to another and everything
still works - no reconfiguration is necessary. Because the "network
protocol" is simple and connectionless, performance is excellent. (Of
course, things are slower between locations because the interlocation
links only run at T1 speed, 1.536 megabit/sec instead of 10
megabit/sec).

I have long tried to figure out some way to apply bridging to amateur
packet radio. Unfortunately, it doesn't work because bridges assume full
connectivity among the stations in each cable segment. I.e., if I hear
stations 1 and 2 on port A, I can assume that stations 1 and 2 can talk
to each other directly without help from me. This is clearly not a wise
assumption in radio, where paths may even be uni-directional (1 may be
able to reach 2 directly, but 2 may have to reach 1 through a
repeater).

Phil


 7-Dec-87 18:56:12-EST,1683;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 7 Dec 87 18:56-EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Mon, 7 Dec 87 18:03:39 EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Mon, 7 Dec 87 18:03:27 EST
Message-Id: <[e-mail]>
Received: from MITVMA.MIT.EDU by MITVMA.MIT.EDU ; Mon, 07 Dec 87 18:04:03 EST
Received: from TRIUMFCL.BITNET (ROSK) by MITVMA.MIT.EDU (Mailer X1.25) with
 BSMTP id 0299; Mon, 07 Dec 87 18:04:00 EST
Date:     Mon, 7 Dec 87 15:03 PST
From: <[e-mail]>
Subject:  WA7MBLbbs/KAMtnc compatibility problem.
To: [e-mail]
X-Original-To:  pack, ROSK


   Hs anyone tried using the WA7MBL bbs software (running on IBM PC) with
the Kantronics  KAM  (all mode packet controller) ?

   I have hit a problem which seems to be due to the hardware flow control
used between the two devices. When a station connects to the KAM, pin 8
goes high. The bbs program responds by sending a C command to the KAM,
and the KAM responds with a "status ... connected to..." message. The bbs
program sends another C command .... and so on in an endless loop. Pin 8
of the KAM never goes low, except if the station disconnects.

   Is this due to:
   a) somthing set up wrong in the KAM
   b) somthing set up wrong in the bbs/PC
   c) a real hardware compatibility problem - if so, what?
   d) something else?

AtDhVaAnNkCsE   VE7AII                [e-mail]

PS. If this is an impossible-to-fix problem with WA7MBLbbs, is there other
    bbs software that will work with the KAM?

 8-Dec-87 09:39:13-EST,1251;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 8 Dec 87 09:39-EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Tue, 8 Dec 87 08:27:46 EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Tue, 8 Dec 87 08:27:40 EST
Received: from MITVMA.MIT.EDU by MITVMA.MIT.EDU ; Tue, 08 Dec 87 08:28:21 EST
Received: from UKACRL.BITNET by MITVMA.MIT.EDU (Mailer X1.25) with BSMTP id
 2623; Tue, 08 Dec 87 08:28:07 EST
Received: from RL.IB by UKACRL.BITNET (Mailer X1.25) with BSMTP id 8449; Tue,
 08 Dec 87 12:20:03 GMT
Via:        UK.AC.RL.EARN; Tue, 08 Dec 87 12:01:51 GMT
Received:
Via:        UK.AC.UMRCC.CMS;  8 DEC 87 12:01:46 GMT
Message-Id: <08 Dec 87 11:57:28 GMT [e-mail]>
Date:       Tue, 08 Dec 87 11:57:28 GMT
From: "John Heaton 061-273-7121 x 5577" <[e-mail]>
Address:    UMRCC Network Unit (Room G45) University of Manchester Oxford Road
        MANCHESTER, M13-9PL, Engla
To: [e-mail]
Subject:    AMIGA+PK232


 I am thinking of buying a PK-232 all mode TNC to use with my AMIGA A500 and
was wondering if anyone out there knew of any decent software drivers

      John Heaton  -  G1YYH
 9-Dec-87 12:50:01-EST,15528;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 9 Dec 87 12:50-EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Wed, 9 Dec 87 10:52:22 EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Wed, 9 Dec 87 10:51:27 EST
Received: by june.cs.washington.edu (5.52.1/6.11)
    id AA22548; Wed, 9 Dec 87 07:53:14 PST
Return-Path: <cbosgd!gwspc!cbcsta!n8emr![e-mail]>
Message-Id: <[e-mail]>
Date: 9 Dec 87 01:36:54 GMT
From: cbosgd!gwspc!cbcsta!n8emr![e-mail] (Gary Sanders)
To: [e-mail]
Subject: gateway 4.6 (12/04/87)

RELAYED via the N8EMR Ham Bulletin Board
----------------------------------------


         Gateway: The ARRL Packet Radio Newsletter

               Stan Horzepa, WA1LOU, Editor

       Volume 4 Number 6                            December 4, 1987


NEW PACKET FREQUENCIES AVAILABLE IN THE SOUTHEAST

The SouthEastern Repeater Association (SERA) board of directors approved
additional frequencies for exclusive use by packet-radio and digital
operations.  These new frequencies are in addition to existing frequencies
that have been set aside for exclusively for digital

The purpose of the new frequencies was to provide digital capability on 220
MHz for Novices and to enable state digital organizations more capacity and
capability on 2 meters when assigning certain LAN and other relay
frequencies in various sections of states.

In assigning new frequencies, SERA reiterated its stand as far as
coordination is concerned.  SERA assigns band plans for digital operations
and various digital state-wide groups have the responsibility of assigning
various frequencies for relay and long-range digital systems.  The board
also agreed to continue the practice that if a digital system requires a
600-kHz split (input-output), it would have to be placed in the repeater
portion of the band and be coordinated as an FM repeater- operating digital
operation.  Otherwise, simplex digital operations, such as digipeaters,
would still be coordinated by state-wide digital groups on assigned simplex
digital frequencies.

The new frequencies for 220 MHz include two new simplex frequencies: 223.42
and 223.58 MHz.  In addition, two high-speed, 100-kHz channels were
assigned: 220.90-221.00 MHz with 220.95 MHz as center frequency and
221.00-221.10 MHz with 221.05 MHz as center frequency.  The two 100-kHz
channels will be available for 19.2-kbaud operation.  The additional
frequencies for digital on 2 meters include 145.61, 145.63, 145.65, 145.67
and 145.69 MHz.

The SERA digital band plan for 2 meters and 220 MHz is as follows:

2 Meters:  145.01, 145.03, 145.05, 145.07, 145.09,
       145.61, 145.63, 145.65, 145.67 and 145.69 MHz.

220 MHz: 221.05, 221.15, 221.25, 221.35, 221.45, 223.42 and 223.58 MHz.

220 MHz 100-kHz channels (center frequencies): 220.95 and 220.05 MHz.

The new digital frequencies are available for immediate use.

(SERA is the repeater council representing Eastern Kentucky, Georgia, North
Carolina, South Carolina, Tennessee, Virginia and West Virginia. - WA1LOU)

>from Repeater Journal


NEW YORK STATE PACKET FORUM ADDRESSES NETWORKING

A meeting of the New York State Packet Forum was held on November 14, at
Ballston Spa, New York, and packet-radio networking was at the subject of
much of the agenda.

EASTNET Overview

Doug Sharp, WB2KMY, presented the status of EASTNET networking.  The system
is moving toward a linear network with a 450-MHz backbone linking multiport
NET/ROM nodes with 2-meter and 220-MHz capability.  Doug made an analogy to
NTS with the 450 links serving "areas", the 220 links serving "regions" and
the 2-meter links serving the "sections." EASTNET is driving toward linking
Boston to Baltimore to Buffalo.

Western New York Networking

Dick Pache, K2LCT, handed out a map outlining a proposed Western New York
networking plan.  Dick stated that Western New York is committed to
NET/ROM.  He said that the NET/ROM developers have assured the Western New
York group that NET/ROM will be compatible with TCP/IP, which the Western
New York group believes will be the future networking protocol.  The
Western New York nodes will be linked with GLB Netlink digital radios and
surplus Microwave Data Systems 900 MHz equipment.  The Western New York
network is arranged in a "honeycomb" topology as opposed to EASTNET's
"linear" topology.

Dick also gave a report on the HEX-9 Packet symposium held in Barrie,
Ontario on September 19.  Lyle Johnson, WA7GXD, and Dave Toth, VE3GYQ, of
TAPR were the primary speakers.  Lyle said that TAPR was out of the TNC
development business and was now supporting Network Node Controller (NNC),
PSK modem, and Digital Signal Processing (DSP) development.  Dave stated
that the key to a successful network is node siting and use of multiple
frequencies.  Dr. Toth also performed an autopsy on the late 145.01 network
and said that it had been choked to death by UI frames (BEACONS!).

Toth is TAPR NNC project director.  The NNC uses the Hitachi 64180
processor.  It addresses 256kbytes of memory and includes a SASI interface.
No software is yet available for it.  (Dick Pache noted that Hitachi now
had a 64180NPU chip which includes on-chip SIO ports.  This may be the
basis for an NNC on a chip.) Dave estimated that a full NNC station
including RF gear would cost about $3000 Canadian.

New York State Networking

After a break for lunch, the assembled group entered into a spirited
brainstorming (read "head-knocking") session on upgrading the linking of
New York State.  There was a consensus that reliably linking Western and
Eastern New York was a top priority.  The way that this should be
accomplished was the main subject of debate.  No resolution was found, but
the group agreed that the means to accomplish the linking were now
available and experiments would be started.

>from George Chapek N2AIG, Secretary, New York State Packet Forum

12-METER PBBS/PCBS ON THE AIR

N3DFD, a new PBBS is on the air on 24.927 MHz.  This PBBS is a PCBS (packet
conference board system) and is dedicated to the exchange of MS-DOS and
BASIC computer programs.  All of the computer program files will be in
either the ARCHIVE DIR or the FILES DIR.  N3DFD also supports "packet
cluster" and provides a mailbox function (but no mail-forwarding).

Up to 26 users may connect to the PCBS at once to minimize waiting.  Users
are encouraged to upload any computer programs, of any type and to download
anything that the user likes. The PCBS is on the air Tuesdays through
Thursdays, 6 PM to 1 AM EST and all day Fridays through Tuesdays.

>from CompuServe's HamNet


NOVICE NOTCH

Upstate New York is a hotbed of Novice packet radio activity with Dana
Jonas, WA2WNI, in Valatie (south of Albany) supporting Novice packet
operations with a PBBS (WA2WNI-4) and digipeater (WA2WNI-1) on 223.58 MHz.

Meanwhile, the N2EZG PBBS in Alpine, New York (near Watkins Glen, half way
between Elmira and Ithaca) has been dual-ported on 145.01 and 145.07 MHz
(Elmira LAN) and recently added an IC-38A transceiver to its .07 port to
provide cross-band digipeater operation with PBBS access on 145.07 and
223.58 MHz. This allows Novices to use the PBBS and also allows KC3BQ and
N2EZG to forward mail between each other on 220 MHz (KC3BQ is in
Skaneateles, New York).

>from George Chapek, N2AIG and Bill, N2EZG

(Gateway would like to continue to publicize Novice packet activities, so
if you know of any, please let me know, too. - WA1LOU)


NEW SOFTWARE

ATARI PBBS SOFTWARE AVAILABLE

Mike Curtis, WD6EHR, has ported the W0RLI PBBS software to the Atari 520ST
and 1040ST computers.  The program has most of the features of the original
program and is available by sending Mike a blank 3-1/2-inch diskette and
postpaid diskette mailer.

>from CompuServe's HamNet


SPACE NEWS VIA PACKET RADIO

Space News from KD2BD is now being distributed to various PBBSs in the
Northeast.  It is a report about specialized communications techniques and
space technology in the Amateur Radio Service.  The first edition of Space
News included stories on OSCAR 10 returning to service, the next space
shuttle flight, USSR space station Amateur Radio operations and current
astronomical events.  These bulletins originate from John, KD2BD, in Wall
Township, New Jersey, and are available on the following PBBSs: W1AW,
KB1BD, NN2Z, WA2SNA, KB3UD and KD6TH.

NET/ROM STANDARDIZED NODE IDENTIFICATION PROPOSAL

The Problem

Recently, there has been a significant increase in the number of IDs
appearing on the NET/ROM NODE lists, much to almost everyone's delight.
Because of the increasing number of NET/ROM nodes, the improved radio links
between nodes and occasional openings on 2 meters, our local node has had
as many as 52 other nodes on its NODE list.  However, it is difficult to
tell which node is where because there is no standard for node
identifications.  As a result, one must look each one up on the ENODES,
MNODES or WNODES lists, which is a very time-consuming process or and
impossible task if you do not have the list for the area of interest or if
the unknown node is new and not on any list.  And, call signs are
meaningless as far as direction- finding is concerned.  The early concept
of using the 3-letter ICAO airport designators for the node was reasonable
when NET/ROM was starting, but there are now more nodes than airports and
few airports are on top of mountains!

A Proposed Solution

To standardize the node identifications for use on 145.01 MHz, I propose
that each node's identification begin with a 2-letter state/province
abbreviation to indicate which state/province the node is located.  For
example, the Virginia Beach node is now VAB; under the new system, it would
be VAVAB.  The Richmond node would become VARIC, the BWI node would become
MDBWI and so on.  Nodes on an LAN would continue to use their present
identifications (without the state/province abbreviation, that is, VAB,
RIC, BWI), however, the 220 and 440 MHz nodes would use their 144.01 MHz
identification unless the node is on an LAN.

Justification

This relatively simple identification system would accomplish several
things.

o  It would permit the person checking a NODES list to identify the general
   location of the 145.01 MHz nodes on the list.

o  It would differentiate between "through" nodes, that is, on 145.01 MHz
   and nodes on an LAN.  For example, VAVAB versus VAB; VARIC versus RIC,
   for 145.01 MHz and the LAN respectively.  The state location of an LAN
   node could still be determined since its 145.01 MHz link should also be
   on the list, for example, both VAVAB and VAB would be on the list.

o  It could be of some use to the PBBS forwarding operations at a future
   time if the software were modified to make use of state/province- coded
   identifications.

o  It could be of use in both the NTS and ARES systems to help determine
   possible paths for normal traffic and emergency packet communication
   within a region.

Comments

Please address your comments concerning this proposal to N4JSP @ WD4MIZ.
Keep them brief and I will edit them down and repeat the distribution of
this original proposal.

[Although this discussion makes some assumptions about network topology
that may not be universally true, there is something to be said for the
idea of standardizing node identification.  We present this for your
consideration and invite your comments.-- Ed]

>from Bill Henry, N4JSP @ WD4MIZ

OPERATORS PROPOSE NON-RADIOGRAM PACKET TRAFFIC

Ed, KA9TAW, of Bloomington, Indiana, has proposed a new way to send
third-party traffic.  His proposal eliminates the radiogram preamble.  It
precedes the text with the following information:  the call sign and local
PBBS call sign of the originating station; the date of the message; and the
name, address, and phone number of the addressee.  Ed proposes a
"conversational" text.  That means complete sentences, normal punctuation,
no Xs to separate thoughts, no ARRL numbered texts and extending the length
limit.

Ed calls his proposed messages "E-Mail" and says third-party E- Mail is
meant only for packet radio.  Ed also says operators should be willing to
print and mail the messages.  Ed doesn't worry about third-party E-Mail
sitting undelivered on PBBSs.  He expects PBBS system operators (SYSOPs) to
take care of them.  But he says third-party E-Mail is easier to deliver
than radiograms...so more operators will be willing to handle the messages.

Peggy Coulter, W9JUJ, is Indiana's highest NTS official...the Section
Traffic Manager.  She says it's OK for packet operators to send E-Mail to
each other.  But she does not recommend it for messages to people not
equipped with packet radio.  She also stresses that Amateur Radio
third-party traffic was never meant for important non-emergency personal or
commercial business; people should use the telephone or postal service for
such messages.  And Peggy says hams need not mail messages for other
operators.  If she receives a message she cannot deliver by telephone, she
sends the originating station a service message.

Sy, KJ9L, handles traffic on several modes in the Chicago area.  He
believes Ed's plan should be adopted.  But he says packet operators should
reject third-party E-Mail they can't handle without using another mode.  Sy
reminds us that "there are many areas where the packet interconnections are
lacking." NTS traffic gets to these areas anyway, because NTS operators
transfer it to other modes.  This is not the case with third- party E-Mail.

>from Indiana Packet NTS Newsletter


ARRL PACKET RADIO BOOK DUE SOON

Your Gateway To Packet Radio written by the editor of Gateway (WA1LOU) is
being published by the ARRL and should be available in the next few weeks.
This 205-page publication contains 13 chapters and 7 appendices, as
follows:

The Radio Hacker; History; Theory of Operation; TNCs; Installation;
Selecting TNC Parameters; Operating Procedures; VHF and UHF Communications;
HF Communications; Time-Shifting Communications; Public Service
Communications; Space Communications; The Network and; Appendices
  o  TNC 1 and 2 Commands
  o  TNC 1 and 2 Control Characters
  o  TNC 1 and 2 Messages
  o  TNC Command Compatibility
  o  ASCII Character Set
  o  Bibliography and Sources
  o  Glossary

Details from ARRL, 225 Main Street, Newington, CT 06111


Needless to say, submissions for publication in "Gateway" are
welcome. Submit material via the US mail to:

   Gateway
   Stan Horzepa, WA1LOU
   75 Kreger Drive
   Wolcott, CT 06716-2702

or electronically, via CompuServe to user ID 70645,247


REPRODUCTION OF GATEWAY MATERIAL

Material may be excerpted from Gateway without prior permission, provided
that the original contributor is credited and Gateway is identified as the
source.

               (Edited for Packet Radio Distribution by N8XX)

--
Gary W. Sanders         {ihnp4|cbosgd}!n8emr!gws
(cis) 72277,1325        (packet) N8EMR @ W8CQK
HAM/SWL BBS (HBBS) 614-457-4227.. 300/1200 bps


 9-Dec-87 20:58:39-EST,1419;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 9 Dec 87 20:58-EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Wed, 9 Dec 87 19:12:42 EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Wed, 9 Dec 87 19:12:20 EST
Received: by june.cs.washington.edu (5.52.1/6.11)
    id AA13261; Wed, 9 Dec 87 16:14:06 PST
From: umunhum![e-mail]
Return-Path: <umunhum![e-mail]>
Message-Id: <[e-mail]>
Date: 9 Dec 87 01:40:39 GMT
To: [e-mail]
Subject: Re: OSI and other holy wars
References: <[e-mail]> <[e-mail]> <[e-mail]>
Reply-To: [e-mail] (Paul Flaherty)

G protocol (UUCP) works just fine across an ax.25 link; just don't advertise
the connection in a MAP entry, or you'll have traffic flowing through it
faster than you'd think...

I would imagine that UUPC would work nicely.  However, since I have yet to see
a working copy (lots of nonworking copies, I've seen), I'll have to continue
imagining it working...

Note New .sig...:-)

-=Paul Flaherty, N9FZX           | "The only thing that we've learned from
Computer Systems Laboratory      |history is that we havn't learned anything
Stanford University              |from history..."
Domain: [e-mail]|              -- William Jennings Bryant


 9-Dec-87 21:18:46-EST,1739;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 9 Dec 87 21:18-EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Wed, 9 Dec 87 19:12:29 EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Wed, 9 Dec 87 19:11:57 EST
Received: by june.cs.washington.edu (5.52.1/6.11)
    id AA13236; Wed, 9 Dec 87 16:13:08 PST
Return-Path: <pyramid!prls!philabs!trotter![e-mail]>
Message-Id: <[e-mail]>
Date: 7 Dec 87 16:03:01 GMT
From: pyramid!prls!philabs!trotter![e-mail] (Bill Gunshannon)
To: [e-mail]
Subject: Re: OSI and other holy wars
Summary: I agree!!!
References: <[e-mail]> <[e-mail]>

In article <[e-mail]>, [e-mail] (Phil R. Karn) writes:
> Agreed. Life is also too short to waste on reinventing working,
> proven wheels.

I agree as well.  Which brings up a new question...

Can anyone give me a reason why we don't run a system using the news software
and UUCP/UUPC to ship things around on packet???
It seems that the news software would allow threaded discussions better than
the current PBBS system.  Don't get me wrong, I think the PBBS's are great
for sending mail around the country but I think a system using news would be
alright also.

Any comments???

bill gunshannon


UUCP: {philabs}\                        US SNAIL: Martin Marietta Data Systems
      {phri   } >!trotter.usma.edu!bill           USMA, Bldg 600, Room 26
      {sunybcs}/                                  West Point, NY  10996
RADIO:         KB3YV                    PHONE: WORK    [phone]
AX.25:         KB3YV @ K3RLI            PHONE: HOME    [phone]


 9-Dec-87 21:24:53-EST,2714;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 9 Dec 87 21:24-EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Wed, 9 Dec 87 19:17:50 EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Wed, 9 Dec 87 19:17:24 EST
Received: by june.cs.washington.edu (5.52.1/6.11)
    id AA13422; Wed, 9 Dec 87 16:19:06 PST
Return-Path: <hao!noao!mcdsun!asuvax!stjhmc![e-mail]>
Message-Id: <[e-mail]>
Date: 1 Dec 87 23:39:00 GMT
From: hao!noao!mcdsun!asuvax!stjhmc![e-mail] (Eric Daymo)
To: [e-mail]
Subject: Re: W0RLI PBBS TO FIDONET

 > Ok, I know it can be done!!  I've downloaded software
 > 'til I'm "blue"!! BinkleyTerm, X00 Fossile Driver,
 > REMAPER, OMMM, ConfigMail, etc.  Still,

I am not sure how the RLI software is set up, but I think I know a way I can
do it from WA7MBL v3.12 and above (maybe earlier versions too, but I am only
experienced with 3.12 3.13 and 3.20)

MBL keeps messages in text files in the format:

MSGxxxxx.MAI - where xxxxx is the message number. these messages are in turn
stored in the \BBS\MAIL directory (normally - unless you specify otherwise).
You can simply archive all the mail messages and then copy that archive to
anothe directory. Then use any mail program to send it over to the FidoNet
system. There you can keep the day's mail in an archive that all can
download.

The only problem is to keep duplicates.. ie

message 1-20 exist on day 1. 1-20 are archived.  messages 1-40 exist on day
2. 1-40 are archived.

Every day's mail is compounded on the last.

At least that is a start.   WB6WEY @ WB6WEY has it working.  He has a "home
brew" BBS system. I am not sure what he uses for packet radio. K6IYK @ K6IYK
also has a system working. He runs the CSC consulting BBS @ 818-998-0319
(RBBS-PC) and W0RLI software.

As for FidoNet... no idea.. I think I know of a packet system using Usenet,
but that callsign has slipped my mind.

Another possibility.. using SERVER.TXT from the MBL software?

Any ideas.. anyone?

And if there is a solution please post it on here!

73s

Eric Daymo

KA6VZA @ KA6VZA

1:102/2800   1:102/2803

--- ConfMail V3.2
 * Origin: 1000 Oaks HUB * [phone] * 1000 Oaks,CA (1:102/2800)
SEEN-BY: 15/6 18 104/56 114/13 15 20 24 26 300

--
St. Joseph's Hospital and Medical Center - Phoenix Arizona
uucp:  {decvax, hao, ihnp4} !noao!asuvax!stjhmc!ddodell
Bitnet: ARDSD @ ASUACAD                    FidoNet=> 1:114/15 or 1:1/0
TWX: 910-380-5182 (Dodell Scottsdale AZ)   MCI Mail: ddodell


 9-Dec-87 21:30:58-EST,4730;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 9 Dec 87 21:30-EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Wed, 9 Dec 87 19:13:27 EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Wed, 9 Dec 87 19:11:58 EST
Received: by june.cs.washington.edu (5.52.1/6.11)
    id AA13171; Wed, 9 Dec 87 16:10:43 PST
Return-Path: <bellcore!faline![e-mail]>
Message-Id: <[e-mail]>
Date: 9 Dec 87 21:07:46 GMT
From: bellcore!faline![e-mail] (Phil R. Karn)
To: [e-mail]
Subject: Re: OSI and other holy wars
Summary: comparisons of networking schemes
References: <[e-mail]> <[e-mail]> <[e-mail]>

Rather than answer Tom's latest ad-hominem attack, I thought I'd instead try
to raise the level of discussion by presenting an analysis of the various
amateur networking schemes with respect to six fairly orthogonal (i.e.,
independent) characteristics. As you can see, each approach takes a
different mix of choices. For example, two approaches that agree on one
attribute (e.g., hop-by-hop acking) might take different stands on whether
the network layer should use datagrams or virtual circuits.

Here are the alternative schemes considered:

1. COSI (W2VY & N2DSY)
2. NET/ROM (Software 2000, W6IXU & WA8DED)
3. Texnet (N5EG et al)
4. NET.EXE (i.e., the KA9Q Internet package)
5. conventional AX.25 digipeaters

1. Is the networking model "computer-to-computer" or "terminal-to-terminal"?

All but NET.EXE are predominantly oriented toward providing terminal-to
terminal communications. Terminal/computer and computer/computer
communications are usually handled by making the computers "look" like
terminals.  NET.EXE is oriented specifically towards computer/computer
communications.

2. Is network level addressing flat or hierarchical?

AX.25 digipeaters, NET/ROM and Texnet use flat addressing.  AX.25 and
NET/ROM addresses are amateur callsigns plus 4-bit "sub station IDs",
while Texnet node addresses are 1-byte node numbers.

COSI and NET.EXE use hierarchical addressing. (Aha! A point of agreement!)
NET.EXE uses an addressing plan specifically created for the amateur IP
network, and can handle flat addressing "exceptions" when desired.  COSI
uses telephone area code and exchange maps.

3. Is the network layer connection-oriented or connectionless?

All but COSI are connectionless (i.e., datagram-oriented) at the network
layer.

4. Are hop-by-hop acknowledgements used?

Hop-by-hop acks are not available in the AX.25 digipeater network.  They are
mandatory in COSI, NET/ROM and Texnet. They are optional in NET.EXE; a
default mode is specified on a per-link basis, but it can be overridden by
bits in the network protocol header.

5. Is the protocol stack "proprietary" (i.e., ad-hoc) or is it a standard
outside of amateur radio?

AX.25 digipeaters, NET/ROM and Texnet use protocols unique to amateur radio.
AX.25 is an official published ARRL standard. Despite its name it is NOT
just a minor variation of CCITT X.25.  NET/ROM, Texnet, COSI and NET.EXE all
build on AX.25 by using it as an ordinary link level protocol.

NET/ROM and Texnet protocol descriptions are available but are not
"official" ARRL standards.

NET.EXE uses the ARPA Internet protocol suite, an official standard of the
US Department of Defense and a de-facto civilian standard popular in
multi-vendor commercial, governmental and educational networks.

COSI uses certain elements of protocols proposed by the International
Standards Organization (ISO) and the International Consultative Committee
for Telephony and Telegraphy (CCITT). Except for X.25, these protocols
are not in widespread use.

6. Are implementations freely available for non-commercial use, or are
they proprietary?

Many implementations of AX.25 exist. Sources to some are proprietary (e.g.,
TNC-2 Z-80 assembler code by N2WX, commercial vendor implementations by AEA,
Kantronics, etc).  Sources to others (e.g., the original TNC-1 Pascal code
by KD4NL et al, the Xerox 820 and IBM PC C code by KA9Q) are available free
on a non-commercial basis.

Although the authors reserve commercial rights, both the source and object
code to NET.EXE is available free for noncommercial use. It is understood
that the same will be true for COSI.  (ANOTHER point of agreement!)

NET/ROM is sold as a copy-protected commercial product. Source code is not
available.

I do not know the availability of Texnet code. (Authoritative info is
solicited).

Constructive comments on these comparisons are invited.

Phil


10-Dec-87 14:30:09-EST,4079;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 10 Dec 87 14:30-EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Thu, 10 Dec 87 12:33:42 EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Thu, 10 Dec 87 12:33:01 EST
Message-Id: <[e-mail]>
Posted-From: The MITRE Corp., Bedford, MA
To: bellcore!faline![e-mail] (Phil R. Karn)
Cc: [e-mail], [e-mail]
Subject: Re: OSI and other holy wars
In-Reply-To: Your message of 09 Dec 87 21:07:46 +0000.
         <[e-mail]>
Date: Thu, 10 Dec 87 11:18:43 EST
From: [e-mail]

I think that it is helpful to remember that each of these solutions
were designed to fit a certain set of problems - for example, AX.25
for the Amateur Community by adding the Amateur Callsigns to the
protocol to take care of the FCC requirement that we identify
ourselves correctly.

If I remember correctly, the reason why TCP/IP is so prevalent is that
the Dod mandated its use for the Arpanet/Milnet hosts, because it was
an awful lot better for internetting (the IP part of it), than the
then-in-use protocol, NCP - which stands for Network Control Protocol.
NCP did not support internetting well at all.  Then, once TCP was in
widespread use, vendors saw the profit (ie., big bucks) that could be
had by also making their product talk TCP/IP too.

I predict that just as TCP found its niche in government things via
the Arpanet, the same thing will probably happen to the ISO protocols
(eg., OSI) once they become well enough defined to be implemented and
start giving people a warm feeling in their tummy.

I would recommend that we use whichever protocol fits the individual
needs of the community that needs to talk.  If interface to Arpanet is
required, we can use TCP; if telephone hookups to Unix systems is
desired, UUCP; if it is needed to put it over the radio, AX.25 or
NET/ROM, etc., etc., etc..

Sometimes, high-level standard protocols aimed at tearing down
communications walls have their problems, too.  I keep hearing things
like one of the reasons that DEC will not implement the GM MAP
protocol is that they feel it is very inefficient. And yet, MAP has
helped a lot in getting factory automation really going.

Then we just need gateways to take care of the ensuing Tower of Babel
that develops from this....

It is useless to argue "Gee, my favorite protocol is the best for
everything" because no matter what the protocol, it has been
specifically tailored for a specific need(s), and something else in
another domain will beat it out where the other protocol has been
tailored to (e.g, don't try to run a CSMA protocol like Ethernet over
the air with no carrier sense, or you will have severe collision problems.
However, Ethernet over Ethernet cables does fine).

No disrespect is intended here to the many knowledgeable people who
are touting this protocol or that.  It just seems humorous to watch
all that.  I have had many a good chuckle over the arguments expressed
here, in the Morse Code wars, and recently in the CB Linear Amplifier
Wars in the ham-radio arena.

Excercise for the reader:
    Take this argument (or one of your own), and write an article
    for the April Issue of QST.

    ___  ...  ..
    ..  ...
    ..  ...  ___
    ...  .__.  .  ._..  ._..  .  _..
    _...  ._  _._.  _._  .__  ._  ._.  _..  ...

    _..  ___  _.  _
    _.__  ___  .._
    .._.  .  .  ._..
    .._.  ___  ___  ._..  ..  ...  ....
    ...  ..  _  _  ..  _.  __.
    _  ....  .  ._.  .
    ._  _.  _..
    _..  .  _._.  ..  .__.  ....  .  ._.  ..  _.  __.
    _  ....  ..  ...
    ..__..

    ....  ..    ....  ..

Disclaimer:  The opinions expressed herein are my own, and are not
         necessarily those of my employer.

English:        Peter T. Baldwin
Arpa:           [e-mail]
Flames:         /dev/null
Ham/packet:     wa1snh@k1ugm-9
Ham/traffic:    HHTN, Saturday nights
Ham/Voice:      147.12 mhz
Voice:          Peter!
10-Dec-87 14:44:21-EST,4079;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 10 Dec 87 14:44-EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Thu, 10 Dec 87 12:33:42 EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Thu, 10 Dec 87 12:33:01 EST
Message-Id: <[e-mail]>
Posted-From: The MITRE Corp., Bedford, MA
To: bellcore!faline![e-mail] (Phil R. Karn)
Cc: [e-mail], [e-mail]
Subject: Re: OSI and other holy wars
In-Reply-To: Your message of 09 Dec 87 21:07:46 +0000.
         <[e-mail]>
Date: Thu, 10 Dec 87 11:18:43 EST
From: [e-mail]

I think that it is helpful to remember that each of these solutions
were designed to fit a certain set of problems - for example, AX.25
for the Amateur Community by adding the Amateur Callsigns to the
protocol to take care of the FCC requirement that we identify
ourselves correctly.

If I remember correctly, the reason why TCP/IP is so prevalent is that
the Dod mandated its use for the Arpanet/Milnet hosts, because it was
an awful lot better for internetting (the IP part of it), than the
then-in-use protocol, NCP - which stands for Network Control Protocol.
NCP did not support internetting well at all.  Then, once TCP was in
widespread use, vendors saw the profit (ie., big bucks) that could be
had by also making their product talk TCP/IP too.

I predict that just as TCP found its niche in government things via
the Arpanet, the same thing will probably happen to the ISO protocols
(eg., OSI) once they become well enough defined to be implemented and
start giving people a warm feeling in their tummy.

I would recommend that we use whichever protocol fits the individual
needs of the community that needs to talk.  If interface to Arpanet is
required, we can use TCP; if telephone hookups to Unix systems is
desired, UUCP; if it is needed to put it over the radio, AX.25 or
NET/ROM, etc., etc., etc..

Sometimes, high-level standard protocols aimed at tearing down
communications walls have their problems, too.  I keep hearing things
like one of the reasons that DEC will not implement the GM MAP
protocol is that they feel it is very inefficient. And yet, MAP has
helped a lot in getting factory automation really going.

Then we just need gateways to take care of the ensuing Tower of Babel
that develops from this....

It is useless to argue "Gee, my favorite protocol is the best for
everything" because no matter what the protocol, it has been
specifically tailored for a specific need(s), and something else in
another domain will beat it out where the other protocol has been
tailored to (e.g, don't try to run a CSMA protocol like Ethernet over
the air with no carrier sense, or you will have severe collision problems.
However, Ethernet over Ethernet cables does fine).

No disrespect is intended here to the many knowledgeable people who
are touting this protocol or that.  It just seems humorous to watch
all that.  I have had many a good chuckle over the arguments expressed
here, in the Morse Code wars, and recently in the CB Linear Amplifier
Wars in the ham-radio arena.

Excercise for the reader:
    Take this argument (or one of your own), and write an article
    for the April Issue of QST.

    ___  ...  ..
    ..  ...
    ..  ...  ___
    ...  .__.  .  ._..  ._..  .  _..
    _...  ._  _._.  _._  .__  ._  ._.  _..  ...

    _..  ___  _.  _
    _.__  ___  .._
    .._.  .  .  ._..
    .._.  ___  ___  ._..  ..  ...  ....
    ...  ..  _  _  ..  _.  __.
    _  ....  .  ._.  .
    ._  _.  _..
    _..  .  _._.  ..  .__.  ....  .  ._.  ..  _.  __.
    _  ....  ..  ...
    ..__..

    ....  ..    ....  ..

Disclaimer:  The opinions expressed herein are my own, and are not
         necessarily those of my employer.

English:        Peter T. Baldwin
Arpa:           [e-mail]
Flames:         /dev/null
Ham/packet:     wa1snh@k1ugm-9
Ham/traffic:    HHTN, Saturday nights
Ham/Voice:      147.12 mhz
Voice:          Peter!
11-Dec-87 14:26:52-EST,1578;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 11 Dec 87 14:26-EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Fri, 11 Dec 87 11:29:48 EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Fri, 11 Dec 87 11:29:29 EST
Message-Id: <[e-mail]>
Received: from DHVRRZN1.BITNET by WISCVM.WISC.EDU ; Fri, 11 Dec 87 10:30:15 CDT
Date: Fri, 11 Dec 87 17:27:39 MEZ
To: [e-mail]
From: [e-mail]
Subject: Searching for host mode terminal prg for MAC & ATARI ST

hello ob's,

I am new with packet radio and I am looking for a special terminal
program to work with TNC2C with WA8DED firmware in host mode for
two kinds of computers, the MAC and the Atari ST. If any body has
an idea, where I can get that adopted programespecially for the MAC,
please let me know. I have full access to all BITNET servers and I
wonder if there is any availibilty for BITNETTER's getting prog's
and sources of such specified code??? I subscribe the packet-radio
bulletin since 3 month, but I don't remember anything in that connection.

Second kind of problems is the solution of TCP/IP for both of these
computers. Atari is well known to much hams here in Hannover but MAC
is not. Therefore system support for MAC with public domain software
with packet-radio application is closed to ZERO.

It would be wonderful to get some information on that 2 problems...
Thank you very much, 73, cul

Michael Hartje, DK5HH, (MAMI@DHVRRZN1)
11-Dec-87 21:29:53-EST,1357;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 11 Dec 87 21:29-EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Fri, 11 Dec 87 20:30:18 EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Fri, 11 Dec 87 20:30:09 EST
Message-Id: <[e-mail]>
Received: from MITVMA.MIT.EDU by MITVMA.MIT.EDU ; Fri, 11 Dec 87 20:30:22 EST
Received: from TRIUMFCL.BITNET (ROSK) by MITVMA.MIT.EDU (Mailer X1.25) with
 BSMTP id 9016; Fri, 11 Dec 87 20:30:03 EST
Date:     Fri, 11 Dec 87 09:53 PST
From: <[e-mail]>
Subject:  KAM<>WA7MBL Resolved.
To: [e-mail]
X-Original-To:  pack, ROSK

   My thanks to all those who replied to my question about WA7MBL<>KAM
communication. Setting MAXUSERS 0/1 or MAXUSERS 1/0 does indeed fix
the problem.
   The local Kantronics agent contacted the factory about the KAM
and got the following information: A new version of the software for
the KAM (firmware?) will be out in the new year. It will have true dual
ports supporting simultaneous port1, port2 and gateway operation. Several
other commands will be added, and it will be compatible with the WA7MBL
and W0RLI BBs. WEFAX will also be added.

Robert Skegg.              VE7AII@VE7RGS           [e-mail]
11-Dec-87 21:45:57-EST,1357;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 11 Dec 87 21:45-EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Fri, 11 Dec 87 20:30:18 EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Fri, 11 Dec 87 20:30:09 EST
Message-Id: <[e-mail]>
Received: from MITVMA.MIT.EDU by MITVMA.MIT.EDU ; Fri, 11 Dec 87 20:30:22 EST
Received: from TRIUMFCL.BITNET (ROSK) by MITVMA.MIT.EDU (Mailer X1.25) with
 BSMTP id 9016; Fri, 11 Dec 87 20:30:03 EST
Date:     Fri, 11 Dec 87 09:53 PST
From: <[e-mail]>
Subject:  KAM<>WA7MBL Resolved.
To: [e-mail]
X-Original-To:  pack, ROSK

   My thanks to all those who replied to my question about WA7MBL<>KAM
communication. Setting MAXUSERS 0/1 or MAXUSERS 1/0 does indeed fix
the problem.
   The local Kantronics agent contacted the factory about the KAM
and got the following information: A new version of the software for
the KAM (firmware?) will be out in the new year. It will have true dual
ports supporting simultaneous port1, port2 and gateway operation. Several
other commands will be added, and it will be compatible with the WA7MBL
and W0RLI BBs. WEFAX will also be added.

Robert Skegg.              VE7AII@VE7RGS           [e-mail]
13-Dec-87 19:11:05-EST,1712;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 13 Dec 87 19:11-EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Sun, 13 Dec 87 18:27:36 EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Sun, 13 Dec 87 18:27:22 EST
Received: by june.cs.washington.edu (5.52.1/6.11)
    id AA19620; Sun, 13 Dec 87 15:28:50 PST
Return-Path: <IUS2.CS.CMU.EDU![e-mail]>
Message-Id: <[e-mail]>
Date: 11 Dec 87 18:48:14 GMT
From: IUS2.CS.CMU.EDU![e-mail] (Ralph Hyre)
To: [e-mail]
Subject: Re: Lately, hardware is so much cheaper than software...
References: <[e-mail]>

In article <[e-mail]> [e-mail] (Dave Wade) writes:
>
>Still looking for a way to plug his Icom 02at into his Macintosh+ without
>having to buy a "modified Color Computer (acting as a tnc)" so they can
>talk to each other.  The serial port on the Mac has a signal which should
>be adaptable as "push-to-talk", and my Mac is smarter than all three of
>my CoCos...
Well, for the Mac you'll at least need a modem chip and a NRZ<->NRZI
conversion chip.  The Mac has 8530, which can do all the HDLC stuff
and it can certainly handle the AX.25 and TCP/IP protocol.  2 years ago
I found out that A local (Pittsburgh, PA) ham here added just the modem part
to his Coco bit-banfer port, and got it running, I can try to get his
call for you if you're interested.



--
                    - Ralph W. Hyre, Jr.

Internet: [e-mail]    Phone:(412)268-{2847,3275} CMU-{BUGS,DARK}
Amateur Packet Radio: N3FGW@W2XO, or c/o W3VC, CMU Radio Club, Pittsburgh, PA


13-Dec-87 19:14:39-EST,904;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 13 Dec 87 19:14-EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Sun, 13 Dec 87 18:19:24 EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Sun, 13 Dec 87 18:19:13 EST
Received: by june.cs.washington.edu (5.52.1/6.11)
    id AA19404; Sun, 13 Dec 87 15:20:47 PST
Return-Path: <uwvax!speedy![e-mail]>
Message-Id: <[e-mail]>
Date: 13 Dec 87 18:29:24 GMT
From: uwvax!speedy![e-mail] (Dan Frank)
To: [e-mail]
Subject: Non-Aztec PC compilers for KA9Q package
Keywords: C, Lattice, TCP/IP
Reply-To: [e-mail] (Dan Frank)

   Has anyone done a version of the KA9Q TCP/IP package that can
be compiled with something besides Aztec C?

   Thanks,
      Dan Frank, W9NK   [e-mail]


13-Dec-87 19:15:59-EST,1097;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 13 Dec 87 19:15-EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Sun, 13 Dec 87 18:22:01 EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Sun, 13 Dec 87 18:21:47 EST
Received: by june.cs.washington.edu (5.52.1/6.11)
    id AA19495; Sun, 13 Dec 87 15:23:19 PST
Return-Path: <uwvax!speedy![e-mail]>
Message-Id: <[e-mail]>
Date: 13 Dec 87 18:26:47 GMT
From: uwvax!speedy![e-mail] (Dan Frank)
To: [e-mail]
Subject: Is there a Wally?
Reply-To: [e-mail] (Dan Frank)

   I sent mail a couple weeks ago to this Wally fellow who is supposed
to give out Internet addresses to hams.  He hasn't read his mail since
November 28.  Has he met with an unfortunate accident?  Does anyone
know if he is ever going to read his mail again?  Is there anyone besides
him who can issue me a block of addresses?

   Inquiring minds want to know ...

   Dan Frank, W9NK      [e-mail]


13-Dec-87 22:16:20-EST,756;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 13 Dec 87 22:16-EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Sun, 13 Dec 87 21:19:16 EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Sun, 13 Dec 87 21:19:02 EST
Received: from huey.udel.edu by Louie.UDEL.EDU id aa03236; 13 Dec 87 21:09 EST
Date:     Sun, 13 Dec 87 21:09:00 EST
From: [e-mail]
To: Dan Frank <[e-mail]>
Cc: [e-mail]
Subject:  Re:  Non-Aztec PC compilers for KA9Q package
Message-Id:  <[e-mail]>

Dan,

Yes, Eric Perkins of our Undergraduate Army did a version of the KarnKode
for Microsoft C. Try [e-mail].

Dave W3HCF
14-Dec-87 18:27:14-EST,1923;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 14 Dec 87 18:27-EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Mon, 14 Dec 87 17:12:18 EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Mon, 14 Dec 87 17:12:04 EST
Received: by june.cs.washington.edu (5.52.1/6.11)
    id AA25425; Mon, 14 Dec 87 14:13:37 PST
Return-Path: <boulder!sunybcs![e-mail]>
Message-Id: <[e-mail]>
Date: 11 Dec 87 14:24:22 GMT
From: boulder!sunybcs![e-mail] (Devon E Bowen)
To: [e-mail]
Subject: Re: New to this stuff
References: <[e-mail]>

In article <[e-mail]> [e-mail] writes:
>
>  First of all, where can I learn the terminology?  Just reading
>  a few postings from this group, I made a PARTIAL list of
>  terms I need to understand better to follow these postings:
>
>  [removed list of terms]
>
>  Where can I learn more about these things?  Thank you in advance.

I just got all six issues of the proceedings of The ARRL Computer
Networking Conferences from the ARRL (1-4 set for $18, 5 and 6 for
$10 each, all for $38) and they've got everything you need to know
about packet in them. There's articles describing the protocol layer
system, details (down to the bit level) of specific layers (AX.25,
TCP/IP, etc.), the latest advances in hardware, and general proposals
for different networking schemes. These books have been invaluable
to me.

                   Devon Bowen (KA2NRC)
                   University of Buffalo

*********************************************************
uucp:      ..!{ames,boulder,decvax,rutgers}!sunybcs!bowen
Internet:  [e-mail]
BITNET:    [e-mail]
*********************************************************


14-Dec-87 18:35:40-EST,2180;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 14 Dec 87 18:35-EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Mon, 14 Dec 87 17:10:47 EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Mon, 14 Dec 87 17:10:34 EST
Received: by june.cs.washington.edu (5.52.1/6.11)
    id AA25350; Mon, 14 Dec 87 14:12:09 PST
From: apollo![e-mail]
Return-Path: <apollo![e-mail]>
Message-Id: <[e-mail]>
Date: 10 Dec 87 15:21:00 GMT
To: [e-mail]
Subject: New to this stuff

  I'm new to this packet racket (just got a PK232 a few days ago)
  and I have lots of questions:

  First of all, where can I learn the terminology?  Just reading
  a few postings from this group, I made a PARTIAL list of
  terms I need to understand better to follow these postings:

  Sample:  ARPA Suite, ASLIP gateway, CMU/MIT PC/IP,
       connectionless / connection-oriented, CONS / CLNS,
       COSI, datagram, DDN Protocol Suite, ISs (routers/gateways),
       IP, KA9Q Internet, KISS, NET/ROM, OSI, PAD, PTT (NOT 'push
       to talk'), RFC, simplex/duplex digi, TCP, TELNET, TP4, VC
       (virtual circuit), wideband packet, WORLI, X.25 levels
       (or a definition of X.25 for that matter), X.75...

  This newsgroup ought to come with a glossary!

  Also I'd like to learn more about the background behind the various
  issues under discussion.  For instance I get the feeling (though I
  may be wrong) that people are trying to adapt computer-computer
  standards and protocols to ham radio digital networking.  This
  despite the fact that ham radio may have unique requirements for
  which the computer standards were not designed (such as call-sign
  encoding).  So why are we doing this?

  Where can I learn more about these things?  Thank you in advance.

                        --Peter (N1CHJ)

  PS-  Is there any packet activity on 10 meters?  Is there a standard
       frequency where I would expect to find activity?




14-Dec-87 23:59:33-EST,1162;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 14 Dec 87 23:59-EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Mon, 14 Dec 87 22:31:14 EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Mon, 14 Dec 87 22:30:50 EST
Received: by june.cs.washington.edu (5.52.1/6.11)
    id AA07340; Mon, 14 Dec 87 19:32:07 PST
Return-Path: <uunet!mcvax!ukc!stc!idec![e-mail]>
Message-Id: <[e-mail]>
Date: 1 Dec 87 09:05:59 GMT
From: uunet!mcvax!ukc!stc!idec![e-mail] (Gareth Howell)
To: [e-mail]
Subject: NEEDED: KISS for TNC220

I have a Pacomm TNC220 on which I want to run KISS and thence the KA9Q
tcp/ip package.  Unfortunately I don't have a KISS for the TNC.
Can anybody help.  I would prefer the co-resident bootstrap with a
downloaded KISS module if possible.
ta Gareth
====
Gareth Howell  <[e-mail]>  G6KVK @ IO91VX
ICL NS PNBC, England, SG1 1YB    Tel:[phone]
[e-mail], mcvax!ukc!idec![e-mail]
G6KVK @ G4SPV (uk packet 144.650MHz)


15-Dec-87 00:03:36-EST,8870;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 15 Dec 87 00:03-EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Mon, 14 Dec 87 22:26:33 EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Mon, 14 Dec 87 22:26:17 EST
Received: by june.cs.washington.edu (5.52.1/6.11)
    id AA07167; Mon, 14 Dec 87 19:27:50 PST
Return-Path: <bellcore!faline![e-mail]>
Message-Id: <[e-mail]>
Date: 15 Dec 87 02:50:11 GMT
From: bellcore!faline![e-mail] (Phil R. Karn)
To: [e-mail]
Subject: Re: New to this stuff
Summary: glossary - an attempt
References: <[e-mail]>

>   Sample:  ARPA Suite, ASLIP gateway, CMU/MIT PC/IP,
>            connectionless / connection-oriented, CONS / CLNS,
>            COSI, datagram, DDN Protocol Suite, ISs (routers/gateways),
>            IP, KA9Q Internet, KISS, NET/ROM, OSI, PAD, PTT (NOT 'push
>            to talk'), RFC, simplex/duplex digi, TCP, TELNET, TP4, VC
>            (virtual circuit), wideband packet, WORLI, X.25 levels
>            (or a definition of X.25 for that matter), X.75...

Okay, here goes with a neutral glossary of amateur packet radio terms.

ARPA Suite - the set of protocols standardized by the Advanced Research
Projects Agency of the US Department of Defense. Includes TCP and IP as
elements, but leaves the lower levels (subnetwork and down) deliberately
unspecified; the ARPA suite can be run on top of multiple subnetworks,
unifying them into a single Internet.

ASLIP - Asynchronous Serial Line (usually just called SLIP). A technique
for encoding IP datagrams so they can be sent across ordinary asynchronous
modems and communications hardware.

CLNS - Connectionless Network Service (see connectionless, datagram).

CMU/MIT PC/IP - one of the public domain packages that implement the ARPA
protocols on the IBM PC and its clones.

connectionless - refers to a packet protocol or service that does not
have the concept of a "connection". Packets may be sent at will, without
prior arrangement or need for connection setup/teardown procedures.

connection-oriented - refers to a protocol or service that requires that
a logical or virtual "connection" first be established with a special
procedure before data can be sent. Another procedure is used to "tear
down" the connection when it is no longer needed.

CONS - Connection Oriented Network Service (see connection-oriented, virtual
circuit).

COSI - Connection-oriented Open Systems Interconnect. A project of W2VY
and N2DSY to implement for amateur packet radio use the
connection-oriented protocols published by the International Standards
Organization (ISO) and the International Consultative Committee for
Telephony and Telegraphy (CCITT). (OSI protocols include both
connection-oriented and connectionless flavors, hence the inclusion of
the qualifier "connection-oriented" in the name). The COSI software is
presently under development.

datagram - Information packets in a connectionless environment.
Datagrams are completely self-contained as far as the network is
concerned. The information needed to get each datagram to its
destination (including, but not limited to, full source and destination
addresses) is carried in each datagram.

DDN Protocol Suite (Defense Data Network Protocol Suite). See ARPA
Protocol Suite.

duplex digi - like a simplex digi, except that different receive and transmit
frequencies are used. Allows simultaneous reception and transmission.

Gateway - a very general term for anything that connects two networks
together. In the ARPA world, "gateway" has a much more specific meaning:
a packet switch that handles IP datagrams.

IP - Internet Protocol. The core protocol of the ARPA suite.  IP is a
simple connectionless (datagram) protocol that handles addressing,
fragmentation and type-of service routing in the heterogeneous
internetwork environment.

IS - Intermediate System. ISO's term for a packet switch.

ISO - International Standards Organization. Publishes specifications for
everything from screw threads to computer communication protocols. Also,
International Snake Oi...oops, promised to keep things neutral. :-)

KA9Q Internet - name for a C software package developed by KA9Q with
programming contributions from N3EUA, K3MC, NG6Q, WA3CVG, PA0GRI, NN2Z,
WB6ECE, AJ9X, K4FUM, N9DVG, K3EZ and probably some others I've
overlooked. Implements the major elements of the ARPA protocol suite:
IP, ICMP, TCP, UDP, Telnet, FTP, SMTP and ARP. Also implements
subnetwork drivers for SLIP, KISS, AX.25, Ethernet and Appletalk.
Primary environment is the IBM PC (and clones), but has been ported to
68K-based machines like the Commodore Amiga and Apple Macintosh, also to
UNIX System 5 environments. Sources, objects and documentation are
available for anonymous ftp from louie.udel.edu under /pub/ka9q.

KISS - Keep It Simple, Stupid. A TNC operating mode where the TNC merely
translates packets between half duplex, synchronous HDLC on the radio
port and full duplex asynchronous SLIP framing on the host port; the
host computer must implement all higher level protocols, including AX.25
if it is used. Gives the host computer full access to and control over
all fields in each packet. Compensates for the lack of a HDLC hardware
controller on many computers.

NET/ROM - A proprietary product of Software 2000, Inc (WA8DED and W6IXU).
Consists of ROM firmware for the TNC-2. Implements AX.25 at the link layer,
with ad-hoc protocols at the network and transport layer. Also provides
a command interpreter and "transport level bridge" that patches incoming
or outgoing vanilla AX.25 connections to internal transport layer
connections.  Uses datagrams at the network layer, virtual circuits at the
transport layer.  Provides automatic routing between NET/ROM nodes, the user
is still responsible for "source routing" between the end NET/ROM nodes and
the ultimate source and destination.

OSI - Open Systems Interconnect. A project of the ISO to develop a set of
computer communications protocols.

PAD - Packet Assembler/Disassembler. A device that interfaces an ordinary
"dumb" terminal to an X.25 packet network. It gathers typed characters
into outgoing packets and translates incoming packets back into serial
asynchronous data streams. Also provides a simple command interpreter for
setting up and tearing down connections, controlling parameters, etc.
The amateur packet radio TNC was heavily modeled on the PAD.

PTT - Postal, Telephone and Telegraph authority. The government-owned
phone monopoly found in almost every country except the USA.

RFC - Request for Cmments.  Memoranda published in electronic form by the
ARPA Network Information Center. Documents everything from informal proposals
to established standards.

Router - Yet another term for a packet switch. Used by Xerox's XNS and
Digital's DECNET, two proprietary networking protocol suites very
similar to (but incompatible with) the ARPA suite (and with each other).

simplex digi - a regenerative digital repeater that receives a packet,
verifies that it was received correctly, and (if appropriate) retransmits
it on the same frequency it was received on.

TCP - Transmission Control Protocol. A major element of the ARPA Suite.
Provides reliable, connection-oriented byte stream service on an end-to-end
basis. Runs atop IP and sits at the transport and session layers.

TELNET - A presentation/application protocol in the ARPA Suite used for
terminal to terminal and terminal to host communications (e.g., remote
login).

TP4 - An element of the ISO OSI suite. A transport protocol that provides
reliable, connection-oriented byte stream service on an end-to-end
basis, analogous to TCP in the ARPA suite.

VC - virtual circuit. The service provided by a connection-oriented network
(qv).  Virtual circuit data packets generally carry less header information
than datagrams, since addresses have been specified at connection setup
time.

wideband packet - Anything faster than 1200 baud. Generally refers to operation
at 56kbps with modems designed by WA4DSY.

W0RLI - Hank Orelson, W0RLI, author of a very widely used packet
bulletin board.

X.25 - A CCITT standard protocol for the subscriber interface to a public
packet switched network. Consists of two layers, link (level 2) and packet
(level 3).  The amateur AX.25 protocol is a highly modified version of just
the link layer of X.25; it does not have a packet layer.

X.75 - A CCITT standard protocol for the interface between two separate
public packet switched networks. Resembles X.25 in considerable detail.

Anything else?

Phil


15-Dec-87 16:24:07-EST,9976;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 15 Dec 87 16:24-EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Tue, 15 Dec 87 14:13:15 EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Tue, 15 Dec 87 14:12:55 EST
Received: by june.cs.washington.edu (5.52.1/6.11)
    id AA28856; Tue, 15 Dec 87 11:14:33 PST
Return-Path: <ihnp4!homxb!hou2d![e-mail]>
Message-Id: <[e-mail]>
Date: 15 Dec 87 14:05:45 GMT
From: ihnp4!homxb!hou2d![e-mail] (G.BEATTIE)
To: [e-mail]
Subject: RATS COSI-Switch Update: 13 December 1987
Keywords: RATS COSI-Switch OSI X.25 Packet Switch CCITT ISO

      The Radio Amateur Telecommuications Society
             Information Bulletin

          COSI-Switch Update: 13 December 1987


* Well December is here we're on track !  As stated in our last update
  we are running a few weeks behind, but we haven't gotten any more
  behind than before !

* Tom, W2VY has the code in the initial Z-80 target machine
  (TNC-2) and has begun the debugging process.  He has previously
  completed an exhaustive set of software and protocol tests on a PC and
  on a Z-80 based CP/M machine.  The protocol tests, test the whole system
  with the exception of the drivers.  The early versions of the test
  environment were loaded to CompuServe and are available there.

* Beta Testing will begin this month (December).

* The RATS COSI-Switch by Thomas A. Moulton, W2VY will be released
  (mailed, uploaded, etc) with source in late January.  Target machines
  for this release include the TNC-2 family and PAC-COMM's DR-200 and PC-100.
  Other targets are being examined...feel free to suggest a favorite !

* RATS is expecting the arrival of a beta test PC-186 board.  The RATS
  COSI-Switch will be ported to this device, providing a vehicle for
  high speed (greater than 56KBps) links.

* The COSI-Switch software has been requested by groups in 33+ states and
  15+ countries !

* The back to back multi-TNC node configurations will be supported
  for those who wish to change their node software.  PLEASE NOTE:
  This was requested by YOU, the folks who expressed a desire run software
  with available source code.

* There have been some questions about our distribution and use policies.
  Our software policy is simple:

    1. Free for non-commercial Amateur Radio use ONLY,
    2. Modification policy for non-commercial Amateur Radio users is simple,
    3. Executable, source and modification licenses can be obtained
       for other uses.

  Software modification policy for non-commercial Amateur Radio users:  You can
  modify the code all you want, but in order to maintain your right
  to use the code you must send us copies of your modified software source.
  This ensures that the distribution of new features added by others
  is consistent.  It also helps us ferret out bug reports from the field.



*******  PLEASE NOTE:  ALL PROCEEDS GO TOWARD NETWORK COMPONENTS  ********
         NO CONVENTION TRAVEL FROM THIS FUND !


* Here is a description of some of the features

     ***  AS IMPLEMENTED in the SWITCH TODAY.



USER CAPABILITIES

The interface to the COSI-Switch has been designed with the
average user in mind.  Current users are familiar with
networking using digipeaters (C CALLSIGN VIA DIGI, DIGI).  We
have continued this basic concept in the COSI user interface.
There are several different ways the user can access the switch
and, through it, the network.


Local Digipeating
----- -----------
This mode of operation is pretty straightforward and provides a
familiar mode of operation to continue WITHIN the local network.
The COSI-Switch will ONLY digipeat frames with just one callsign (its own)
in the "via" field of the AX.25 frame.

Within the local network, users may digipeat through the switch by typing:

          "C N2FWI V N2DSY-3"



Multi-Switch Networking
------------ ----------
There is only one new concept for users to learn in order to use the advanced,
multi-switch networking capabilities of the COSI-Switch.  Each switch has a
unique, 6-digit "address."  This address is made up of two parts: the telephone
area code serving the switch's location (first three digits), and a three digit
Switch Number.

In order to connect to another station at a remote switch one must know the
address for that switch.  If KB7UV uses the switch "718010" then to connect
to him a user would type:

          "C KB7UV V N2DSY-3,718010"

The call request will be routed TRANSPARENTLY to the destination
switch and user.



Local Switching
----- ---------
There is however another option: a user may want to use the advanced
functionality of the switch WITHIN the local network.  This is just like a
multi-switch connection except the Destination Switch Address is that of
Source Switch!  To do this type:

          "C N2FWI V N2DSY-3,201010"

This initially looks like a two hop digipeater connection, but in reality
the COSI-Switch gets into the picture and make the connection more
reliable.  The COSI-Switch will receive the request from W2XYZ and then
send a connect to N2FWI.  After this connection is established the switch
will acknowledge the initial connect request.    If required, the N2DSY-3
switch will retransmit frames that are unacknowledged.  The switch will
use its own parameters to determine the need and ideal opportunity to
retransmit.  The switch will not only automatically determine the port
used by "known" users, but will search out the "unknown" user on its user
ports.


Network Management
------- ----------
After examining the trends of the last few years, we have determined that most
switches, digipeaters and other devices seem to be fairly stable.  We have
chosen to build on this and plan our network implementation philosophy
on the premise that inter-switch trunks will be planned and preconfigured.
This reduces the need to endlessly tie-up precious bandwidth with automatic
reconfiguration tables.  This also has the additional advantage of preventing
renegade nodes from appearing and jeopardizing the operational effectiveness
of the backbone.  This brings up two points:

1. How will the COSI-Switches be managed ?

The COSI-Switch when released, will contain a remote configuration and
statistics module.  This system will have a security mechanism.  Another
capability of the COSI-Switch is the generation of "connection records".
These provide an record for the COSI-Switch owner/trustee of the source, and
destination calls and network addresses, access digipeater path (if any), the
time and whether the record is a call or a clear record.  The clear records
will also contain the clearing cause and diagnostic code.  These are valuable
items which aid in the network configuration process.  They are also useful
when attempting to track down the source of undesirable activity.

2. How will temporary COSI-Switches be added in times of emergency when
   a stricken area requires supplemental communications ?

A COSI-Switch may be added to the network at any time.  The new switch
located in the stricken area would appear as a Level 3 user.  Calls would
be routed out by the new switch and through any switches attached to it.
Inbound calls would not be routed into the stricken area until, or unless
the new switch is added to the tables of the existing switches.  This is
an IDEAL situation since emergency traffic should flow outbound from the
stricken area, until the situation has stablized.  The remote configuration
feature can be used to integrate the new switch into the network if the
situation requires.

The procedure and format of the remote configuration are currently being
finalized.


Addressing Plan
---------- ----
The Level 2 user can be found in the network by routing on the
destination user's callsign and the destination node address.  A
short form entry mechanism has been provided for Level 2 TNC
users.  This is the six digit switch number made up of the
telephone area code and switch number.  This is a part of a
larger (20+ character) address.  Don't expect us to ask you the
users to type in all this, but if you wish to have full
interworking between networks (Amateur and others) then you
might want the option for some connections.  We'll talk about
this in further bulletins.  Here's a brief overview to get you
started.

The addressing plan used by the COSI-Switches is based on the
OSI NSAP Address (Open Systems Interconnection - Network Service
Access Point).  This address contains two components: the
callsign of the station and the COSI-Switch Address.  The NSAP
takes the form: Prefix + callsign + Data Country Code + Number
The Prefix is determined jointly by CCITT and ISO.  It functions
to identify the portion of the addressing plan that we are
using.  The next field contains the Amateur callsign.
The last two field identify the country of operation and the switch
address.  Specific plans for national use outside of North America
will be developed.  Consultation with RATS is suggested so that we can
include such plans in our documentation.


Final Note
----- ----
We will be circulating switch software to the beta group later
in the month and general distribution will be in late January.
Despite some recent questions about commercial systems, we are
investigating through letter the possibility of distributing the
COSI-Switch software via CompuServe.  Planned channels are via
telephone BBS, UUCP, US Mail, and Amateur Packet Networks Look
for it.


73, J. Gordon Beattie, Jr.  N2DSY @ KD6TH or ihnp4!hotps!n2dsy-4!n2dsy
                Telephone: [phone]


15-Dec-87 16:31:50-EST,1648;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 15 Dec 87 16:31-EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Tue, 15 Dec 87 11:10:49 EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Tue, 15 Dec 87 11:10:37 EST
Received: by june.cs.washington.edu (5.52.1/6.11)
    id AA21969; Tue, 15 Dec 87 08:12:11 PST
Return-Path: <uunet!mcvax!unido!rmi!dg2kk![e-mail]>
Message-Id: <[e-mail]>
Date: 10 Dec 87 23:09:52 GMT
From: uunet!mcvax!unido!rmi!dg2kk![e-mail] (Walter)
To: [e-mail]
Subject: Problems with WA8DED 2.1 and TNC-2 clones (+possible solution)
Summary: PTT line is released too early
Posted: Fri Dec 11 00:09:52 1987

Some TNC-2's have problems with the WA8DED software (version 2.1).
Most of the outgoing frames cannot be docoded by other stations because
the software turns off the transmitter before all bits have been transmitted.

There are two solutions to this problem:

Hardware: connect a small (~2.2uf) capacitor from the base of the PTT keying
      transistor to ground. (Note: you may have to increase TXDELAY)

Software: the code that turns off the transmitter starts at location $037B
      (3E 05...). It's possible to insert a short delay loop, so that the
      transmitter remains keyed for a few milliseconds longer.
      (I haven't tried this yet.)


73s, Walter  [e-mail]


PS: Does anyone know if WA8DED is on USENET/Bitnet/ARPANET/anynet???
    What is his email address? Please let me know.  Thanks.


15-Dec-87 18:21:23-EST,9976;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 15 Dec 87 18:21-EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Tue, 15 Dec 87 14:13:15 EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Tue, 15 Dec 87 14:12:55 EST
Received: by june.cs.washington.edu (5.52.1/6.11)
    id AA28856; Tue, 15 Dec 87 11:14:33 PST
Return-Path: <ihnp4!homxb!hou2d![e-mail]>
Message-Id: <[e-mail]>
Date: 15 Dec 87 14:05:45 GMT
From: ihnp4!homxb!hou2d![e-mail] (G.BEATTIE)
To: [e-mail]
Subject: RATS COSI-Switch Update: 13 December 1987
Keywords: RATS COSI-Switch OSI X.25 Packet Switch CCITT ISO

      The Radio Amateur Telecommuications Society
             Information Bulletin

          COSI-Switch Update: 13 December 1987


* Well December is here we're on track !  As stated in our last update
  we are running a few weeks behind, but we haven't gotten any more
  behind than before !

* Tom, W2VY has the code in the initial Z-80 target machine
  (TNC-2) and has begun the debugging process.  He has previously
  completed an exhaustive set of software and protocol tests on a PC and
  on a Z-80 based CP/M machine.  The protocol tests, test the whole system
  with the exception of the drivers.  The early versions of the test
  environment were loaded to CompuServe and are available there.

* Beta Testing will begin this month (December).

* The RATS COSI-Switch by Thomas A. Moulton, W2VY will be released
  (mailed, uploaded, etc) with source in late January.  Target machines
  for this release include the TNC-2 family and PAC-COMM's DR-200 and PC-100.
  Other targets are being examined...feel free to suggest a favorite !

* RATS is expecting the arrival of a beta test PC-186 board.  The RATS
  COSI-Switch will be ported to this device, providing a vehicle for
  high speed (greater than 56KBps) links.

* The COSI-Switch software has been requested by groups in 33+ states and
  15+ countries !

* The back to back multi-TNC node configurations will be supported
  for those who wish to change their node software.  PLEASE NOTE:
  This was requested by YOU, the folks who expressed a desire run software
  with available source code.

* There have been some questions about our distribution and use policies.
  Our software policy is simple:

    1. Free for non-commercial Amateur Radio use ONLY,
    2. Modification policy for non-commercial Amateur Radio users is simple,
    3. Executable, source and modification licenses can be obtained
       for other uses.

  Software modification policy for non-commercial Amateur Radio users:  You can
  modify the code all you want, but in order to maintain your right
  to use the code you must send us copies of your modified software source.
  This ensures that the distribution of new features added by others
  is consistent.  It also helps us ferret out bug reports from the field.



*******  PLEASE NOTE:  ALL PROCEEDS GO TOWARD NETWORK COMPONENTS  ********
         NO CONVENTION TRAVEL FROM THIS FUND !


* Here is a description of some of the features

     ***  AS IMPLEMENTED in the SWITCH TODAY.



USER CAPABILITIES

The interface to the COSI-Switch has been designed with the
average user in mind.  Current users are familiar with
networking using digipeaters (C CALLSIGN VIA DIGI, DIGI).  We
have continued this basic concept in the COSI user interface.
There are several different ways the user can access the switch
and, through it, the network.


Local Digipeating
----- -----------
This mode of operation is pretty straightforward and provides a
familiar mode of operation to continue WITHIN the local network.
The COSI-Switch will ONLY digipeat frames with just one callsign (its own)
in the "via" field of the AX.25 frame.

Within the local network, users may digipeat through the switch by typing:

          "C N2FWI V N2DSY-3"



Multi-Switch Networking
------------ ----------
There is only one new concept for users to learn in order to use the advanced,
multi-switch networking capabilities of the COSI-Switch.  Each switch has a
unique, 6-digit "address."  This address is made up of two parts: the telephone
area code serving the switch's location (first three digits), and a three digit
Switch Number.

In order to connect to another station at a remote switch one must know the
address for that switch.  If KB7UV uses the switch "718010" then to connect
to him a user would type:

          "C KB7UV V N2DSY-3,718010"

The call request will be routed TRANSPARENTLY to the destination
switch and user.



Local Switching
----- ---------
There is however another option: a user may want to use the advanced
functionality of the switch WITHIN the local network.  This is just like a
multi-switch connection except the Destination Switch Address is that of
Source Switch!  To do this type:

          "C N2FWI V N2DSY-3,201010"

This initially looks like a two hop digipeater connection, but in reality
the COSI-Switch gets into the picture and make the connection more
reliable.  The COSI-Switch will receive the request from W2XYZ and then
send a connect to N2FWI.  After this connection is established the switch
will acknowledge the initial connect request.    If required, the N2DSY-3
switch will retransmit frames that are unacknowledged.  The switch will
use its own parameters to determine the need and ideal opportunity to
retransmit.  The switch will not only automatically determine the port
used by "known" users, but will search out the "unknown" user on its user
ports.


Network Management
------- ----------
After examining the trends of the last few years, we have determined that most
switches, digipeaters and other devices seem to be fairly stable.  We have
chosen to build on this and plan our network implementation philosophy
on the premise that inter-switch trunks will be planned and preconfigured.
This reduces the need to endlessly tie-up precious bandwidth with automatic
reconfiguration tables.  This also has the additional advantage of preventing
renegade nodes from appearing and jeopardizing the operational effectiveness
of the backbone.  This brings up two points:

1. How will the COSI-Switches be managed ?

The COSI-Switch when released, will contain a remote configuration and
statistics module.  This system will have a security mechanism.  Another
capability of the COSI-Switch is the generation of "connection records".
These provide an record for the COSI-Switch owner/trustee of the source, and
destination calls and network addresses, access digipeater path (if any), the
time and whether the record is a call or a clear record.  The clear records
will also contain the clearing cause and diagnostic code.  These are valuable
items which aid in the network configuration process.  They are also useful
when attempting to track down the source of undesirable activity.

2. How will temporary COSI-Switches be added in times of emergency when
   a stricken area requires supplemental communications ?

A COSI-Switch may be added to the network at any time.  The new switch
located in the stricken area would appear as a Level 3 user.  Calls would
be routed out by the new switch and through any switches attached to it.
Inbound calls would not be routed into the stricken area until, or unless
the new switch is added to the tables of the existing switches.  This is
an IDEAL situation since emergency traffic should flow outbound from the
stricken area, until the situation has stablized.  The remote configuration
feature can be used to integrate the new switch into the network if the
situation requires.

The procedure and format of the remote configuration are currently being
finalized.


Addressing Plan
---------- ----
The Level 2 user can be found in the network by routing on the
destination user's callsign and the destination node address.  A
short form entry mechanism has been provided for Level 2 TNC
users.  This is the six digit switch number made up of the
telephone area code and switch number.  This is a part of a
larger (20+ character) address.  Don't expect us to ask you the
users to type in all this, but if you wish to have full
interworking between networks (Amateur and others) then you
might want the option for some connections.  We'll talk about
this in further bulletins.  Here's a brief overview to get you
started.

The addressing plan used by the COSI-Switches is based on the
OSI NSAP Address (Open Systems Interconnection - Network Service
Access Point).  This address contains two components: the
callsign of the station and the COSI-Switch Address.  The NSAP
takes the form: Prefix + callsign + Data Country Code + Number
The Prefix is determined jointly by CCITT and ISO.  It functions
to identify the portion of the addressing plan that we are
using.  The next field contains the Amateur callsign.
The last two field identify the country of operation and the switch
address.  Specific plans for national use outside of North America
will be developed.  Consultation with RATS is suggested so that we can
include such plans in our documentation.


Final Note
----- ----
We will be circulating switch software to the beta group later
in the month and general distribution will be in late January.
Despite some recent questions about commercial systems, we are
investigating through letter the possibility of distributing the
COSI-Switch software via CompuServe.  Planned channels are via
telephone BBS, UUCP, US Mail, and Amateur Packet Networks Look
for it.


73, J. Gordon Beattie, Jr.  N2DSY @ KD6TH or ihnp4!hotps!n2dsy-4!n2dsy
                Telephone: [phone]


16-Dec-87 13:44:14-EST,836;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 16 Dec 87 13:44-EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Wed, 16 Dec 87 12:14:18 EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Wed, 16 Dec 87 12:13:32 EST
Received: Wed, 16 Dec 87 08:11:15 PST by ames.arpa (5.58/1.2)
Received: Wed, 16 Dec 87 08:11:12 PST by ames.arpa (5.58/1.2)
Date: Wed, 16 Dec 87 07:47 PST
Message-Id: <SJIH-2720-2609@nasamail>
From: [e-mail] (ERIC KIRKENDALL)
To: [e-mail]
Cc: [e-mail]
Subject: PACKET RADIO DIST LIST


Please add me to your distribution list.  Thank you.

Eric Kirkendall
NASA Headquarters
Mail Code NTI
Washington, DC 20546
202-453-1787

[e-mail]

17-Dec-87 18:17:58-EST,1839;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 17 Dec 87 18:17-EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Thu, 17 Dec 87 17:09:11 EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Thu, 17 Dec 87 17:08:51 EST
Received: by june.cs.washington.edu (5.52.1/6.11)
    id AA10845; Thu, 17 Dec 87 14:10:26 PST
Return-Path: <linus!philabs!trotter![e-mail]>
Message-Id: <[e-mail]>
Date: 16 Dec 87 12:20:01 GMT
From: linus!philabs!trotter![e-mail] (Bill Gunshannon)
To: [e-mail]
Subject: Re: NEEDED: KISS for TNC220
Summary: out of luck
References: <[e-mail]>

Having spoken with PAC-COMM on this subject, I have bad news for you.
Because the 220 is not a TNC-1 or TNC-2 clone but a complete redesign
by PAC-COMM the existing KISS PROMs won't work and no one that PAC-COMM
is aware of has written KISS for the 220 specificly.

I know it is hardly comforting but the best solution I can think of is
to purchase another TNC for just running KISS and TCP-IP.  Again PAC-COMM
has a new product called the TINY-2 which is a reduced size TNC-2 imitator.
It does use the normal TNC-2 PROM so you can put in one of the existing
KISS implementations.

Good luck.

P.S. If anyone can prove me wrong please do as I have a TNC220 also and
would love to be able to run KISS in it as well as my KANTRONICS!!!

73's

bill gunshannon


UUCP: {philabs}\                        US SNAIL: Martin Marietta Data Systems
      {phri   } >!trotter.usma.edu!bill           USMA, Bldg 600, Room 26
      {sunybcs}/                                  West Point, NY  10996
RADIO:         KB3YV                    PHONE: WORK    [phone]
AX.25:         KB3YV @ K3RLI            PHONE: HOME    [phone]


17-Dec-87 20:22:48-EST,1992;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 17 Dec 87 20:22-EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Thu, 17 Dec 87 19:24:20 EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Thu, 17 Dec 87 19:23:59 EST
Message-Id: <[e-mail]>
Received: from MITVMA.MIT.EDU by MITVMA.MIT.EDU ; Thu, 17 Dec 87 19:24:43 EST
Received: from NJECNVM.BITNET (H156004) by MITVMA.MIT.EDU (Mailer X1.25) with
 BSMTP id 7486; Thu, 17 Dec 87 19:24:41 EST
Date: 17 Dec 87   19:21 EST
From: [e-mail]
To: [e-mail]
Subject: BITNET mail follows


RELAYED BY WB2PUW @ WB2DRD

I STAND BY MY ORIGINAL STATEMENTS COMPLETELY, AND DO NOT
PARTICULARLY CARE IF RLI AGREES OR NOT. HE RECEIVED FROM
ME A DISK THAT REPRESENTED ONE OF MY EARLIEST DEVELOPMENT
CUTS ON THE CODE. IT MAY NOT HAVE SEEMED TO HAVE CHANGED
MUCH AS FAR AS HE IS CONCERNED BUT AMONG THE CHANGES THAT
WERE MADE WERE LISTING AND READING RANGES OF MESSAGES,
CORRECTIONS TO ABOUT 20 OF HIS BUGS, A FIND TEXT COMMAND, AND
PROBABLY A FEW MORE THINGS. AT THIS POINT I CANNOT REMEMBER
WHAT WAS IN IT AS OPPOSED TO LATER RELEASES; IT WAS SO FAR
BACK IN MY DEVELOPMENT CYCLE.

I AM ABOUT SICK OF THIS ARGUMENT. PRMBS IS AND HAS BEEN PROVEN
A SUPERIOR PIECE OF CODE ON THE PC. WE INTEND TO MAKE IT FLY
ON OTHER SYSTEMS WHEN TIME PERMITS. IF HANK WANTS TO TRY TO
KNOCK ME DOWN TO DRAW ATTENTION AWAY FROM THAT FACT, HE IS
WELCOME TO TRY, BUT HE IS JUST MAKING HIMSELF LOOK SILLY. HE
MAY BE HARD PRESSED TO EXPLAIN WHY OF THE 80 TO 100 PRMBS SITES
RIGHT NOW ABOUT HALF ARE CONVERTS FROM OTHER SYSTEMS MOST OF
WHOM USED TO RUN CBBS.

THIS IS MY LAST REPLY. IF ORDESON THINKS HE NEEDS IT PLEASE FEEL
FREE TO SEND HIM A COPY. THE LAST MESSAGE MBL AND I GOT FROM HIM
SAID MORE OR LESS FOR JEFF AND ME TO DROP HIM FROM OUR
DISTRIBUTION LISTS.

73 DE BRIAN RILEY -- KA2BQE

19-Dec-87 23:11:00-EST,1645;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 19 Dec 87 23:11-EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Sat, 19 Dec 87 22:33:12 EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Sat, 19 Dec 87 22:33:02 EST
Received: by june.cs.washington.edu (5.52.1/6.11)
    id AA09321; Sat, 19 Dec 87 19:34:40 PST
From: tsdiag![e-mail]
Return-Path: <tsdiag![e-mail]>
Message-Id: <[e-mail]>
Date: 17 Dec 87 13:50:11 GMT
To: [e-mail]
Subject: Re: RATS COSI-Switch Update: 13 December 1987
Keywords: RATS COSI-Switch OSI X.25 Packet Switch CCITT ISO
References: <[e-mail]>

I just want to add that you will notice that the addressing described
for COSI referenced Area Code and Switch number, Gordon and I fought
over this a bit.

Why?

Everything listed is CODED AND WORKING unless otherwise stated.
We will be using Area Codes and Exchanges in future releases but I was
very firm on having the update notice reflect REALITY not what we want to
have in for the first release.  It's just a matter of coding to get the ideal
things in place.

The beta release will use switch numbers, I HOPE to have exchanges in for the
offical release in Jan.

hi ho hi ho it's off to code we go...

--
Thomas A. Moulton, W2VY          Life is too short to be mad about things.
Home: (201) 779-W2VY             Packet: w2vy@kd6th  Voice: 145.190 (r)
Work: [phone] x3226       FAX:  [phone]
Concurrent Computer Corp.        uucp: ...!ihnp4!hotps!ka2qhd!w2vy


19-Dec-87 23:35:17-EST,1168;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 19 Dec 87 23:35-EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Sat, 19 Dec 87 23:00:44 EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Sat, 19 Dec 87 23:00:33 EST
Received: by june.cs.washington.edu (5.52.1/6.11)
    id AA09596; Sat, 19 Dec 87 20:02:12 PST
Return-Path: <bellcore!faline![e-mail]>
Message-Id: <[e-mail]>
Date: 17 Dec 87 18:47:37 GMT
From: bellcore!faline![e-mail] (Phil R. Karn)
To: [e-mail]
Subject: Re: NEEDED: KISS for TNC220
Summary: Kantronics does support SLIP
References: <[e-mail]> <[e-mail]>

> P.S. If anyone can prove me wrong please do as I have a TNC220 also and
> would love to be able to run KISS in it as well as my KANTRONICS!!!

I'm not sure what you meant by the reference to Kantronics, but they now
support SLIP on all their TNCs. They advertise it as "TCP/IP
compatibility". I appreciate the plug, but "KISS compatibility" would
have been more accurate and descriptive.

Phil


19-Dec-87 23:41:11-EST,1054;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 19 Dec 87 23:41-EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Sat, 19 Dec 87 23:02:42 EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Sat, 19 Dec 87 23:02:18 EST
Received: by june.cs.washington.edu (5.52.1/6.11)
    id AA09607; Sat, 19 Dec 87 20:03:55 PST
Return-Path: <ll-xn!oberon!hamal.usc.edu![e-mail]>
Message-Id: <[e-mail]>
Date: 16 Dec 87 19:07:37 GMT
From: ll-xn!oberon!hamal.usc.edu![e-mail] (Dick Mead)
To: [e-mail]
Subject: Re: TCP/IP
References: <[e-mail]>
Reply-To: [e-mail] (Dick Mead)

 Does anyone have a working copy of the KA9Q TCP/IP package for the Mac???
 If you do, I would dearly love to have the MAKEFILE that will allow me
 to have the same success! So far I've had NO luck getting my Mac and PK232
 to talk with the KA9Q stuff...

 Dick  WB6NGC
 <[e-mail]>




25-Dec-87 16:43:38-EST,1885;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 25 Dec 87 16:43-EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Fri, 25 Dec 87 16:03:38 EST
Received: from mc.lcs.mit.edu by EDDIE.MIT.EDU via Chaosnet with SMTP with sendmail-5.45/4.7 id <[e-mail]>; Fri, 25 Dec 87 16:03:22 EST
Resent-Message-Id: <[e-mail]>
Received: from SIMTEL20.ARPA (TCP 3200000112) by MC.LCS.MIT.EDU 25 Dec 87 16:05:26 EST
Date: Thursday, 24 December 1987  19:55-MST
Message-Id: <[e-mail]>
Sender: ptsfa!well![e-mail] (John A. Limpert)
From: ptsfa!well![e-mail] (John A. Limpert)
To: [e-mail]
Subject:   PC/AT UNIX TCP/IP software development
Resent-From: [e-mail]
Resent-To: [e-mail]
Resent-Date: Fri 25 Dec 1987 14:03-MST

I have ported KA9Q's TCP/IP software to several UNIX machines, an AT
clone running Microport System V/AT and a Heurikon 68010 running
UniPlus+ 5.0.  It currently supports SLIP and KISS on asynchronous
lines.  I am using it on a packet radio TCP/IP net. I haven't added
any support for Ethernet since I do not have the hardware.  It is
running reliably and supports FTP, SMTP and TELNET.  After I finish
cleaning up some things and add the revisions from the latest KA9Q
release, I will make the sources and binaries available to anyone who
is interested in them.  I expect that they will eventually show up in
the KA9Q distributed sources along with the Macintosh, Amiga and UNIX
code that is already in there.  I started with Jere Sandidge's (sp?)
UNIX PC (68000) port and made some changes so that it would run on an
80286 system.  Also fixed a few bugs while I was at it.

John A. Limpert, N3DMC

[e-mail], bellcore!wb6rqn!n3dmc!johnl, n3dmc@wa3pxx