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

Text File | 1993-12-31 | 218.1 KB | 4,930 lines

6-Jan-88 13:54:39-EST,16158;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 6 Jan 88 13:54-EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Wed, 6 Jan 88 12:11:35 EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Wed, 6 Jan 88 12:11:00 EST
Received: by june.cs.washington.edu (5.52.1/6.11)
    id AA23906; Wed, 6 Jan 88 09:13:33 PST
Return-Path: <cbosgd!gwspc!cbcsta!n8emr![e-mail]>
Message-Id: <[e-mail]>
Date: 25 Dec 87 05:28:51 GMT
From: cbosgd!gwspc!cbcsta!n8emr![e-mail] (Gary Sanders )
To: [e-mail]
Subject: gateway 4.7 12/18/87

Relayed: From W8CQK packet bbs 144.93
Relayed:  by N8EMR's Ham BBS (HBBS), 614-457-4227 300/1200 8N1



Gateway: The ARRL Packet Radio Newsletter

     Stan Horzepa, WA1LOU,
              Editor

Vol. 4, No. 7                                 December 18, 1987

PACSAT CRASH PROGRAM UNDERWAY

Within the next two years, packet radio users may be able to pass their
signals through an orbiting satellite as a result of a crash program that is
underway to build and launch such a bird, according to Jan King, W3GEY,
AMSAT Vice President of Engineering.  The satellite, generally referred to
as PACSAT, has been dreamed about for nearly half a decade since the
conception of the TAPR TNC.

There are several "fertile" launch opportunities within calendar 1988 and
1989 and the AMSAT Board has authorized the formation of a PACSAT team and
funded it at $50,000 to take advantage of any feasible launch that would be
compatible with the PACSAT mission.  According to Tom Clark, W3IWI, a major
portion of the design of PACSAT is complete, and the construction of a
prototype will commence immediately.

All packet-radio enthusiasts will be able to make use of the PACSAT
satellite when it is launched, possibly within the next two years.
Attainment of this very ambitious goal will entail financial support and a
special fund has been set up for this purpose.

Contact AMSAT, PO Box 27, Washington, DC 20044 for further details.

>from The ARRL Letter

PHASE 3C UNDERGOES PRE-LAUNCH TESTS

AMSAT's new Phase 3 satellite is undergoing pre-launch tests at AMSAT-DL in
West Germany.  If all goes well, this new OSCAR will be launched on the
European Space Agency's (ESA) V-22 mission planned for March 15, 1988.  Like
OSCAR-10, this new satellite will also be placed in a highly elliptical
orbit.  It is expected to carry three linear transponders and a single-
frequency, digital RUDAK transponder.

Satellite operations should include:

   Mode B  : 435 MHz up, 145 MHz down.
   Mode JL : 1269 MHz, 145 MHz up,
         combined 435 MHz down.
   Mode S  : 435 MHz up, 2400 MHz down.
   RUDAK   : 1269.675 MHz up,
         435.675 MHz down.

>from Space News

THIRD REGION ADOPTS 5-DIGIT ZIP CODE ROUTING

The Third Region has recently adopted 5-digit ZIP codes for NTS traffic
forwarding.  The format is used without any @<bbs_call> or
@<section_designator> entries.  The @<anything> may still be used for those
entries that require it, but the 5-digit routing is preferred.  In addition,
the Title entry serves a new purpose.  Recognizing that NTS ultimately
operates to serve the user, the Title entry will be of the form:

   <town_name> / <phone_exchange>

that is, the town and telephone exchange of the addressee, not the
originating station.

This will allow a local user to use the LT (list traffic) command and
determine immediately whether or not it is a deliverable message without
actually reading the message to see where it is going. The PBBS would
respond to the LT command, as follows:

14707 TN 236 18013 WA3PGR 25-NOV EAST BANGOR / 588
14705 TN 566 18042 KR0AK  25-NOV EASTON / 250
14703 TN 502 18103 WA3PGR 25-NOV ALLENTOWN / 820

The user can quickly identify and download those messages which he is
capable of handling.  It is hoped that this will increase efficiency and cut
down on unnecessary downloads.

Black Box Theory

Within the Third Region, T traffic is defined as that sent using the ST
command; traffic that is killable (via the K command) by anyone and
generally destined for a third party, not necessarily a ham and not
necessarily NTS (but certainly driven by NTS).

Let's "construct" the Third Region as a multiported black box.  The entry
portals, for the purpose of this example are two HF portals, AG3F and W3IWI,
and four VHF/UHF portals, W2XO, K3RLI, AK3P and KB3UD.  (Before PBBSs get
excited, remember that this is only an example).

           @AG3F            @K3RLI
             |                |
       ----------------------------------------  @
      | 16*->  <-15*  17?->      <-15*         | K
@W2XO-| 17*->         18*->      <-16*     18* |-B
      | 18*->         19*->      <-17?     19* | 3
      | 19*->            17*                v  | U
      |              <-15* 18*->               | D
      |15*           <-16* 19*->      ^   2*   |
       -----------------------------  |    |   |
               |       | 1*    v   |
   * = ALL               @AK3P      -----------
   ? = "SOME"                          @W3IWI

Any of these portals are equipped to receive T traffic addressed either TO
ZZZZZ or TO ZZZZZ @NTSst (NTSst is either NTSPA, NTSDE, NTSMD or NTSMDC)
where TO ZZZZZ using the 5-digit ZIP code is preferred. Using wild-card
forwarding, each of these portals has the ability to send the received T
traffic in its appropriate direction with minimal forwarding file entries.
15*s and 16*s go west, some 17*s go central, some 17*s and 18*s go north by
northeast, some 18*s go east and 19*s go southeast.  If T traffic is
received with an @<entry> in the NTS<state> format, then this would be
stripped and replaced by a null to permit full-featured 5-digit ZIP routing
to take effect.  This also allows alternate routing in the case of path
failures or simply for redundancy.

There is also the outward flow in which case 4*s go west to Ohio, 5*s, 6*s,
7*s, 8*s and 9*s all head in the direction of the closest HF portal; 0*s go
northeast, 1*s need to be defined one layer deeper to the next ZIP digit
before they reach a portal, but can be easily wild-carded as well.  A
similar black box can be constructed for every state and the routing of T
traffic can assume an orderly march to its destination based upon its
5-digit ZIP code address.

>from Tom Teel, KB3UD (@ KB3UD), 3rd Region
Packet Manager and STM of Eastern Pennsylvania

XEROX 820 W0RLI PBBS SOFTWARE UPDATED

A new version of the W0RLI PBBS software for the Xerox 820 computer has been
produced by John Bennett, N4XI.  The following changes and additions are
included:

o Fixed the bug which did not allow messages numbered higher than 9999 from
being displayed.

o Fixed the bug which allowed garbage to be sent to the TNC when the message
count is 0 and you issue a "bt $E."

o Fixed the bug in SYSGEN which prevented bootstrap tracks from being
written on a 5.25-inch disk drive systems.

o Added forwarding capability through NET/ROM and COSI network nodes.
Connect (success) messages and prompts from nodes are configurable in
CONFIG.TNC file.

o Added deletion of the @ field in received message on conditional match
with list given in CONFIG.TNC file.

o Added a second forwarding file to permit forwarding the same file at two
different times or two files at their own time.

o Added message text in the CONFIG.TNC file to be sent to a user when he
invokes the KT command and no service message is generated.

o Added MAXERR count to the CONFIG.TNC file to set the number of bad
commands before a forced log-off occurs (may be changed from the local menu
using the P command).

o Added flag in the CONFIG.TNC file to selectively and automatically kill
private messages (P messages).

o Added flag in the CONFIG.TNC file to selectively and automatically kill
NTS type messages (T and S messages).

o Added a software clock set from a hardware clock for automatic booting
(this is operable only when an additional circuit is installed).

o Added hard disk modifications for CBIOS integrated into CBIOS.

o Added Xerox 820-II modifications in CBIOS to permit use of the LP keyboard
and the terminal bell.

o Provided utility programs to transfer COM and data files between two Xerox
computers via their serial ports (e.g., transfer between 8-inch and
5.25-inch disk drive systems).

A copy of the software may be obtained by sending two 8-inch, single-sided
disks and a self-addressed disk mailer with sufficient postage to John
Bennett, N4XI, 5805 Whitehorne Dr, Evansville, IN 47710.  Note that
double-sided disks cannot be copied.  Also, if you only need the source code
and do not plan to run a hard disk, then one disk will suffice.

>from John Bennett, N4XI

WORLDWIDE PBBS LIST AVAILABLE

Dave Zeph, W9ZRX, is the keeper of the worldwide PBBS list and the latest
edition of the list is now available for downloading from CompuServe's
HamNet or directly from Dave by sending a formatted 5.25-inch diskette (for
an IBM PC/XT/AT or compatible computer) with a diskette mailer, address
label and return postage to Dave at 16310 Spring Mill Road, Westfield, IN
46074.

The current list contains approximately 700 systems located in the United
States, Canada and overseas.  In the past, the list has been published in
Gateway, but due to its size, this is no longer possible as it would fill
two complete issues of the newsletter!

The list is only as good as the information received, so Dave eagerly
solicits additions, corrections, modifications and suggestions.  If you have
something to send, Dave needs the following data: PBBS call sign, PBBS name,
PBBS address (city, state, ZIP code, grid square, latitude and longitude,
telephone area code), port frequency(ies), which ports are open and which
ports are closed and the call sign of the nearest HF gateway.

As the keeper of the PBBS list, Dave made the following observations:

Packet networking is spreading around the globe; an ASIANET forwarding
network has been established on 14.111 MHz.

The list includes the first PBBSs in India and Africa (Kenya).

Now, there are PBBSs in 48 states (Delaware and Nevada are still missing)
with 549 US. PBBSs in all.  The most explosive growth in the last four
months has been in Montana, which now boasts five systems.  Oregon remains
the "black hole" of PBBSs with the fewest (only two) for a "major" state.

The greatest unknown in packet forwarding today: Is there a path to Idaho?

>from Dave Zeph, W9ZRX

NOVICE NOTCH

Southern California

In Southern California, there is a packet-radio network on the 220-MHz band
that serves two purposes: 1) access to WESTNET for Novice (and other) users
via 223.42 MHz and 2) as a backup forwarding channel for several PBBS
stations in the area.  Because of the user-oriented status of the channel,
the second function is generally limited to off-hours.

The facilities on the channel are, as follows:

PBBS Stations    Location

AJ6F-11          Torrance (LAX/NTS)
K6IYK-14         Chatsworth (S CA VHF Gateway)
KB6GVT-1         Rialto (IEBBS support)
KD4SQ-2          Riverside (BBS access only)

Digipeaters      Location

KB6CUN           Hollywood Hills
KD6SQ-4          Riverside (144.76 MHz gateway)
N6PWD            Huntington Beach

NET/ROM Nodes    Location

K6IYK-13/VERA13  Hollywood Hills
W6TJ-2/SBD1      San Bernardino Mountains
W6VPZ-11/PV11    Palos Verdes

All of the listed PBBS stations have multiport capabilities and support
at least one other port on 2 meters.  AJ6F-11 is accessible on 145.07 MHz
(users) and, as AJ6F-1, on 145.36 MHz (PBBS).  K6IYK-14 is available on
145.01 MHz (users) and, as K6IYK-4, on 145.36 MHz (PBBS).  K6IYK also
supports traffic to and from WESTNET on a 220-MHz backbone frequency.
KB6GVT-1 is also available on 145.03 MHz.  KD6SQ-2 has additional ports
on 2 and 40 meters, but access is limited to other PBBS stations.

Novice users are encouraged to acquaint themselves with the 220-MHz
activity.  The facilities are abundant; why not use them!

>from Bob Poole, AJ6F

 Northern New Jersey

The Major Armstrong Memorial Amateur Radio Club, Inc. has a NET/ROM node
on 223.420 MHz located in Alpine, New Jersey (on the cliffs of the Hudson
River, across the river from Yonkers, New York). A PBBS (W2LWB-4) is
available there also.

>from John Gubernard, K2LSX

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


CONNECT INTERNATIONAL QRX

We have word that RSGB's Connect International monthly packet newsletter has
suspended publication, as they are in between editors.  Subscriptions are
being extended each month that a newsletter is not produced.  Any inquiries
should be directed to Tim Charles, G4EZA, RSGB, Lambda House, Cranborne
Road, Potters Bar, Herts EN6 3JE, England.

A NOTE ABOUT CONTACTING A DIGITAL DXPEDITION

After being on a number of digital DXpeditions, we find it necessary to
provide some brief notes on how to make a contact with us or other digital
DXpedition.  Remember that, in most cases, we are battery and/or gasoline
powered and that our operating time is limited.  We have portable equipment
and portable antennas and may be plagued by poor ground and by RF getting
into the equipment on certain frequencies.  Under these conditions, we are
trying to contact as many stations as possible (because there is little
activity from the spot we are visiting).  Often we are the only station
active in a particular digital mode (packet radio, RTTY, ASCII and AMTOR)
>from that DXCC country.

With that understood, we would appreciate it if you followed these three
simple recommendations:

o Send short RY-trailers; we do not have time or need 80 RYs!

o Send short calls (call only: RYRYRY LA4LN DE your call K).

o Keep the QSO short; just RST three times; we will ask if we want more
information.

Many stations call at the same time, so we listen at least 1 kHz, often 5
kHz unless we make an announcement otherwise.  We try to keep QSOs short,
often limited to RST, so that we may work as many stations as possible
during our limited time.  Do not expect us to give our name, QTH and QSL
information in every QSO.  Listen a few minutes and we will give it
periodically.

Do not expect us to have time to listen to the complete history of your
life.  When operating from the wilderness of Iceland, we would like to
spread our gasoline evenly among the many stations we contact.  Finally,
please do not call CQ or start a QSO close to our frequency.  We use low
power and need that frequency window.

Thank you in advance; we hope to chat with you when we get back home.

>from Siri, LA2SR, and Tom Victor Sega|stad, LA4LN, in SARTG News


WAIT 'TIL NEXT YEAR

Since Gateway is only published 25 times per year, twice a year there is a
three week break between issues rather than the normal two week break. One
of those three week breaks is going to occur between this and the next issue
of Gateway (to be dated January 8).  So, Happy Holidays and see you next
year.


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 Co[UMIYto 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


 6-Jan-88 21:20:34-EST,1496;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 6 Jan 88 21:20-EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Wed, 6 Jan 88 20:38:38 EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Wed, 6 Jan 88 20:38:22 EST
Received: by june.cs.washington.edu (5.52.1/6.11)
    id AA22015; Wed, 6 Jan 88 17:22:28 PST
Return-Path: <uunet!wa3wbu![e-mail]>
Message-Id: <[e-mail]>
Date: 5 Jan 88 05:21:22 GMT
From: uunet!wa3wbu![e-mail] (Eric Rosenberg)
To: [e-mail]
Subject: KISS Rom info for TNC-1
Keywords: KISS TNC-1

Now that I've successfully burned KISS roms for my TNC2's (thanks to Brian Lloyd and Mike Chepponis), I'd like to burn some for the otherwose dead TNC-1's floating around here. I've picked up the files from winfree, but am not clear as
to where I burn them (that is, TNC1KISS.HEX). Which of the TNC-1 proms am I
replacing? Where do I put this file -- this is the dedicated KISS, not the boot-loader. Also, what are the default switches on the TNC set to?

It's been a long time since I've used a TNC-1, but now's as good a time as any
to get it going again.

Thanks,
Eric Rosenberg WA6YBT

--
Eric Rosenberg                     |        Packet: WA6YBT @ WA6YBT
WITF-TV                            |        UUCP: uunet!wa3wbu!eric
Harrisburg,PA                      |        ARPA: wa3wbu![e-mail]


 6-Jan-88 21:22:08-EST,2205;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 6 Jan 88 21:22-EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Wed, 6 Jan 88 20:34:20 EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Wed, 6 Jan 88 20:34:04 EST
Received: by june.cs.washington.edu (5.52.1/6.11)
    id AA22512; Wed, 6 Jan 88 17:36:36 PST
Return-Path: <cadre!pitt![e-mail]>
Message-Id: <[e-mail]>
Date: 4 Jan 88 20:31:28 GMT
From: cadre!pitt![e-mail] (Bob Hoffman)
To: [e-mail]
Subject: Re: Need some TCP/BM help
References: <[e-mail]> <[e-mail]> <[e-mail]>

In article <[e-mail]> [e-mail] (Gary Sanders (n8emr)) writes:
>First problem is how do you do an attach for a serial line?

I use this:

    attach asy 0 /dev/tty000 ax25 ax0 2048 256 4800
    attach asy 0 /dev/tty001 ax25 ax1 2048 256 4800

Yes, multiple ports work fine.  Beware that unix.h has the line

    #define ASY_MAX 2

so you'll have to edit that and recompile to use more than two ports.

>Since I dont have my kiss tnc in yet, can I talk to myself with net?
>I seem to be able to ftp files and telnet to the echo server, but
>never get a login prompt if i just to a telnet [node], IS the login
>server the default telnet sever?

Unlike BSD Unix, the telnet server in NET is strictly a
keyboard-to-keyboard 'chat' process.  Nothing exists yet to allow
remote logins.  If you'd like to try to make it work, let me know.
You will probably have to install the PD pty driver for the Unix-PC
which came over the net a while back.

>Is there even a preliminary manual for unix installation of net?

No... it's new enough that there are only a handful of people working
on it.  I have volunteered to coordinate Sys V development efforts
and collect all of the patches for testing.  Bdale has just rewritten
the users guide and I'm sure there will be some Unix paragraphs
forthcoming.

    ---Bob.

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


 6-Jan-88 21:22:09-EST,3209;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 6 Jan 88 21:22-EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Wed, 6 Jan 88 20:27:22 EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Wed, 6 Jan 88 20:26:56 EST
Received: by june.cs.washington.edu (5.52.1/6.11)
    id AA22140; Wed, 6 Jan 88 17:24:55 PST
Return-Path: <bellcore!faline![e-mail]>
Message-Id: <[e-mail]>
Date: 4 Jan 88 23:47:45 GMT
From: bellcore!faline![e-mail] (Phil R. Karn)
To: [e-mail]
Subject: Re: KA9Q TCP/IP under Microport: Help!
Summary: some answers
Keywords: perennial checksum errors
References: <[e-mail]>

> My transmitter never keys if I try to telnet to myself. I have done route
> adds and arp adds for the appropriate pathing, but no soap.

This is a feature, not a bug. :-)  Every net.exe module is a IP packet
switch as well as an end-user host, and every incoming and outgoing packet
passes through the IP switch module. Packets sent to yourself never
reach a hardware interface -- they are looped right back "upstairs" in
software.

> If I set 'trace ax0 110',
> I decode frames properly - except that all TCP headers, and about 1/3 of the
> IP headers, get 'CHECKSUM ERROR (n)'.

There was a portability bug in the .0 version, I think; it has since
been corrected. Look for the function eac() in iproute.c. Make sure that
each constant of the form "0xffff" is specified as a LONG integer (i.e.,
0xffffL). Some compilers were sign-extending this constant to 32 bits
(i.e., 0xffffffff) which was not the intended effect.

> 1) In the Unix attach asy command, what does the first parameter (the
> address of the comm port, under MS-DOS) mean? I looked at the asy_attach
> code in slip.c (coincidentally, where the compiler error manifested itself!
> It was a register assignment error, though, not a C error.), and it doesn't
> seem to use argv[1] at all in that routine. My attach command looks like:
> attach asy 55 /dev/tty1 ax25 ax0 2048 256 4800
> Is this right? (assuming that the TNC is tied to /dev/tty1)

Bob Hoffman, N3CVL, (pitt!hoffman) is coordinating all of the code
specific to System-V. I cannot answer any questions about that particular
code since a) I did not write it and b) I don't even have a System V machine
to test it on!

> 2) Am I correct in my assumption that, if I can do ax25 connects, that the
> rest of the prereqs (except for the code on the host itself) are OK as well?

I'm not sure I understand this question, but if you can do ax25 connects,
then chances are your serial interface link and KISS TNC is working
fine.

> 3) What is the (n) in the CHECKSUM ERROR message?

That's the residual after the checksum is computed on the packet.  It's
supposed to be zero; any non-zero value is an error. I print it because
seeing it sometimes gives a clue as to the reason the packet is
corrupted.

> I may wind up writing a short doc on installing it under Unix, if I can get
> it going...

Excellent! Contributions to the effort are most welcome...

73, Phil, KA9Q


 6-Jan-88 21:25:42-EST,1178;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 6 Jan 88 21:25-EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Wed, 6 Jan 88 20:19:03 EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Wed, 6 Jan 88 20:18:49 EST
Received: by june.cs.washington.edu (5.52.1/6.11)
    id AA21970; Wed, 6 Jan 88 17:21:29 PST
Return-Path: <uunet!wa3wbu![e-mail]>
Message-Id: <[e-mail]>
Date: 5 Jan 88 05:24:58 GMT
From: uunet!wa3wbu![e-mail] (Eric Rosenberg)
To: [e-mail]
Subject: MBBIOS and NET
Keywords: MBBIOS NET

I'm using AA4RE's MBBIOS program on my DOS machine to run a multi-port BBS
(coms 2-3). I'd like to add NET to the remaining port, using com4 and the
shared interrupt IRQ3 (com2). Has anyone used MBBIOS for both a BBS and
NET this way? Will it work?

Thanks,
Eric Rosenberg, WA6YBT

--
Eric Rosenberg                     |        Packet: WA6YBT @ WA6YBT
WITF-TV                            |        UUCP: uunet!wa3wbu!eric
Harrisburg,PA                      |        ARPA: wa3wbu![e-mail]


 6-Jan-88 21:45:21-EST,1568;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 6 Jan 88 21:45-EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Wed, 6 Jan 88 20:17:01 EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Wed, 6 Jan 88 20:16:34 EST
Received: by june.cs.washington.edu (5.52.1/6.11)
    id AA21809; Wed, 6 Jan 88 17:19:09 PST
Return-Path: <uunet!kddlab!icot32!nttlab!ouicsu!icssm!oucom2![e-mail]>
Message-Id: <[e-mail]>
Date: 5 Jan 88 19:28:20 GMT
From: uunet!kddlab!icot32!nttlab!ouicsu!icssm!oucom2![e-mail] (Akira Ishida)
To: [e-mail]
Subject: Re: New Release of KA9Q TCP/IP Package
Summary: May I forward it to PBBS in JA?
References: <[e-mail]>

In article <[e-mail]>, [e-mail] (Bdale Garbee) writes:
>
>             *** This is the one you've been waiting for! ***
>                        *** MERRY CHRISTMAS !! ***
>
> Announcing an update to the KA9Q TCP/IP software package release of 870829.0,
> bringing the current release date up to 871225.0.  This update is a *MAJOR
> LEAGUE* revision.  If you're running 870829 or earlier, update *now*.

May I forward this article to PBBS in JA?

To all OMs;
      If you allow me to forward your articles to PBBS in JA,
please add the permission message of forwarding. Thank you.

Caution: Don't send me reply-mail,please. I can't still
     receive a mail from overseas.

Akira Ishida          JG3RTQ @ JR3WDK


 6-Jan-88 21:54:17-EST,2075;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 6 Jan 88 21:54-EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Wed, 6 Jan 88 20:13:42 EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Wed, 6 Jan 88 20:13:30 EST
Received: by june.cs.washington.edu (5.52.1/6.11)
    id AA21605; Wed, 6 Jan 88 17:16:09 PST
Return-Path: <ihnp4!homxb!hotps![e-mail]>
Message-Id: <[e-mail]>
Date: 6 Jan 88 15:12:46 GMT
From: ihnp4!homxb!hotps![e-mail] (Dave Trulli)
To: [e-mail]
Subject: Re: MBBIOS and NET
Keywords: MBBIOS NET
References: <[e-mail]>

I have run both net and a bbs on the same system. The bbs is PRMBS
using COMBIOS which is pretty much the same as MBBIOS. Net
has its own aync driver so it doesn't need mbbios. All net needs to
know is the com port address and interrupt vector.

It sounds like you are sharing interrupt vectors between devices
by chaining onto the interrupt vector.
I didn't do it this way because net currently doesn't share the vector
but replaces it.
A much easier way to run both on the same system is to put net on a com port
with its own vector interrupt vector (the typical case) and use the shared
vector ports for the bbs side of the system.

On an XT I jumpered my com3 port to IRQ2
instead of 3 or 4. IRQ2 is not used on most XT systems.
I can run net or the bbs with a modified mbbios/combios on this port.

I have passed this info to Phil and the next version of net will
chain onto the vector if this will make running dual systems easier.

Some of you may be wondering why net doesn't use mbbios/combios too.
Net does its own internal multi-tasking which needs full interrupt driven
IO for both transmit and receive. Combios/mbbios only uses interrupt driven
receive and busy wait on transmit.

Dave
--
UUCP:   ihnp4!hotps!djt                 Dave Trulli  NN2Z
    [e-mail]               AT&T Network Systems
PACKET: nn2z@nn2z                       Holmdel NJ.
                    201-949-4774


 7-Jan-88 11:15:10-EST,750;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 7 Jan 88 11:15-EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Thu, 7 Jan 88 10:11:58 EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Thu, 7 Jan 88 10:11:16 EST
Message-Id: <[e-mail]>
Date:  7 Jan 1988 10:11:16 EST
From: [e-mail]
Subject: Exploder removal
To: [e-mail]
Cc: [e-mail]

Help,

Please don't take this personally, but PLEASE remove me from both "packet-radio"
and "packet-redistribution" exploders. I have neither the time nor the disk
space to read all the amateur mail.

Thanks, again,

Paul WB2HQW
-------
 7-Jan-88 13:39:37-EST,966;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 7 Jan 88 13:39-EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Thu, 7 Jan 88 12:14:46 EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Thu, 7 Jan 88 12:14:28 EST
Received: by june.cs.washington.edu (5.52.1/6.11)
    id AA11726; Thu, 7 Jan 88 09:16:45 PST
Return-Path: <hplabs!hpcea!hpdml80![e-mail]>
Message-Id: <[e-mail]>
Date: 6 Jan 88 19:37:34 GMT
From: hplabs!hpcea!hpdml80![e-mail] (Bob Davidson)
To: [e-mail]
Subject: hf modems?

What is necessary to watch out for using the commercially
available modems on hf.  I am interested in rtty, amtor and
hf packet.  I understand that there is a lot of variability
in the performance of modems on hf while vhf and landlines
are not as critical.

Bob Davidson
WA7IUT
Eagle, Idaho


 7-Jan-88 21:16:25-EST,1844;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 7 Jan 88 21:16-EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Thu, 7 Jan 88 20:18:07 EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Thu, 7 Jan 88 20:17:53 EST
Received: by june.cs.washington.edu (5.52.1/6.11)
    id AA09300; Thu, 7 Jan 88 17:19:20 PST
Return-Path: <uunet!nuchat!splut![e-mail]>
Message-Id: <[e-mail]>
Date: 6 Jan 88 23:53:13 GMT
From: uunet!nuchat!splut![e-mail] (Jay Maynard)
To: [e-mail]
Subject: Re: KA9Q TCP/IP under Microport: Help!
Summary: It not only core dumps occasionally...
Keywords: perennial checksum errors
References: <[e-mail]> <[e-mail]>

In article <[e-mail]>, [e-mail] (John Gayman) writes:
>     For the most part, the UNIX version works ok. It does have a tendancy
> to core-dump every now and again with a memory fault. We're getting this
> on both mine and KA3ADU. This is not the final version and I beleive several
> of the problems are being resolved. But overall, Im happy with the
> operation of it on Uport.

I've noticed that, occasionally, if I fire up net and then switch virtual
consoles to go do something else, when I flip back, not only has net
stopped, but the virtual console has logged off! I didn't think a Unix
process could do that...
Of course, it'd help if I'd take the 'tput clear' out of my .logout...

--
Jay Maynard, K5ZC (@WB5BBW)...>splut!< | GEnie: JAYMAYNARD  CI$: 71036,1603
uucp: {uunet!nuchat,academ!uhnix1,{ihnp4,bellcore,killer}!tness1}!splut!jay
Never ascribe to malice that which can adequately be explained by stupidity.
The opinions herein are shared by none of my cats, much less anyone else.


 7-Jan-88 21:22:59-EST,3075;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 7 Jan 88 21:22-EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Thu, 7 Jan 88 20:19:34 EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Thu, 7 Jan 88 20:19:08 EST
Received: by june.cs.washington.edu (5.52.1/6.11)
    id AA09363; Thu, 7 Jan 88 17:20:47 PST
Return-Path: <uunet!nuchat!splut![e-mail]>
Message-Id: <[e-mail]>
Date: 6 Jan 88 23:49:44 GMT
From: uunet!nuchat!splut![e-mail] (Jay Maynard)
To: [e-mail]
Subject: Re: KA9Q TCP/IP under Microport: Help!
Summary: Well, it's talking...
Keywords: perennial checksum errors
References: <[e-mail]> <[e-mail]>

In article <[e-mail]>, [e-mail] (Phil R. Karn) writes:
> > My transmitter never keys if I try to telnet to myself. I have done route
> > adds and arp adds for the appropriate pathing, but no soap.
>
> This is a feature, not a bug. :-)  [...] Packets sent to yourself never
> reach a hardware interface -- they are looped right back "upstairs" in
> software.

As it turns out, it wasn't keying the transceiver for telnetting anywhere
else, either. This was a result of another portability bug in lcsum.c. The
#ifdef that tries to determine if it's running on an Intel architecture
wasn't detecting that Microport was an Intel OS, so it didn't set the
LITTLE_ENDIAN flag. I commented out the #ifdef and #endif, and it works fine
now.
Any Microport gurus out there have a suggestion about what to add to that
#ifdef for System V/AT?

> There was a portability bug in the .0 version, I think; it has since
> been corrected. Look for the function eac() in iproute.c. Make sure that
> each constant of the form "0xffff" is specified as a LONG integer (i.e.,
> 0xffffL). Some compilers were sign-extending this constant to 32 bits
> (i.e., 0xffffffff) which was not the intended effect.

Mine is apparently the .1 version. (Is there a reliable way to tell from
looking at the code?)

> > 3) What is the (n) in the CHECKSUM ERROR message?
>
> That's the residual after the checksum is computed on the packet.  It's
> supposed to be zero; any non-zero value is an error. I print it because
> seeing it sometimes gives a clue as to the reason the packet is
> corrupted.

Aha. I was always seeing 6 in the TCP headers; maybe that'll help later. I'm
not having that problem now, at least.

> > I may wind up writing a short doc on installing it under Unix, if I can get
> > it going...
>
> Excellent! Contributions to the effort are most welcome...

Looks like I'm elected, by popular demand...

--
Jay Maynard, K5ZC (@WB5BBW)...>splut!< | GEnie: JAYMAYNARD  CI$: 71036,1603
uucp: {uunet!nuchat,academ!uhnix1,{ihnp4,bellcore,killer}!tness1}!splut!jay
Never ascribe to malice that which can adequately be explained by stupidity.
The opinions herein are shared by none of my cats, much less anyone else.


 7-Jan-88 21:34:06-EST,2759;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 7 Jan 88 21:34-EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Thu, 7 Jan 88 20:25:35 EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Thu, 7 Jan 88 20:25:23 EST
Received: by june.cs.washington.edu (5.52.1/6.11)
    id AA09521; Thu, 7 Jan 88 17:27:03 PST
Return-Path: <uunet!nuchat!flatline!splut![e-mail]>
Message-Id: <[e-mail]>
Date: 3 Jan 88 05:58:44 GMT
From: uunet!nuchat!flatline!splut![e-mail] (Jay Maynard)
To: [e-mail]
Subject: KA9Q TCP/IP under Microport: Help!
Keywords: perennial checksum errors

 have gotten the Christmas version of the KA9Q TCP/IP code compiled under
Microport System V/AT. Aside from a gotcha (a compiler error in slip.c), it
compiled clean after I set up config.h.

However, I'm running into another problem:
My transmitter never keys if I try to telnet to myself. I have done route
adds and arp adds for the appropriate pathing, but no soap. If I try to do
an AX25 connect to myself, everything works fine. If I set 'trace ax0 110',
I decode frames properly - except that all TCP headers, and about 1/3 of the
IP headers, get 'CHECKSUM ERROR (n)'.

Questions:
1) In the Unix attach asy command, what does the first parameter (the
address of the comm port, under MS-DOS) mean? I looked at the asy_attach
code in slip.c (coincidentally, where the compiler error manifested itself!
It was a register assignment error, though, not a C error.), and it doesn't
seem to use argv[1] at all in that routine. My attach command looks like:
attach asy 55 /dev/tty1 ax25 ax0 2048 256 4800
Is this right? (assuming that the TNC is tied to /dev/tty1)

2) Am I correct in my assumption that, if I can do ax25 connects, that the
rest of the prereqs (except for the code on the host itself) are OK as well?

3) What is the (n) in the CHECKSUM ERROR message?

4) Are there any other gotchas for running it under Unix? The documentation
is scanty in this area (I understand, Bdale: you've been busy doing other
stuff.)

Environment, if it makes a difference:
10 MHz PC/AT, 4 meg RAM, 80 meg disk in two drives, Microport System V/AT
v2.3.0L, two dumb I/O ports, TAPR TNC-1, KISS ROM code.

I may wind up writing a short doc on installing it under Unix, if I can get
it going...

--
Jay Maynard, K5ZC (@WB5BBW)...>splut!< | GEnie: JAYMAYNARD  CI$: 71036,1603
uucp: {uunet!nuchat,academ!uhnix1,{ihnp4,bellcore,killer}!tness1}!splut!jay
Never ascribe to malice that which can adequately be explained by stupidity.
The opinions herein are shared by none of my cats, much less anyone else.


 7-Jan-88 23:17:24-EST,2139;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 7 Jan 88 23:17-EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Thu, 7 Jan 88 22:12:00 EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Thu, 7 Jan 88 22:11:38 EST
Date: 7 Jan 88 14:17:06 PST
From: "David W. Palmer"  <[e-mail]>
To: [e-mail]
Message-Id: <[e-mail]>
Subject: MBBIOS and NET
Keywords: MBBIOS NET

Here's a note from Roy, AA4RE on this topic.
    Cheers to all,
    Dave, N6KL    ([e-mail]  or  N6KL @ NV6Z)
...........
Date: 7 January 88, 11:15:34 PST
From: Roy Engehausen, AA4RE

There is no reason why you cannot have any number of programs using
the different COM ports on the multi-serial cards but the programs
must use the "BIOS" interface thru INT14 to communicate with the port.
It is my understanding that NET.EXE uses a direct hardware interface.
I sure would like to see someone fixup NET.EXE so it could use INT14
for its port I/O since that would also enable you to use the PACCOMM
PC-100 cards internal to the PC for NET.EXE..  The current version of
MBBIOS has a KISS driver for the PC-100 cards included.

MBBIOS has the capability for interrupt driven transmit.  It is
normally disabled since with the standard BBS programs, it seems to
cause difficulty.  It can be enabled easily with DEBUG for a certain
port or using MBBCONFG for all ports.

Chaining interrupt vectors will not work on the PC/XT/AT architecture.
Because edge triggering is used, it is impossible for multiple
interrupt handlers that have been chained together to ensure that all
interrupts have been serviced.  You must used a single handler that
confirms that all devices are clear before leaving the handler.

If you have any questions or want to correspond further, I can be
found on COMPUSERV or directly to AA4RE @ AA4RE.  I would be very
happy to work with the NET.EXE people to enable them to use MBBIOS.

Thanks to N6KL for bringing your USENET note to my attention and for
sending this reply.

Roy, AA4RE

 8-Jan-88 13:05:15-EST,758;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 8 Jan 88 13:05-EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Fri, 8 Jan 88 12:03:09 EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Fri, 8 Jan 88 12:02:37 EST
Message-Id: <[e-mail]>
Received: from DBSTU1.BITNET by CUNYVM.CUNY.EDU ; Fri, 08 Jan 88 11:51:15 EST
Date: Fri, 08 Jan 88 16:21:42 MEZ
To: [e-mail]
From: [e-mail]
Comment: CROSSNET mail via SMTP@CUNYVM
Subject: subscribe packet-radio

HELP
SUBSCRIBE PACKET-RADIO  [e-mail]    Christian Boettger
SUBSCRIBE PACKET-RADIO  Christian Boettger
[e-mail]
 9-Jan-88 22:19:02-EST,1491;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 9 Jan 88 22:19-EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Sat, 9 Jan 88 21:42:30 EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Sat, 9 Jan 88 21:42:10 EST
Received: by june.cs.washington.edu (5.52.1/6.11)
    id AA24857; Sat, 9 Jan 88 18:43:53 PST
Return-Path: <yale!cmcl2!acf3![e-mail]>
Message-Id: <[e-mail]>
Date: 8 Jan 88 17:56:00 GMT
From: yale!cmcl2!acf3![e-mail] (David HM Spector)
To: [e-mail]
Subject: Re: New Release of KA9Q TCP/IP Package
References: <[e-mail]>

Hello,

I would really _love_ to be able to get a copy of Phil's new TCP software,
but the fact that _everything_ is arc'd makes it impossible. (In case you
haven't guessed, I am a Macintosh user.)  There are no utilities that
I know of that can un-arc files onto a macintosh.  Leo LaPorte's Un-Arc
program dies a horrible death (to say nothing of killing my Macintosh).

I would like to look into using to sources for making a MacintoshII , under
MultiFindfer, to be a standalone tnc.  (I'd really rather not invest in another
piece of hard ware when I have a $10,000 workstation at home.)

Any help in getting the sources in tar format would be _greatly_ appreciated.

        73,
        David
        N2BCA

[e-mail]
...!{allegra, rocky, harvard}!cmcl2!spector


10-Jan-88 12:49:14-EST,1302;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 10 Jan 88 12:49-EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Sun, 10 Jan 88 12:17:10 EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Sun, 10 Jan 88 12:17:01 EST
Received: by june.cs.washington.edu (5.52.1/6.11)
    id AA08315; Sun, 10 Jan 88 09:18:54 PST
Return-Path: <husc6!ut-sally!im4u!oakhill![e-mail]>
Message-Id: <[e-mail]>
Date: 8 Jan 88 16:56:16 GMT
From: husc6!ut-sally!im4u!oakhill![e-mail] (Charlie Thompson)
To: [e-mail]
Subject: DSP modem
Keywords: DSP

I am interested in doing a DSP modem for packet radio.  Has anyone
out there done such a thing??  Is there a need for better modems?
I am talking not about protocols but rather the actual bit transmission
stuff.  Where can I get a technical description of the modulation
format used for standard packet radio?

With DSP I can program up stable high performance filters that could
possibly provide lower bit error rates etc.  Perhaps I am suggesting
the proverbial sledge hammer to kill a fly routine....any comments from
the experts out there??

Thanks.

Charlie Thompson WB4HVD
Austin, TX.


10-Jan-88 13:30:54-EST,20916;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 10 Jan 88 13:30-EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Sun, 10 Jan 88 12:25:48 EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Sun, 10 Jan 88 12:25:19 EST
Received: by june.cs.washington.edu (5.52.1/6.11)
    id AA08583; Sun, 10 Jan 88 09:27:08 PST
Return-Path: <gatech!ufcsv!codas!mtune!whuts!homxb!hou2d![e-mail]>
Message-Id: <[e-mail]>
Date: 7 Jan 88 22:55:47 GMT
From: gatech!ufcsv!codas!mtune!whuts!homxb!hou2d![e-mail] (G.BEATTIE)
To: [e-mail]
Subject: Proposed Address Field Header Changes for AX.25 Link Layer Version 3
Keywords: AX.25 Packet Radio


                The Radio Amateur Telecommunications Society
                206 North Vivyen Street
                Bergenfield, New Jersey  07621


                30 December, 1987


Mr. Paul Rinaldo

ARRL
225 Main Street
Newington, CT 06111


Dear Paul,


We have enclosed a draft paper which outlines some proposed
header changes for the AX.25 Link Layer Protocol.  We felt that
there was such a great body of proposed changes that a "fresh"
look into the problem was required.  Proposed changes could fall
into three basic groups: format, operational parameters and
elements of procedure.  We felt that by addressing the format
related issues we could provide a framework for reasonable and
manageable growth and diversity.

Several other issues, not addressed in our paper, are important
to us.  We feel that there is a need for a separate Physical
Layer document.  Such basic issues as: framing, error detection,
contention guidelines, modulation schemes and bandwidth
limitations should be defined in this document.  Some differences
may also be required when operations are conducted in contention,
point-to-point and multi-cast environments.

We feel that the following basic points should be incorporated
into the document:

1. HDLC frames should be used by Amateur Radio packet mode
   stations.

2. Bit-synchronous packet mode operations should follow the
   format specified by the HDLC protocol.

3. Asynchronous packet mode operations should be as specified by
   the HDLC protocol and the proposed "Asynchronous Framing
   Technique" currently being considered by ISO.

4. Some form of exponential back-off procedure should be used
   when re-transmission is required.  The proposal by Phil Karn
   would be fine.


Certain other issues of concern to us are:

1. The default user data field size for AX.25 Link Layer (only) DXEs
   should be 256 octets.  The Frame Window size should default to 2.
   Larger maximum frame sizes could be considered use useful in
   high speed environments.  A maximum user data field length of
   between 1024 and 4096 octets seems reasonable.  Maximum
   window sizes could be increased but only when the window size
   causes DXE's to be flow controlled while waiting for "RRs".

2. The default user data field size for Amateur Radio X.25 DXEs
   should be 256 octets.  The X.25 Packet Window should default
   to 2.  A maximum user data field length of between 1024 and
   4096 octets seems reasonable.  Maximum window sizes could be
   increased but only when the window size causes DXE's to be
   flow controlled while waiting for "RRs".

3. We would like to see the full X.25 protocol incorporated as
   an option defined in the AX.25 specification.  This would be
   possible by placing all Amateur Callsign and Station octets
   before the standard X.25 Link Layer Address (01H or 03H) and
   Control fields.  The proposals we have made will facilitate
   such a move in future.  Such steps will also provide the
   basis for Amateur Radio Networking Standards to one day be
   referenced in ISO and CCITT standards documents.

4. We would like to see extended Frame and Packet Sequence
   Numbering used (as an option) on satellite circuits or other
   environments where there is significant propagation delay.


Other areas which should be investigated during the first part
of 1988 include the possible addition of a standard protocol for
remote DXE parameter reading and setting. A  specification for
the definition of locally and remotely controllable packet
interface parameters would also be desirable.  Maybe this should
include a definition of standard device support (eg. ANSI X3.64,
or TTY).

We are also wondering when the task group chartered to
investigate message systems will get together.  There seems to
be a good basis of agreement between the CCITT X.400 Message
Handling Systems and ARPA RFC822 crews in a convergence document
called RFC 987.  RATS has already implemented a portion of the
common elements as outlined in RFC987 in its BBS software, PRMBS
(Packet Radio Mail Box System - by KA2BQE based on an early
release of the W0RLI "C" BBS).  Who are the other members of the
group ?

In any case, we are looking forward to the meeting on the 9th of
January.  If there is anything we can do before the meeting to
improve the quality of the work, please let us know.

Please circulate this letter and the enclosed draft paper to
the anticipated attendees of the January meeting and others who
might comment on the text.


                Vy 73,



                J. Gordon Beattie, Jr.  N2DSY
                Chairman, RATS


                Thomas A. Moulton  W2VY
                Treasurer, RATS






cc:     Stephen Mendelsohn, Director ARRL Hudson Division
    Stan Horzepa
    Members of the Board, RATS








       Proposed Changes to the Amateur Radio Link Layer Protocol Header


              J. Gordon Beattie, Jr., N2DSY

             Thomas A. Moulton, W2VY


        The Radio Amateur Telecommuications Society

             206 North Vivyen Street
              Bergenfield, New Jersey  07621


                29 December 1987

                 DRAFT



ABSTRACT
--------
In this paper we offer improvements to the AX.25 Link Layer
protocol header.  In order to provide a more complete picture of
the problems with the existing header,  we have described the
current header and provided a list of frequently requested
changes which would help make the protocol more flexible.

The proposed revised format addresses the needs of a wide
variety of users including the users of the CCITT
connection-oriented X.25 (ISO 7776/8208) protocol, the ISO
Connectionless ISO 8348 AD1 (ISO IP) protocol, the DoD Internet
Protocol and the existing Layer 2 Terminal Node Controllers.
These users may be found in the Amateur Radio Service, Military
Affiliate Radio Service, commercial radio services, and
government radio services.  Further changes have beeen included
to address requirements imposed on the Amateur Service by
foreign telecommunications administrations.  Consideration of other
services and administrations has helped mold the revisions
proposed in this document.  This "external" influence has been a
positive component in the re-specification process.


INTRODUCTION
------------
This paper has been written to introduce members of the Amateur
Radio community to the need for changes to the current Amateur
Radio AX.25 Version 2 Link Layer Protocol.  We have outlined a
proposal for a revised AX.25 link layer protocol and provided
the rational for the changes.  It should be pointed out that the
proposed changes do not change the logic of existing AX.25 Link
Layer implementations, but requires that frame format changes be
made to the header.  These changes are sweeping in the
flexibility they offer, but not in the effort required to
implement them.


CURRENT HEADER
------- ------
The basic format of the existing layer 2 frame is:

Flag / Address / Control / Protocol ID / User Data / FCS / Flag


The header of the AX.25 frame has three components which we will address:

1. Address field,
2. Control field,
3. Protocol Identifier.


The Address field of the AX.25 frame header currently supports a
Destination callsign (DST), a Source callsign (SRC) and up to
eight digipeater callsigns: VIA1-VIA8.  This is shown below:

DST / SRC / VIA1 / VIA2 / VIA3 /.../ VIA8

Each field contains six uppercase, numeric or SPACE characters
coded in ASCII.  Each callsign is followed by an "SSID" byte
which is used to discriminate between multiple stations
operating under the same callsign. These characters are
"bit-shifted" so that the low order bit is filled with a "0".
The last octet in the Address field contains a "1" in the
low-order bit position.  This is in accord with the HDLC address
field extension procedures.

The Control field contains frame type and data flow information.
Its use is fully defined by HDLC and no changes are required.

The Protocol Identifier (PID) is used to reflect the Layer 3
protocol capabilities (if any) of the system.  Values have been
assigned for systems supporting X.25 packet layer (layer 3) and
the Internet suite of protocols.  If no layer 3 protocol is
supported by the system, then the octet is encoded as a "0F0H".


REQUESTED CHANGES
--------- -------
There have been several requests for changes to the Address
field which will help make the protocol more useful to Amateurs
and other users.  These have taken various forms including:

1. Expansion of the Address length to a number greater than six
   characters,

2. Variable length Addresses,

3. Support for a reciprocal/portable/mobile operating prefix in the callsign,

4. Extension of the SSID field to more than 16 values,

5. Simplification of the handling of SSIDs,

6. The addition of a "FROM" Address if different than the Source Address, and
   the addition of a "TO" Address if different than the Destination Address,

7. Simplification of the "has been repeated" signal,

8. Simplification of the Command/Response signal,

9. Improved alignment of the AX.25 link protocol with the X.25
   link protocol,

10. Support for ISO Connectionless Network Layer (ISO 8348 AD1),

11. Support for the US DoD Internet suite,

12. Support for the vanilla level 2 "TNC" user,

13. Support for vendor specific extensions, not part of the protocol,

14. Distinction from existing protocol implementations,

15. Capability to signal future extensions to the protocol.


PROPOSED LAYER 2 HEADER
-------- ----- - ------
The proposed header has the following basic format:

Flag / Address / Supplementary Address Field / Control / User Data / FCS / Flag

The Address field will contain the Source and Destination
addresses.  Each field will be preceeded by a length octet
expressed as a binary value and then bit-shifted up (X2) to
conform to the encoding rules for HDLC address fields.  The
length octet is not counted as part of the address length.  The
Destination and Source Address fields may each contain up to 31
octets.

Valid values are the characters 0-9, A-Z, slash ("/") and the
hyphen ("-").  The slash may only be used to separate a station
callsign from a reciprocal or mobile/portable operating ID (eg.
GW0/WB2XYZ or 4X4FN/W2).  The callsign sequence may be followed
by a hyphen and other characters used to identify a unique
instance of the station authority. An example may be:

   N2DSY-2

     or

   N2DSY-UNIX

The hyphen and additional characters will be called an
"System Identifier" or "SID".  The callsign and the "SID"
comprise an Address.  Again, this sequence may not exceed 31
characters.

The Supplementary Address field will contain facilities to
communicate a "FROM" Address (optional), a "TO" Address
(optional), Digipeater Addresses (optional), and upper layer
protocol capability (mandatory).

The "FROM" Address (FRM) field contains the callsign and "SID"
of the station which orginated the packet if different than the
"Source".  It needs to be included ONLY when regulatory
administrations require such identification on a per frame
basis.  It will be preceeded by a tag character coded as an
ASCII "F" (46H) bit-shifted up (X2) to conform  to the encoding
rules for HDLC address fields.  The octet following will contain
a length octet reflecting the length of the Address in the
remaining part of the field.

The "TO" Address (TO) field contains the callsign and "SID" of
the station which is to receive the packet if different than the
"Destination".  It needs to be included ONLY when regulatory
administrations require such identification on a per frame
basis.  It will be preceeded by a tag character coded as an
ASCII "T" (54H) bit-shifted up (X2) to conform  to the encoding
rules for HDLC address fields.  The octet following will contain
a length octet reflecting the length of the Address in the
remaining part of the field.

The Digipeater Address field(s) contain(s) up to eight address
sub-fields, VIA1 through VIA8.  Each of these Digipeater
Addresses may contain a callsign and an "SID".  Each digipeater
address field will be preceeded by a tag character coded as an
ASCII "R" (52H) or ASCII "r" (72H).  The "has been repeated"
condition will be signalled by through the use of the lower case
"r" (72H).  The "unrepeated" condition will be signalled through
the use of the upper case "R" (52H).   The octet following is
the length which will be expressed as a binary value and then
bit-shifted up (X2) to conform to the encoding rules for HDLC
address fields.  The length octet is not counted as part of the
address length. The VIA1-VIA8 Address fields may each contain up
to 31 octets.

The upper layer protocol identifier (ULPID) will be an odd value
(except as noted in the table below).  The upper layer protocol
identifier may be signaled as follows:

01 - CCITT X.25 DXE implemented
03 - CCITT X.25 DXE implemented

81 - ISO 8748 AD2 Protocol implemented on AX.25 Link
83 - ISO 8748 AD2 Protocol implemented on AX.25 Link
8D - ISO 8748 AD2 Protocol implemented on AX.25 UI Frames
8E - Escape value - Reserved for future use by the OSI community

AE - Escape value - for vendor extensions - not part of the protocol

C1 - DoD Internet Protocol implemented on AX.25 Link
C3 - DoD Internet Protocol implemented on AX.25 Link
C5 - DoD Internet Address Resolution Protocol implemented on AX.25 Link
C7 - DoD Internet Address Resolution Protocol on AX.25 Link
CB - DoD Internet Address Resolution Protocol on AX.25 UI Frames
CD - DoD Internet Protocol implemented on AX.25 UI Frames
CE - Escape value - Reserved for future use by the Internet community

F1 - No upper layer protocol implemented on an AX.25 Link
F3 - No upper layer protocol implemented on an AX.25 Link
FD - No upper layer protocol implemented on an AX.25 UI Frame
FE - Escape value - reserved for future use.

 Note that each of these values (except the Escape values)
provides a valid terminating octet for an HDLC address field.
Each value is odd except where noted above.


SUMMARY
-------
In this section we will summarize the proposed changes to the
AX.25 Link Layer Protocol and show how each change provides a
realistic solution to a particular open issue.


Issues 1, 2, 3, 4, and 5:

1. Expansion of the Address length to a number greater
   than six characters.

2. Variable length Addresses,

3. Support for a reciprocal operating/portable/mobile
   prefix/suffix in the callsign,

4. Extension of the SSID field to more than 16 values,

5. Simplification of the handling of SSIDs,

Response:

Each Address field may contain up to 31 characters.  This
provides adequate space for an Amateur Callsign or other
identifier.

There is a length octet before each Address field which provides
a reasonable address space.

In this proposal the callsign and  reciprocal operating prefix
is considered to be part of the callsign portion of the Address.

The System Identifier (SID) provides space for many systems to
be operated under a common license.  Its only limit is 31 octet
less the number of callsign octets.

The SID is processed in a manner identical to the way callsign
characters are processed.  No special processing is required to
extract the value.


Issue 6:

6. The addition of a "FROM" Address if different than the Source Address, and
   the addition of a "TO" Address if different than the Destination Address.

Response:

There has been some call for a way to indicate the Address
(Callsign et al) of the end-point stations when operating
through a network.  The Link Layer Address fields Destination
and Source reflect the Addresses of the stations operating over
the current link.  They do not however reflect the originator
(FROM) or the terminating (TO) Addresses.  Some administrations,
not realizing that other methods can be used to determine this
information have placed such requirements on Amateurs under
their control.  In several cases, the inability of the protocol
to provide this information has forced Amateurs to remove
advanced networking units from service.  This capability should
remove such problems.


Issue 7:

7. Simplification of the "has been repeated" signal.

Response:

The Repeater Address fields have been prefixed by an octet
which, depending on coding, indicates "unrepeated" and "has been
repeated" status.  They are the ASCII values "R" and "r"
respectively.  As with the SID, no special process is required
to derive the repeated status.


Issue 8:

8. Simplification of the Command/Response signal.

Response:

The Command/Response signal is provided by using two sequential
odd values for the ULPID octets.  These value pairs are
negotiated during initial link setup.  The sender of the SABM
will use the lower of the two values.

Since these values are only valid for stations using LAPB, a
third value of ULPID has been defined for use with the UI frame.


Issues 9, 10, 11, and 12:

9. Improved alignment of the AX.25 link protocol with the X.25
   link protocol,

10. Support for ISO Connectionless Network Layer (ISO 8348 AD1),

11. Support for the US DoD Internet suite,

12. Support for the vanilla level 2 "TNC" user,

Response:

The table in the last section contains a detailed list of a wide
variety of supported Upper Layer Protocol Identifiers (ULPIDs).
Each community of interest has been provided with a flexible
mechanism by which the use of upper layer protocols may be
signalled.

Many of the more difficult Link Layer protocol issues (eg.
Frame size, Window size and elements of procedure) may be more
easily resolved by allowing the default parameters of operation
to be set on a per user group (X.25, ISO IP, Internet, etc.)
basis.  The ULPID provides a mechanism to signal the upper layer
protocol and (in this environment) to imply default operational
parameters.


Issue:

13. Support for vendor specific extensions.

Response:

There is an ULPID extension value defined in the table above,
which provides a mechanism for vendor-specific extensions to the
protocol.  As proprietary extensions, they are not part of the
protocol, and no other implementation is required to support
such extensions for purposes of conformance to the protocol.
Software 2000's NET/ROM protocol would probably fit into this
category.

Issue:

14. Distinction from existing protocol implementations.

Response:

The first octet of the HDLC Address field will now contain
values in the range of 0 to 1FH.  Values found in the first
octet of the current header (Version 1 or 2) have values above
30H.  Determination of "old" vs "new" implemtations can easily
be based on this difference.


Issue:

15. Capability to signal future extensions to the protocol.

Response:

Several extension values have ben provided for the overall protocol
and for specific interest groups.  These should allow the protocol
to be extended in ways appropriate to the user community.


CONCLUDING STATEMENT
---------- ---------
The primary objective of this proposal was to meet most of the
outstanding needs of the various users of the AX.25 protocol.
It is felt that this proposal provides the needed changes and
flexibility for the various users of the protocol.  Much effort
was made to provide a framework for growth and independence for
each of these communities.  It is hoped that the proposal
addresses most of their needs.  If further considerations must
be made, we will incorporate them into an appropriate revision
of this document.

A lot of thought and "soul-searching" has gone into the proposed
changes outlined in this document.  It is hoped that similar
effort is made by those providing comments.


10-Jan-88 16:04:52-EST,1713;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 10 Jan 88 16:04-EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Sun, 10 Jan 88 15:10:56 EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Sun, 10 Jan 88 15:10:39 EST
Message-Id: <[e-mail]>
Received: from MITVMA.MIT.EDU by MITVMA.MIT.EDU ; Sun, 10 Jan 88 15:11:07 EST
Received: from FINTUVM.BITNET by MITVMA.MIT.EDU (Mailer X1.25) with BSMTP id
 0657; Sun, 10 Jan 88 15:11:03 EST
Received: by FINTUVM (Mailer X1.25) id 7268; Sun, 10 Jan 88 22:02:31 EET
Date:         Sun, 10 Jan 88 21:45:37 EET
From: Matti Aarnio <[e-mail]>
Subject:      Re: subscribe packet-radio
To: [e-mail]
In-Reply-To:  Message of Fri, 8 Jan 88 16:21:42 MEZ from
 <[e-mail]>

>HELP
>SUBSCRIBE PACKET-RADIO  [e-mail]    Christian Boettger
>SUBSCRIBE PACKET-RADIO  Christian Boettger
>[e-mail]

Well, Christian did assume that original list behaves similar to
LISTSERV-lists on BITNET.

For all BITNET-people receiving this list directly from MIT-EDDIE,
you should change your subscriptions to either  I-PACKRAD at UIUCVMD
(via LISTSERV at UIUCVMD, USA), or PACKRAD at FINHUTC (via LISTSERV
 at FINHUTC, Finland).
Via direct message, or mail to LISTSERV at NODE (NODE is closer one
of above two, USA vs. Europe):

SUBSCRIBE listname  userid at node  Your Real Name

I hope, this helps Christian, and others who may be interested.

     / Matti Aarnio, University of Turku, Finland
       FYS-MA%FINTUVM.BITNET@INTERBIT (alias @CUNYVM.CUNY.EDU ?)
10-Jan-88 18:27:28-EST,1691;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 10 Jan 88 18:27-EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Sun, 10 Jan 88 17:38:10 EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Sun, 10 Jan 88 17:37:54 EST
Received: by june.cs.washington.edu (5.52.1/6.11)
    id AA16417; Sun, 10 Jan 88 14:39:42 PST
Return-Path: <gatech!ufcsv!codas!mtune!whuts!homxb!hou2d![e-mail]>
Message-Id: <[e-mail]>
Date: 7 Jan 88 22:51:41 GMT
From: gatech!ufcsv!codas!mtune!whuts!homxb!hou2d![e-mail] (G.BEATTIE)
To: [e-mail]
Subject: NTS EAS Packet Follow-up
Keywords: NTS EAS PBBS Packet Radio Area Codes

I am happy to report an update on this issue !
Rick Palm, K1CE has inofrmed me that there will
be a corrected report of the NTS Eastern Area Staff
meeting report on their actions regarding Addressing
Plans for Packet BBSs.

As had been reported earlier, there was a misquote in
several ARRL and other publications.
The NTS EAS passed a motion to endorse the use of ZIP codes,
state identifiers, and Telephone Area Codes and Exchanges for
routing NTS messages via the Amateur Packet Network.
Stations handling such traffic in the Eastern Region
should be prepared tohandle any of these formats.  This
approach was taken in order to provide a choice of formats
for use under a variety of conditions.




Thanks,
        J. Gordon Beattie, Jr.
E-mail:    ihnp4!hou2d!n2dsy (Unix)  [e-mail]
Telephone: [phone] (Office)     201-615-4669 (Office FAX)
Telephone: [phone] (Home)


10-Jan-88 18:35:35-EST,2735;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 10 Jan 88 18:35-EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Sun, 10 Jan 88 17:43:06 EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Sun, 10 Jan 88 17:42:50 EST
Received: by june.cs.washington.edu (5.52.1/6.11)
    id AA16571; Sun, 10 Jan 88 14:44:29 PST
Return-Path: <uunet!wa3wbu![e-mail]>
Message-Id: <[e-mail]>
Date: 4 Jan 88 12:20:20 GMT
From: uunet!wa3wbu![e-mail] (John Gayman)
To: [e-mail]
Subject: Re: KA9Q TCP/IP under Microport: Help!
Summary: Its working here so far
Keywords: perennial checksum errors
References: <[e-mail]>

In article <[e-mail]>, [e-mail] (Jay Maynard) writes:
>
>  have gotten the Christmas version of the KA9Q TCP/IP code compiled under
> Microport System V/AT. Aside from a gotcha (a compiler error in slip.c), it
> compiled clean after I set up config.h.
> attach asy 55 /dev/tty1 ax25 ax0 2048 256 4800
> Is this right? (assuming that the TNC is tied to /dev/tty1)

     I recently received the binaries from WB6RQN and so far its been
working fine on two Microport systems, mine and KA3ADU. Brian did the
compiling and sent me the binaries. My attach command looks somewhat differnt
than yours, especially the number after the "asy". I'm not really sure what
that number is supposed to specify. Here is my attach statements:

attach asy 0 /dev/tty3 slip sl0 1024 1024 9600
attach asy 0 /dev/tty1 ax25 ax0 1024 576 2400

    This configures a slip link to a MS-DOS PC running Net and also /dev/tty1
to the TNC. I havn't really tried the Telnet to myself test. Although it
works to other stations.

> Environment, if it makes a difference:
> 10 MHz PC/AT, 4 meg RAM, 80 meg disk in two drives, Microport System V/AT
> v2.3.0L, two dumb I/O ports, TAPR TNC-1, KISS ROM code.
>
    Everything you have should not cause a problem. I am running an 8 Mhz AT
with Uport 2.3.0U, 92MB disk in two drives, 3 MB RAM and an 8-port "dumb"
Digiboard serial card.

    For the most part, the UNIX version works ok. It does have a tendancy
to core-dump every now and again with a memory fault. We're getting this
on both mine and KA3ADU. This is not the final version and I beleive several
of the problems are being resolved. But overall, Im happy with the
operation of it on Uport.

                    John WA3WBU



--
John Gayman, WA3WBU              |           UUCP: uunet!wa3wbu!john
1869 Valley Rd.                  |           ARPA: wa3wbu![e-mail]
Marysville, PA 17053             |           Packet: WA3WBU @ AK3P


10-Jan-88 18:47:43-EST,9175;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 10 Jan 88 18:47-EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Sun, 10 Jan 88 17:36:48 EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Sun, 10 Jan 88 17:36:24 EST
Received: by june.cs.washington.edu (5.52.1/6.11)
    id AA16291; Sun, 10 Jan 88 14:38:08 PST
Return-Path: <gatech!ufcsv!codas!mtune!whuts!homxb!hou2d![e-mail]>
Message-Id: <[e-mail]>
Date: 7 Jan 88 22:39:53 GMT
From: gatech!ufcsv!codas!mtune!whuts!homxb!hou2d![e-mail] (G.BEATTIE)
To: [e-mail]
Subject: NTS EAS Packet Addressing Actions - THE REAL TRUTH !
Keywords: NTS PBBS Packet Area Codes ZIP


                The Radio Amateur Telecommunications Society
                206 North Vivyen Street
                Bergenfield, New Jersey  07621


                29 December, 1987


Mr. Rick Palm

ARRL
225 Main Street
Newington, CT 06111


Dear Rick:


I am writing to you in reference to a matter of great importance
to us.

There has been a bit of misinformation circulating in some ARRL
publications regarding the actions of the NTS Eastern Area Staff
(EAS) pertaining to packet radio operations.  It seems that in
the ARRL Letter, Gateway, and possibly several other
publications there was a report that indicated that the NTS EAS
had endorsed only "ZIP code addressing for routing of radiograms
through the emerging PBBS autoforwarding network".  This quote
was obtained from page one of the November 20, 1987 issue of
Gateway.  It reflects a credit to the ARRL Letter.

What was published was not the whole story.  The motion that was
passed UNANIMOUSLY provided for the use of ZIP codes, two letter
State abbreviations, AND TELEPHONE AREA CODE/EXCHANGES for
routing NTS traffic through Amateur Packet message systems.

We are at a loss to understand how such a sweeping proposal
could somehow be misquoted.  What is important is the logic used
by the NTS Eastern Area Staff in deciding to provide such
flexibility.  The members felt that there were situations where
any of these mechanisms would be optimum, and as such, each
should be supported by packet messaging systems handling NTS
traffic.  Apparently they are not alone in this approach.  W9ZRX
compiles a BBS list and he requests that each of the addressing
formats be provided by system operators wishing to list their
systems.  Flexibility seems to be the name of the game here.

A second motion passed by the staff directed that: "a study of
specific proposals made by members of the Northeast-based Radio
Amateur Telecommunications Society (RATS) for NTS user interface
with the system" be made by the Regional Packet Managers.  They
are to report on their findings by March, 1988.

This motion was made after a presentation made by Thomas A.
Moulton, W2VY and me on the role of existing PBBS header
elements in a migration of NTS and PBBSs in general, to more
flexible mail schemes such as those used by the CCITT
X.400-based Message Handling Systems and Arpanet RFC822 mail
systems.  Support for some of the additional header elements
common to these systems has already started in the RATS PRMBS
(KA2BQE) and the MBL Mailbox (WA7MBL) PBBS packages.  We look
forward to working with the Regional Packet Managers on this
important project.  After the first of the year we expect to
hear from them and finally get started.

I have also enclosed an Area Code file for your reference and
possible publication.  We hope that you can publish news items
which alert the Amateur Radio community to the mistatements made
previously and hopefully rectify some of the misconceptions that
exist on this issue.




                Vy 73,




                J. Gordon Beattie, Jr.  N2DSY
                Chairman, RATS





cc:     Doug Zuckerman, Chairman ARRL NTS EAS
    Stephen Mendelsohn, Director ARRL Hudson Division
    Paul Rinaldo
    Stan Horzepa
    Members of the Board, RATS






The following list is provided as a service of the Radio Amateur
Telecommunications Society to assist packet mail system sysops
and users set up Area Code routing tables.  As per a recent ARRL
National Traffic System Eastern Area Staff motion: Telephone
Area Codes and Exchanges may be used as alternatives to Zip
Codes or two letter state abbreviations for the purposes of
routing messages.

We have also compiled this list because the RATS COSI-Switch
uses the Telephone Area Codes as part of its addressing plan for
North America.  When used here in North America, users will not
need to supply a country code (as per CCITT X.121) when making
connections.  These will be provided automatically by the
network nodes.  International operations will be based on the
same CCITT country code plus national numbering plans.

An automatic remote BBS connection routing capability will also
be provided by the RATS COSI-Switch based on the same addressing
plan.  Each switch will have a list of local BBS systems in its
configuration.  A remote user or system wishing to forward mail
to northern New Jersey need only connect to "BBS" at "201".  The
first switch with a "201" address will route the connection to
one of the BBSs in its list.




United States
------ ------

Alabama                 AL      205     All
Alaska                  AK      907     All
Arizona                 AZ      602     All
Arkansas                AR      501     All
California              CA      209     Fresno
California              CA      213     Los Angeles
California              CA      408     San Jose
California              CA      415     San Francisco
California              CA      619     San Diego
California              CA      707     Santa Rosa
California              CA      714     Orange
California              CA      805     Bakersfield
California              CA      818     Pasadena
California              CA      916     Sacramento
Colorado                CO      303     All
Connecticut             CT      203     All
Delaware                DE      302     All
District of Columbia    DC      202     All
Florida                 FL      305     Orlando, Miami
Florida                 FL      813     St. Petersburg, Tampa
Florida                 FL      904     Jacksonville, Tallahassee
Georgia                 GA      404     Atlanta
Georgia                 GA      912     Savannah
Hawaii                  HI      808     All
Idaho                   ID      208     All
Illinois                IL      217     Springfield
Illinois                IL      309     Peoria
Illinois                IL      312     Chicago
Illinois                IL      618     Centralia
Illinois                IL      815     Rockford
Indiana                 IN      219     South Bend
Indiana                 IN      317     Indianapolis
Indiana                 IN      812     Evansville
Iowa                    IA      319     Cedar Rapids
Iowa                    IA      515     Des Moines
Iowa                    IA      712     Council Bluffs
Kansas                  KS      316     Whichita
Kansas                  KS      913     Topeka
Kentucky                KY      502     Frankfort, Louisville
Kentucky                KY      606     Ashland
Louisiana               LA      318     Shreveport
Louisiana               LA      504     Baton Rouge, New Orleans
Maine                   ME      207     All
Maryland                MD      301     All
Massachusetts           MA      413     Springfield
Massachusetts           MA      617     Boston, Falmouth, Lowell, Worcester
Michigan                MI      313     Detroit
Michigan                MI      517     Lansing
Michigan                MI      616     Grand Rapids
Michigan                MI      906     Escanaba
Minnesota               MN      218     Duluth
Minnesota               MN      507     Rochester
Minnesota               MN      612     Minneapolis
Mississippi             MS      601     All
Missouri                MO      314     Jefferson City, St. Louis
Missouri                MO      417     Springfield
Missouri                MO      816     Kansas City
Montana                 MT      406     All
Nebraska                NE      308     North Platte
Nebraska                NE      402     Lincoln, Omaha
Nevada                  NV      702     All
New Hampshire           NH      603     All
New Jersey              NJ      201     Newark
New Jersey              NJ      609     Atlantic City, Trenton
New Mexico              NM      505     All
New York                NY      212     Manhattan, Bronx
New York                NY      315     Syracuse, Utica
New York                NY      516     Garden City, Hempstead, Riverhead
New York                NY      518     Albany, Greenport, Saratoga Springs
New York                NY      607     Binghamton, Ithaca
New York                NY      716     Buffalo, Rochester
New York                NY      718     Brooklyn, Queens, Staten Island
New York                NY      914     Nyack, Poughkeepsie, White Plains
North Carolina          NC      704     Ashville, Charlotte
North Carolina          NC      919     Fayetteville, Raleigh, Winston-Salem
North Dakota            ND      701     All
Ohio                    OH      216     Akron, Cleveland, Youngstown
Ohio                    OH      419     Toledo
Ohio                    OH      513     Cincinnati, Dayton
Ohio                    OH      614     Columbus
Oklahoma                OK      405     Oklahoma City
Oklahoma                OK      918     Tulsa
Oregon                  OR      503     All
Pennsylvania            PA      215     Allentown, New Hope, Philadelphia
Pennsylvania            PA      412     Pittsburgh
Pennsylvania            PA      717     Harrisburg, Lancaster, Wilkes-Barre
Pennsylvania            PA      814     Altoona, Johnstown
Rhode Island            RI      401     All
South Carolina          SC      803     All
South Dakota            SD      605     All
Tennessee               TN      615     Chattanooga, Nashville
Tennessee               TN      901     Memphis
Texas                   TX      214     Dallas
Texas                   TX      409     Galveston
Texas                   TX      512     Austin, San Antonio
Texas                   TX      713     Houston
Texas                   TX      806     Amarillo
Texas                   TX      817     Fort Worth
Texas                   TX      915     El Paso
Utah                    UT      801     All
Vermont                 VT      802     All
Virginia                VA      703     Arlington, Fredricksburg, Roanoke
Virginia                VA      804     Lynchburg, Norfolk, Richmond
Washington              WA      206     Olympia, Seattle
Washington              WA      509     Spokane
West Virginia           WV      304     All
Wisconsin               WI      414     Milwaukee
Wisconsin               WI      608     Madison
Wisconsin               WI      715     Superior
Wyoming                 WY      307     All




Canada
------

Alberta                         403     All
British Columbia                604     All
Manitoba                        204     All
New Brunswick                   506     All
Newfoundland                    709     All
Nova Scotia                     902     All
Ontario                         416     Toronto
Ontario                         519     Windsor
Ontario                         613     Ottawa
Ontario                         705     Sault Ste. Marie
Ontario                         807     Thunder Bay
Quebec                          418     Quebec City
Quebec                          514     Montreal
Quebec                          819     Trois Riveres
Saskatchewan                    306     All


10-Jan-88 18:59:47-EST,1994;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 10 Jan 88 18:59-EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Sun, 10 Jan 88 17:48:35 EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Sun, 10 Jan 88 17:48:16 EST
Received: by june.cs.washington.edu (5.52.1/6.11)
    id AA16800; Sun, 10 Jan 88 14:50:03 PST
Return-Path: <ihnp4!cbosgd!gwspc!cbcsta!n8emr![e-mail]>
Message-Id: <[e-mail]>
Date: 3 Jan 88 19:52:43 GMT
From: ihnp4!cbosgd!gwspc!cbcsta!n8emr![e-mail] (Gary Sanders)
To: [e-mail]
Subject: Re: Need some TCP/BM help
References: <[e-mail]> <[e-mail]>
Reply-To: n8emr![e-mail] (Gary Sanders (n8emr))

I have just installed (attempted) the xmas release of tcp-ip software
on my unix box (3B1). The doc files are mainly related to the dos world
but have been able to "translate" some of the info over to unix.
First problem is how do you do an attach for a serial line?
the DOC say to give the addres and interupt,
attach asy 0x2f8 3 slip....
but what about under unix, I am not running on a PC clone so address and
interrupt will not work. I have tried putting a /dev/ttyxx in the field(s),
and lights on my breakout box comes on, but if I exit net, light dont go out.

Also bm will not compile on my SYSV box, make coplains about timezone and
ltm  being redefined and time_t being unfdefined.

Since I dont have my kiss tnc in yet, can I talk to myself with net?
I seem to be able to ftp files and telnet to the echo server, but
never get a login prompt if i just to a telnet [node], IS the login
server the default telnet sever?

Is there even a preliminary manual for unix installation of net?

    many thanks...


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


10-Jan-88 19:03:13-EST,1725;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 10 Jan 88 19:03-EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Sun, 10 Jan 88 17:53:44 EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Sun, 10 Jan 88 17:53:32 EST
Received: by june.cs.washington.edu (5.52.1/6.11)
    id AA17068; Sun, 10 Jan 88 14:55:17 PST
Return-Path: <bellcore!faline![e-mail]>
Message-Id: <[e-mail]>
Date: 1 Jan 88 14:58:11 GMT
From: bellcore!faline![e-mail] (Phil R. Karn)
To: [e-mail]
Subject: Re: Need some TCP/BM help
Summary: tcp help
References: <[e-mail]>

Hi John,

Yes, you can run TCP/IP through a digipeater. However, it takes a little
more effort than running direct.  The difference is that in direct mode,
a technique called "ARP" (Address Resolution Protocol) automatically
discovers the AX.25 callsign belonging to a desired IP address. However,
it uses a broadcast technique (ARP request packets are sent to "QST-0")
and that doesn't work through digipeaters.  So you have to use the 'arp"
command to put an entry into the table manually, and it gives you the
option of adding a digipeater to the path as well. All that is
documented in the user manual under the "arp" command.

As for problems with BM, it appears you may not have set up your
/hosts.net file with all the necessary entries. Why don't you send mail
to [e-mail]? Dave has been doing a lot of work on BM and
the related facilities and he can probably help you out.

Thanks for the interest in net. It looks like it's really going to take
off this year!

Phil


10-Jan-88 19:10:00-EST,2966;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 10 Jan 88 19:09-EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Sun, 10 Jan 88 17:52:05 EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Sun, 10 Jan 88 17:51:33 EST
Received: by june.cs.washington.edu (5.52.1/6.11)
    id AA16952; Sun, 10 Jan 88 14:53:11 PST
Return-Path: <somewhere![e-mail]>
Message-Id: <[e-mail]>
Date: 3 Jan 88 05:18:57 GMT
From: [e-mail] (Dan Frank)
To: [e-mail]
Subject: Re: Need some TCP/BM help
References: <[e-mail]>
Reply-To: [e-mail] (Dan Frank)

In article <[e-mail]> someone writes:
>
>This might seem like a
>stupid question, but can Telnet or FTP connections be made through a
>Digipeater ?
>
   Absolutely.  You have to manually set up an ARP entry for every
station to whom you have to digipeat.  Something like:

    arp add feeble-pc.ampr ax25 wf3eeb-1 wl3oud

where feeble-pc's ax25 address is wf3eeb-1 and the digipeater is
wl3oud.  If you need a string of digis, just list them all, I think
with commas between them, but I don't remember.  The station on the
other end will need a similar line.  Also, if they can't hear you
but you can hear them, they can put in an arp line without a
digipeater specified, which will make them transmit to you directly.

>   The other problem seems to be the mailer (BM.EXE). I have read through
>all the documentation and I still can't get it to work. I mean, it comes
>up and all but if I send mail to myself and then come back in, it says
>"no mail". I can look in /spool/mqueue and the messages are in there but
>it wont report or read them from the prompt.

   Well, first thing to note is that mail from you, to you, is not
delivered until smtp does it.  So, you need to exit mail, kick smtp,
wait a bit, *then* check.

>If I send mail to
>"lester@ka3adu" and then initiate an "smtp" the following occurs:
>
>Net> smtp kick
>smtpcli: unknown address wa3wbu.ampr
>[same line 5 times]
>smtpcli: unknown address wa3wbu

   Well, are you in your own hosts.net?  If you're not, you can't send
mail to yourself.

>  At this point the xmitter fires off and starts transferring something to
>KA3ADU. When its finished, if he initiates BM, it again reports "no mail"
>but /spool/mail contains the mail. But the names of the files look screwed
>up. Like if he sent "mail john@wa3wbu", then my DIR of /spool/mail shows
>a DOS filename of "AIL JOHN.TXT".

   Try "m john@wa3wbu".  I think the parser in BM is a bit simple minded,
and thinks the addressee is "ail john".

   Be aware that you gotta get the host addresses just the way they
look in your hosts.net.  If you want to have an alias or a shortened
address, I think you'll have to put in another entry for it.

   Good luck!

   73, Dan Frank, W9NK


10-Jan-88 19:11:24-EST,1309;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 10 Jan 88 19:11-EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Sun, 10 Jan 88 18:03:03 EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Sun, 10 Jan 88 18:02:38 EST
Received: by june.cs.washington.edu (5.52.1/6.11)
    id AA17380; Sun, 10 Jan 88 15:04:22 PST
Return-Path: <uunet!mcvax!enea!kuling![e-mail]>
Message-Id: <[e-mail]>
Date: 28 Dec 87 10:54:36 GMT
From: uunet!mcvax!enea!kuling![e-mail] (Anders Klemets)
To: [e-mail]
Subject: TCP/IP DX QSO

According to the latest NRRL bulletin a DX QSO with TCP/IP, possibly
the first ever, was completed two weeks ago by the Norwegian TCP/IP
address coordinator, LA4JL (44.141.2.1) and YU3FK-3. Both stations were
on 2 meters and they were routing their packets through a couple of
digipeaters and gateways, namely LA4LN-9,YU3APR-3,YU3APR-2,YU3APR-1.
Since Yugoslavia has not yet been assigned an IP number YU3FK had to
use the vacant IP address 44.150.1.1.

--
    Anders Klemets, Sikvagen 51, S-135 41 Tyreso, SWEDEN
    UUCP/ARPA:      [e-mail]
            [e-mail]
    Phone:          [phone]
    Packet:         SM0RGV @ SK0TM


10-Jan-88 20:43:50-EST,1725;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 10 Jan 88 20:43-EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Sun, 10 Jan 88 17:53:44 EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Sun, 10 Jan 88 17:53:32 EST
Received: by june.cs.washington.edu (5.52.1/6.11)
    id AA17068; Sun, 10 Jan 88 14:55:17 PST
Return-Path: <bellcore!faline![e-mail]>
Message-Id: <[e-mail]>
Date: 1 Jan 88 14:58:11 GMT
From: bellcore!faline![e-mail] (Phil R. Karn)
To: [e-mail]
Subject: Re: Need some TCP/BM help
Summary: tcp help
References: <[e-mail]>

Hi John,

Yes, you can run TCP/IP through a digipeater. However, it takes a little
more effort than running direct.  The difference is that in direct mode,
a technique called "ARP" (Address Resolution Protocol) automatically
discovers the AX.25 callsign belonging to a desired IP address. However,
it uses a broadcast technique (ARP request packets are sent to "QST-0")
and that doesn't work through digipeaters.  So you have to use the 'arp"
command to put an entry into the table manually, and it gives you the
option of adding a digipeater to the path as well. All that is
documented in the user manual under the "arp" command.

As for problems with BM, it appears you may not have set up your
/hosts.net file with all the necessary entries. Why don't you send mail
to [e-mail]? Dave has been doing a lot of work on BM and
the related facilities and he can probably help you out.

Thanks for the interest in net. It looks like it's really going to take
off this year!

Phil


11-Jan-88 00:59:00-EST,2463;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 11 Jan 88 00:58-EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Mon, 11 Jan 88 00:13:08 EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Mon, 11 Jan 88 00:12:58 EST
Received: by june.cs.washington.edu (5.52.1/6.11)
    id AA26630; Sun, 10 Jan 88 21:14:46 PST
Return-Path: <uunet!wa3wbu![e-mail]>
Message-Id: <[e-mail]>
Date: 10 Jan 88 19:17:56 GMT
From: uunet!wa3wbu![e-mail] (John Gayman)
To: [e-mail]
Subject: Re: KA9Q TCP/IP under Microport: Help!
Summary: logs off here as well
Keywords: perennial checksum errors
References: <[e-mail]> <[e-mail]> <[e-mail]>

In article <[e-mail]>, [e-mail] (Jay Maynard) writes:
> In article <[e-mail]>, [e-mail] (John Gayman) writes:
> >     For the most part, the UNIX version works ok. It does have a tendancy
> > to core-dump every now and again with a memory fault.
>
> I've noticed that, occasionally, if I fire up net and then switch virtual
> consoles to go do something else, when I flip back, not only has net
> stopped, but the virtual console has logged off! I didn't think a Unix
> process could do that...
> Of course, it'd help if I'd take the 'tput clear' out of my .logout...
>
  I am now running the 871225 version on Net under Microport. It has only
core-dumped on me once with a memory fault. At the time it did, I had two
telnets, two FTP's and an AX.25 session up. When I went to switch to the
one FTP session, it dumped and logged out my terminal. I have a seperate
login for Net which plops me into a directory where all the net stuff is.
Its on virtual console9 (Could be any though). When Net core dumps, it does
log out this terminal. I have nothing so to speak in my .profile. I have no
problems in running multiple virtual consoles. Im running 2.3U which allows
15 virtual consoles and I normally have 4-5 up and logged into all of them
as it makes it real handy to use the system for various tasks at once. This
has caused no problems for me with net.

                    John WA3WBU



--
John Gayman, WA3WBU              |           UUCP: uunet!wa3wbu!john
1869 Valley Rd.                  |           ARPA: wa3wbu![e-mail]
Marysville, PA 17053             |           Packet: WA3WBU @ AK3P


11-Jan-88 08:27:06-EST,3876;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 11 Jan 88 08:27-EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Mon, 11 Jan 88 07:41:48 EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Mon, 11 Jan 88 07:41:22 EST
Message-Id: <[e-mail]>
Received: from amc1 by AMC-HQ.ARPA id ab17008; 11 Jan 88 7:36 EST
Date:     Mon, 11 Jan 88 7:25:07 EST
From: "D. H. Bennett, AMCRM-FTM"  <[e-mail]>
To: [e-mail]
Subject:  Stats on Packet by State

       Recap of USA-PKT.DBF
      As of  10 January 1988
         by K4NGC

The  following  is a computed recap of  the
USA-PKT.DBF file I maintain.  It shows  the
number and type of activities by state.  If
you  have  any changes to  the  USA-PKT.DBF
files please address them to K4NGC @ K4NGC.

State            PBBS  DIGI  TOTAL  PERCENT
---------------- ----  ----  -----  -------
Alabama            15    19    34     1.58%
Alaska              6     8    14     0.65%
Arizona            47    17    64     2.98%
Arkansas            9    11    20     0.93%
California        108    89   197     9.16%
Colorado           35    63    98     4.56%
Connecticut        10    14    24     1.12%
Delaware            0     3     3     0.14%
Dist of Columbia    0     2     2     0.09%
Florida            88    71   159     7.39%
Georgia            26    23    49     2.28%
Guam                0     0     0     0.00%
Hawaii              9    11    20     0.93%
Idaho               2     4     6     0.28%
Illinois           23    16    39     1.81%
Indiana            37    24    61     2.84%
Iowa               21    28    49     2.28%
Kansas             11    13    24     1.12%
Kentucky           16    25    41     1.91%
Louisiana          15     5    20     0.93%
Maine              13     1    14     0.65%
Maryland           45    40    85     3.95%
Massachusetts      36    24    60     2.79%
Michigan           33    11    44     2.05%
Minnesota          11     8    19     0.88%
Mississippi        13     4    17     0.79%
Missouri           13    43    56     2.60%
Montana             6     7    13     0.60%
Nebraska           11    16    27     1.26%
Nevada              1    10    11     0.51%
New Hampshire      10     9    19     0.88%
New Jersey         59    35    94     4.37%
New Mexico         15     9    24     1.12%
New York           74    65   139     6.46%
North Carolina     15    20    35     1.63%
North Dakota        6     1     7     0.33%
Ohio               45    18    63     2.93%
Oklahoma           13    22    35     1.63%
Oregon              6     8    14     0.28%
Pennsylvania       47    36    83     3.86%
Puerto Rico         0     0     0     0.00%
Rhode Island        5     5    10     0.46%
South Carolina      7     9    16     0.74%
South Dakota        3     9    12     0.56%
Tennessee          18    19    37     1.72%
Texas              37    15    52     0.00%
Utah                9    24    33     1.53%
Vermont             5     2     7     0.33%
Virginia           29    43    72     3.35%
Virgin Islands      0     0     0     0.00%
Washington         19    20    39     1.81%
West Virginia       8    12    20     0.93%
Wisconsin          23    16    39     1.81%
Wyoming             9    15    24     1.12%
         ----  ----  ----  --------
Total            1122  1029  2151   100.00%

The   USA-PKT.DBF  files  is  available  on
CompuServe to all who want it.  It is  also
available on the AMRAD BBS at 703-734-1387.
Its in text  and dBASE formats.

Don Bennett (K4NGC)
15016 Carlsbad Road
Woodbridge, Va 22193
(Home) 703-670-4773
(Work) 703-274-9355/56
(CompuServe) 72310,263
(ARPANET) [e-mail]

11-Jan-88 08:30:12-EST,6507;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 11 Jan 88 08:30-EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Mon, 11 Jan 88 07:41:23 EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Mon, 11 Jan 88 07:40:47 EST
Message-Id: <[e-mail]>
Received: from amc1 by AMC-HQ.ARPA id aa17008; 11 Jan 88 7:36 EST
Date:     Mon, 11 Jan 88 7:24:21 EST
From: "D. H. Bennett, AMCRM-FTM"  <[e-mail]>
To: packet-radio%eddie.mit.edu@AMC1
Cc: info-hams%simtel20@AMC1
Subject:  Stats on Packet Frequencieis

           Recap of USA-PKT.DBF
          As of  10 January 1988
             by K4NGC

The  following  is  a computed recap of  the  USA-
PKT.DBF file I maintain.  It shows the number  and
type  of activities by frequency.  If you have any
changes  to the USA-PKT.DBF files  please  address
them to K4NGC @ K4NGC.

State             DIGI     PBBS    TOTAL   PERCENT
----------------  ----     ----    -----   -------
   7.0910 Mhz        0        1        1     0.05%
   7.0930 Mhz        0       33       33     1.53%
   7.0940 Mhz        0        1        1     0.05%
   7.0970 Mhz        0        2        2     0.09%
   7.9300 Mhz        0        1        1     0.05%
  10.1450 Mhz        0        1        1     0.05%
  10.1473 Mhz        0        1        1     0.70%
  10.1490 Mhz        0       15       15     0.00%
  14.0700 Mhz        0        0        0     0.00%
  14.1030 Mhz        0        5        5     0.23%
  14.1050 Mhz        1        3        4     0.19%
  14.1070 Mhz        0       29       29     1.35%
  14.1090 Mhz        0       23       23     1.07%
  14.1110 Mhz        0       26       26     1.21%
  14.1115 Mhz        0        1        1     0.05%
  14.1490 Mhz        0        1        1     0.05%
  28.1050 Mhz        0        8        8     0.37%
  28.1490 Mhz        0        1        1     0.05%
  28.2750 Mhz        0        1        1     0.05%
  50.0900 Mhz        0        1        1     0.05%
  51.1200 Mhz        4        0        4     0.19%
 144.0100 Mhz        1        0        1     0.05%
 144.1100 Mhz        0        1        1     0.05%
 144.5100 Mhz        1        3        4     0.19%
 144.7600 Mhz        1        1        2     0.09%
 144.9100 Mhz        1        3        4     0.19%
 144.9300 Mhz        1       11       12     0.56%
 144.9500 Mhz        2        6        8     0.37%
 144.9700 Mhz        1        9       10     0.46%
 144.9900 Mhz        2        8       10     0.46%
 145.0000 Mhz        1        0        1     0.05%
 145.0100 Mhz      638      440     1078    50.12%
 145.0300 Mhz       45       63      108     5.02%
 145.0500 Mhz      106      122      228    10.60%
 145.0700 Mhz       39       54       93     4.32%
 145.0900 Mhz       47       69      116     5.39%
 145.1100 Mhz        0        3        3     0.14%
 145.1500 Mhz        0        3        3     0.14%
 145.3300 Mhz        1        0        1     0.05%
 145.3500 Mhz        0        1        1     0.05%
 145.3600 Mhz        4        9       13     0.60%
 145.5100 Mhz        3        1        4     0.19%
 145.5500 Mhz        4        3        7     0.33%
 145.5550 Mhz        0        1        1     0.05%
 145.5700 Mhz        0        3        3     0.14%
 145.5900 Mhz        4        2        6     0.28%
 145.6100 Mhz        1        0        1     0.05%
 145.6500 Mhz        0        1        1     0.05%
 145.6600 Mhz        0        1        1     0.05%
 145.6700 Mhz        4        2        6     0.28%
 145.9300 Mhz        1        0        1     0.05%
 145.9700 Mhz        0        1        1     0.05%
 146.0700 Mhz        0        1        1     0.05%
 146.1300 Mhz        0        1        1     0.05%
 146.1450 Mhz        1        0        1     0.05%
 146.7000 Mhz        0        2        2     0.09%
 146.7300 Mhz        0        1        1     0.05%
 146.7450 Mhz        0        1        1     0.05%
 146.9800 Mhz        1        1        2     0.09%
 147.0100 Mhz        1        0        1     0.05%
 147.4800 Mhz        2        1        3     0.14%
 147.4900 Mhz        0        3        3     0.14%
 147.5400 Mhz        0        2        2     0.09%
 147.5550 Mhz       12        6       18     0.84%
 147.5600 Mhz        0        1        1     0.05%
 147.7000 Mhz        0        1        1     0.05%
 149.0900 Mhz        0        1        1     0.05%
 220.0100 Mhz        0        2        2     0.09%
 220.0600 Mhz        0        1        1     0.05%
 220.4500 Mhz        1        0        1     0.05%
 220.5200 Mhz        0        3        3     0.14%
 220.5300 Mhz        0        1        1     0.05%
 220.5500 Mhz        0        1        1     0.05%
 220.5700 Mhz       18        8       26     1.21%
 220.9500 Mhz        9        1       10     0.46%
 221.0100 Mhz       22       20       42     1.95%
 221.1000 Mhz        1        0        1     0.05%
 221.1100 Mhz        9       34       43     2.00%
 223.4000 Mhz        1        1        2     0.09%
 223.4200 Mhz        1        3        4     0.19%
 223.5000 Mhz        0        1        1     0.05%
 223.5800 Mhz       11       18       29     1.35%
 223.7000 Mhz        0        1        1     0.05%
 433.8000 Mhz        0        1        1     0.05%
 438.0000 Mhz        3        0        3     0.14%
 441.0000 Mhz        5       11       16     0.74%
 441.5000 Mhz        2        2        4     0.19%
 441.9000 Mhz        3        0        3     0.14%
 443.8000 Mhz        1        0        1     0.05%
 445.5500 Mhz        1        0        1     0.05%
 446.0500 Mhz        1        1        2     0.09%
 446.1000 Mhz        0        2        2     0.09%
 446.8000 Mhz        1        9       10     0.46%
 446.8200 Mhz        0        2        2     0.09%
 448.4000 Mhz        2        0        2     0.09%
1297.5000 Mhz        0        1        1     0.05%
         ------   ------   ------
TOTAL             1029     1122     2151   100.00%

The USA-PKT.### files is availble on CompuServe to
all who want it. It is also available on the AMRAD
BBS  at  703-734-1387.   Its  in  text  and  dBASE
formats.

Don Bennett (K4NGC)
15016 Carlsbad Road
Woodbridge, Va 22193
(Home) 703-670-4773
(Work) 703-274-9355
(CompuServe) 72310,263
(ARPANET) [e-mail]

11-Jan-88 12:32:27-EST,1186;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 11 Jan 88 12:31-EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Mon, 11 Jan 88 11:25:39 EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Mon, 11 Jan 88 11:25:24 EST
Received: by june.cs.washington.edu (5.52.1/6.11)
    id AA08695; Mon, 11 Jan 88 08:27:13 PST
From: pur-ee!uiucdcs!uxc.cso.uiuc.edu![e-mail]
Return-Path: <pur-ee!uiucdcs!uxc.cso.uiuc.edu![e-mail]>
Message-Id: <[e-mail]>
Date: 10 Jan 88 18:21:00 GMT
To: [e-mail]
Subject: Re: New Release of KA9Q TCP/IP Pack
References: <[e-mail]>
Nf-Id: #R:acf3.NYU.EDU:770001:uxc.cso.uiuc.edu:190200003:000:332
Nf-From: uxc.cso.uiuc.edu!pat    Jan 10 12:21:00 1988


This is Mike Matthews using a friend's logon.  I will have a new version of the
Amiga and Mac system available this week (hopefully tonight).  I will be sending
the code, binaries, and installation guide to Phil and Bdale right after I get
an answer to a question I asked Phil.

Mikel Matthews - N9DVG
{ihnp4!}uiucuxc!addamax!mikel


11-Jan-88 12:35:20-EST,1124;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 11 Jan 88 12:35-EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Mon, 11 Jan 88 11:24:10 EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Mon, 11 Jan 88 11:23:53 EST
Received: by june.cs.washington.edu (5.52.1/6.11)
    id AA08577; Mon, 11 Jan 88 08:25:36 PST
Return-Path: <sdcsvax!ucsdhub!hp-sdd!hplabs!well![e-mail]>
Message-Id: <[e-mail]>
Date: 10 Jan 88 18:40:21 GMT
From: sdcsvax!ucsdhub!hp-sdd!hplabs!well![e-mail] (John A. Limpert)
To: [e-mail]
Subject: Re: KA9Q TCP/IP under Microport: Help!
Summary: Microport cpp symbol
Keywords: perennial checksum errors
References: <[e-mail]> <[e-mail]> <[e-mail]>

The proper symbol to test on Microport is 'iAPX286'.  You can always
add 'CFLAGS=-DLITTLE_ENDIAN' to the makefile to get the same result.
I have the 871225.0 stuff running pretty reliably here, when I get the
time I will be adding the changes from 871225.3.


11-Jan-88 16:54:14-EST,2079;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 11 Jan 88 16:54-EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Mon, 11 Jan 88 15:36:09 EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Mon, 11 Jan 88 15:35:25 EST
Received: by june.cs.washington.edu (5.52.1/6.11)
    id AA21699; Mon, 11 Jan 88 12:37:05 PST
Return-Path: <somewhere![e-mail]>
Message-Id: <[e-mail]>
Date: 28 Dec 87 14:03:24 GMT
From: [e-mail] (Dan Frank)
To: [e-mail]
Subject: Re: Flow control on PK-232
References: <[e-mail]>
Reply-To: [e-mail] (Dan Frank)

In article <[e-mail]> [e-mail] (John Gayman) writes:
>      Has anyone experienced any flow control problems with the PK-232
>when utilizing software flow control ?  I was playing around with it on
>my UNIX machine which utiltizes software flow control on the ports and I
>was unsuccessful at finding options for enabling software flow control
>in the converse mode.

   I have a PK-87, and I have experienced precisely the problems you
describe.  I did find that sometimes the FLOW feature (that keeps the
TNC from sending to you when you have a line pending) appears to
interfere with proper software flow control, but I still sometimes
experienced mangled files.

   I spoke to AEA about it, and they said they had increased the
number of characters they could accept after they sent an XOFF.  I'm
still waiting for the new firmware they were going to send me, so I
can't report on whether they've fixed the problems.  I strongly
suggest that you speak to their tech support people, because the
fellow I spoke to said I was the first one to report difficulties with
flow control.

   I've given up sending files through the PK-87's AX.25 software.
Now if I have to send something to a BBS, I put the TNC in KISS mode
and use the AX.25 support in KA9Q's excellent TCP/IP package.  No flow
control problems there!

   73,  Dan W9NK


11-Jan-88 18:58:19-EST,2219;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 11 Jan 88 18:58-EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Mon, 11 Jan 88 15:37:38 EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Mon, 11 Jan 88 15:36:39 EST
Received: by june.cs.washington.edu (5.52.1/6.11)
    id AA21756; Mon, 11 Jan 88 12:38:13 PST
Return-Path: <ames!umd5!brl-adm!cmcl2!phri!dasys1![e-mail]>
Message-Id: <[e-mail]>
Date: 28 Dec 87 03:34:46 GMT
From: ames!umd5!brl-adm!cmcl2!phri!dasys1![e-mail] (Andy Funk)
To: [e-mail]
Subject: PBBS Programs
Keywords: Packet BBS Programs

I'm attempting to compile a list of Packet Bulletin Board programs.

So far I've seen others are keeping lists of just about everything else for
packet, but this seems to have been forgotten.

If you have written, or know of, a packet radio BBS (PBBS) program, please
send me some info on it.  Specifics I need to know are:

    What machine does it run on?  Is a certain amount of RAM needed?  Disk
                     Drives?  I/O options?
    Which TNCs are supported?
    Will it forward W0RLI standard "mail?"
    Who is (are) the author(s)?
    How is the program available?
    Public Domain?  Shareware?  Commercial?  Other?
    Special features?

Also, does the program have any features which make it specially suited for
use as a "personal mailbox?"  (A "personal mailbox" is a PBBS operated for an
individual, the sysop, no "users."  It is used to provide automated delivery
of incoming messages and automated transmission of outgoing messages, via a
"host" PBBS.)

All data gathered will be shared with the Amateur Packet Radio community via
USENET, CompuServe, Packet, and possibly publication.

Thank you and vy 73,


--
----------------------[ Insert Commercial Here ]----------------------------
Andy Funk  (kb7uv)              UUCP:  {sun!hoptoad,cmcl2!phri}!dasys1!kb7uv
ENG Editor, WCBS-TV             UUCP:  ...ihnp4!hotps!n2dsy-4!kb7uv
New York, NY                    ampr:  kb7uv@n2mh      Ma Bell: 718-956-0027


11-Jan-88 21:24:02-EST,1798;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 11 Jan 88 21:24-EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Mon, 11 Jan 88 20:06:32 EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Mon, 11 Jan 88 20:06:06 EST
Received: by june.cs.washington.edu (5.52.1/6.11)
    id AA05220; Mon, 11 Jan 88 17:07:52 PST
Return-Path: <uunet!wa3wbu![e-mail]>
Message-Id: <[e-mail]>
From: uunet!wa3wbu![e-mail] (John Gayman)
To: [e-mail]
Subject: Flow control on PK-232
Date: 27 Dec 87 19:28:02 GMT

      Has anyone experienced any flow control problems with the PK-232
when utilizing software flow control ?  I was playing around with it on
my UNIX machine which utiltizes software flow control on the ports and I
was unsuccessful at finding options for enabling software flow control
in the converse mode.

      I'm currently using a TNC2 and by setting FLOW & XFLOW on, it responds
to software flow control. The manual for the PK-232 seems to indicate that
its soft flow control is only active during TRANSPARENT mode. And indeed, it
does appear to work in TRANS. But when attempting to send large files in
CONV (Like uploading to a BBS) I seem to loose data. It works fine however
with hardware flow control when hooked to my DOS machine. I have properly set
the START and STOP parameters. Any ideas ??  If it makes a difference, I am
running Microport 2.3 on an AT-clone.

                    John, WA3WBU




--
John Gayman, WA3WBU              |           UUCP: uunet!wa3wbu!john
1869 Valley Rd.                  |           ARPA: wa3wbu![e-mail]
Marysville, PA 17053             |           Packet: WA3WBU @ AK3P


11-Jan-88 21:53:08-EST,3281;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 11 Jan 88 21:53-EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Mon, 11 Jan 88 20:09:32 EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Mon, 11 Jan 88 20:08:40 EST
Received: by june.cs.washington.edu (5.52.1/6.11)
    id AA05350; Mon, 11 Jan 88 17:10:22 PST
Return-Path: <sdcsvax![e-mail]>
Message-Id: <[e-mail]>
Date: 31 Dec 87 16:39:20 GMT
From: sdcsvax![e-mail] (Brian Kantor)
To: [e-mail]
Subject: Re: TCP/IP network address assignment and MORE
Summary: A Manifesto
References: <[e-mail]> <[e-mail]>
Reply-To: [e-mail] (Brian Kantor)

Yup, NET/ROM was the first kid on the block, but TCP/IP is catching up.
I think you'll find most of the Los Angeles TCP/IP activity on 145.36,
along with other protocol experimentation.  Here in San Diego, the
"preferred channel" is 144.76.  High-speed stuff is on 220MHz or 441.5.

As for assigning addresses, there is already a block assigned for the
Los Angeles area, according to my records - Don, WB5EKU is the address
coordinator for that area.

I have agreed (well, been badgered into) taking over address block
assignments for areas that have not already been assigned an AMPR
address block.  If you had a request pending with Wally, please send it
to me and I'll take care of it as soon as I get organized.  My address
is below at the end of this overly-prolix message.

There are nearly 500 hosts registered in the AMPR address database so far.
Hostnames are assigned within the AMPR domain as follows:

    for a single host:
        wb6cyt

    for multiple hosts:
        sun.wb6cyt
        pc.wb6cyt
        etc.wb6cyt

These would appear in the hosts table as
    44.8.0.1        WB6CYT                  # Brian Kantor, San Diego CA
    44.8.0.101      3b2.wb6cyt
    44.8.0.102      pc.wb6cyt
    44.8.0.103      sun.wb6cyt
    44.8.0.104      unix-pc.wb6cyt
    44.8.0.186      ps186.wb6cyt

The fully-qualified domain name would be <the above>.AMPR.<top>,
whatever the NIC finally gets around to deciding <top> should be.
Thus a hostname might well be something like
    ps186.wb6cyt.ampr.exp
if they wind up stuffing us in the (imaginary) EXPerimenters domain.

For people ACTIVELY EXPERIMENTING with TCP/IP on packet radio (i.e.,
you've got the station on the air and are doing more than just typing
keyboard-to-keyboard and saying "gee whiz" about it), there is a mailing
list for technical discussions and arguments.  If you are interested in
subscribing to that list, send mail to 'tcp-group-request' at the hostname
below and explain what it is you are doing.  The list is getting large
enough that I'd prefer NOT to add just lookers-on, since we get some
pretty rapid-fire and heated (and occasionally abusive) discussions
going on, as is common any place that technoids congregate.

UCSD is reachable from uucp, the Darpa Internet, BITNET, SPAN, and other
wonderous communications media.  Don't call me on the phone.

    Brian Kantor    WB6CYT  UC San Diego
        [e-mail]                  <- Internet
        ...!sdcsvax!brian                       <- uucp
        BRIAN@UCSD                              <- BITNET
        SDSC::"[e-mail]"          <- SPAN


12-Jan-88 10:25:45-EST,1272;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 12 Jan 88 10:25-EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Tue, 12 Jan 88 09:16:49 EST
Received: from mc.lcs.mit.edu by EDDIE.MIT.EDU via Chaosnet with SMTP with sendmail-5.45/4.7 id <[e-mail]>; Tue, 12 Jan 88 09:16:30 EST
Received: from SIMTEL20.ARPA (TCP 3200000112) by MC.LCS.MIT.EDU 12 Jan 88 09:17:56 EST
Date: Tue, 12 Jan 1988  07:16 MST
Message-Id: <[e-mail]>
Sender: [e-mail]
From: Keith Petersen <[e-mail]>
To: [e-mail]
Subject: KA9Q TCP/IP for Unix-PC?

The latest version (871225.4) of the KA9Q TCP/IP package is available
via standard anonymous FTP from SIMTEL20:

Filename                        Type     Bytes   CRC

Directory PD1:<MISC.KA9Q-TCPIP>
NELSON.ARC.2                    BINARY    7413  B587H
NET_BM.ARC.7                    BINARY   19127  122CH
NET_DES.ARC.5                   BINARY   26249  1336H
NET_DOC.ARC.5                   BINARY  143157  42C5H
NET_PC.ARC.3                    BINARY  126524  0DEEH <--for IBM-PC
NET_SRC.ARC.8                   BINARY  302422  0A1DH
TNC_ASH.ARC.4                   BINARY   57076  F2ECH
TNC_LDR.ARC.4                   BINARY   15790  0D43H
TNC_TNC1.ARC.4                  BINARY   52127  B5F7H
TNC_TNC2.ARC.4                  BINARY   49542  0413H

--Keith

12-Jan-88 18:36:26-EST,1766;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 12 Jan 88 18:36-EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Tue, 12 Jan 88 16:42:23 EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Tue, 12 Jan 88 16:41:54 EST
Message-Id: <[e-mail]>
Received: from MITVMA.MIT.EDU by MITVMA.MIT.EDU ; Tue, 12 Jan 88 16:42:12 EST
Received: from FINTUVM.BITNET by MITVMA.MIT.EDU (Mailer X1.25) with BSMTP id
 1550; Tue, 12 Jan 88 16:42:02 EST
Received: by FINTUVM (Mailer X1.25) id 8271; Tue, 12 Jan 88 22:52:19 EET
Date:         Tue, 12 Jan 88 22:40:33 EET
From: Matti Aarnio <[e-mail]>
Subject:      BITNET-only: subscribe packet-radio
To: [e-mail], I2010506@DBSTU1
In-Reply-To:  Message of Sun, 10 Jan 88 21:45:37 EET from
 <[e-mail]>

Oh well, I did say it wrong way :-(  LISTSERV knows your sending
address.  You must not tell it to LSV. (its not obeyed.)

Internet-landians: Your style is to use  *-request
           (eg.  packet-radio-request)

*For all BITNET-people receiving this list directly from MIT-EDDIE,
*you should change your subscriptions to either  I-PACKRAD at UIUCVMD
*(via LISTSERV at UIUCVMD, USA), or PACKRAD at FINHUTC (via LISTSERV
* at FINHUTC, Finland).  Lets not overuse gateways.
*Via direct message, or mail to LISTSERV at NODE (NODE is closer one
*of above two, USA vs. Europe):

Here is the real one:
   SUBSCRIBE listname  Your Real Name

*I hope, this helps Christian, and others who may be interested.

     / Matti Aarnio, University of Turku, Finland
       FYS-MA%FINTUVM.BITNET@INTERBIT (alias @CUNYVM.CUNY.EDU ?)
12-Jan-88 20:40:08-EST,1466;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 12 Jan 88 20:40-EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Tue, 12 Jan 88 17:24:56 EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Tue, 12 Jan 88 17:24:27 EST
Received: by june.cs.washington.edu (5.52.1/6.11)
    id AA02250; Tue, 12 Jan 88 14:25:23 PST
Return-Path: <sabre!faline![e-mail]>
Message-Id: <[e-mail]>
Date: 11 Jan 88 21:57:14 GMT
From: sabre!faline![e-mail] (Phil R. Karn)
To: [e-mail]
Subject: Re: MBBIOS and NET
Summary: Reason for my own device driver
References: <[e-mail]>

The problem with INT14 (and the reason I wrote my own asynchronous
device driver as part of net.exe) is that it handles only one character
per call. The 8086 family interrupt mechanism is slow enough without
having to invoke it for every single character that is sent or received.
There are people running net.exe at serial line speeds of 9600 baud and
up full duplex, so efficiency is very important.

Looks like the braindamaged standards set by IBM software have struck
yet again. The one saving grace of the PC is that you can always thumb
your nose at IBM and talk to the hardware if necessary.

Thanks for the info re interrupt chaining; you saved me from quite a bit
of effort that wouldn't have worked anyway!

Phil


12-Jan-88 22:37:39-EST,1000;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 12 Jan 88 22:37-EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Tue, 12 Jan 88 17:13:16 EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Tue, 12 Jan 88 17:13:01 EST
Received: by june.cs.washington.edu (5.52.1/6.11)
    id AA01342; Tue, 12 Jan 88 14:13:55 PST
Return-Path: <sabre!faline![e-mail]>
Message-Id: <[e-mail]>
Date: 11 Jan 88 21:29:38 GMT
From: sabre!faline![e-mail] (Phil R. Karn)
To: [e-mail]
Subject: Re: NTS EAS Packet Addressing Actions - THE REAL TRUTH !
Summary: zip codes vs area codes vs garbage collection districts vs...
References: <[e-mail]>

Perhaps the Internet (TCP/IP) gang should show how we run a network
without having ANY routing codes visible to the user at all.  All you
need is a callsign, and the rest is handled automagically.

Phil


13-Jan-88 09:10:00-EST,953;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 13 Jan 88 09:10-EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Wed, 13 Jan 88 08:12:48 EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Wed, 13 Jan 88 08:12:31 EST
Message-Id: <[e-mail]>
Received: from MITVMA.MIT.EDU by MITVMA.MIT.EDU ; Wed, 13 Jan 88 08:12:58 EST
Received: from CZHETH5A.BITNET (HB9ZZ) by MITVMA.MIT.EDU (Mailer X1.25) with
 BSMTP id 3977; Wed, 13 Jan 88 08:12:25 EST
Date:     Wed, 13 Jan 88 14:00 GMT
From: <[e-mail]>
Subject:  NEEDED: TCP/IP for DEC VAX/VMS
To: [e-mail]
X-Original-To:  [e-mail], HB9ZZ



I am searching a version of the KA9Q TCP/IP for DEC VAX/VMS op. sys.
Any idea ?

            Marco Brignoli HB9SFD

Bitnet : HB9ZZ@RZETH5
Packet : HB9SFD @ I2JJR-1 RBBS
13-Jan-88 12:52:24-EST,2377;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 13 Jan 88 12:52-EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Wed, 13 Jan 88 11:10:40 EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Wed, 13 Jan 88 11:10:21 EST
Message-Id: <[e-mail]>
To: [e-mail]
Cc: [e-mail]
Subject: Wild shots
Date: Wed, 13 Jan 88 11:00:54 -0500
From: [e-mail]

In message <[e-mail]>, Phil writes:

     Date: 11 Jan 88 21:29:38 GMT
     From: "Phil R. Karn" <sabre!faline![e-mail]>
     To: [e-mail]
     Subject: Re: NTS EAS Packet Addressing Actions - THE REAL TRUTH !
     Summary: zip codes vs area codes vs garbage collection districts vs...
     References: <[e-mail]>

     Perhaps the Internet (TCP/IP) gang should show how we run a network
     without having ANY routing codes visible to the user at all.  All you
     need is a callsign, and the rest is handled automagically.

     Phil

Normally, I just ignore the stupid blasts back and forth between
the TCP/IP and X.25 crowds, since the information content has
dropped to zero.  But this one is a little too much.

1) "All you need is a callsign": The referenced message was about
NTS traffic, which generally is to people who have NO callsigns.
That problem needs a solution, whichever transport/network
protocol you use.

2) "routing codes visible to the user": At present, the ham
TCP/IP users ARE the sysops.  Or did I miss the BBS option in a
recent release?  And the sysops/users sure do have to deal with
routing.

3) "the rest is handled automagically": Darn. I must have missed
the routing and name/address server demons in the distribution,
too.  Seriously, a callsign was all you needed in the AX.25
network when they had as few active stations as we do now in ham
TCP/IP.  They all fit in a short routing table (handled by the
sysops) back then, too.

Let's get real, guys.

(For the record, I do both TCP/IP and X.25 at work, and do TCP/IP
and NTS and AX.25 at home.  Not that I'm thrilled with what went
on at that NTS EAS meeting, from first-hand reports, but that's a
different subject.)

73, Bob, K1BC   [e-mail]
13-Jan-88 12:52:29-EST,1609;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 13 Jan 88 12:52-EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Wed, 13 Jan 88 11:29:23 EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Wed, 13 Jan 88 11:29:12 EST
Received: by june.cs.washington.edu (5.52.1/6.11)
    id AA26495; Wed, 13 Jan 88 08:29:59 PST
Return-Path: <ncrcpx![e-mail]>
Message-Id: <[e-mail]>
Date: 31 Dec 87 17:58:07 GMT
From: ncrcpx![e-mail] (R. Craig Peterson)
To: [e-mail]
Subject: Any TCP/IP Sites in/around East Central OHIO?
Keywords: tcp/ip ohio

I'm going to be setting up a TCP/IP link here in Cambridge.  I'd like
it to be able to go outside of Cambridge, and my two or three machines
that'll be hooked up to it.

Does anyone have (or plan on having) a TCP/IP "node" that I could hit
>from my location?  I'm inbetween Zanesville, and Wheeling W.Va., kind
of a no-where location.  Without a repeater somewhere inbetween I'm a
little too far away from Columbus.  Maybe I'll have to get something
set up in Zanesville...

I'll also need an address.  Any help there?  Is anyone else trying to
run this stuff in a "remote" area?  Would tieing into an existing uucp
network provide anything (mail, etc.)?

Or am I tied forever to AX.25L2???
--
R. Craig Peterson               "Next time someone asks you if you're a god
ncrlnk!ncrcam!ncrcpx!craig       say YES!!"
N8INO                                   Ghost Busters
E Pluribus Unum         (NSA stuff - terrorist, DES, cipher, secret, NRO, CIA)


13-Jan-88 13:21:36-EST,3204;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 13 Jan 88 13:21-EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Wed, 13 Jan 88 11:31:09 EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Wed, 13 Jan 88 11:30:55 EST
Received: by june.cs.washington.edu (5.52.1/6.11)
    id AA26532; Wed, 13 Jan 88 08:31:37 PST
Return-Path: <uunet!wa3wbu![e-mail]>
Message-Id: <[e-mail]>
Date: 1 Jan 88 02:06:25 GMT
From: uunet!wa3wbu![e-mail] (John Gayman)
To: [e-mail]
Subject: Need some TCP/BM help

   Please correct me if there is a better place to ask this stuff. I just
received the latest TCP/IP revision from winfree and after a tense moment
or two, I got it running for the most part (this was my first implementation).
I have a couple questions that I'm sure those of you who have been running
it can probably answer.

   I had some difficulty getting my PK-232 into the KISS mode. I seemed to
be experiencing the common bug that the TNC would drop back into command-
mode. I was using Procomm which is rumored to work without sending a BREAK
on exit. Well, for me it seemed to knock me back to command mode when I
exited Procomm. So I simply made a file with one entry, "host on" and
after exiting Procomm, I would "copy filename com1:" and viola, the TNC
was in KISS mode and TCP worked.

   So far, TCP is working fine and I'm wading through the documentation
trying to get a handle on what all it can do. This might seem like a
stupid question, but can Telnet or FTP connections be made through a
Digipeater ? Here in Harrisburg, activity is just starting and its tough
finding someone you get a good signal direct. At the moment, myself and
KA3ADU seem to have a good path between us.

   The other problem seems to be the mailer (BM.EXE). I have read through
all the documentation and I still can't get it to work. I mean, it comes
up and all but if I send mail to myself and then come back in, it says
"no mail". I can look in /spool/mqueue and the messages are in there but
it wont report or read them from the prompt. If I send mail to
"lester@ka3adu" and then initiate an "smtp" the following occurs:

Net> smtp kick
smtpcli: unknown address wa3wbu.ampr
[same line 5 times]
smtpcli: unknown address wa3wbu

  At this point the xmitter fires off and starts transferring something to
KA3ADU. When its finished, if he initiates BM, it again reports "no mail"
but /spool/mail contains the mail. But the names of the files look screwed
up. Like if he sent "mail john@wa3wbu", then my DIR of /spool/mail shows
a DOS filename of "AIL JOHN.TXT".

  What am I doing wrong and what must be done to get mail working properly ?
Every other aspect of TCP seems to work fine. It's mostly a matter of
pouring over the docs.  Any help is appreciated.

                    73, John WA3WBU


--
John Gayman, WA3WBU              |           UUCP: uunet!wa3wbu!john
1869 Valley Rd.                  |           ARPA: wa3wbu![e-mail]
Marysville, PA 17053             |           Packet: WA3WBU @ AK3P


13-Jan-88 22:41:39-EST,4047;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 13 Jan 88 22:41-EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Wed, 13 Jan 88 21:25:37 EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Wed, 13 Jan 88 21:25:24 EST
Received: from MITVMA.MIT.EDU by MITVMA.MIT.EDU ; Wed, 13 Jan 88 21:25:58 EST
X-Delivery-Notice:  SMTP MAIL FROM does not correspond to sender.
Received: from UWAVM.ACS.WASHINGTON.EDU (X400GATE) by MITVMA.MIT.EDU (Mailer
 X1.25) with BSMTP id 8385; Wed, 13 Jan 88 21:25:56 EST
P1-Message-Id: US**EDU;UWAVM.ACS.WASHINGTON.EDU:LCPF70wt
Date:         Wed, 13 Jan 88 18:21-0800
X400-Trace:   US**EDU; arrival Wed, 13 Jan 88 18:21-0800 action Relayed
X400-Trace:   US**EDU; arrival Wed, 13 Jan 88 18:23-0800 action Relayed
From: The Mail Server<[e-mail]>
Subject:      Undeliverable mail
To: <[e-mail]>
Message-Id:   <UWAVM.ACS.WASHINGTON.EDU:LCPF70wt*>

Message had a bad or missing To address.
The entire text of the message follows:

Received: by UIUCVMD (Mailer X1.25) id 9159; Wed, 13 Jan 88 12:28:53 CST
Date: Fri, 1 Jan 88 02:06:25 GMT
From: John Gayman <uunet!wa3wbu![e-mail]>
Subject: Need some TCP/BM help
Sender: Packet Radio <I-PACRAD@UIUCVMD>
To: Packet operator <BRUCE@UWALOCKE>, Packet operator <SIGOURNEY@UWALOCKE>
Reply-to: [e-mail]
X-To:         [e-mail]

   Please correct me if there is a better place to ask this stuff. I just
received the latest TCP/IP revision from winfree and after a tense moment
or two, I got it running for the most part (this was my first implementation).
I have a couple questions that I'm sure those of you who have been running
it can probably answer.

   I had some difficulty getting my PK-232 into the KISS mode. I seemed to
be experiencing the common bug that the TNC would drop back into command-
mode. I was using Procomm which is rumored to work without sending a BREAK
on exit. Well, for me it seemed to knock me back to command mode when I
exited Procomm. So I simply made a file with one entry, "host on" and
after exiting Procomm, I would "copy filename com1:" and viola, the TNC
was in KISS mode and TCP worked.

   So far, TCP is working fine and I'm wading through the documentation
trying to get a handle on what all it can do. This might seem like a
stupid question, but can Telnet or FTP connections be made through a
Digipeater ? Here in Harrisburg, activity is just starting and its tough
finding someone you get a good signal direct. At the moment, myself and
KA3ADU seem to have a good path between us.

   The other problem seems to be the mailer (BM.EXE). I have read through
all the documentation and I still can't get it to work. I mean, it comes
up and all but if I send mail to myself and then come back in, it says
"no mail". I can look in /spool/mqueue and the messages are in there but
it wont report or read them from the prompt. If I send mail to
"lester@ka3adu" and then initiate an "smtp" the following occurs:

Net> smtp kick
smtpcli: unknown address wa3wbu.ampr
[same line 5 times]
smtpcli: unknown address wa3wbu

  At this point the xmitter fires off and starts transferring something to
KA3ADU. When its finished, if he initiates BM, it again reports "no mail"
but /spool/mail contains the mail. But the names of the files look screwed
up. Like if he sent "mail john@wa3wbu", then my DIR of /spool/mail shows
a DOS filename of "AIL JOHN.TXT".

  What am I doing wrong and what must be done to get mail working properly ?
Every other aspect of TCP seems to work fine. It's mostly a matter of
pouring over the docs.  Any help is appreciated.

            73, John WA3WBU


--
John Gayman, WA3WBU              |           UUCP: uunet!wa3wbu!john
1869 Valley Rd.                  |           ARPA: wa3wbu![e-mail]
Marysville, PA 17053             |           Packet: WA3WBU @ AK3P


15-Jan-88 12:54:27-EST,2409;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 15 Jan 88 12:54-EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Fri, 15 Jan 88 11:41:02 EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Fri, 15 Jan 88 11:40:33 EST
Received: by june.cs.washington.edu (5.52.1/6.11)
    id AA24110; Fri, 15 Jan 88 08:40:49 PST
Return-Path: <ulysses!faline![e-mail]>
Message-Id: <[e-mail]>
Date: 14 Jan 88 16:31:22 GMT
From: ulysses!faline![e-mail] (Phil R. Karn)
To: [e-mail]
Subject: Re: Wild shots
Summary: addressing vs naming
References: <[e-mail]>

Bob,

I was only trying to point out something that I think has been lost in the
din of the area-code vs zip-code wars:

        Names are not addresses!
        Addresses are not names!

For a network to be truly easy to use, there must be a clean separation
between these two concepts. Addresses may be chosen for the network's
convenience (i.e., to simplify routing) but names are chosen for the
convenience of the human user.

Every network requires *some* sort of database to do name/address
translation. If you "simplify" your network by requiring the user to give
network addresses, you've merely forced him to keep his own database, most
likely in his head! (The telephone network is a good example).  Computer
processing and storage is cheaper now than it's ever been, and it's only
getting more so. I therefore reject the notion that it is somehow "cheaper"
to force humans to memorize lists of numbers than to store them in a
computer.

Whether the name/address database is stored in a centrally-maintained host
table or with a distributed name server is an (albeit important)
implementation detail.

I wasn't really referring to NTS. Rather I was talking about the various
proposals to route traffic BETWEEN AMATEURS using zip codes or area codes.
I see NTS as a sort of "super internet", where the ham packet Internet is
just a "subnetwork" in an even larger system that also contains phone and CW
traffic nets. "Names" in the amateur Internet therefore become "subnetwork
addresses" to NTS, and it's really up to them to decide what kind of message
formatting, addressing and routing they want to layer on top of us; it
really doesn't matter to me.

Phil


15-Jan-88 12:56:44-EST,2145;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 15 Jan 88 12:56-EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Fri, 15 Jan 88 11:33:30 EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Fri, 15 Jan 88 11:33:12 EST
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Cc: [e-mail]
Subject: Re: Wild shots
Date: Fri, 15 Jan 88 11:31:00 -0500
From: [e-mail]


In msg <[e-mail]>, Phil Karn writes:
<    Bob,
<    I was only trying to point out something that I think has been
<    lost in the din of the area-code vs zip-code wars:
<                    Names are not addresses!
<                    Addresses are not names!
<
<    [... deleted stuff which supports the above, and with which
<    I agree ... ]

Well, with all due respect, your message didn't say that.  In
fact, it talked about ROUTING CODES, which as we all know, are
not addresses or names, either:

>> Summary: zip codes vs area codes vs garbage collection districts vs...
>>
>> Perhaps the Internet (TCP/IP) gang should show how we run a network
>> without having ANY routing codes visible to the user at all.  All you
>> need is a callsign, and the rest is handled automagically.

<    I wasn't really referring to NTS. Rather I was talking about
<    the various proposals to route traffic BETWEEN AMATEURS using
<    zip codes or area codes.

But the message to which you were replying WAS about NTS.  Which
is the only reason I took exception to your message.

<    [...]
<
<    Phil

Thank you for clarifying your intent.  And I should clarify that
my comment about not-yet-implemented systems referred to HAM
TCP/IP, not TCP/IP in general, where the name/address servers are
of course implemented and working.  I didn't mean that the
concept was bad, just that they aren't there yet in the ham
arena. It's true that we can show how we run A network that way,
but not A HAM RADIO network (yet).

Peace.

73, Bob, K1BC   [e-mail]
15-Jan-88 14:58:48-EST,1017;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 15 Jan 88 14:58-EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Fri, 15 Jan 88 12:08:44 EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Fri, 15 Jan 88 12:08:19 EST
Received: by june.cs.washington.edu (5.52.1/6.11)
    id AA24225; Fri, 15 Jan 88 08:43:34 PST
Return-Path: <hplabs!hpcea!hpdml80!hpmrtca![e-mail]>
Message-Id: <[e-mail]>
Date: 5 Jan 88 13:27:25 GMT
From: hplabs!hpcea!hpdml80!hpmrtca![e-mail] (bob davidson)
To: [e-mail]
Subject: HF MODEM?

I would appreciate a pointer to articles that concern the
operation of modems on HF.  I have seen bits and pieces that
indicate the problems there are different than those on VHF.
I'm interested in rtty, amtor and hf packet.

                Bob Davidson, WA7IUT
                Eagle, Idaho


15-Jan-88 15:17:43-EST,673;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 15 Jan 88 15:17-EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Fri, 15 Jan 88 14:19:25 EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Fri, 15 Jan 88 14:19:01 EST
Date: 14 Jan 88 14:33:15 PST
From: "David W. Palmer"  <[e-mail]>
To: [e-mail]
Message-Id: <[e-mail]>
Subject: MBBIOS block transfers

From AA4RE via N6KL:

MBBIOS currently supports block transfers for the PACCOMM PC-1xx cards.
It could easily be extended to all ports if there was a need.

Roy Engehausen -- AA4RE

15-Jan-88 18:34:54-EST,1838;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 15 Jan 88 18:34-EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Fri, 15 Jan 88 17:40:51 EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Fri, 15 Jan 88 17:40:11 EST
Message-Id: <[e-mail]>
Received: from MITVMA.MIT.EDU by MITVMA.MIT.EDU ; Fri, 15 Jan 88 17:40:29 EST
Received: from UIUCVMD.CSO.UIUC.EDU by MITVMA.MIT.EDU (Mailer X1.25) with BSMTP
 id 7989; Fri, 15 Jan 88 17:40:27 EST
Received: by UIUCVMD (Mailer X1.25) id 3306; Thu, 14 Jan 88 18:02:36 CST
Date:         Thu, 14 Jan 88 17:52:50 CST
From: Phil Howard <[e-mail]>
To: Packet Radio <[e-mail]>

I am ready to get my packet station going.  I have yet to aquire a TNC,
and also plan to dedicate a transceiver to it.

I would like to get specific recommendations for a 144 Mhz transceiver
to be dedicated to packet.
   1.   It does NOT have to be synthesized.  A crystal controlled model
    should have at least 8 channels.  I hear that crystal is better
    but that synthesized rigs have improved.
   2.   It should have quick switching times appropriate for packet
    operations.
   3.   A sister model for 220 Mhz would be a big plus.
   4.   It needs to be fully usable for voice, i.e. mic connectors, repeater
    splits, etc.
   5.   12 VDC operation would be a big plus, but 110v AC only is acceptable.
    I have a Kenwood PS-50 power supply I can drive it from for a while.
   6.   It does not have to be a new model, if an older one works well.
   7.   I would be interested in paying up to $450 for a new model.
    For used it will depending on condition.

Can someone make specific model recommendations?
16-Jan-88 13:03:49-EST,4003;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 16 Jan 88 13:03-EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Sat, 16 Jan 88 12:03:37 EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Sat, 16 Jan 88 12:03:22 EST
Received: by june.cs.washington.edu (5.52.1/6.11)
    id AA00207; Sat, 16 Jan 88 09:03:50 PST
Return-Path: <sabre!faline![e-mail]>
Message-Id: <[e-mail]>
Date: 15 Jan 88 22:29:27 GMT
From: sabre!faline![e-mail] (Phil R. Karn)
To: [e-mail]
Subject: Amateur TCP/IP path contest

Now that TCP/IP is really starting to take off in the amateur world, I think
it would be fun to start a running contest. The goal is to see who can come
up with the most complex, ad-hoc Internet path involving one or more amateur
packet radio links.  This is inspired by Mike O'Dell's famous "worst wire"
contest. The only requirement is that the path must actually work!  At a
minimum, you must successfully complete a three-way TCP handshake and then
successfully close the connection.

To start things off, I'd like to describe an experiment we did last weekend.
As many of you know, Telenet has this nifty service called PC Pursuit. From
any Telenet access number, you may connect to a remote dialout modem in in
something like 6 metropolitan areas.  As long as you use it only during
evenings and weekends, it costs $25/month -- flat rate!  Several amateur
TCP/IP groups have begun using PC Pursuit to link their otherwise isolated
"islands", with excellent results.

Last weekend Al, WB0MPQ (another resident of Warren, NJ) dialed up a PC
Pursuit link to Brian, WB6RQN, in the Maryland suburbs of DC. While the link
was up, I had Bob, WA3PXX, telnet briefly to a Bellcore machine named
"sabre" in Navesink, NJ.  The path was as follows:

Node, location                  Link/Subnetwork
----                            ---- ----------
wa3pxx.ampr (PC/XT)
                222.06 Mhz AX.25 link
duplex RF repeater
Gaithersburg, MD(?)
                223.66 Mhz AX.25 link
wb6rqn.ampr (PC/AT)
Germantown, MD
                SLIP on 1200 baud dialup phone line (C&P Tel)
Telenet dialer port
Washington, DC
                GTE Telenet X.25 network
Telenet TIP port
Rahway, NJ
                SLIP on 1200 baud dialup phone line (NJ Bell)
wb0mpq.ampr (PC/XT)
Warren, NJ
                147.525/430.05 Mhz full duplex AX.25 link
switch.ka9q.ampr (PX/XT)
Warren, NJ
                KA9Q shack Ethernet
sun.ka9q.ampr (Sun 3/75)
                SLIP on 9600 bps dialup phone line (NJ Bell)
Micom terminal switch
Piscataway, NJ
                T-1 leased line (portion) (NJ Bell)
Micom terminal switch
Morristown, NJ
                hardwired RS-232 line
doomsday.bellcore.com (Sun 2/170)
                Lab Ethernet
Ethernet repeater
                Machine room central Ethernet
DEC Lan Bridge
                Building backbone Ethernet
Ethernet repeater
                Building "core" Ethernet
Vitalink Translan
                T-1 leased line (portion) (NJ Bell)
Vitalink Translan
Piscataway, NJ
                T-1 leased line (portion) (NJ Bell)
Vitalink Translan
Navesink, NJ
                building backbone Ethernet
DEC Lan Bridge
                Building wing Ethernet
DEC Lan Bridge
                Lab Ethernet
sabre.bellcore.com (Vax 11/750?)

...and back.

This was a direct end-to-end connection; the TCPs on wa3pxx.ampr and
sabre.bellcore.com spoke directly to each other.  Excluding the endpoints
themselves, the path their IP datagrams took included:

8 Ethernets
5 IP gateways (2 Suns, 3 PC's running KA9Q net.exe)
4 radio frequencies on 3 amateur bands
3 dialup phone links (2 @ 1200 baud, 1 @ 9600 baud)
3 T-1 digital leased lines with multiplexors
3 Vitalink Translan IIIs
3 DEC Translan 100s
2 Micom terminal switches
2 Ethernet repeaters
1 full duplex RF repeater
1 public X.25 network (Telenet)
1 partridge in a pear tree :-)

So...can anybody top this?  Who will be the first to include an amateur
satellite link in a TCP/IP path once AMSAT Phase 3-C is launched later this
year?

73, Phil


16-Jan-88 13:44:08-EST,2779;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 16 Jan 88 13:44-EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Sat, 16 Jan 88 12:30:08 EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Sat, 16 Jan 88 12:26:14 EST
Received: by june.cs.washington.edu (5.52.1/6.11)
    id AA00123; Sat, 16 Jan 88 09:00:11 PST
Return-Path: <umunhum![e-mail]>
Message-Id: <[e-mail]>
Date: 16 Jan 88 05:18:32 GMT
From: umunhum![e-mail] (Paul Flaherty)
To: [e-mail]
Subject: Proposed Second Generation Link Layer Protocol
Reply-To: [e-mail] (Paul Flaherty)

The time has come to reconsider the reigning role of AX.25 as the standard
protocol for Amateur Packet Radio.  This discussion is motivated by the
weight of evidence which indicates that X.25 is not well suited for a
multiaccess environment, nor was it ever designed to be.  Other considerations
exist, not limited to the following:

1. Protocol Thrashing in common multiaccess environments.
2. Difficulty in implenting the protocol; in particular, the expense of the
    chips required to perform the protocol.
3. Lack of persistence / backoff algolrithm.
4. Connection orientation of the protocol.

Admittedly, these shortcomings were probably not know to the designing
committee (although they should have been aware of them, since the results
of academic research into packet radio were widely available).  Even given
this consideration, however, AX.25 is of minimal utility, except for the
fact that it exists, and the FCC allows unattended operation of it.

As a replacement, I would propose the AppleTalk / AppleLink protocol
as described (thoroughly) in _Inside Appletalk_, which is available from
APDA for a nominal fee.  In particular:

1. AppleTalk was designed for use in a CSMA environment, by an individual who
    did his dissertation work in packet radio.

2. The protocol is relatively straightforward, and is easy to implement
    using less expensive chips (such as the 8530).

3. The top speed of most of the protocol implentations exceeds that of
    AX.25 by an order of magitude.


As a test of the protocol, I'm currently working on an inexpensive (cf. $1k)
microwave AppleTalk system as part of my dissertation work (see the March
1988 issue of MacWorld for more info).

I would welcome and appreciate any comments on this proposal.


-=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


16-Jan-88 19:38:37-EST,1509;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 16 Jan 88 19:38-EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Sat, 16 Jan 88 18:35:56 EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Sat, 16 Jan 88 18:35:38 EST
Posted-Date: Sat 16 Jan 88 15:36:43-PST
Received: by venera.isi.edu (5.54/5.51)
    id AA27979; Sat, 16 Jan 88 15:36:44 PST
Date: Sat 16 Jan 88 15:36:43-PST
From: William A. Brackenridge <[e-mail]>
Subject: AppleTalk as Amateur Radio Standard
To: [e-mail]
Message-Id: <[e-mail]>
Mail-System-Version: <VAX-MM(216)+TOPSLIB(128)@VENERA.ISI.EDU>

If you haven't already found out proposing standards for amateur radio is
a thankless task!

Amateur Radio is for experimentation for the fun of it. Don't ask me to go to
a standards committee meeting but playing with appletalk over radio links
sounds like fun even if it may never be a "standard".

When a node comes up on an AppleTalk network it assigns its self a random
number as a node number and broadcasts it saying "here I am anybody using
this node number????". This seems inappropriate to a packet radio net where
almost by defenition not all nodes can hear each other. Do you have a
solution to this problem?

Even if you don't have an answer to this problem if you have a simple scheme
to hook a macintosh up to a modem and radio it might be fun to try out.

N6NLE
-------
17-Jan-88 13:47:33-EST,1076;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 17 Jan 88 13:47-EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Sun, 17 Jan 88 12:36:34 EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Sun, 17 Jan 88 12:36:22 EST
Date: Sun, 17 Jan 88 12:36:02 est
From: [e-mail] (Jim Babb)
Message-Id: <[e-mail]>
Received: by acf4.nyu.edu; Sun, 17 Jan 88 12:36:02 est
To: [e-mail]
Subject: FCC proposal to reallocate 220 MHz
Cc: [e-mail]


Recently, I received a communication from Lynn Martin,
Representative 16th District, Illinois, concerning a
proposal to reallocate 220-2 MHz.

This is Docket 87-14.

I don't get QST, but I assume there is info there.

Write your protests to:

Dennis R. Patrick
Chairman, FCC
1919 M Street, N.W., Room 814
Washington, D.C. 20554

For more information:
Representative Lynn Martin
Suite 1208
Longworth House Office Building
Washington, D.C. 20515


Jim Babb WB9SWI


17-Jan-88 15:30:34-EST,4186;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 17 Jan 88 15:30-EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Sun, 17 Jan 88 14:07:38 EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Sun, 17 Jan 88 14:07:23 EST
Received: by june.cs.washington.edu (5.52.1/6.11)
    id AA19506; Sun, 17 Jan 88 11:07:52 PST
Return-Path: <clyde!bellcore!faline![e-mail]>
Message-Id: <[e-mail]>
Date: 16 Jan 88 01:26:32 GMT
From: clyde!bellcore!faline![e-mail] (Phil R. Karn)
To: [e-mail]
Subject: Re: Amateur TCP/IP path contest
References: <[e-mail]>

I should add that I actually have a serious purpose behind the "most
complicated amateur Internet path" contest. The idea is to get people
thinking about how they might assemble an ad-hoc computer network in an
emergency using whatever communication facilities might be available,
amateur or otherwise.

It is unrealistic for us to say "we're hams, so we're not interested in
anything that doesn't use ham radio", or to look down on using
commercial facilities in an amateur network as "cheating" even when
there is no amateur alternative.  In many communities, the hams are the
people who are also the most knowledgeable about communications in
general -- not just radio. I therefore believe we have an obligation to
offer our skills as "communication system integrators", not just as
providers of POT-WARS (Plain Old Two-Way Amateur Radio Service). In an
emergency, pragmatism rules supreme, and getting the traffic through is
the only thing that counts. If picking up the phone is the best way to
do it, then so be it (assuming, of course, that the phone still works).

As an example of a hypothetical emergency situation where a hybrid
amateur/commercial computer network might be extremely useful, consider
a major earthquake in Los Angeles. (This is "The Big One", the magnitude
8+ quake that has a better than 50% chance of hitting southern
California sometime in the next 30 years). Local utilities (power,
telephone) are completely destroyed for many tens of miles. However, the
phones a hundred miles away are still working, and of course the
remainder of the country is unaffected (except for long-distance
telephone trunks that would be routed through LA). There is an urgent
need for record communications from the city to places all over the
country, first to carry official emergency traffic (requests for rescue
equipment and assistance, etc) and later to carry personal health and
welfare messages from the survivors.

In this situation I would envision portable and mobile amateur packet
radio stations (consisting of a laptop computer, TNC/modem, radio and
battery power) in the disaster areas. Packets would be relayed on
amateur and/or public service frequencies using either analog or digital
repeaters to gateway stations in areas where the phone service is still
operating. There they would enter an ad-hoc "backbone network" composed
primarily of personal computers switching packets between modems on
dialed-up phone lines, but also using whatever else the operators can
get their hands on: amateur, government and commercial HF and satellite
circuits, commercial X.25 networks like Telenet and TYMNET,
government-sponsored long-haul computer networks like ARPANET, MILNET,
SATNET and NSFNET, and perhaps even a private corporate or academic
computer network or two.

All of this complexity will have to be hidden from the end-users of the
network; they will be far too busy typing lists of names into laptops to
be bothered with managing virtual circuits in Telenet. Running the
network will be the responsibility of the software running in the
backbone packet switches plus the human operators of those switches.

This is an extremely ambitious goal, and I have no illusions about the
work that would be required to build a complete network that could
handle even a small fraction of the offered load in a major emergency. But I
think it's something worth thinking about.

Phil


17-Jan-88 23:14:51-EST,1123;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 17 Jan 88 23:14-EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Sun, 17 Jan 88 22:33:13 EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Sun, 17 Jan 88 22:32:44 EST
Received: by umix.cc.umich.edu (5.54/umix-2.0)
    id AA09348; Sun, 17 Jan 88 20:02:20 EST
Received: from cc.sfu.ca by um.cc.umich.edu via MTS-Net; Sun, 17 Jan 88 19:59:44 EST
Date: Sun, 17 Jan 88 16:58:48 PST
From: [e-mail]
To: [e-mail]
Message-Id: <[e-mail]>
Subject: Re: Amateur TCP/IP path contest

     About the public packet-switched networks during emergencies: It's
interesting to note that during the tornado in Edmonton last year, the
phones were completely tied up or out of service, but Datapac service to the
area operated smoothly throughout the emergency (and proved to be a useful
communications path for a number of people).  The public PSNs can be quite
useful as a path during some emergencies.

Richard Chycoski - VE7CVS
18-Jan-88 13:49:27-EST,2169;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 18 Jan 88 13:49-EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Mon, 18 Jan 88 12:44:45 EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Mon, 18 Jan 88 12:44:34 EST
Received: by june.cs.washington.edu (5.52.1/6.11)
    id AA12079; Mon, 18 Jan 88 09:45:10 PST
Return-Path: <aim.dec.com![e-mail]>
Message-Id: <[e-mail]>
Date: 18 Jan 88 15:33:47 GMT
From: aim.dec.com![e-mail] (Fred's usually home at DELNI::)
To: [e-mail]
Subject: New Data Link Layer protocol time?

I'd second Paul Flaherty's motion that it's not unreasonable to look
at other possible data link layer protocols besides AX.25, though we
still have to keep our old standby going and fix it up :-) .

A couple of suggestions that sound reasonable to me:

    The new protocol should support both local ack (I frame)
    and real connectionless (UI frame) operation.  In a
    complex network, one hop may be very bad and its own
    problems could down the end-to-end link without local
    corrections.  One-hop links, though, or other very good
    ones, don't need it.

    The whole HDLC orientation of AX.25 is questionable for
    ham use.  It sells TNCs, but a truly async-capable data
    link, or a byte-oriented (no stuffing) data link would
    allow PCs to use more standard serial hardware.  Checksum
    becomes an issue, though:  CRC is nice but computationally
    expensive if you don't use dedicated hardware.  TP4 uses
    a different checksum that's much easier but not really
    meant for, or as good at, data link bit error detection.

If we stick to bytes, we may be able to use ASCII coding for the
callsign address fields, too, which could please the FCC; otherwise
they may be stuck on existing AX.25 compatibility.  Just a thought.

Something designed for CSMA or even Aloha environments (we're halfway
between them on most channels) would make sense; X.25 type procedures
don't really fit, nor do others that assume that everyone can hear.
     fred k1io


18-Jan-88 14:07:09-EST,1343;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 18 Jan 88 14:07-EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Mon, 18 Jan 88 12:47:19 EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Mon, 18 Jan 88 12:47:01 EST
Received: by june.cs.washington.edu (5.52.1/6.11)
    id AA12113; Mon, 18 Jan 88 09:47:32 PST
Return-Path: <gatech!purdue!umd5!umbc3![e-mail]>
Message-Id: <[e-mail]>
Date: 17 Jan 88 17:09:05 GMT
From: gatech!purdue!umd5!umbc3![e-mail] (Mr. Rick Battle )
To: [e-mail]
Subject: 2400 bps modems for packet
Keywords: ax.25 packet

I have been researching as much as I can about packet.  From
my reading I have found that two areas exhibit the most
activity.  Local AX.25 PBBS and new networking ideas.

I would like to address a less prominent area that may be of
interest to my fellow packeteers.

The current Bell 202 built in modem is ok but not great.
How about a discussion on how to build a 2400 bps chip set
circuit that will provide faster link speeds.

Which scheme is best?  How to interface to the TNC?
Where to get the chips?

Any interest?  This would make a great practical project.


Rick Battle   kb3ng
[e-mail]


18-Jan-88 18:22:34-EST,2021;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 18 Jan 88 18:22-EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Mon, 18 Jan 88 17:06:21 EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Mon, 18 Jan 88 17:05:57 EST
Received: by june.cs.washington.edu (5.52.1/6.11)
    id AA18989; Mon, 18 Jan 88 14:06:25 PST
Date: Mon, 18 Jan 88 14:06:25 PST
Return-Path: <princeton!phoenix![e-mail]>
Message-Id: <[e-mail]>
From: princeton!phoenix![e-mail] (Amit S. Joshi)
To: [e-mail]
Subject: Turbo C port of the KA9Q TCP/IP
Keywords: TCP/IP KA9Q TurboC
Reply-To: [e-mail]

Hello,

I have received a number of requests for the Turbo C port of the KA9Q
TCP/IP code. I have been mailing it out but now I am swamped. I thought
that only a few people would be interested in the code when I made the
offer to mail out copies. I shall therefore post the stuff to the net.

I would like to warn everybody that the version I have ported is NOT the
Christmas release. I am not using it for a packet radio, in fact I am
only using things to the socket level and so I have no plans to port the
Christmas release either. Also since I am not using most of the features
I have not tested them extensively. I am reasonably certain everthing
works over the ethernet with the 3COM board (I have used that portion),
but the rest I know that it compiles - I have fixed all the problems
that cropped in the ethernet portion and fixed similar code in other
places similarly.

My apologies to those people who requested and had to wait and then get
this message. I'll probably post to comp.protocols.tcp-ip.ibmpc unless I
get messages to the contrary soon.

--
Amit Joshi      BITNET  |       [e-mail]
        USENET  | {seismo, rutgers}\!princeton\!phoenix\!asjoshi
"There's a pleasure in being mad... which none but madmen know!" - St.Dryden


18-Jan-88 18:25:24-EST,2169;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 18 Jan 88 18:25-EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Mon, 18 Jan 88 12:44:45 EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Mon, 18 Jan 88 12:44:34 EST
Received: by june.cs.washington.edu (5.52.1/6.11)
    id AA12079; Mon, 18 Jan 88 09:45:10 PST
Return-Path: <aim.dec.com![e-mail]>
Message-Id: <[e-mail]>
Date: 18 Jan 88 15:33:47 GMT
From: aim.dec.com![e-mail] (Fred's usually home at DELNI::)
To: [e-mail]
Subject: New Data Link Layer protocol time?

I'd second Paul Flaherty's motion that it's not unreasonable to look
at other possible data link layer protocols besides AX.25, though we
still have to keep our old standby going and fix it up :-) .

A couple of suggestions that sound reasonable to me:

    The new protocol should support both local ack (I frame)
    and real connectionless (UI frame) operation.  In a
    complex network, one hop may be very bad and its own
    problems could down the end-to-end link without local
    corrections.  One-hop links, though, or other very good
    ones, don't need it.

    The whole HDLC orientation of AX.25 is questionable for
    ham use.  It sells TNCs, but a truly async-capable data
    link, or a byte-oriented (no stuffing) data link would
    allow PCs to use more standard serial hardware.  Checksum
    becomes an issue, though:  CRC is nice but computationally
    expensive if you don't use dedicated hardware.  TP4 uses
    a different checksum that's much easier but not really
    meant for, or as good at, data link bit error detection.

If we stick to bytes, we may be able to use ASCII coding for the
callsign address fields, too, which could please the FCC; otherwise
they may be stuck on existing AX.25 compatibility.  Just a thought.

Something designed for CSMA or even Aloha environments (we're halfway
between them on most channels) would make sense; X.25 type procedures
don't really fit, nor do others that assume that everyone can hear.
     fred k1io


18-Jan-88 18:32:31-EST,1634;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 18 Jan 88 18:32-EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Mon, 18 Jan 88 17:11:05 EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Mon, 18 Jan 88 17:10:51 EST
Received: by june.cs.washington.edu (5.52.1/6.11)
    id AA19059; Mon, 18 Jan 88 14:11:22 PST
Return-Path: <winfree![e-mail]>
Message-Id: <[e-mail]>
Date: 12 Jan 88 07:54:31 GMT
From: winfree![e-mail] (Bdale Garbee)
To: [e-mail]
Subject: Re: KISS Rom info for TNC-1
References: <[e-mail]> <[e-mail]>

In article <[e-mail]> [e-mail] (Bob Hoffman) writes:

>Marc Kaufman included a new ROM in the latest distribution:  TNC1NEW.ASM.
>This one saves parameters in NOVRAM.  I'll be testing one of those soon.

Don't bother.  I don't like touching the NOVRAM, so I asked Gerard PA0GRI
to migrate his changes into Kaufman's latest.  The result is that the
current TNC_TNC1.ARC on my BBS (soon to be on winfree and louie) only
contains one version, including Kaufman's fix in Gerard's version that doesn't
touch NOVRAM... and including a minor fix/mod from Gerard.

Two versions are confusing and take up disk space, I like Gerard's approach
better.
--
Bdale Garbee, N3EUA                     phone: [phone] h, 303/590-2868 w
uucp: {bellcore,crash,hp-lsd,ncc,pitt,usafa}!winfree!bdale
arpa: [e-mail]               packet: n3eua @ k0hoa, Colorado Springs
fido: sysop of 128/19 at 303/495-2061, 2400/1200/300 baud, 24hrs/day


18-Jan-88 20:27:16-EST,1353;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 18 Jan 88 20:27-EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Mon, 18 Jan 88 17:23:16 EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Mon, 18 Jan 88 17:22:43 EST
Received: by june.cs.washington.edu (5.52.1/6.11)
    id AA19344; Mon, 18 Jan 88 14:23:17 PST
Return-Path: <winfree![e-mail]>
Message-Id: <[e-mail]>
Date: 12 Jan 88 07:50:26 GMT
From: winfree![e-mail] (Bdale Garbee)
To: [e-mail]
Subject: Re: KA9Q TCP/IP under Microport: Help!
Keywords: perennial checksum errors
References: <[e-mail]> <[e-mail]> <[e-mail]>

In article <[e-mail]> [e-mail] (Jay Maynard) writes:

>Mine is apparently the .1 version. (Is there a reliable way to tell from
>looking at the code?)

In the src directory, look at the file version.c, which contains the value.
When you get an executable, the version is printed in the banner...
--
Bdale Garbee, N3EUA                     phone: [phone] h, 303/590-2868 w
uucp: {bellcore,crash,hp-lsd,ncc,pitt,usafa}!winfree!bdale
arpa: [e-mail]               packet: n3eua @ k0hoa, Colorado Springs
fido: sysop of 128/19 at 303/495-2061, 2400/1200/300 baud, 24hrs/day


19-Jan-88 05:10:07-EST,1072;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 19 Jan 88 05:10-EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Tue, 19 Jan 88 04:09:21 EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Tue, 19 Jan 88 04:09:02 EST
Message-Id: <[e-mail]>
Received: from DHHDESY3.BITNET by CUNYVM.CUNY.EDU ; Tue, 19 Jan 88 04:09:58 EST
Date:     19 JAN 88  09:32:42 MEZ
From: [e-mail]
To: [e-mail]
Subject:  Re: New Data Link Layer protocol time? (Checksum)

>    fred k1io:
>   allow PCs to use more standard serial hardware.  Checksum
>   becomes an issue, though:  CRC is nice but computationally
>   expensive if you don't use dedicated hardware.  TP4 uses

Did you ever see the checksum algorithm used by the W4UCH software
for the TRS-80? It is very fast! The CRC algorithm uses byte-wise
table lookup and was first suggested by Adam Perez in the June '83
issue of I.E.E.E. Micro.

vy 73 Karl-Heinz DK8HI

19-Jan-88 05:21:28-EST,1072;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 19 Jan 88 05:21-EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Tue, 19 Jan 88 04:09:21 EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Tue, 19 Jan 88 04:09:02 EST
Message-Id: <[e-mail]>
Received: from DHHDESY3.BITNET by CUNYVM.CUNY.EDU ; Tue, 19 Jan 88 04:09:58 EST
Date:     19 JAN 88  09:32:42 MEZ
From: [e-mail]
To: [e-mail]
Subject:  Re: New Data Link Layer protocol time? (Checksum)

>    fred k1io:
>   allow PCs to use more standard serial hardware.  Checksum
>   becomes an issue, though:  CRC is nice but computationally
>   expensive if you don't use dedicated hardware.  TP4 uses

Did you ever see the checksum algorithm used by the W4UCH software
for the TRS-80? It is very fast! The CRC algorithm uses byte-wise
table lookup and was first suggested by Adam Perez in the June '83
issue of I.E.E.E. Micro.

vy 73 Karl-Heinz DK8HI

19-Jan-88 07:54:59-EST,1646;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 19 Jan 88 07:54-EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Tue, 19 Jan 88 07:05:00 EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Tue, 19 Jan 88 07:04:22 EST
Received: from F29.Tymnet by OFFICE-1.ARPA; 19 Jan 88 04:03:43 PST
Received: from F29.Tymnet by EMSTUMS.Ontyme.Tymnet; Tue, 19 Jan 88 3:48:17 PST
Received: from OFFICE-1.ARPA by F29.Tymnet; Tue, 19 Jan 88 3:41:16 PST
Received: from EDDIE.MIT.EDU by OFFICE-1.ARPA; 19 Jan 88 01:54:47 PST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>;
    Tue, 19 Jan 88 04:09:21 EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>;
    Tue, 19 Jan 88 04:09:02 EST
Received: from DHHDESY3.BITNET by CUNYVM.CUNY.EDU ; Tue, 19 Jan 88 04:09:58 EST
Return-Path: <@OFFICE-1.ARPA:[e-mail]>
From: [e-mail]
Date: 19 JAN 88 09:32:42 MEZ
To: [e-mail]
Message-Id: <[e-mail]>
Subject: Re: New Data Link Layer protocol time? (Checksum)

>    fred k1io:
>   allow PCs to use more standard serial hardware.  Checksum
>   becomes an issue, though:  CRC is nice but computationally
>   expensive if you don't use dedicated hardware.  TP4 uses

Did you ever see the checksum algorithm used by the W4UCH software
for the TRS-80? It is very fast! The CRC algorithm uses byte-wise
table lookup and was first suggested by Adam Perez in the June '83
issue of I.E.E.E. Micro.

vy 73 Karl-Heinz DK8HI

19-Jan-88 20:18:03-EST,1616;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 19 Jan 88 20:18-EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Tue, 19 Jan 88 16:22:00 EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Tue, 19 Jan 88 16:19:35 EST
Received: by june.cs.washington.edu (5.52.1/6.11)
    id AA04889; Sat, 16 Jan 88 15:08:06 PST
Return-Path: <somewhere![e-mail]>
Message-Id: <[e-mail]>
Date: 16 Jan 88 04:51:27 GMT
From: [e-mail] (Paul Flaherty)
To: [e-mail]
Subject: Re: TCP/IP: KA9WGN rebuggal
Keywords: I love the Smell of Napalm in the Morning...
Reply-To: [e-mail] (Paul Flaherty)

Hello folks.  Having returned from a nice, long vacation, I thought I'd
start off my return to the net in a proper and decent manner.

Having said that...



Most of the problems addressed in KA9WGN have been addressed previously.
In particular:

Problem:                        Solution:
========                        =========
Name / IP Address Mapping       National Servers; Caching resolvers
Portable Operation              PRRP proxy addresses (using BOOTP)

The fact that much of this is being done "under the table" is due to the
desire to avoid publicity and get the job done.  And to avoid becoming
"Victims of GroupThink".

-=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


19-Jan-88 21:44:51-EST,6398;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 19 Jan 88 21:44-EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Tue, 19 Jan 88 18:03:38 EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Tue, 19 Jan 88 18:02:52 EST
Received: by june.cs.washington.edu (5.52.1/6.11)
    id AA03009; Tue, 19 Jan 88 15:03:18 PST
Return-Path: <bellcore!faline![e-mail]>
Message-Id: <[e-mail]>
Date: 19 Jan 88 05:16:21 GMT
From: bellcore!faline![e-mail] (Phil R. Karn)
To: [e-mail]
Subject: Re: New Data Link Layer protocol time?
Summary: new link protocols
References: <[e-mail]>

I'm glad to see that I'm in some company when it comes to wanting to
replace AX.25. An ARRL-sponsored meeting had been scheduled in northern
Virginia a weekend ago to discuss both short-term compatible changes to
the current AX.25 (AX.25 Version 2.x) plus initial long-term proposals
for a new protocol, one that would necessarily be incompatible with the
old. (This new protocol has the working title AX.25 V3.0?, but more
about this later). However the meeting was snowed out, and a new date
hasn't been set yet.

One proposal (from the Radio Amateur Telecommunications Society in the
northern New Jersey area) has already been floated. Others would be most
welcome.  What follow are my own comments and ideas, not to be confused
with those of RATS (not that there's much chance of this happening! :-))

Before I start bashing AX.25, though, there is one thing I believe was
done *right* in its design, and that was the addition of a datagram-
style address layer to each packet. This avoided so many problems, and
has worked so well in practice, that it's hard to remember that anyone
ever proposed "dynamic addressing" link protocols seriously. (The really
fun part about all this is that the Founding Fathers Of AX.25 were and
still are firmly in the "virtual circuit" camp, and to this day they
vehemently deny having contaminated AX.25 with any datagram-like
principles :-) ).

The main problem with AX.25 as it now stands, and the main reason for
the work on a new protocol, is the hard limit on callsign length: 6
characters.  This is not a problem for most amateurs, but those required
to identify with suffixes (temporary and reciprocal licenses, etc) are
stuck.  Fixing this implies a complete redesign of the addressing
sublayer. In the process, we might as well do the whole thing right,
since it will be incompatible with the present protocol anyway.  So here
are some thoughts about how to design a new protocol from the ground up.

1. The boundary above the datagram (address) sub-layer should be more
clearly defined. The C-bits in AX25L2V2 (for which I take full blame)
are a gross and disgusting hack because they carry information that
properly belongs in the LAPB control field, not the address field. (I
confess to taking CCITT at its word when they called the byte ahead of
the control byte the "address octet", even though X.25 runs on
point-to-point links where link level addressing has no meaning. I was
young and naive then, and I hereby throw myself on the mercy of the
court. :-) )

2. There should be a protocol identifier field between the address field
and the control field so that protocols other than LAPB can be used.  It
sort of works now with the UI (unnumbered information) frame, but it's
"unclean". This translates into wasted header space and messier
function-call interfaces between the various layers (I know, I've
implemented this stuff).

3. The use of "bit shifting" in the present address field is a classic
example of blind subservience to "international standards". ("Why was it
done?" "Because ISO said so.") It bought absolutely nothing in terms of
compatibility with anything else, but it created a low but persistent
irritation factor (double ascii displays on trace dumps, extra code,
etc). Furthermore, the information carried by the low order bits (the
length of the address field) could have been encoded in fewer bits by
just putting it in a count field. This also saves the CPU from having to
scan each byte to find the end of the address field, something that will
become important at high speeds.

4. Along the same lines, store-and-forward digipeaters (which won't go
away completely, no matter how much we would like them to) should make
their mark on packets by incrementing a "pointer" field in the address
header rather than by setting has-been-repeated bits scattered
throughout.  This is how it's done in IP source routing, and it's also a
lot faster to process.

5. The protocol should be more streamlined for connectionless network
traffic. (Except for COSI, every amateur network layer protocol at
present is connectionless).  One should not have to go through a "null"
LAPB layer to run the link in connectionless mode; that was my reason
for suggesting a protocol ID field directly after the address field.
Even if a connection-oriented protocol like LAPB is used to provide
link-level acknowledgements, it should allow data in connect-request
packets. This would be much like the "fast select" feature found at the
network layer in X.25.

6. Asynchronous framing should definitely be an option. HDLC is nice,
and now that we have it we might as well use it, but it should not be
the only way things can be done.  SLIP-style framing plus a suitable
checksum would work just fine at low speeds. (SLIP is already used on
the asynch port between a host computer and a KISS TNC).

7. Last but not least, we must name the new protocol something other
than "AX.25". This is a serious misnomer even for the present protocol,
as it misleads people into assuming it to be a compatible subset of
CCITT X.25 in the way BX.25 ("Bell X.25") is. It isn't, and we're likely
to diverge even further as we learn just how different the needs of
amateur packet radio are from the wants of landline common-carriers.
Furthermore, because of its CCITT connotations,  "AX.25" is often
downright embarassing to those of us trying to establish the legitimacy
of amateur packet radio to our non-amateur peers in the more progressive
communications research organizations. :-)

Comments?

Phil


20-Jan-88 12:53:57-EST,1016;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 20 Jan 88 12:53-EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Wed, 20 Jan 88 11:11:06 EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Wed, 20 Jan 88 11:10:02 EST
Message-Id: <[e-mail]>
Received: from MITVMA.MIT.EDU by MITVMA.MIT.EDU ; Wed, 20 Jan 88 11:10:21 EST
Received: from TRIUMFCL.BITNET (ROSK) by MITVMA.MIT.EDU (Mailer X1.25) with
 BSMTP id 2204; Wed, 20 Jan 88 11:07:03 EST
Date:     Tue, 19 Jan 88 23:34 PST
From: <[e-mail]>
Subject:  YAPP file xfer info needed.
To: [e-mail]
X-Original-To:  pack, ROSK

  Can someone tell me where I can find details of the YAPP file transfer
protocol? I want to transfer files from a VAX via a connected TNC to a
BBS which accepts YAPP file transfers. Any info would be appreciated.
Thanks,  Robert Skegg. VE7AII             [e-mail]

20-Jan-88 15:28:40-EST,831;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 20 Jan 88 15:28-EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Wed, 20 Jan 88 11:38:17 EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Wed, 20 Jan 88 11:37:47 EST
Message-Id: <[e-mail]>
Date: 20 Jan 88 08:28:42 PST
From: "W. E. Moerner"  <[e-mail]>
To: [e-mail]
Subject: Decimal or Hexadecimal???

I am running version 871225.4 of the KA9Q package, in which the
documentation states that the arguments of the "param" command for KISS
parameter settings are in HEXADECIMAL.  However, yesterday's GATEWAY
states that the arguments are in DECIMAL.  Which is correct?

W. E. Moerner, WN6I      [e-mail]     44.4.0.98  on 144.91
21-Jan-88 18:34:45-EST,1815;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 21 Jan 88 18:34-EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Thu, 21 Jan 88 16:37:22 EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Thu, 21 Jan 88 16:21:05 EST
Received: by june.cs.washington.edu (5.52.1/6.11)
    id AA06551; Thu, 21 Jan 88 13:18:45 PST
Return-Path: <tower![e-mail]>
Message-Id: <[e-mail]>
Date: 20 Jan 88 00:44:33 GMT
From: tower![e-mail] (John Moore)
To: [e-mail]
Subject: Re: Proposed Second Generation Link Layer Protocol
References: <[e-mail]>

In article <[e-mail]> [e-mail] (Paul Flaherty) writes:
>The time has come to reconsider the reigning role of AX.25 as the standard
>protocol for Amateur Packet Radio.  This discussion is motivated by the
> ...
>1. Protocol Thrashing in common multiaccess environments.
>2. Difficulty in implenting the protocol; in particular, the expense of the
>       chips required to perform the protocol.
This simply isn't true. SDLC/HDLC chips are a dime a dozen
these days, and SDLC and HDLC are the
standard (:-)) protocols in commercial
work today.


>3. Lack of persistence / backoff algolrithm.
>4. Connection orientation of the protocol.
How about:
 5. Not suitable for moderate or high Bit Error Rate (HF environment)
 6. Hidden station problem (Again HF, or digipeaters).

I doubt if appletalk is good for these problems either, but
they need to be addressed,
at least for HF work.
--
John Moore (NJ7E)   hao!noao!mcdsun!nud!anasazi!john
[phone] (day or evening)
The opinions expressed here are obviously not mine, so they must be
someone else's.


21-Jan-88 20:29:22-EST,2346;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 21 Jan 88 20:29-EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Thu, 21 Jan 88 18:56:05 EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Thu, 21 Jan 88 18:55:35 EST
Received: by june.cs.washington.edu (5.52.1/6.11)
    id AA12842; Thu, 21 Jan 88 15:21:54 PST
From: uunet!portal!cup.portal.com![e-mail]
Return-Path: <uunet!portal!cup.portal.com![e-mail]>
Message-Id: <[e-mail]>
Date: 20 Jan 88 17:42:59 GMT
To: [e-mail]
Subject: re:  Amateur/TCP-Its okay to use non-hamradio
Distribution: usa

Phil Karn writes:

>It is unrealistic for us to say "we're hams, so we're not interested in
>anything that doesn't use ham radio", or to look down on using
>commercial facilities in an amateur network as "cheating" even when
>there is no amateur alternative.  In many communities, the hams are the
>people who are also the most knowledgeable about communications in
>general -- not just radio.

Right on!  Your local fire department does NOT have a ham radio problem -
they have a COMMUNICATIONS problem.  They don't care how you solve the problem
as long as it is solved.  If you don't solve, well, they'll go somewhere
else ...

Similarly, sometimes as part of our public service work we get asked to
do a function that the FCC currently considers illegal for us to perform
(particularly with respect to the fuzzy areas around "almost business"
communications) and so we say we CAN NOT HELP THEM.  But if we see ourselves
as generic communications problem solvers, we can do much better and offer
to use an alternate radio service.   We can probably get some of these
groups to pay the costs of *renting* business band radios.  Or, certain
larger groups might even purchase some of they're own for use at special
events.  (This includes land mobile, 154 MHz 1 w portables, GMRS, even
49 MHz short range HTs).

Look for my article, "Emergency Communications:  Is it legal?" later this
year, probably in QST.  If anybody's interested, I'll post it to the net.
(By the way, the answer to "Is it legal?" is YES!).

Ed Mitchell
WA6AOD @ N6IIU
sun!portal!cup.portal.com!ed.mitchell


21-Jan-88 21:27:27-EST,911;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 21 Jan 88 21:27-EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Thu, 21 Jan 88 15:25:38 EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Thu, 21 Jan 88 15:25:22 EST
Received: by june.cs.washington.edu (5.52.1/6.11)
    id AA03939; Thu, 21 Jan 88 12:14:55 PST
Return-Path: <bellcore!faline![e-mail]>
Message-Id: <[e-mail]>
Date: 20 Jan 88 23:59:03 GMT
From: bellcore!faline![e-mail] (Phil R. Karn)
To: [e-mail]
Subject: Re: Decimal or Hexadecimal???
Summary: param args are in decimal
References: <[e-mail]>

The arguments to the "param" command are in decimal. The manual didn't
get properly updated (sorry 'bout that).

You could always look in the source code... :-)

Phil


21-Jan-88 21:40:24-EST,3512;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 21 Jan 88 21:40-EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Thu, 21 Jan 88 17:57:07 EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Thu, 21 Jan 88 17:55:34 EST
Received: by june.cs.washington.edu (5.52.1/6.11)
    id AA11140; Thu, 21 Jan 88 14:49:02 PST
Return-Path: <ihnp4!ihopa![e-mail]>
Message-Id: <[e-mail]>
Date: 20 Jan 88 14:19:31 GMT
From: ihnp4!ihopa![e-mail] (John Unruh)
To: [e-mail]
Subject: Re: New Data Link Layer protocol time?
References: <[e-mail]>

In article <[e-mail]>, [e-mail] (Fred's usually home at DELNI::) writes:

>
>       The whole HDLC orientation of AX.25 is questionable for
>       ham use.  It sells TNCs, but a truly async-capable data
>       link, or a byte-oriented (no stuffing) data link would
>       allow PCs to use more standard serial hardware.  Checksum
>       becomes an issue, though:  CRC is nice but computationally
>       expensive if you don't use dedicated hardware.  TP4 uses
>       a different checksum that's much easier but not really
>       meant for, or as good at, data link bit error detection.
>
> If we stick to bytes, we may be able to use ASCII coding for the
> callsign address fields, too, which could please the FCC; otherwise
> they may be stuck on existing AX.25 compatibility.  Just a thought.
>
> Something designed for CSMA or even Aloha environments (we're halfway
> between them on most channels) would make sense; X.25 type procedures
> don't really fit, nor do others that assume that everyone can hear.
>      fred k1io

I don't have much experience with packet radio, but I have quite a bit
of experience with packet data links, and therefore I believe I have
some valid comments.  To have a viable protocol, it is not necessary to
be compatible with HDLC.  I do, however, believe that it IS necessary to
use something similar, and the easy availablity of HDLC chips makes it a
good candidate.  Just sending bytes (without stuffing) leads to problems
detecting the start and end of packets.  I have seriously thought of
using byte counts like DDCMP, but I realized that some other sort of recovery
mechanism is needed (DDCMP has one), because loss of a byte throws the
byte count off and makes resynchronization very difficult.  The best thing
I have seen for sending characters without error is AMTOR.  I think to avoid
flags (and the resultant stuffing, bit or byte) something of that type is
needed.  Especially in a radio environment, I would expect some sort
of checksum would be necessary.  Because multiple stations may transmit
simultaneously, and especially since not all may be able to hear all the
others, you will get collisions, and a good detection method is necessary.
The CRC-16 algorithm works well, and chips implement it, so again it is
a good choice.  I have long been of the opinion that in a packet network,
ISO protocols have a place AT THE TWO ENDS.  I am not convinced that ISO
protocols work well within the network.  When the layers build up, there
is a tremendous amount of overhead.  ISO protocols also are good for
point to point links.

                   John Unruh
                   ihnp4!ihlpk!jdu

This does not necessarily represent the opinions of my employer.


21-Jan-88 23:46:27-EST,1998;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 21 Jan 88 23:46-EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Thu, 21 Jan 88 15:26:21 EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Thu, 21 Jan 88 15:25:49 EST
Received: by june.cs.washington.edu (5.52.1/6.11)
    id AA04002; Thu, 21 Jan 88 12:16:10 PST
Return-Path: <gatech!hao!boulder!sunybcs!trotter![e-mail]>
Message-Id: <[e-mail]>
Date: 21 Jan 88 16:00:33 GMT
From: gatech!hao!boulder!sunybcs!trotter![e-mail] (Bill Gunshannon)
To: [e-mail]
Subject: Re: Proposed Second Generation Link Layer Protocol
References: <[e-mail]>

In article <[e-mail]>, [e-mail] (Paul Flaherty) writes:
> The time has come to reconsider the reigning role of AX.25 as the standard
> protocol for Amateur Packet Radio.

I agree with this...

> As a replacement, I would propose the AppleTalk / AppleLink protocol
> as described (thoroughly) in _Inside Appletalk_, which is available from
> APDA for a nominal fee.  In particular:

I totally disagree with this.
I can not see using a proprietary protocol for Amatuer use.  Especially one
>from someone who has proved as litigious(sp) as Apple has (remember the "look
and feel" lawsuit).  I can see them waiting til a network is in place and
then saying we have to pay them royalties.


Its proprietary nature is also why I don't agree with the concept of NETROM
and intend to continue to run N2WX Switch code till COSI is ready.

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]


22-Jan-88 01:33:13-EST,1980;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 22 Jan 88 01:33-EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Thu, 21 Jan 88 15:20:14 EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Thu, 21 Jan 88 14:24:28 EST
Posted-Date: Thu 21 Jan 88 11:22:02-PST
Received: by venera.isi.edu (5.54/5.51)
    id AA18624; Thu, 21 Jan 88 11:22:03 PST
Date: Thu 21 Jan 88 11:22:02-PST
From: Richard Bisbey <[e-mail]>
Subject: Re: New Data Link Layer protocol time?
To: [e-mail]
Message-Id: <[e-mail]>
Mail-System-Version: <VAX-MM(216)+TOPSLIB(128)@VENERA.ISI.EDU>

If some committee is going to legislate a new Link-level protocol for
amateurs, how about considering:

1)  A separate HDLC-level that includes an HDLC destination address octet (to
    allow use of the address filter function found in most HDLC silicon to
    eliminate 90% of unwanted packets), and a Packet-Type octet to select
    interpretation of the remaining octets (to support different link-level
    protocols, e.g., bootstrap, debugging, etc.).

2)  A separate header checksum (and two flag bits, Allow-Damage and Damaged),
    to permit FEC and/or transmission of data for which errors are acceptable.
    (The header checksum would cover link and net level addresses and flags.
    The Allow-Damage bit, when set, would indicate that the packet should be
    processed, and any data forwarded as long as the header checksum was
    valid.  The Damaged bit, when set, would indicate that the higher-level
    data in the packet may have been damaged at some point.)

3)  Link-level flag bits to trigger debugging, expedite packet processing,
    and indicate reliable/unreliable link-level exchanges.

4)  An explicit Next-Protocol octet to indicate the higher-level protocol for
    which this packet contains data.

Richard
ng6q
-------
26-Jan-88 13:30:17-EST,2462;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 26 Jan 88 13:30-EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Tue, 26 Jan 88 11:10:28 EST
Received: from ai.ai.mit.edu by EDDIE.MIT.EDU via Chaosnet with SMTP with sendmail-5.45/4.7 id <[e-mail]>; Tue, 26 Jan 88 11:10:11 EST
Received: from ALDERAAN.SCRC.Symbolics.COM (TCP 20024224555) by AI.AI.MIT.EDU 26 Jan 88 11:07:43 EST
Received: from ROOK.SCRC.Symbolics.COM by ALDERAAN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 162565; Tue 26-Jan-88 11:09:18 EST
Date: Tue, 26 Jan 88 11:09 EST
From: Henry Minsky <[e-mail]>
Subject: GLB Netlink 220 txcvr
To: [e-mail], [e-mail]
Message-Id: <[e-mail]>


I saw an item in QST magazine announcing a digital transceiver from GLB
electronics. The text is as follows:

"The GLB netlink 220 is a digital-signal-in, digital-signal-out radio
designed for high-speed packet linking. It is designed to solve the
problems of interfacing high-speed modems to conventional VHF FM
transceivers. The Netlink 220 is directly compatible with the GLB PK2
TNC. It also works with TAPR TNC 2s and TNC 2 clones, although a few
minor PC-board modifications must be made to those TNCs. DEsigned for
simplex operation in the 220-225Mhz range, NETLINK 220 features a data
rate of 19,200 bauds and 2 W RF output. Additional features include

* oven-controlled crystal oscillators for high stability
* PIN diode antenna switching for fast (3 ms) turnaround time
* automatic receiver tracking for long-term drift compensation
* 5 helical resonators in the receiver for good spurious signal
rejection
* TTL/CMOS compatible digital inputs and outputs
* conservative design for longtime reliability
* transmitter watchdog timer

The netlink 220 requires 12-13.8 V dc at 1.2 A.
Size 4.3 x 12 x 10.3 in (HWD) Weight 6Lb.
For more information contact
GLB Electronics
151 Commerce Pkwy,
Buffalo, NY, 14224,
tel [phone] "

I called them to get technical info, and they said they'd send me some,
but that the announcement was a little "premature" (i.e., they said they
wouldn't have the stuff back from the printer until next week).

The person I talked to didn't have a lot of details, but said that it
used "NRZI", and would cost amateurs about $700.

Henry, N1EZP

28-Jan-88 22:27:10-EST,2171;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 28 Jan 88 22:27-EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Thu, 28 Jan 88 21:03:36 EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Thu, 28 Jan 88 20:13:50 EST
Received: by june.cs.washington.edu (5.52.1/6.11)
    id AA16033; Thu, 28 Jan 88 16:57:45 PST
Return-Path: <hplabs!hpcea!hpfcdc!hpldola!hp-lsd!winfree![e-mail]>
Message-Id: <[e-mail]>
Date: 14 Jan 88 00:49:04 GMT
From: hplabs!hpcea!hpfcdc!hpldola!hp-lsd!winfree![e-mail] (Bdale Garbee)
To: [e-mail]
Subject: Re: New Release of KA9Q TCP/IP Package
References: <[e-mail]> <[e-mail]>

In article <[e-mail]> [e-mail] (David HM Spector) writes:
>I would really _love_ to be able to get a copy of Phil's new TCP software,
>but the fact that _everything_ is arc'd makes it impossible. (In case you
>haven't guessed, I am a Macintosh user.)

The code was born on a Xerox 820, has grown up on PC clones, and is just now
entering adolescence with the addition of support for the Mac and Amiga...
Sorry, I didn't realize this would be such a hassle for folks.  You're not
the only one who can't deal with ARC... unfortunately!

>Any help in getting the sources in tar format would be _greatly_ appreciated.

There will be a set of .tar.Z files on winfree by sometime on Saturday for
anonymous uucp.  I will post another note at that time.  In addition, I'll
try to get the bits on to an Internet host for anonymous ftp by the first of
the week.

Grab the file /usr/spool/uucppublic/pub/README on Saturday or whenever after
for info, it will from now on always contain the current version number info
as well as the pathnames and descriptions...

Hope this helps?
--
Bdale Garbee, N3EUA                     phone: [phone] h, 303/590-2868 w
uucp: {bellcore,crash,hp-lsd,ncc,pitt,usafa}!winfree!bdale
arpa: [e-mail]               packet: n3eua @ k0hoa, Colorado Springs
fido: sysop of 128/19 at 303/495-2061, 2400/1200/300 baud, 24hrs/day


28-Jan-88 23:54:55-EST,2246;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 28 Jan 88 23:54-EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Thu, 28 Jan 88 19:51:26 EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Thu, 28 Jan 88 19:50:57 EST
Received: by june.cs.washington.edu (5.52.1/6.11)
    id AA15695; Thu, 28 Jan 88 16:51:16 PST
Return-Path: <cbosgd!gwspc!n8emr![e-mail]>
Message-Id: <[e-mail]>
Date: 26 Jan 88 14:34:23 GMT
From: cbosgd!gwspc!n8emr![e-mail] (Gary Sanders)
To: [e-mail]
Subject: what am i doing wrong


Ok, Well I finally got my KPC-1 tnc upgraded to 2.71 so I can run KISS,
Its seem to be working fine in non-kiss mode, but when running net
on my unix-pc, nothing seems to happen. It looks like I can take
the tnc out of kiss mode with param ax0 255, but when I try to connect
to anyone (anything) the tnc never keys the transmitter. Below is some
.net files I am using.

net version 871225.0

startup.net.....

#startup.net
#This is me..
hostname n8emr.ampr
ax25 mycall n8emr

ip address [44.128.0.1]

#TNC is attached to tty001
attach asy 0 /dev/tty001 slip sl0 2048 256 9600
attach asy 0 /dev/tty001 ax25 ax0 2048 256 9600

#Kill it after 3, just for testing
ip ttl 16

#This are some default items I picked up
tcp mss 216
tcp window 432

#start them up!!!
start smtp
start ftp
start echo
start discard
start telnet

#some more defaults..
ax25 digipeat off
ax25 maxframe 1
ax25 paclen 256
ax25 retry 10
ax25 window 2048

#point them...
route add [44.128.0.1]/10 sl0


... host.net....
#
# Just a few items to test us out..
#
44.128.0.1 n8emr gary 3b1
44.128.0.2 n8emr-1 gary 3b2
#
44.128.0.3 k1lt-1 vic-lap
44.128.0.4 k1lt vic-ibm

.... tnc settings are default plus ....

abaud 9600              # also tried 1200, but no luck.
dwait 0
persist 50
slottime 16
kiss on

Well any hints on how to get a telnet session working or even just
to get an ax25 session working on the tnc?


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


29-Jan-88 00:12:51-EST,858;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 29 Jan 88 00:12-EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Thu, 28 Jan 88 19:56:43 EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Thu, 28 Jan 88 19:56:02 EST
Received: by june.cs.washington.edu (5.52.1/6.11)
    id AA15874; Thu, 28 Jan 88 16:53:52 PST
Return-Path: <uunet!mcvax!unido!rmi!dg2kk![e-mail]>
Message-Id: <[e-mail]>
Date: 23 Jan 88 16:23:44 GMT
From: uunet!mcvax!unido!rmi!dg2kk![e-mail] (Walter)
To: [e-mail]
Subject: KA9Q TCP/IP 871225.3
Posted: Sat Jan 23 17:23:44 1988

Can someone please tell me, what the changes are between version 871225.1 and
871225.3.
Where can I get a list of the changes made?

Walter


29-Jan-88 01:27:29-EST,1260;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 29 Jan 88 01:27-EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Thu, 28 Jan 88 19:56:37 EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Thu, 28 Jan 88 19:55:55 EST
Received: by june.cs.washington.edu (5.52.1/6.11)
    id AA15932; Thu, 28 Jan 88 16:55:07 PST
Return-Path: <gatech!udel!burdvax!bpa!cp1!cpesac![e-mail]>
Message-Id: <[e-mail]>
Date: 23 Jan 88 00:43:53 GMT
From: gatech!udel!burdvax!bpa!cp1!cpesac![e-mail] (Jerry Aycock)
To: [e-mail]
Subject: ICOM IC 551- PACKET
Keywords: ICOM IC551 PACKET

Two of my friends are trying to link up via packet on 6 meters.
They have no trouble on 10 or 2 meters. Both are using ICOM IC-551's
Both are using good beams and strong signal at both ends. They can
only connect 1 out of 4 times and then never print on either end.
They cannot copy 1 single (UA) packet but will print all if there
are 10 or more (UA) packets. THey have tried MAX delay's and DEWAITS
nothing seems to help. Any ideas ?? tnx  73
WA4OHX @ WA4OHX  JERRY C.AYCOCK WA4OHX PBBS HAMPTON VIRGINIA.
or AT WB0TAX    HF_


30-Jan-88 12:49:14-EST,1978;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 30 Jan 88 12:49-EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Sat, 30 Jan 88 11:49:41 EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Sat, 30 Jan 88 11:49:32 EST
Received: by june.cs.washington.edu (5.52.1/6.11)
    id AA19512; Sat, 30 Jan 88 08:49:57 PST
Return-Path: <bellcore!faline!thumper![e-mail]>
Message-Id: <[e-mail]>
Date: 29 Jan 88 02:57:01 GMT
From: bellcore!faline!thumper![e-mail] (Phil R. Karn)
To: [e-mail]
Subject: Re: Proposed Second Generation Link Layer Protocol
References: <[e-mail]> <[e-mail]>

> This simply isn't true. SDLC/HDLC chips are a dime a dozen
> these days, and SDLC and HDLC are the
> standard (:-)) protocols in commercial
> work today.

Yes, HDLC chips are fairly cheap these days. Yes, they're widespread in
commercial equipment. Despite it being an ISO standard, I even like it.
(I'm referring only to that part of HDLC you generally find in hardware,
i.e., framing, bit stuffing and CRC, not the brain-damaged LAPB protocol
usually implemented in software above it).

Unfortunately HDLC chips are still not as cheap as ordinary asynchronous
UARTS, so you don't find many as standard equipment on the kinds of
cheap computers most hams have in their shacks. Hence the desirability
of an alternate (co-standard) link level protocol based on asynchronous
framing.

> I doubt if appletalk is good for these problems either...

I believe the relevant part of AppleTalk is the low-level channel access
mechanism. Not being familiar with it I'll let Paul describe it in
detail. I believe it involves the transmission of a "request to send"
message before sending actual data, the idea being to confine collisions
to the request-to-send messages, not the data packets.

Phil


30-Jan-88 14:35:22-EST,1192;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 30 Jan 88 14:35-EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Sat, 30 Jan 88 13:32:27 EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Sat, 30 Jan 88 13:32:11 EST
Received: by june.cs.washington.edu (5.52.1/6.11)
    id AA20649; Sat, 30 Jan 88 10:32:34 PST
Return-Path: <bellcore!faline!thumper![e-mail]>
Message-Id: <[e-mail]>
Date: 29 Jan 88 03:00:38 GMT
From: bellcore!faline!thumper![e-mail] (Phil R. Karn)
To: [e-mail]
Subject: Re: Proposed Second Generation Link Layer Protocol
Summary: net/rom isn't completely proprietary
References: <[e-mail]> <[e-mail]>

> Its proprietary nature is also why I don't agree with the concept of NETROM
> and intend to continue to run N2WX Switch code till COSI is ready.

Their technical merits (or demerits) notwithstanding,  NET/ROM's protocols
are fully documented in the manual.  Anyone is free to develop their own
implementation if they don't want to send money to Software 2000.

Phil


30-Jan-88 14:45:44-EST,3692;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 30 Jan 88 14:45-EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Sat, 30 Jan 88 13:36:37 EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Sat, 30 Jan 88 13:36:12 EST
Received: by june.cs.washington.edu (5.52.1/6.11)
    id AA20682; Sat, 30 Jan 88 10:36:35 PST
Return-Path: <bellcore!faline!thumper![e-mail]>
Message-Id: <[e-mail]>
Date: 29 Jan 88 03:23:09 GMT
From: bellcore!faline!thumper![e-mail] (Phil R. Karn)
To: [e-mail]
Subject: Re: New Data Link Layer protocol time?
References: <[e-mail]>

In article <[e-mail]>, Richard Bisbey, NG6Q, writes:
> If some committee is going to legislate a new Link-level protocol for
> amateurs, how about considering:
>
> 1)  A separate HDLC-level that includes an HDLC destination address octet (to
>     allow use of the address filter function found in most HDLC silicon to
>     eliminate 90% of unwanted packets)

Is this really worth it? Although faster amateur modems are coming, ARPA
experience has shown that UHF packet radio links are often limited by
multipath reflections to speeds of 400 kbps or less. It's not *that*
hard to filter packets at such speeds in software (unless you use
obsolete Z-80s or 6502s :-))

I suppose we could compute a one-byte hash function over the destination
address, putting this code at the start of the frame.  The Vancouver
"V2" protocol did something like this, but it omitted the regular
source/destination callsign information. This got it banned in
Australia, whose Department of Communications has mandated datagram-
style headers containing full source and destination addressing at both
the link and network layers in amateur packet radio. As long as the
regular addressing is included, though, there's no problem in adding
additional info.

> , and a Packet-Type octet to select
>     interpretation of the remaining octets (to support different link-level
>     protocols, e.g., bootstrap, debugging, etc.).

There is already a "level 3 Protocol ID" field in the present AX.25. I assume
you mean that the implementation should be cleaner, e.g., to avoid the need
for a "null LAPB layer" in the form of the UI frame. Agreed.

> 2)  A separate header checksum (and two flag bits, Allow-Damage and Damaged),
>     to permit FEC and/or transmission of data for which errors are acceptable.
>     (The header checksum would cover link and net level addresses and flags.
>     The Allow-Damage bit, when set, would indicate that the packet should be
>     processed, and any data forwarded as long as the header checksum was
>     valid.  The Damaged bit, when set, would indicate that the higher-level
>     data in the packet may have been damaged at some point.)

This is very difficult in the context of a half-duplex channel, perhaps
impossible when HDLC is used. How do you efficiently tell the difference
between a "real" packet received with errors -- and random noise?

> 3)  Link-level flag bits to trigger debugging, expedite packet processing,
>     and indicate reliable/unreliable link-level exchanges.

These could be provided in a "reserved for local use" field, though I'd like
to see a more explicit explanation of how they'd be used.

> 4)  An explicit Next-Protocol octet to indicate the higher-level protocol for
>     which this packet contains data.

As I mentioned, this is already present in the Protocol ID field. Though
of course the implementation should be cleaned up....

Phil


30-Jan-88 14:51:13-EST,2174;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 30 Jan 88 14:51-EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Sat, 30 Jan 88 13:56:34 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, 30 Jan 88 13:56:16 EST
Resent-Message-Id: <[e-mail]>
Received: from SIMTEL20.ARPA (TCP 3200000112) by MC.LCS.MIT.EDU 30 Jan 88 13:57:05 EST
Date: Friday, 15 January 1988  02:06-MST
Message-Id: <[e-mail]>
Sender: [e-mail]
From: [e-mail]
To: [e-mail]
Subject:   Packet Addresses
Resent-From: [e-mail]
Resent-To: [e-mail]
Resent-Date: Sat 30 Jan 1988 11:56-MST

I note that much of the mail concerning packet radio addressing
schemes is based around telephone area codes and/or ZIP codes.

My question is; Are the gentlemen who are designing these schemes
interested in worldwide compatibility? The reason I ask is that the
packet network is, or will become, world-wide. If, at this early
stage, the addressing schemes have North American dependencies built
in, the only way that US Amateurs will be able to communicate with
amateurs outside North America is through gateways or by special
addressing schemes.

It would seem that this is a plus point in favour of TCP/IP which
appears not to have been mentioned so far - which although a US
'invention' is at least not dependent on cultural peculiarities such
as ZIP codes, etc.

(FYI, There is no European 'ZIP' code scheme. The British scheme uses
a mixture of letters and numbers, for example my Postcode is AL3 5HP,
(complete with a space). Postcodes are always 2 letters, a number, a
space, a number and 2 letters. British telephone 'area codes' are not
fixed length, so they can't be used either - although my 'area code '
(called STD codes in Britain) is 727, I have friends (looks in
telephone book) with STD codes like 6285, 24020 and 1.)

Hugh Davies, G0CNR.
Packet: G0CNR@GB3HQ    (144.625MHz)

30-Jan-88 15:11:45-EST,6671;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 30 Jan 88 15:11-EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Sat, 30 Jan 88 13:54:06 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, 30 Jan 88 13:53:44 EST
Resent-Message-Id: <[e-mail]>
Received: from SIMTEL20.ARPA (TCP 3200000112) by MC.LCS.MIT.EDU 30 Jan 88 13:54:29 EST
Date: Friday, 15 January 1988  13:02-MST
Message-Id: <[e-mail]>
Sender: Phil Howard <[e-mail]>
From: Phil Howard <[e-mail]>
To: [e-mail]
Subject:   TCP/IP: KA9WGN rebuttal
Resent-From: [e-mail]
Resent-To: [e-mail]
Resent-Date: Sat 30 Jan 1988 11:53-MST

I think maybe my question was misunderstood.  If need be, I can rephrase it.

> From: ... Brian Kantor
> Partly right, but mostly wrong.  Domain names provide a map from a
> symbolic name that people can deal with (e.g, sun.wb6cyt.ampr) to an
> internet 32-bit address (i.e., 44.8.0.103) that is less intuitive.

So in the ham radio world, at least every ham who wants one, gets an
IP address, maybe ALL of them, and somewhere there will be a complete
mapping table.

> NOTHING ELSE!  Your example of 'faline.bellcore.com' is incorrect; that
> hostname implies no more or less addressing than 'falinebellcorecom'
> would.  It's just a unique name that maps to a 32-bit IP address, with
> or without the dots.  The domain system allows the lookup to made
> dynamically on the network instead of looking through a huge file of
> hosts and addresses, but that's all.

Unique yes, but the hierarchy is the IMPORTANT part because without its
concept, you can have nothing but the totally impractical 1:1 mapping
of half a million call signs.

> The internet addresses are interpreted by the underlying transport
> system to provide the routing.  As an example, in a packet switch in
> the middle of an IP network, the only decision to be made when
> forwarding a packet is which port to resend the packet out of.  That
> port selection is based on criteria which may include fixed routing
> rules, dynamic rerouting instructions, and periodic updates of
> systemwide tables.  But YOU never deal with that; it's done
> automagically.

Since I am planning to implement software for this, I certainly cannot
work on the notion of "automagically".  It has to be done somehow, and there
are choices in the ways to do it.  I have to at least know what those choices
are at the minimum.  I would even like to get involved in the decisions if
it would help (and I think it might).

> When I connect using regular AX.25 packet rtty on 28.105 to VK2ALS, I
> don't know, and don't need to know, whether he's in Australia or
> Wisconsin.  Ditto for voice or CW.  With the TCP/IP network, it's the
> same.  I know his callsign, and that's enough.  Why should I need to
> know more to use a network that's supposedly there to make communications
> easier?

The example here might not be clear.  You MIGHT connect directly, where your
radio signal would actually reach his receiver, and visa-versa.  Of course
that would not involve routing, only recognition.  But routing is a totally
different matter.  The best way to consider routing is to think of working
on UHF.

> How is this done?  Well, in some part, IP addresses are assigned
> regionally in subnets, and routing tables know that.  The routing
> tables in the packet switching nodes also know about exceptions to the
> subnets as well, since there is a protocol for automatically exchanging
> that information on the network between the nodes.  Since CALLSIGNS are
> the hostnames that you'd use when establishing a connection or sending
> mail, you don't have to know the IP address.  (Nothing stops you from
> knowing and using the IP address, but you don't HAVE to know it.)

Great, that's the way it works now on national TCP/IP networks.  But even
still someTHING knows how to route even these addresses.

> If someone moves, his callsign doesn't change.  His US Postal address
> does, and so would his IP address.  Just as with the USPS's ability to

Ah ha... you are now FINALLY getting to what I actually asked.  So, his
IP address changes when he MOVES is PRIMARY STATION.  Now what about PORTABLE
OPERATION at my parents home, at my brother's home, at my other brother's
home, at my vacation retreat, at a DX-pedition, what about the home of the
girl I just met last week who lives 500 miles away and I am going to go visit
her there and operate portable.

The experiences of a national TCP/IP network are things we need to know, but
can cannot consider that this is all that we need to know.  Ham Radio poses
many NEW problems.  We need to consider them.  They do NOT have to be
considered immediately to get a TCP/IP network going at a minimum, but we
will eventually HAVE TO be considered, and the optimal solutions there MIGHT
be incompatible (in terms of all those AUTOMAGICAL things going on) with
what is designed first.

We need to consider all things now, so that we can get a good network going
sooner, without all the problems of compatibilities.  Maybe someone has
already considered it; maybe they already have a working solution; maybe
even YOU have done it; but its is NOT out on the table for those who care
to see.

> cope with forwarding your mail when you move, the IP network can
> redirect an address too - so that you could conceivable keep your IP
> address when you move.  You wouldn't, since redirects are inefficient,
> but the system will cope.  The USER NEVER SEES THIS!  He would still
> issue the "connect wb6cyt" command and he would get connected.

I don't think addressing a problem with "USER NEVER SEES THIS" is going
to help make it work better.  I fully agree that the user should not
HAVE TO see it, but I also want to make sure that it REALLY works under
the unique problems that Ham Radio pose.  If it FAILS, then the user won't
see that either??????

> I hope this makes it a bit clearer.

Somewhat, but not as clear as TCP/IP itself is already.

> Oh by the way, these are proven concepts, not pie-in-the-sky.  They
> work, or this mail wouldn't be getting to you.

It didn't get here by Ham Radio.  It didn't get here by having every
single node be known by every other node.  It didn't get by a direct
connection on an Ethernet.  It didn't get here AUTOMAGICALLY.

30-Jan-88 15:58:36-EST,1068;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 30 Jan 88 15:58-EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Sat, 30 Jan 88 15:08:47 EST
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Sat, 30 Jan 88 15:08:21 EST
Received: by june.cs.washington.edu (5.52.1/6.11)
    id AA22460; Sat, 30 Jan 88 12:08:25 PST
Date: Sat, 30 Jan 88 12:08:25 PST
From: [e-mail] (Clifford Neuman)
Return-Path: <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail]
Cc: [e-mail]
In-Reply-To: Death to the Daleks!'s message of Thu, 17 Sep 87 09:26 PDT <[e-mail]>
Subject: Mailing List Removal

Have you been removed from the packet radio mailing list as per your
request.  You do not seem to be on the BITNET redistribution.  If you
are still getting messages, send me one of them including all headers
so I can figure out how you are getting it.

    ~ Cliff