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

Text File | 1993-12-31 | 227.2 KB | 4,785 lines

2-Sep-87 00:01:43-EDT,2226;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 2 Sep 87 00:01-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Tue, 1 Sep 87 23:03:11 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Tue, 1 Sep 87 23:03:00 EDT
Received: by june.cs.washington.edu (5.52.1/6.6)
    id AA06334; Tue, 1 Sep 87 20:04:50 PDT
Return-Path: <hoptoad![e-mail]>
Message-Id: <[e-mail]>
Date: 1 Sep 87 14:21:30 GMT
From: hoptoad![e-mail] (Tim Pozar)
To: [e-mail]
Subject: Public access to ham spectrum
References: <[e-mail]>


   I'll have to agree with the points that Bob McGwier makes.
If John wants to orginize or experiment with some sort of
packet radio link, he can apply for a Special Temporary
Authorization (STA) from the FCC.  The Big Boys do it all the
time (eg. California Microwave, Ampex, Motorola, etc.)  STAs can
be taylored to allow some pretty sloppy modulation too, so you
can find some sort of old commercial gear to use with it.
   John, you are asking to use a NON-commercial meadium to
handle commercial traffic.  How would you feel if a commercail
user of the net started to do message bombing runs on the net
through your board.  I keep hearing about the "non-commercal"
flavor to UUCP (something that will have to change in the near
future, by the way).  Using the net commercially would be like
using ham freqs commercially.  There are frequencies set aside
for what you want to do (eg 23GHz).  Building equipment for
those freqs isn't that difficult or expensive.
   If you are interested in applying, you should contact the
local field office of the FCC at [phone], and ask for the
STA forms.  I'm not sure what the form numbers are, but if you
ask for one of the officers<?> s/he should be able to guide you
in the right direction.  The last time I needed something like
this I tald to a woman named "Amy".  Sorry, I don't remember her
last name.

--
    Tim Pozar
UUCP    [e-mail]
Fido    1:125/406
USNail  KLOK-FM
    77 Maiden Lane
    San Francisco CA 94108
PaBell  [phone]


 2-Sep-87 00:02:36-EDT,2246;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 2 Sep 87 00:02-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Tue, 1 Sep 87 22:59:52 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Tue, 1 Sep 87 22:59:39 EDT
Received: by june.cs.washington.edu (5.52.1/6.6)
    id AA06190; Tue, 1 Sep 87 20:01:27 PDT
Return-Path: <cornell!batcomputer!itsgw!steinmetz![e-mail]>
Message-Id: <[e-mail]>
Date: 1 Sep 87 14:15:48 GMT
From: cornell!batcomputer!itsgw!steinmetz![e-mail] (William E. Davidsen Jr)
To: [e-mail]
Subject:  Public access to ham spectrum
References: <[e-mail]>
Reply-To: crdos1![e-mail] (bill davidsen)

I will just add a little fuel to the fire on this debate, the Zmodem
protocol, heavily advertized in Chuck Forsburg's (sp?) signature, work
*very well* over packet connections, having been designed for just that.
In addition the low volume of reverse channel makes it suitable for use
with half duplex connections. Typical performance is 95+% of theoretical
max, for example 231-233 cps on 2400 baud async half duplex connects
(actual measured on a number of 100k+ file transfers).

I'm told that SEAlink and megalink provide the same range of
performance, but I see little reason to use them other than
compatibility and on very small machines which benefit from the low
overhead of megalink.

I have no idea why the performance of ham packet radio is so poor, nor
why various people on this group have claimed that the use of more than
one (or at most two) repeaters resulted in unacceptable throughput.
Unless there is a legal reason why this protocol may not be used, I
would like to invite one of the interested parties to test it. Source to
several versions of the drivers for the protocol have been posted, I
will supply them on request.

Yes, I realize that there will still be a problem with very small
messages, don't waste bandwidth mentioning it.
--
    bill davidsen           ([e-mail])
  {chinet | philabs | seismo}!steinmetz!crdos1!davidsen
"Stupidity, like virtue, is its own reward" -me


 2-Sep-87 00:05:25-EDT,1734;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 2 Sep 87 00:05-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Tue, 1 Sep 87 22:57:20 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Tue, 1 Sep 87 22:57:08 EDT
Received: by june.cs.washington.edu (5.52.1/6.6)
    id AA06142; Tue, 1 Sep 87 19:58:54 PDT
Return-Path: <ihnp4!homxb!hotps!ka2qhd![e-mail]>
Message-Id: <[e-mail]>
Date: 1 Sep 87 19:19:45 GMT
From: ihnp4!homxb!hotps!ka2qhd![e-mail] (Tom)
To: [e-mail]
Subject: Starting to lean our way?
References: <[e-mail]> <[e-mail]>

Phil, I was very pleased to see your talk, especially your slides!

Your OSI (7 Layer) Model was wonderful!

I guess you are starting to see our view...

I also enjoyed your multi-film slide showing very graphically the extra 54 bytes
tcp/ip adds, all I would need to do to use that slide is change the 20's to 3's
and it would have depicted x.25+x.2xx very well...

oh yea, Mr. Padlipski (excuse the mispelling) and I had a nice talk,
and we agreed that the ISO protocols were still very new and they still had to
mature before they would replace the TCP/IP systems of the USA...
And that this probally would happen fairly quickly...

I guess TCP/IP is the protocol of the late 60's/early 70's and the ISO suite
is the protocol of the late 80's/early 90's...
(global acceptance helps a lot...)

on another topic, Mr. P has a lot of followers and has sold many books because
he can nitpick all things (protocols/groups) and find problems for people to
feed on for fuel for thier FLAME!!!
 2-Sep-87 15:08:12-EDT,6347;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 2 Sep 87 15:08-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Wed, 2 Sep 87 12:16:29 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Wed, 2 Sep 87 12:16:11 EDT
Received: by june.cs.washington.edu (5.52.1/6.6)
    id AA16160; Wed, 2 Sep 87 09:18:05 PDT
Return-Path: <bellcore!faline![e-mail]>
Message-Id: <[e-mail]>
Date: 2 Sep 87 04:39:54 GMT
From: bellcore!faline![e-mail] (Phil R. Karn)
To: [e-mail]
Subject: Re: (none)
References: <[e-mail]> <[e-mail]> <[e-mail]>

>Your OSI (7 Layer) Model was wonderful!

If you had looked at it carefully, you would have noticed that I was
actually showing the (four-layer) ARPA model. From top to bottom, the ARPA
layers are Application, Host-Host, Internet and Subnet.  I did show the
closest equivalent ISO layers solely for sake of comparison:

ARPA Application <--> ISO Application and Presentation
ARPA Host-Host   <--> ISO Session and Transport
ARPA Internet    <--> ISO Network Layer (upper half)
ARPA Subnet      <--> ISO Network Layer (lower half), Link and Physical

So perhaps you are finally coming around to my point of view...

>I also enjoyed your multi-film slide showing very graphically the extra 54
>bytes tcp/ip adds...

Again if you had looked at it carefully you would have noticed that the
figure is 40 bytes, not 54. You may have been confused by the Ethernet
subnet/link level datagram header of 14 bytes which is of course used by all
protocols on Ethernet, not just IP.  You might also reflect on the minimum
Ethernet packet length of 60 bytes. Even a TCP/IP packet must be padded out
to meet this minimum when it carries less than 6 bytes of data. You'll have
a hard time selling your protocols to LAN people on the basis of "low header
overhead".

Even on packet radio, careful analysis shows concern about header overhead
to be unwarranted.  At 1200 baud, it takes only 1/4 second to send 40 bytes.
Many stations spend much more than this just keying up the transmitter.  At
higher speeds, keyup delay will take proportionately more time. For example,
the WA4DSY modem currently requires a keyup delay of 10-13 ms.  At 56kbps,
this is 560-728 bit times, or 70-91 byte times, about twice the TCP/IP
header size.  The coherent version of the demodulator takes 60 ms, or 420
byte times.

In almost every case, "header overhead" is a red herring. It is a factor
*only* in character-at-a-time "echoplex" remote terminal applications over
slow and expensive transmission facilities. Because this has been the Public
Data Networks' traditional business for the past decade, their use of
virtual circuits is at least somewhat understandable.

But if you were truly concerned about overhead in the modern world, you
would concentrate instead on minimizing the number of packets that get sent
when transferring a given amount of information.  You can do this by

1. Migrating from the "remote terminal" application model toward a
"distributed computing" model that makes more effective use of the local
computing power now available at the user's site. PCs and Macs (just to name
two) are capable of better things than running "terminal programs".

2. Using intelligent transmission control algorithms like the "Nagle
algorithm" in TCP to alleviate the network impact of those applications that
insist on writing many small chunks of data.

3. Increasing the maximum physical packet size. This is especially important
with the faster modems.

4. Getting rid of redundant low-level functionality that can only be done
properly on an end-to-end basis anyway. For example, clean up the RF paths
and get rid of link level acknowledgments.  (Note that AX.25 link level acks
involve considerably more overhead than the corresponding X.25 acks since
they carry our 14-byte datagram headers plus transmitter keyup delays).
This is possible only when a powerful end-to-end host-host/transport
protocol like TCP is used, however.

> all I would need to do to use that slide is change the 20's to 3's
> and it would have depicted x.25+x.2xx very well...

Perhaps. Except that you would have to figure out a way to show all of the
complex interactions going on between the (more than 4) layers that control
your multi-level virtual circuit setups and teardowns, indicate your reset
and circuit failure indications, etc. I suspect it would take quite a bit
more than one slide, unless of course you simply sweep it under the rug. And
of course you would still be "comparing apples and oranges where the
criteria is redness and smoothness", to quote Padlipsky.  In other words,
your protocol might well have lower header overhead, but only by sacrificing
the functionality and flexibility of TCP/IP; it would be completely
unsuitable for internetworking between heterogeneous networks.  In sum, your
protocol would be penny-wise but pound-foolish.

>I guess TCP/IP is the protocol of the late 60's/early 70's and the ISO suite
>is the protocol of the late 80's/early 90's...

The initial design of TCP/IP began in 1974 with the paper on packet network
interconnection by Cerf and Kahn.  It became a formal ARPA standard on
January 1, 1983, so I suppose that makes it a "protocol of the 1980s",
whatever that means.

>(global acceptance helps a lot...)

TCP/IP is now supported by literally hundreds of vendors, not all American.
A typical vendor, Sun Microsystems, supports TCP/IP as its "prime language",
and something like 30% of Sun's production is shipped overseas.  Everywhere
I look I read about TCP/IP sites outside the US. I would say that it has
already been "globally accepted".

It'll take a bit more than vague assertions like "ISO is the protocol of the
90s" to convince me and many others to suddenly throw away our working
investments in TCP/IP and switch to "vaporcols" because International Snake
Oil feels like declaring a flag day just for the hell of it.  On the other
hand, if somebody can show me that the move is based on sound technical
considerations instead of pure politics, I'd be happy to change my views.

Phil


 2-Sep-87 19:08:37-EDT,1818;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 2 Sep 87 19:08-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Wed, 2 Sep 87 17:31:18 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Wed, 2 Sep 87 17:31:01 EDT
Received: by june.cs.washington.edu (5.52.1/6.6)
    id AA26289; Wed, 2 Sep 87 14:32:39 PDT
Return-Path: <bellcore!faline![e-mail]>
Message-Id: <[e-mail]>
Date: 27 Aug 87 18:53:18 GMT
From: bellcore!faline![e-mail] (Phil R. Karn)
To: [e-mail]
Subject: Like open systems? Use TCP/IP!
References: <[e-mail]>

> The entire globe needs yet anotehr new protocol like it needs 5 billion
> new holes, one each in the heads of the earth's 5 billion people.

Amen! That's why the OSI stuff is so pointless -- there's already a working,
proven, OPEN collection of protocols known as the ARPA Internet Suite.
OSI doesn't do anything that "TCP/IP" doesn't already do, and in many
cases the existing protocols work better than what OSI promises to do
someday in the far distant future.

If the standards process worked as it's supposed to, ISO would have
taken the existing, proven, de-facto standard ARPA protocols, perhaps
made minor tweaks, and established them as formal standards. Instead
they prefer to build new and deliberately incompatible protocols from
scratch, expect everybody to drop what they have in favor of the new
stuff, and then resort to glitzy hype campaigns and political pressure
when they can't win on the technical merits of their work.

A standards committee is a strange place to do design work.  I prefer
protocols that have evolved and have been proven in constant, everyday
use.

Phil


 3-Sep-87 02:20:05-EDT,1206;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 3 Sep 87 02:20-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Wed, 2 Sep 87 23:01:58 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Wed, 2 Sep 87 23:01:42 EDT
Received: by jade.berkeley.edu (5.54 (CFC 4.23)/1.16.16)
    id AA23314; Wed, 2 Sep 87 20:02:18 PDT
Message-Id: <[e-mail]>
Date: Wed, 2 Sep 1987  22:54:57 EDT
From: [e-mail]    (Len Brady)
Subject: re: (Phil Karn) Like Open Systems?
To: [e-mail]


     Re-inventing the wheel will always be with us so long as there are
those who have never seen a wheel and those who seek to make themselves
glamorous, famous, authoritative, or rich.  You are perfectly correct,
Phil, but it's hard to see a way out.  The profit oriented (see list
above) have lots better public relations machines and (usually) louder
voices than does sweet Reason.
                   73
                      Len <[e-mail]>
                      KF8J @ N8ET (packet address)

 3-Sep-87 02:25:17-EDT,1206;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 3 Sep 87 02:25-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Wed, 2 Sep 87 23:01:58 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Wed, 2 Sep 87 23:01:42 EDT
Received: by jade.berkeley.edu (5.54 (CFC 4.23)/1.16.16)
    id AA23314; Wed, 2 Sep 87 20:02:18 PDT
Message-Id: <[e-mail]>
Date: Wed, 2 Sep 1987  22:54:57 EDT
From: [e-mail]    (Len Brady)
Subject: re: (Phil Karn) Like Open Systems?
To: [e-mail]


     Re-inventing the wheel will always be with us so long as there are
those who have never seen a wheel and those who seek to make themselves
glamorous, famous, authoritative, or rich.  You are perfectly correct,
Phil, but it's hard to see a way out.  The profit oriented (see list
above) have lots better public relations machines and (usually) louder
voices than does sweet Reason.
                   73
                      Len <[e-mail]>
                      KF8J @ N8ET (packet address)

 3-Sep-87 03:45:17-EDT,2154;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 3 Sep 87 03:45-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Thu, 3 Sep 87 00:37:22 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Thu, 3 Sep 87 00:37:06 EDT
Received: by june.cs.washington.edu (5.52.1/6.6)
    id AA06583; Wed, 2 Sep 87 21:38:59 PDT
Return-Path: <husc6!uwvax![e-mail]>
Message-Id: <[e-mail]>
Date: 31 Aug 87 20:43:59 GMT
From: husc6!uwvax![e-mail] (Daniel M. Frank)
To: [e-mail]
Subject: Re: PK-232 Help
References: <[e-mail]>

In article <[e-mail]> [e-mail] writes:
>PROBLEM: I have the PK-232 hooked up to a 2 meter rig right now and it
>seems to receive fine [I haven't tried to transmit yet]. The problem is
>that the first character of each displayed line is deleted.
>
>When I first turn on the PK-232 the sign on message and the CMD: prompt
>appear intact. If I type a request for Display Z [as an example] the
>first line is fine...all lines after that the first character is
>missing. At the end of the Z list the CMD: prompt now appears as MD:.

   This problem may go away if you get a better communications program.
It sounds like the Apple takes a significant amount of time to scroll
the screen, during which incoming characters are lost.  The first line
is fine because it was not received following a line feed.

   I believe the PK-232 has a settable parameter, something like LFNULL,
which allows you to insert a set of nulls or a delay (maybe it's called
LFDELAY?) following a line feed.  This allows the receiving program some
time to do its scrolling stuff before it is sent another printing
character.  Try playing with this parameter; by default the PK-232 has
it set to NO, or 0, or something like that.

   Good luck!

   -- Dan, w9nk
      Dan Frank  (w9nk)
    ARPA: [e-mail]                   ATT: [phone] (home)
    UUCP: ... uwvax!prairie!dan                  [phone] (office)
    SNAILMAIL: 1802 Keyes Ave. Madison, WI 53711-2006


 3-Sep-87 03:52:17-EDT,3501;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 3 Sep 87 03:52-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Thu, 3 Sep 87 00:49:03 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Thu, 3 Sep 87 00:48:37 EDT
Received: by june.cs.washington.edu (5.52.1/6.6)
    id AA06791; Wed, 2 Sep 87 21:50:33 PDT
Return-Path: <winfree![e-mail]>
Message-Id: <[e-mail]>
Date: 27 Aug 87 05:23:58 GMT
From: winfree![e-mail] (Bdale Garbee)
To: [e-mail]
Subject: TCP/IP Intro and Docs on Disk
Reply-To: winfree![e-mail] (Andy Freeborn)

I'm posting this for Andy since he's not yet become a news wizard... replies
to winfree!andy...



            AN INTRODUCTION TO TCP/IP


      Millions of folks have used it in conventional commercial,
      military and government telecommunications applications.
      Few of them ever realized it, or really cared.

      Since the introduction of TCP/IP into the packet radio world
      by Phil Karn, KA9Q, we are hearing it discussed more and
      more frequently. Being the type of folks that Amateurs are,
      they want to know more about it. Unfortunately up until June
      1987 there was little easy-read material available on the
      subject, unless of course, you were a networking engineer,
      designer or writer of networking code.

      In June Mr. Charles Hedrick at Rutgers University wrote a
      paper describing TCP/IP in terms that most of us can
      understand. For those wishing to dig deeper into TCP/IP
      Hedrick makes many references to documents (called RFC's)
      which permit one to explore as far as wanted.

      A package of two diskettes "Introduction to TCP/IP"
      (MSDOS, 360K) is now available. They contain Hedricks paper
      (about 92k) and most of the RFC's he refers to. (as many as
      will fit in compressed format on 2 disks, unARC utility also
      provided).

      To augment the Introduction paper Bdale Garbee, N3EUA, has
      prepared a Preface which introduces the reader to the
      amateur packet radio version of TCP/IP. Bdale is one of the
      writers of code for the packet radio application of TCP/IP.

      In keeping with the Rocky Mountain Packet Radio Association
      charter of providing "information and education in amateur
      digital communications", one of the RMPRA founders is
      providing this service.

      Send:
      Two dollars to cover costs (foreign add appropriate additional
      for foreign mailing costs, 2 oz., IRC ok).

      A mailing label with your address on it.


      To:
      Andy Freeborn N0CCZ
      5222 Borrego Drive
      Colorado Springs  CO
      80918

      DO NOT send mailers, diskettes or postage.
      But  DO  send the completed label.
                                   08/26/87



--
Bdale Garbee, N3EUA             phone: [phone] h, 303/590-2868 w
uucp: {bellcore,crash,hp-lsd,ncc,pitt,usafa,vixie}!winfree!bdale
arpa: [e-mail]
fido: sysop of 128/19           packet: n3eua @ k0hoa, Colorado Springs


 3-Sep-87 04:02:54-EDT,9465;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 3 Sep 87 04:02-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Thu, 3 Sep 87 00:42:14 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Thu, 3 Sep 87 00:40:46 EDT
Received: by june.cs.washington.edu (5.52.1/6.6)
    id AA06616; Wed, 2 Sep 87 21:41:57 PDT
Return-Path: <ll-xn!ames!ptsfa!hoptoad!academ!uhnix1!nuchat!splut![e-mail]>
Message-Id: <[e-mail]>
Date: 30 Aug 87 22:36:14 GMT
From: ll-xn!ames!ptsfa!hoptoad!academ!uhnix1!nuchat!splut![e-mail] (Jay Maynard)
To: [e-mail]
Subject: public access to ham spectrum

Here's John's response to my posting, with my comments added:

(> > = me, > = John Gilmore)
> > There's no real reason yu can't innovate in ham radio, either. If you want
> > to experiment, go right ahead - and, as long as you don't cause a real
> > interference problem, nobody will stop you. If you want to do something that
> > might cause interference, but it's a technical advance, the mechanism is
> > there - and the FCC is liberal in granting STAs to reasonable requests.
>
> What I wanted to do was send computer data through the airwaves.  Funny,
> a bunch of people wanted to stop me.  I wasn't planning to interfere with
> anybody, but for some reason they wanted me to learn morse code and apply
> to the government for "permission".

>From your comments, I suspect strongly that you wanted to provide an
unlimited bridge between computer networks and the packet network. There are
real problems with that approach, and amateur radio is not the appropriate
place to set up a common carrier.

Learning the code and applying to the government for a ticket are
responsibilities that go along with the privilege of reasonably unfettered
access to the radio spectrum. There's exactly one radio service that
requires no license of any kind to operate. Have you listened on 27
megahertz lately?

> We are just coming from opposite points of view; you obviously can't see
> how the requirement for a ham ticket is a limitation on innovation.  Just
> like a curb is no problem for somebody in a wheelchair; if they really
> want to get up that curb, they sure can.

This analogy is fatally flawed: it's not like a curb for someone in a
wheelchair, but it's the wheelchair itself for a paraplegic. Without the
ticket, you can't legally get on and experiment, just like a paraplegic
can't get around (easily) without a wheelchair.

The requirement for a license is written in the Communications Act of 1934.
If you dislike it that much, write your Congressmen - but don't expect to
get very far.

> > There IS a problem with letting the world flow data on an amateur link:
> > Amateur radio is a non-commercial service. Hams can use cheaper equipment,
> > more frequencies, and higher power than their commercial counterparts. If
> > the entire world was permitted to use the packet network to pass any data
> > they wished, what would stop GTE from having its employees get ham licenses
> > and use the packet network as part of Telenet?
>
> Good question.  Except if anybody could use the packet network to pass any
> data they wished, why would we need GTE?

Are you out to put GTE out of business? Good luck....the FCC won't sit still
for that.

> You mention another problem with ham radio as a means for computer data
> sharing -- its "non-commercial" orientation.  I got the impression that if
> I logged into my employer's machine and did some work via packet radio,
> some of the "mickey mouse" rulewatchers would "try to stop me" again.
> What good is it to build a network if you can't use it for any real work?

Because ham radio is a hobby. Pure and simple. That has been built into the
very bedrock of the service, from its earliest origins. Using the packet
network to log on to your employer's machine puts the packet network in
direct competition with the common carriers, and that's illegal and unfair
competition.

> > ) [They claim to be practicing for providing emergency communications
> > ) service.  However, if the public was permitted to use the airwaves for
> > ) REGULAR communications service, then no EMERGENCY service would be
> > ) needed, since the regular service would continue to work in
> > ) emergencies.
> > I've addressed this one before, but I'll repeat myself: Public service
> > agency communications are fine for the normal case. When all hell breaks
> > loose, though, their channels fill up rapidly and become unusable. Who do
> > they turn to for their enhanced communications needs? Hams.
>
> I wasn't talking about public service agencies using the airwaves.
> I was talking about THE PUBLIC using the airwaves.  Certainly in a disaster
> all the phones fill up, all the CB's fill up, all the hams get on the air,
> everything gets busier.  A well designed public radio network would have
> provisions for dealing with high congestion -- the same as the phone
> company does, or the military phone systems do.  The cellular phone systems
> also have provisions like this.

Public radio networks, no matter how well designed, will fill to unusability
during a disaster...or, again, have you listened to 27 megahertz? The public
using the airwaves leads inevitably to anarchy and uselessness in times of
stress. The phone company doesn't do all that well a job in preparing for
heavy network loading during a disaster; have you tried to call into, or
even out of, a disaster area? I have. It's no picnic - in fact, most of the
time it's downright impossible.

This is a nice, motherhood-and-apple-pie argument - but it simply will not
work.

> > The proposal was very badly thought out. It would have given wide-ranging
> > radio privileges to someone based on a simple written test, and did not even
> > try to see that they had the minimal technical knowledge to operate their
> > equipment within the bounds of the rules.
>
> I challenge you to find a group of 50 hams where at least 25 of them could
> tell if their equipment was operating within the rules or not.  Most people
> go for the "study for the test then forget it" approach.  And few of them
> have the equipment to verify correct operation anyway, e.g. spectrum
> analyzers.

I don't know about the hams in Southern California, but I'll pick any ham
club in the Houston area, and let you run that test. You'd lose big. By far
and away most hams I know take great pride in emitting a clean signal and
following the rules.

> > The Morse Code objection is a red herring. Anyone can, with a minimal amount
> > of study, learn the code. Are you trying to suggest that computer types
> > aren't intelligent enough to do so?
>
> I've heard this one before, it's not my experience, and I reject the
> implication that anyone who doesn't want to waste their time on Morse
> is unintelligent.

I wasn't trying to imply that they were. I was asking if you were implying
they weren't. I repeat my earlier contention: ANYONE can learn the code. All
it takes is a minimal amount of time and work.

Your whole argument is that anyone should be able to get a ham license,
thereby earning the privilege of access to some of the choicest spectrum
available, without having to work for it. Then they should be able to use
these new privileges to bypass the telephone and other common carrier
networks and do whatever they wish.

Why? Why should a network of volunteer ham radio operators try to compete
with commercial interests? Worse, why should hams allow these commercial
interests to take over our spectrum, with all the impact on the public
interest that that entails? Hams have a long and shining history of public
service. Does GTE Telenet? Would they suddenly get the desire to unselfishly
serve the public by going out and passing a written test only?

I suggest instead that allowing commercial use of amateur spectrum would
result in the death of any public service that the amateur service provides.
That service is the ONLY reason we still have the wide range of frequencies
that we do. That is what is remembered by the delegates to the World
Administrative Radio Conferences. Commercial interests have no reason to
unselfishly pursue the public welfare. Amateurs do.

I take more pride in the fact that I use my radio expertise to advance the
public welfare than in the fact that I hold an Extra class license. The look
on a motorist's face as I stand there and call an ambulance with my handheld
is worth all the work I had to do to get there. Public service is highly
rewarding - but not in the only way that interests a commercial entity:
money. Therefore, why should they do it?

(Apologies to comp.dcom.modems readers; I haven't seen John respond to any
of the comments on this subject posted on rec.ham-radio.packet, so I
crossposted to make sure John could read it and respond. Replies have been
directed to rec.ham-radio.packet [I think].)
--
Jay Maynard, K5ZC...>splut!< | uucp: hoptoad!academ!uhnix1!nuchat!splut!jay
"Don't ask ME about Unix...  | (or sun!housun!nuchat)       CI$: 71036,1603
I speak SNA!"                | internet: beats me         GEnie: JAYMAYNARD
The opinions herein are shared by neither of my cats, much less anyone else.


 3-Sep-87 12:55:54-EDT,2539;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 3 Sep 87 12:55-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Thu, 3 Sep 87 10:40:25 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Thu, 3 Sep 87 10:40:06 EDT
Received: by umix.cc.umich.edu (5.54/umix-2.0)
    id AA07333; Thu, 3 Sep 87 08:59:44 EDT
Received: from SFU.Mailnet by um.cc.umich.edu via MTS-Net; Thu, 3 Sep 87 05:00:39 EDT
Date: Wed, 2 Sep 87 17:58:38 PDT
From: [e-mail]
To: [e-mail]
Message-Id: <[e-mail]>
Subject: TCP as an "Open Systems Protocol".

re: TCP as an "Open Systems Protocol".

     Phil, please get down off your high horse.  The DOD protocol suite is a
defacto standard *only* in the United States.  It's true that it can be
found in some other parts of the world.  Outside of the U.S., though, it's
used mainly as a stop-gap measure until other internationally recognised
protocols are developed.  This is especially true in Western Europe, where
the governments are making it very difficult for institutions to use non-ISO
recognised protocols.

     I agree that some of these international protocols have not yet
addressed many of the problems that have already been solved in the DOD
protocol community.  That doesn't mean they won't eventually be solved, and
wouldn't you rather see Amateur Radio play a part in helping to develop the
next generation of protocols, rather than merely copy existing work?  While
I admit that this will not happen overnight, and the use of DOD protocols
will expand somewhat for a few years yet, the writing is on the wall: If you
want to be able to communicate with the rest of the world well into the
future, be prepared to go with the international standards.  If you want to
use the DOD suite in the meantime, that is perfectly reasonable, but plan on
being somewhere else in two-to-five years.

     (Please understand where I'm coming from.  I work at a university that
is currently in the process of building a rather extensive campus-wide
network.  We're going to support TCP/IP and friends in the short term (as
well as the international standards that already exist), but we will install
OSI products just as soon as they are available.  And you can't tell me that
*all* of the international standard protocols are unusable even now - we've
had a local 800+ terminal/host X.25 network running for the last five
years.)
 3-Sep-87 16:18:41-EDT,1503;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 3 Sep 87 16:18-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Thu, 3 Sep 87 13:54:41 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Thu, 3 Sep 87 13:54:22 EDT
Received: by june.cs.washington.edu (5.52.1/6.6)
    id AA05149; Thu, 3 Sep 87 10:56:19 PDT
Return-Path: <winfree![e-mail]>
Message-Id: <[e-mail]>
Date: 1 Sep 87 14:17:19 GMT
From: winfree![e-mail] (Bdale Garbee)
To: [e-mail]
Subject: Re: Doubledos vs. DOS 3.2.
References: <[e-mail]>

In article <[e-mail]> [e-mail] (Karl Georg Schjetne) writes:
>Some days ago I put DOS 3.2 on the PC  -  DDOS does not work any more!
>
>DDOS starts OK, but the system deadlocks imediately after startup  -  before
>the BBS gets any opportunity to do any work!

>    -  My version of DDOS is (3.2) V.

To run under dos 3.2, you need at least v4.0 of doubledos.  Call the folks
that wrote it, they'll give you an updated version for a reasonable upgrade
cost... also, the program appears to no longer have any copy-protection in
it...
--
Bdale Garbee, N3EUA             phone: [phone] h, 303/590-2868 w
uucp: {bellcore,crash,hp-lsd,ncc,pitt,usafa,vixie}!winfree!bdale
arpa: [e-mail]
fido: sysop of 128/19           packet: n3eua @ k0hoa, Colorado Springs


 3-Sep-87 16:28:58-EDT,1043;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 3 Sep 87 16:28-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Thu, 3 Sep 87 12:15:06 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Thu, 3 Sep 87 12:14:00 EDT
Received: from Riesling.ms by ArpaGateway.ms ; 03 SEP 87 09:15:47 PDT
Sender: "Ferris_D._Jennings.osbunorth"@Xerox.COM
Date: 3 Sep 87 09:15:12 PDT (Thursday)
Subject: Thanks for PK-232 help.
From: [e-mail]
To: [e-mail]
Cc: [e-mail]
Message-Id: <870903-091547-9746@Xerox>


Just wanted to say thanks to all those who responded to my request for
help with my PK-232 problem.

It was a timing problem alright, and way back on page 221 of the manual
I found an explanation of the NULF command. Default was 0, I changed it
to 1 and the problem went away.

Its nice to have such a knowledgable resource [this net] at my
fingertips...thanks again.

73,
Ferris NB6T


 3-Sep-87 16:44:25-EDT,8102;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 3 Sep 87 16:44-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Thu, 3 Sep 87 14:13:11 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Thu, 3 Sep 87 14:12:28 EDT
Received: by june.cs.washington.edu (5.52.1/6.6)
    id AA05866; Thu, 3 Sep 87 11:14:26 PDT
Return-Path: <winfree![e-mail]>
Message-Id: <[e-mail]>
Date: 2 Sep 87 14:09:14 GMT
From: winfree![e-mail] (Bdale Garbee)
To: [e-mail]
Subject: New release of KA9Q Internet Package

Announcing an update to the KA9Q TCP/IP software package release of 870526.0,
bringing the current release date up to 870829.0.  This update adds fixes bugs,
and adds some minor functionality.  A new release will occur in a couple of
weeks with support for 4bsd and sysV unix machines, this version still supports
only the PC and PC clone class of machines.

The changes:
    - Improved KISS bits for the TNC1 from Gerard, PA0GRI.

    - the ASCII text at the top of one of the TNC2 hex files is gone now.

    - Minor tweaks to BM from Gerard, PA0GRI, Phil KA9Q, and yours truly.
      Biggest noticeable differences are that BM no longer looks at the
      hosts.net file at all, but instead passes symbolic hostnames to
      the smtp client in net... and we once again changed the text entry
      code.  It's more like bsd Mail now.  Default is a silly text entry
      routine, a "~e" gets you into your favorite editor, and a "~p"
      shows what you've typed so far.

    - NET.EXE understanding of symbolic hostnames ala the hosts.net file
      has been extended.  You now need to wrap numeric IP addresses in
      square brackets, as in "[44.32.0.16]", as you can use symbolic names
      anywhere you need to use an IP address (including in the autoexec.net
      file!)

    - Since BM no longer deals with IP addresses, a "gateway" command has
      been added to NET.EXE, so that it knows where to send mail that
      fails the lookup in hosts.net.

    - Internal changes and a fix to the ftp server so that it now handles
      NLST command properly, all from Phil, KA9Q.  Bugs that were in the
      870526.5 interim release that was only distributed in a limited
      fashion apparently disappeared with the latest tweaks...

    - documentation has (as usual) been updated somewhat.

    - some other random tweaks I'm sure I've forgotten...

What to do once you have software, aka "getting an IP address":

    Users of this software package become part of the "global IP
    internet", and as such need to obtain unique IP address assignments
    for each host they plan to put on the air, or "on the wire".  Major
    metropolitan areas in the US, and countries with active TCP-using
    groups probably already have blocks of addresses in amateur radio
    44.X.X.X block assigned to them.  Ask around locally before you go
    any further.

    If there is no local address block in your area, and/or noone is
    coordinating address assignments for your local net, contact Wally
    Linstruth WA6JPR.  Wally is the global top-level address administrator
    for the ham radio 44.X.X.X subnet.  Wally may be reached by email at

        [e-mail]
    or      [e-mail]
    or      ...!sdcsvax!net1!wally

    or via the new forwarding mechanism I have set up for those sites who
    know how to reply via mail to this message, but can't reach Wally's
    machine directly:

        winfree!wally   -or-   [e-mail]
    or      [e-mail]

How to obtain the KA9Q Internet software:

-       Via uucp, the files are on winfree in tar archives as:

      /usr/spool/uucppublic/pub/ka9q_all.tar.Z      16 bit Compress 4.0
      /usr/spool/uucppublic/pub/ka9q_all.t12.Z      12 bit Compress 4.0

    For Anonymous UUCP login, use phone number 303/593-0696, at 2400
    baud (it will do 1200 if you send a return to rotate it down),
    "standard Unix login sequence", username of "Uanon", password of
    "notFTP".  An example L.sys entry ala winfree's uucp would be:

        winfree Any ACU 2400 13035930696 ogin: Uanon word: notFTP

    I've never run an anonymous login for uucp before, so let me know
    if I got it wrong!

    A reasonable command to issue to pick up the 12-bit distribution
    would be

        uucp winfree!~/pub/ka9q_all.t12.Z /usr/spool/uucppublic


-       ***** My BBS is currently down with a dead hard drive.  If anyone
    ***** has a spare drive they would be willing to donate to the cause,
    ***** *please* get in touch with me ASAP!  Cashflow around here is
    ***** a joke... :-(   Normally,

    Via Opus, log in to my BBS and download from the appropriate files
    area.  There are several .ARC files for the full distribution, one
    for each of the directories.  SeaDog file requests are ok.

    I have configured my BBS to allow first time users ample resources to
    download the full distribtuion at 1200 baud.  The phone number is
    303/593-0766.

    If you have any trouble downloading from the BBS, please let me know.
    Speeds that are supported include 300, 1200, and 2400.

-       Via US Snail, Andy Freeborn N0CCZ has agreed to make floppy copies.
    To get a copy from him, send $5 AND a completed return address mailing
    label (orders without a mailing label will be considered
    contributions to the BBS hard drive fund, see above... :-) to:

        Andy Freeborn, N0CCZ
        5222 Borrego Drive
        Colorado Springs, CO  80918
        USA

    What you get for the $5:  5 floppies, including two of RFC's and IEN's
    that relate to the code, two that include the actual release, and one
    that is intended to be a sort of "plug and play" disk for getting on
    the air immediately...

    For those who just want the RFC/IEN disks, Andy will send you just
    those two disks for $2 and a mailing label.  If you want any particular
    RFC or IEN, contact Andy to find out what archive it is in (we have
    them all packed up, one ARC per 360k pc disk), and he will send you
    that RFC or IEN, along with many others, on a floppy for $1/disk.  You
    can't mix and match, you get the block of documents that are in a
    given archive.

    DO NOT SEND floppies, mailers, postage, etc... but DO send the mailing
    label!

    Andy is also reachable as
        winfree!andy or [e-mail]
    if you need more information (?).  Andy is within an on-air FTP of
    me, so we should be able to keep his bits up to date!

-       on the ARPAnet, or attached portions of the Internet, look on
        louie.udel.edu
    via anonymous FTP for the files in the directory
        pub/ka9q

-       Within a day or two of a new release, the code should also be available
    from the following additional secondary distribution points:

        from Doug KD4NC in Atlanta, GA
            uucp: winfree!kd4nc!dug
        from Bob Hoffman N3CVL in Pittsburgh, PA
            arpa: [e-mail]
            uucp: pitt!hoffman
        from Wally Linstrugh WA6JPR in Santa Barbara, CA
            arpa: [e-mail]
        from Brian Kantor at UCSD.  (via anonymous FTP?)
            arpa: [e-mail]
            uucp: sdcsvax!tcp-group-request

    Unreleased (read: under development) versions are often available
    on louie.udel.edu, generally alongside official releases...
    caveat emptor...

If anyone has any trouble getting hold of a copy of the code, please let me
know!

How to contact me:

    Bdale Garbee, N3EUA
    1433 Territory Trail
    Colorado Springs, CO  80919
    303/590-2868w, 303/593-9828h

    *** go easy on the phone calls please, I'm not getting much sleep! ***

uucp: {bellcore,crash,hp-lsd,ncc,pitt,vixie}!winfree!bdale
arpa: [e-mail]
      [e-mail]
fido: Bdale Garbee at 128/19, 303/593-0766, 300/1200/2400 baud, 24hrs (*DOWN*)
packet: n3eua @ k0hoa
--
Bdale Garbee, N3EUA             phone: [phone] h, 303/590-2868 w
uucp: {bellcore,crash,hp-lsd,ncc,pitt,usafa,vixie}!winfree!bdale
arpa: [e-mail]
fido: sysop of 128/19           packet: n3eua @ k0hoa, Colorado Springs


 3-Sep-87 18:24:54-EDT,1135;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 3 Sep 87 18:24-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Thu, 3 Sep 87 16:53:39 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Thu, 3 Sep 87 16:53:21 EDT
Received: from adam.dg.com by RELAY.CS.NET id aa14082; 3 Sep 87 15:58 EDT
Received: by adam.DG.COM; Thu, 3 Sep 87 15:54:34 edt
Return-Path: <PODSIADLO~[e-mail]>
Received: from WDS by adam.DG.COM with CEO; Thu, 3 Sep 87 15:52:08 EDT
Date: Thu, 3 Sep 87 15:43:14 EDT
From: PODSIADLO~[e-mail]
Message-Id: <[e-mail]>
To: [e-mail]
Subject: csnet email

I CAN NOT RETRIEVE AND EXTRACT FILES FROM THE MSDOS ARCHIVES ON
SIMTEL20. WHEN I 'ARC' THEM, THE FILENAMES ARE GARBAGE AND FILE SIZES
ARE UNREALISTIC. SEEMS LIKE OTHERS SHARE MY GRIEF. CAN SOMEONE PLEASE
ENLIGHTEN ME! I AM DRAGGING THE ARCHIVES TO MY PC VIA A DG MV
MACHINE, BUT OTHERS HAVE PROBLEMS WITH VAX'S. HELP!!
Jim Podsiadlo AE1C [phone] W........tnx es 73's>>
 4-Sep-87 14:54:39-EDT,1487;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 4 Sep 87 14:54-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Fri, 4 Sep 87 13:15:10 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Fri, 4 Sep 87 13:14:55 EDT
Received: by june.cs.washington.edu (5.52.1/6.6)
    id AA28461; Fri, 4 Sep 87 10:16:50 PDT
Return-Path: <uunet!epiwrl!chemo![e-mail]>
Message-Id: <[e-mail]>
Date: 3 Sep 87 22:17:11 GMT
From: uunet!epiwrl!chemo![e-mail] (Brian J. McGinness)
To: [e-mail]
Subject: AX25L2 file transfer problems

I just set up a packet station using an AX25L2 box called a PK-87
by AEA. The software I am using is called YAPP version 2.00 BY
WA7MBL. My problem is that I seem to be able to send binary files
OK but I can't receive them. Activity is so lean on the freq I am using
that I can only talk to a couple others so I don't have a lot of others
to try with. It seems that there are too many outstanding sliding
packets unacknowledged that the sending PC aborts the transfer. Any what of using
your old reliable xmodem or other terminal program? The book says use whatever
you use over the wireline modem but I can't seem to get Crosstalk's file
transfer to work. Any comments would be appreciated. Please EMAIL to:

 chemo![e-mail]   Internet
 uunet!epiwrl!chemo!brian  UUCP

73, Brian WA3WJD


 4-Sep-87 14:57:21-EDT,1944;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 4 Sep 87 14:57-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Fri, 4 Sep 87 13:11:52 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Fri, 4 Sep 87 13:11:39 EDT
Received: by june.cs.washington.edu (5.52.1/6.6)
    id AA28327; Fri, 4 Sep 87 10:13:43 PDT
Return-Path: <rutgers!princeton!idacrd![e-mail]>
Message-Id: <[e-mail]>
Date: 4 Sep 87 08:19:53 GMT
From: rutgers!princeton!idacrd![e-mail] (Bob McGwier)
To: [e-mail]
Subject: Re: TCP as an "Open Systems Protocol".
References: <[e-mail]>

in article <[e-mail]>, [e-mail] says:
>
> re: TCP as an "Open Systems Protocol".
>
>      Phil, please get down off your high horse.  The DOD protocol suite is a
> defacto standard *only* in the United States.  It's true that it can be
>      (Please understand where I'm coming from.  I work at a university that
> is currently in the process of building a rather extensive campus-wide
> network.  We're going to support TCP/IP and friends in the short term (as
> well as the international standards that already exist), but we will install
> OSI products just as soon as they are available.  And you can't tell me that
> *all* of the international standard protocols are unusable even now - we've
> had a local 800+ terminal/host X.25 network running for the last five
> years.)

Tell us what progress has been made and what new system features and
what type internetting you can do from your 800+ terminal net.  I am
kinda sick of this West European version of "Not Invented Here".
International Standards ?  What networking protocol is used most
worldwide?  Further, nothing could appall me more than Network design in
standards committees.

Bob


 4-Sep-87 18:38:50-EDT,2708;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 4 Sep 87 18:38-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Fri, 4 Sep 87 17:15:58 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Fri, 4 Sep 87 17:15:34 EDT
Received: from chem.Span by VLSI.JPL.NASA.GOV with VMSmail ;
    Fri, 4 Sep 87 14:01:22 PDT
Date:    Fri, 4 Sep 87 14:01:22 PDT
From: [e-mail]
Message-Id: <[e-mail]>
Subject: YAPP PACKET system
To: [e-mail]
X-St-Vmsmail-To: JPLLSI::"[e-mail]"

Brian J. McGinness writes:

>I just set up a packet station using an AX25L2 box called a PK-87
>by AEA. The software I am using is called YAPP version 2.00 BY
>WA7MBL. My problem is that I seem to be able to send binary files
>OK but I can't receive them.

Is the other station also using YAPP? What does the protocol say when you
transmit the file?  What does the protocol say when you receive a file?
What TNC is the other station using and what PC? Jeff, WA7MBL, lives here
in Logan and he and I use YAPP all of the time for testing and development.
I have a TNC-2 and he has a PK-87 and PK-232. BTW YAPP does not work with
any of the KANTRONICS units that we know of. The only TNC's that we know
it works well with are the TNC-2's or completely compatible clones like the
PK-87. Have you tried to access an MBL BBS (Version 3.12 or above) and
attempted a YAPP transfer? That may help to debug the problem.

> Any what of using your old reliable xmodem or other terminal program?
> The book says use whatever you use over the wireline modem but I can't
> seem to get Crosstalk's file transfer to work.

      Xmodem and KERMIT will work on PACKET if the TNC doesn't trash the
control characters during receive or transmit. KERMIT uses standard ASCII
printabel characters plus one control character (^A). XMODEM requires the
use of all 256 combinations of an 8 bit word. You would have to be in
TRANSPARENT mode to use XMODEM or the CROSSTALK protocol. The main
advantage to YAPP is that there is NO checksumming or CRC checking to add
to the overhead. It runs about 20% faster than XMODEM and 100% faster than
KERMIT. YAPP uses the fact that PACKET already HAS error checking built in
and does not require addtional checks. You can always convert the binary
files to HEX with BSQ or HEXIFY and send them as ASCII text but the
overhead is terrible (at least double the file size). Please feel free to
ask further questions on YAPP. I cannot answer you direct, my GATEWAY
doesn't accept your address as valid.
73, Bob

 4-Sep-87 23:30:58-EDT,1652;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 4 Sep 87 23:30-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Fri, 4 Sep 87 22:24:37 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Fri, 4 Sep 87 22:24:04 EDT
Received: by june.cs.washington.edu (5.52.1/6.6)
    id AA11337; Fri, 4 Sep 87 19:25:55 PDT
Return-Path: <rutgers!uwvax!ncc![e-mail]>
Message-Id: <[e-mail]>
Date: 4 Sep 87 21:11:43 GMT
From: rutgers!uwvax!ncc![e-mail] (Lyndon Nerenberg)
To: [e-mail]
Subject: Re: New release of KA9Q Internet Package
Summary: Don't call ncc for this *yet*
References: <[e-mail]>

In article <[e-mail]>, [e-mail] (Bdale Garbee) writes:
>Announcing an update to the KA9Q TCP/IP software package release of 870526.0,
>bringing the current release date up to 870829.0.  This update adds fixes bugs,
>and adds some minor functionality.  A new release will occur in a couple of
>weeks with support for 4bsd and sysV unix machines, this version still supports
>only the PC and PC clone class of machines.

Just before everyone runs out to download this from ncc...

I will *not* be bringing down 870829.0. Instead I am waiting for the
next release with the UNIX support as this is the environment I'm
building "APSSNet" on (a Convergent MightyFrame). If anyone else plans
on working with this under System V please let me know so we can share
war stories.

I will post an announcement once the new version is available from ncc.

--lyndon  VE6BBM


 7-Sep-87 23:55:28-EDT,1078;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 7 Sep 87 23:55-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Mon, 7 Sep 87 22:28:35 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Mon, 7 Sep 87 22:28:18 EDT
Date: Mon, 7 Sep 1987  11:38 MDT
Message-Id: <[e-mail]>
Sender: [e-mail]
From: Keith Petersen <[e-mail]>
To: [e-mail]
Cc: [e-mail]
Subject: Displaying weather fax on IBM-PC and clones

Some time ago there was an inquiry about a program that was described
in August 85 QST for using the IBM-PC and clones to display weather fax
transmissions.  The program is now available to Arpa/Milnet readers
who have FTP access to SIMTEL20.  Others may get the file from GEnie's
IBM RoundTable.

Filename                        Type     Bytes   CRC

Directory PD:<MSDOS.HAMRADIO>
WEFAX.ARC.1                     BINARY   35968  0CECH

No documentation is included in the ARC.  See August 1985 QST
magazine.

73,
--Keith
 8-Sep-87 00:22:10-EDT,1078;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 8 Sep 87 00:22-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Mon, 7 Sep 87 22:28:35 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Mon, 7 Sep 87 22:28:18 EDT
Date: Mon, 7 Sep 1987  11:38 MDT
Message-Id: <[e-mail]>
Sender: [e-mail]
From: Keith Petersen <[e-mail]>
To: [e-mail]
Cc: [e-mail]
Subject: Displaying weather fax on IBM-PC and clones

Some time ago there was an inquiry about a program that was described
in August 85 QST for using the IBM-PC and clones to display weather fax
transmissions.  The program is now available to Arpa/Milnet readers
who have FTP access to SIMTEL20.  Others may get the file from GEnie's
IBM RoundTable.

Filename                        Type     Bytes   CRC

Directory PD:<MSDOS.HAMRADIO>
WEFAX.ARC.1                     BINARY   35968  0CECH

No documentation is included in the ARC.  See August 1985 QST
magazine.

73,
--Keith
 8-Sep-87 13:16:47-EDT,1793;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 8 Sep 87 13:16-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Tue, 8 Sep 87 11:57:07 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Tue, 8 Sep 87 11:56:54 EDT
Received: by leg.ai.mit.edu; Tue, 8 Sep 87 11:52:51 EDT
Date: Tue, 8 Sep 87 11:52:51 EDT
From: [e-mail] (Michael Chepponis)
Message-Id: <[e-mail]>
To: [e-mail]
Cc: [e-mail]
Subject: New TCP/IP newsletter

This may be of interest.  It is from the September 1987 IEEE Spectrum, p 57:

            "TCP/IP Newsletter

The U.S. Defense Data Network protocol suite, known as TCP/IP, is currently
the only one for interoperability over diverse communications networks
between heterogeneous computer systems from different vendors.  A new monthly
newsletter `ConneXions - The Interoperability Report,' features tutorials,
articles, and interviews covering a variety of topics related to TCP/IP and
networking.  The annual subscription rate is $360 in the U.S. and Canada
($240 for universities).  In other countries, the rate is $50 higher.
Contact: ConneXions, 21370 Val Ave., Cupertino, Calif. 95014; 408/996-2042."



I have no pecuniary interest in ConneXions, have never seen this newsletter,
and have provided the above for information purposes only.  And although this
newsletter is for the entire TCP/IP community (that is, not specifically
aimed at TCP/IP within the ham world), it is still probably apropos.

-Mike k3mc


I especially like the part "TCP/IP is currently the only one for
interoperability over diverse communications networks...

For Amateur Radio, use TCP/IP: The Right Choice!
 8-Sep-87 14:18:25-EDT,1793;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 8 Sep 87 14:18-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Tue, 8 Sep 87 11:57:07 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Tue, 8 Sep 87 11:56:54 EDT
Received: by leg.ai.mit.edu; Tue, 8 Sep 87 11:52:51 EDT
Date: Tue, 8 Sep 87 11:52:51 EDT
From: [e-mail] (Michael Chepponis)
Message-Id: <[e-mail]>
To: [e-mail]
Cc: [e-mail]
Subject: New TCP/IP newsletter

This may be of interest.  It is from the September 1987 IEEE Spectrum, p 57:

            "TCP/IP Newsletter

The U.S. Defense Data Network protocol suite, known as TCP/IP, is currently
the only one for interoperability over diverse communications networks
between heterogeneous computer systems from different vendors.  A new monthly
newsletter `ConneXions - The Interoperability Report,' features tutorials,
articles, and interviews covering a variety of topics related to TCP/IP and
networking.  The annual subscription rate is $360 in the U.S. and Canada
($240 for universities).  In other countries, the rate is $50 higher.
Contact: ConneXions, 21370 Val Ave., Cupertino, Calif. 95014; 408/996-2042."



I have no pecuniary interest in ConneXions, have never seen this newsletter,
and have provided the above for information purposes only.  And although this
newsletter is for the entire TCP/IP community (that is, not specifically
aimed at TCP/IP within the ham world), it is still probably apropos.

-Mike k3mc


I especially like the part "TCP/IP is currently the only one for
interoperability over diverse communications networks...

For Amateur Radio, use TCP/IP: The Right Choice!
 8-Sep-87 19:07:14-EDT,1229;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 8 Sep 87 19:07-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Tue, 8 Sep 87 17:00:52 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Tue, 8 Sep 87 17:00:31 EDT
Received: by faline.bellcore.com (4.12/4.7)
    id AA23618; Tue, 8 Sep 87 16:46:54 edt
Date: Tue, 8 Sep 87 16:46:54 edt
From: [e-mail] (Phil R. Karn)
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re:  New TCP/IP newsletter
Cc: [e-mail]

Yes, I am on the subscription list for this newsletter. I've even had an
article in it -- a reprint of a flame I posted on [e-mail]
about the GOSIP (Government Open Systems Interconnection Procurement
specification) that made Michael Padlipsky proud.

This newsletter is published by Dan Lynch's company, the same group that
has put on the two highly successful TCP/IP conferences in Monterey that
I've attended, one August a year ago and a second last March.  The
newsletter is worth reading, but then again I get it free -- the
"regular" subscription price is awfully steep.

Phil
 8-Sep-87 23:18:34-EDT,3570;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 8 Sep 87 23:18-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Tue, 8 Sep 87 21:40:46 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Tue, 8 Sep 87 21:40:30 EDT
Received: by umix.cc.umich.edu (5.54/umix-2.0)
    id AA10929; Tue, 8 Sep 87 21:43:05 EDT
Received: from SFU.Mailnet by um.cc.umich.edu via MTS-Net; Tue, 8 Sep 87 19:42:19 EDT
Date: Tue, 8 Sep 87 14:56:12 PDT
From: [e-mail]
To: [e-mail]
Message-Id: <[e-mail]>
Subject: re: TCP as an "Open Systems Protocol".

re: TCP as an "Open Systems Protocol".

> Tell us what progress has been made and what new system features and
> what type internetting you can do from your 800+ terminal net....


     The network that we are currently running supports X.25 connections
into an IBM host running the Michigan Terminal System.  Terminals are
supported using a "non-standard" Virtual Terminal Protocol (since the VTP
standard has not yet been defined), with "full screen" terminal support in a
record oriented (rather than character-at-a-time) environment.  Ethernet and
HDLC links (of up to 600 kbps) are used to interconnect the "PADs" and the
packet switching nodes.  Our PADs give conversation buffering, multiple
concurrent sessions, and support the VTP for full screen access.  These
facilities are also available for use across Datapac at the other sites that
currently support this VTP.  File transfer is currently supported using
another temporary home-grown protocol, but will eventually move to ISO-TP4.
Access to the rest of the world is via X.25 and "triple-X" connections to
the "world standard" X.25 networks.  Unlike the Internet, which is limited
to the U.S.  and a very few selected foreign sites, the X.25 networks give
access to virtually everywhere, *including* the U.S.

     Note that I've never claimed that ISO/OSI is technically better.
Unfortunately, that's not the issue here.  You can dismiss the political
situation if you want to, but it's politics that drive the world, not
technical solutions.  The ISO/OSI boat may be a little leaky yet (the keel's
in place, but a lot of planks are still missing), but its got a full head of
steam and will replace the DOD protocol networks over a course of years.
That shouldn't stop use from using TCP/IP and friends in the short term, but
we shouldn't ignore where the world is going - again, *including* the U.S.
(Or haven't you seen GOSIP?  Another political decision that will eventually
cause the DOD protocols to be displaced.)

     Also, please be careful with the "Not-Invented-Here" paint can.  The
same brush could be used against dyed-in-the-wool Internetters....  I happen
to believe that it would be better to use slightly inferior protocols if
necessary (I'm not saying that ISO/OSI is inferior, though) as long as you
can get *everybody* talking the same protocols.  Since there is a large
portion of the world that has already started on a course that is leading
towards real interconnection, we really can't ignore them just because we
don't like their politics.

                - Richard Chycoski, VE7CVS
                  Systems Consultant,
                  Communications Development Group,
                  Simon Fraser University
                  Computing Services Department.
 8-Sep-87 23:19:26-EDT,3570;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 8 Sep 87 23:19-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Tue, 8 Sep 87 21:40:46 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Tue, 8 Sep 87 21:40:30 EDT
Received: by umix.cc.umich.edu (5.54/umix-2.0)
    id AA10929; Tue, 8 Sep 87 21:43:05 EDT
Received: from SFU.Mailnet by um.cc.umich.edu via MTS-Net; Tue, 8 Sep 87 19:42:19 EDT
Date: Tue, 8 Sep 87 14:56:12 PDT
From: [e-mail]
To: [e-mail]
Message-Id: <[e-mail]>
Subject: re: TCP as an "Open Systems Protocol".

re: TCP as an "Open Systems Protocol".

> Tell us what progress has been made and what new system features and
> what type internetting you can do from your 800+ terminal net....


     The network that we are currently running supports X.25 connections
into an IBM host running the Michigan Terminal System.  Terminals are
supported using a "non-standard" Virtual Terminal Protocol (since the VTP
standard has not yet been defined), with "full screen" terminal support in a
record oriented (rather than character-at-a-time) environment.  Ethernet and
HDLC links (of up to 600 kbps) are used to interconnect the "PADs" and the
packet switching nodes.  Our PADs give conversation buffering, multiple
concurrent sessions, and support the VTP for full screen access.  These
facilities are also available for use across Datapac at the other sites that
currently support this VTP.  File transfer is currently supported using
another temporary home-grown protocol, but will eventually move to ISO-TP4.
Access to the rest of the world is via X.25 and "triple-X" connections to
the "world standard" X.25 networks.  Unlike the Internet, which is limited
to the U.S.  and a very few selected foreign sites, the X.25 networks give
access to virtually everywhere, *including* the U.S.

     Note that I've never claimed that ISO/OSI is technically better.
Unfortunately, that's not the issue here.  You can dismiss the political
situation if you want to, but it's politics that drive the world, not
technical solutions.  The ISO/OSI boat may be a little leaky yet (the keel's
in place, but a lot of planks are still missing), but its got a full head of
steam and will replace the DOD protocol networks over a course of years.
That shouldn't stop use from using TCP/IP and friends in the short term, but
we shouldn't ignore where the world is going - again, *including* the U.S.
(Or haven't you seen GOSIP?  Another political decision that will eventually
cause the DOD protocols to be displaced.)

     Also, please be careful with the "Not-Invented-Here" paint can.  The
same brush could be used against dyed-in-the-wool Internetters....  I happen
to believe that it would be better to use slightly inferior protocols if
necessary (I'm not saying that ISO/OSI is inferior, though) as long as you
can get *everybody* talking the same protocols.  Since there is a large
portion of the world that has already started on a course that is leading
towards real interconnection, we really can't ignore them just because we
don't like their politics.

                - Richard Chycoski, VE7CVS
                  Systems Consultant,
                  Communications Development Group,
                  Simon Fraser University
                  Computing Services Department.
 9-Sep-87 19:21:18-EDT,1757;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 9 Sep 87 19:21-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Wed, 9 Sep 87 15:18:50 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Wed, 9 Sep 87 15:18:29 EDT
Message-Id: <[e-mail]>
Received: from (MAILER)MITVMA.BITNET by MITVMA.MIT.EDU on 09/09/87 at
  15:21:06 EDT
Received: from Uiucvmd.Cso.Uiuc.Edu by MITVMA.MIT.EDU (Mailer X1.25)
  with BSMTP
 id 8031; Wed, 09 Sep 87 15:21:01 EDT
Received: by UIUCVMD (Mailer X1.25) id 7024; Wed, 09 Sep 87 14:19:38 CDT
Date:         Wed, 09 Sep 87 14:11:10 CDT
From: Phil Howard  <[e-mail]>
Subject:      Hams with Amiga computers
To: Packet Radio <[e-mail]>,
    Info Hams <[e-mail]>

I would like to know of any hams who own an Amiga computer and are
using or want to use it with ham radio.  Also, I would like to know
of any already established groups of such.

I'm interested in doing things such as Packet, Slow-Scan ATV, Fast-Scan
ATV, as well as the other misc. things like contest logging, satellite
tracking, QSL printing, etc.

Sorry, no packet address yet.
---------------------------------------------------------------------------
Phil Howard                         bitnet: <[e-mail]>
KA9WGN                            internet: <phil%vmd.cso.uiuc.edu>
Apartment 3C                            or: <[e-mail]>
1203 West Main Street                 at&t: 10288-1-217-384-4934
Urbana, IL  61801-2344                 mci: 10222-1-217-384-4934
---------------------------------------------------------------------------
10-Sep-87 16:26:22-EDT,1316;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 10 Sep 87 16:26-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Thu, 10 Sep 87 14:32:26 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Thu, 10 Sep 87 14:32:13 EDT
Received: by june.cs.washington.edu (5.52.1/6.6)
    id AA13098; Thu, 10 Sep 87 11:34:38 PDT
Return-Path: <winfree![e-mail]>
Message-Id: <[e-mail]>
Date: 10 Sep 87 05:59:48 GMT
From: winfree![e-mail] (Bdale Garbee)
To: [e-mail]
Subject: KA9Q TCP/IP bits via BBS

I am pleased to report that through the generosity of a local PC dealer,
my BBS is back online running a slightly damaged ST-238.  The KA9Q
TCP/IP package distribution of 870829.0 is now available there for those
of you without any other means of obtaining it.

As a reminder, the bbs can be reached at 303/593-0766, 300/1200/2400 baud,
and first time callers have sufficient privs to download the entire release.

Have fun!
--
Bdale Garbee, N3EUA             phone: [phone] h, 303/590-2868 w
uucp: {bellcore,crash,hp-lsd,ncc,pitt,usafa,vixie}!winfree!bdale
arpa: [e-mail]
fido: sysop of 128/19           packet: n3eua @ k0hoa, Colorado Springs


10-Sep-87 16:58:51-EDT,1316;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 10 Sep 87 16:58-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Thu, 10 Sep 87 14:32:26 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Thu, 10 Sep 87 14:32:13 EDT
Received: by june.cs.washington.edu (5.52.1/6.6)
    id AA13098; Thu, 10 Sep 87 11:34:38 PDT
Return-Path: <winfree![e-mail]>
Message-Id: <[e-mail]>
Date: 10 Sep 87 05:59:48 GMT
From: winfree![e-mail] (Bdale Garbee)
To: [e-mail]
Subject: KA9Q TCP/IP bits via BBS

I am pleased to report that through the generosity of a local PC dealer,
my BBS is back online running a slightly damaged ST-238.  The KA9Q
TCP/IP package distribution of 870829.0 is now available there for those
of you without any other means of obtaining it.

As a reminder, the bbs can be reached at 303/593-0766, 300/1200/2400 baud,
and first time callers have sufficient privs to download the entire release.

Have fun!
--
Bdale Garbee, N3EUA             phone: [phone] h, 303/590-2868 w
uucp: {bellcore,crash,hp-lsd,ncc,pitt,usafa,vixie}!winfree!bdale
arpa: [e-mail]
fido: sysop of 128/19           packet: n3eua @ k0hoa, Colorado Springs


10-Sep-87 17:54:07-EDT,3225;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 10 Sep 87 17:54-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Thu, 10 Sep 87 15:57:14 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Thu, 10 Sep 87 15:56:46 EDT
Received: by june.cs.washington.edu (5.52.1/6.6)
    id AA15358; Thu, 10 Sep 87 12:59:11 PDT
Return-Path: <ihnp4!homxb!hou2d![e-mail]>
Message-Id: <[e-mail]>
Date: 10 Sep 87 15:56:15 GMT
From: ihnp4!homxb!hou2d![e-mail] (G.BEATTIE)
To: [e-mail]
Subject: The Realities of Networking
Keywords: OSI/ISO/CCITT/X.25/Internet/DoD/IP

I have been watching the commentaries fly back and forth about
the "better" protocol suite and after I stopped chuckling I
collected my thoughts and provide the following:

Mr. Chycoski's comments about the availability of X.25
vs Internet connections for the general public are quite
telling of the realities of the world.  The facts are the
following:

The Internet suite is available on many systems because it
has been around for a long while.

The networks avaialable to most folks are based on X.25.
These can be accessed via direct X.25 connections or dial-up
PADs (packet asembler/disassemblers).

The Open Systems Interconnection Reference Model and protocols
are here to stay.  They are not quite as complete, but enough
pieces are out there to be useful.  Much development of
protocols and software has been going on and is rapidly
demanding more and more attention.

Speaking of software, a major strength of the Internet is the
availability of FREE software.  This is rapidly improving for
the OSI community and is becoming a non-issue very rapidly.

Oh yes !  Politics !  This wonderful characteristic of social
systems DOES intrude into the wonderful world of
communications.  The real world view is that OSI-based
protocols are going to dominate the scene.  It is a real shame
that many of the brightest folks are hanging on to what is/was,
pretending that their world will remain unchanged. (On the
other hand maybe the're bright, but not WISE in the ways of the
world.)
It's a shame because in many cases their expertise would be better
spent implementing the OSI protocols, and getting the NEW
WAYS m in
general circulation.  Then we would at least have everyone on
the same turf and would be able to go forward with legitimate
criticisms and make appropriate changes.  Optimization will
only come through experience with the new suite.
Brain-damaged models aren't enough...
BUT again POLITICS (and pride) will prevent folks from
adopting change for the common good.

Kinda reminds me of a movie called "Clan of the Cave Bear"
where the tribe rejects the blond, atheletic, hunting woman
>from their tribe of brown-haired male-dominated hunters
because she didn't fit the model established through years of
tradition.



Thanks,

        J. Gordon Beattie, Jr.

        MAIL
Unix:       ihnp4!hou2d!n2dsy
Amateur:    [e-mail]

        TELEPHONE
Office:     201-615-2506
Home:       201-387-8896


11-Sep-87 20:48:55-EDT,3084;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 11 Sep 87 20:48-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Fri, 11 Sep 87 18:50:39 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Fri, 11 Sep 87 18:50:21 EDT
Received: by june.cs.washington.edu (5.52.1/6.6)
    id AA14720; Fri, 11 Sep 87 15:25:31 PDT
Date: Fri, 11 Sep 87 15:25:31 PDT
From: princeton!idacrd![e-mail]
Return-Path: <princeton!idacrd![e-mail]>
Message-Id: <[e-mail]>
Apparently-To: [e-mail]

Date: 11 Sep 87 16:23:36 GMT
From: princeton!idacrd![e-mail] (Bob McGwier)
To: [e-mail]
Subject: Re: The Realities of Networking

in article <[e-mail]>, [e-mail] (G.BEATTIE) says:
> The Open Systems Interconnection Reference Model and protocols
> are here to stay.  They are not quite as complete, but enough
> pieces are out there to be useful.  Much development of
> protocols and software has been going on and is rapidly
> demanding more and more attention.
>

You didn't expect us to let this go by.  You are probably right cause
the world is full of wimps who will let the telecommunications giants
control there every available bit.  This is THE reason for the OSI
approach in my opinion.  I am still awaiting for something to come from
you, Moulton, and others that says something besides: "Internationally
Acceptable".  What a complete crock.  Why is it better?  Compare on its
merits and not who accepts it.  I confess that I'm one of the bright
guys holding onto WHAT WORKS (i.e. if it ain't broke don't fix it).
CONVINCE ME that what you have is better from an arguable logical
viewpoint.  This how a WISE person convinces bright people.

> Speaking of software, a major strength of the Internet is the
> availability of FREE software.  This is rapidly improving for
> the OSI community and is becoming a non-issue very rapidly.
>

Wrong.  It is widely available.  It ALLOWS internetting which is
what we want. It works.  Further, AX.25 is NOT X.25.  It is not now
and given the standard conservatism of most groups, it will never be.
Further, the placing of 201010 in the header of an AX.25 packet IS
ILLEGAL.  You had better get an STA for that.  Now you see why we
fought these moves to place these "standards" in concrete.  You and
others said its just those damn datagrammers wanting things all there
own way.  Now reap the consequences yourself.

I refer to the coming COSI code which will use area codes and subnet
addressing by placing this information in the CALLSIGN field of a
supposed digipeater field.  It is my opinion, that since Part 97
put the current AX25L2 spec in concrete, this is illegal.  Once again,
I can be convinced that this isn't so but my callsign will not go in
one of those packets until this is clarified.  Also, I can't seem to
find that in my CCITT books anywhere.  Is that X.75?  Point me in
the right direction.

Bob


11-Sep-87 21:41:50-EDT,2235;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 11 Sep 87 21:41-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Fri, 11 Sep 87 18:06:50 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Fri, 11 Sep 87 18:06:22 EDT
Received: by june.cs.washington.edu (5.52.1/6.6)
    id AA13955; Fri, 11 Sep 87 15:08:08 PDT
Return-Path: <seismo![e-mail]>
Message-Id: <[e-mail]>
Date: 11 Sep 87 19:38:57 GMT
From: seismo![e-mail] (Mike O'Dell)
To: [e-mail]
Subject: Foolishness

I generally lay low when the protocol wars heat up
as they routinely do, but I had to comment about
this drivel being purveyed that somehow "International
Standards Efforts" politically FORCE Ham Radio to do
anything in particular.

This is purest Horse Hockey!!

The local PTT's in random technico-fasciast
countries may in fact force their random will upon
users forced to deal with them, but for the
life of me, I CANNOT see what that has to do with us!

If tomorrow you could claim that "Every other network
in the world runs ISO (not just X.25)," which is
clearly preposterous as long as IBM lives and breaths,
THIS IS UTTERLY IMMATERIAL!!

In your freshman/sophomore philosophy class this was
called "Argument by appeal to authority."  THis is
exactly identical to
    "Nine out of ten doctors enjoy breathing."

Again, what the commercial boys are doing has
NO effect on us, except possibly on 220 MHz.
As for any potential cost advantages of using ISO,
if you folks have priced the pitifully few
ISO offerings in the market, you can buy SEVERAL
complete rigs, if not whole shacks,
for the cost of much of it.

If I remember correctly, this cost argument is
routinely cited as reasons why TCP/IP isn't workable -
because you gotta have a $500 computer to run it.

And as for this "In Leage with The Future" crap,
I got news for you - this IS the future, and it
will be for the next N years while the ISOOSI tribe
tries to get its act together.

    -Mike O'Dell

Packet-for-the-day:

    "Networks connect computers.
    Packet without computers is just bad RTTY."


12-Sep-87 19:49:25-EDT,3552;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 12 Sep 87 19:49-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Sat, 12 Sep 87 19:01:28 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Sat, 12 Sep 87 19:01:16 EDT
Received: by june.cs.washington.edu (5.52.1/6.6)
    id AA03174; Sat, 12 Sep 87 16:03:02 PDT
Return-Path: <faline![e-mail]>
Message-Id: <[e-mail]>
Date: 11 Sep 87 21:25:56 GMT
From: faline![e-mail] (Phil R. Karn)
To: [e-mail]
Subject: Re: The Realities of Networking
Summary: What's wrong with COSI
Keywords: OSI/ISO/CCITT/X.25/Internet/DoD/IP
References: <[e-mail]>

I'm glad Gordon has finally admitted that the status of OSI in the world
has to do with pure politics, not technical merit.  I (and a lot of
other Internetters) have been saying that for a long time, but I guess
it carries more weight when it comes from the horse's mouth.

I should point out something for those following this discussion who may
be unfamiliar with what's actually going on in the protocol development
game. Gordon (N2DSY) and Tom (W2VY) are fond of pointing at the "TCP/IP
to OSI migration" talk we've heard in the Internet world over the past
few years as justification for their "COSI" project. They strongly imply
that only COSI will let us talk anywhere in the world, and conversely,
without it we'll have no one to talk to.

However, just using "OSI standard protocols" is no guarantee that you
can talk to someone else also using "OSI standard protocols". The
problem is that, for reasons having to do mostly with politics and
bureaucratic waffling, "OSI" actually consists of a very large flock of
"co-standard" but mutually incompatible protocols at each layer. Most,
for reasons I'll mention later, are connection-oriented (i.e., virtual-
circuit based). Others are connectionless (i.e., datagram-based). So
you can't really say you're "OSI compatible" without saying *which* OSI!
(So much for "open systems interconnection"!)

Potential users of the OSI protocols recognize this problem. The
aforementioned "migration" discussions have centered *exclusively* on
replacing ARPA TCP with the ISO Transport Protocol Class 4 (TP-4) and
ARPA IP with the ISO Connectionless Internetwork Protocol. One good
reason is that virtually all modern high speed local area networks
(e.g., Ethernet/IEEE 802.3) are connectionless. But the most important
reason is INTERNETWORKING, which is what "open systems interconnection"
really ought to be about. It is now a foregone conclusion that
internetworking between heterogeneous subnetworks is practical *only*
with a connectionless internetwork protocol. The connection-oriented
network protocols aren't even in the running in the computer industry.
They're in OSI mainly because of certain European PTTs and others with
similar "strategic objectives" and hidden agendas. Basically, they're
scared to death of internetworking because it makes it too easy to
bypass the telephone monopolies.

How is all this relevant to COSI? Well, COSI is *not* TP-4/ISO IP, but
rather X.25 and TP-1. It is fully connection-oriented at all layers.
Despite all of the grandiose claims made by its perpetrators, COSI as it
now stands will never provide the internetworking functionality and
flexibility that is already available *now* from TCP/IP, or may someday
be available from TP-4/ISO IP.

Phil


12-Sep-87 23:15:29-EDT,1412;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 12 Sep 87 23:15-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Sat, 12 Sep 87 22:33:19 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Sat, 12 Sep 87 22:33:08 EDT
Received: by june.cs.washington.edu (5.52.1/6.6)
    id AA04517; Sat, 12 Sep 87 19:34:57 PDT
Return-Path: <rutgers!hplabs!hplvla![e-mail]>
Message-Id: <[e-mail]>
Date: Fri, 11 Sep 87 09:22:47 mdt
From: Chris Kelly <rutgers!hplabs!hplvla![e-mail]>
To: mit-eddie![e-mail]
Subject: Re:  PK-232 Help

About the Apple II questions:

When using the Super Serial Card's ROM to be terminal emulation,
a carriage return will cause the apple to get busy moving the display and
you can lose characters on the next line because it is not interrupt
driven...the solution is to use a number of NULLS after a carriage
return (line feed) sequence. The TNC-1 and TNC-2 have a NULLS command
to insert filler nulls (or simulate nulls bu

to i
to insert filler nulls or simulate nulls by pausing it's output.
try this command if it exists in the PK-232.
I don't know what public domain terminal emulators are out there for
the apple, but if you find one, please mail me a copy too!
Thanks and 73, Chris WD5IBS.
:wq



14-Sep-87 13:23:34-EDT,1197;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 14 Sep 87 13:23-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Mon, 14 Sep 87 12:01:08 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Mon, 14 Sep 87 12:00:45 EDT
Message-Id: <[e-mail]>
Received: from relay2.cs.net by RELAY.CS.NET id aa08715; 14 Sep 87 11:51 EDT
Received: from suny-sbcs by csnet-relay.csnet id aa02065; 14 Sep 87 11:43 EDT
Received: by sbcs (5.5/4.7)
    id AA25005; Sat, 12 Sep 87 18:34:53 EDT
Date: Sat, 12 Sep 87 18:34:53 EDT
From: Root <[e-mail]>
To: [e-mail], ihnp4!homxb!hou2d![e-mail]
Subject: Re:  The Realities of Networking

Hi Gordon,

    I'll admit to my bias for the Internet protocols, but heck
I'm willing to listen to reason.  How about calling a moratorium
on the silly OSI/Internet protocols wars and just internalize the
model of a free market enterprise - you guys produce the ISO
protocol stuff, let Phil and his guys produce IP/TCP stuff, and
then both camps just pull back and see who uses what..

                    73's,

                        Rick.

14-Sep-87 14:59:47-EDT,960;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 14 Sep 87 14:59-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Mon, 14 Sep 87 13:19:37 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Mon, 14 Sep 87 13:19:20 EDT
Received: from huey.udel.edu by Louie.UDEL.EDU id aa13105; 14 Sep 87 13:09 EDT
Date:     Mon, 14 Sep 87 13:07:48 EDT
From: [e-mail]
To: Root <[e-mail]>
Cc: [e-mail], ihnp4!homxb!hou2d![e-mail]
Subject:  Re:  The Realities of Networking
Message-Id:  <[e-mail]>

Rick,

The AX.25 protocol octet, which now has values assigned for IP and ARP,
needs additional values for ISO 8473, NET/ROM, etc., etc. If that isn't
in the works, the czar/czarina (Jon Postel/Joyce Reynolds) at ISI should
be notified, presumably by the original requestor (Keith Peterson?).

Dave
14-Sep-87 21:15:19-EDT,1926;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 14 Sep 87 21:15-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Mon, 14 Sep 87 19:38:35 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Mon, 14 Sep 87 19:36:10 EDT
Received: by marlin.nosc.mil (5.58/1.27)
    id AA17067; Mon, 14 Sep 87 16:36:40 PDT
Date: Mon, 14 Sep 87 16:36:40 PDT
From: [e-mail] (James N. Price)
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Cc: [e-mail], [e-mail]
Subject: Yaesu FT727 on packet

-------
First a thanks to the rec.ham-radio folks who responded to my
request for info on the FT727.  Two bands for a little more than
the price of one seemed like a good deal, and I bought one last
week.

Now, I'd like to use the thing on packet.  A while back some
kindly soul here on the net posted an RC coupling circuit that
would allow use of Icom HTs (e.g.  IC-2AT) on packet.  The
circuit coupled the mic line from the TNC (thru a .01 capacitor)
with the PTT line (thru a 22K resistor) which then plugged into
the HT's mic jack as a combined signal.  This odd arrangement is
necessitated by Icom (and Yaesu) not bringing a PTT line out to a
connector.

Now, the AEA PK-232 booklet says the SAME circuit will also allow
the FT727 to work on packet.  But mine doesn't.  I can receive
packets fine, but the HT won't key in response to the TNC's PTT
signal.  Do I need to diddle the value of the resistor?  Is there
some fundamental difference the in mic keying circuits that AEA
is unaware of?

Bottom line: has anyone got an FT727 working on packet, and if so
how'd you do it?  I have an MFJ-1270 TNC, by the way, whose
documentation suggests a transformer coupler.

Thanks in advance.

Jim Price, K6ZH, [e-mail]
-------

14-Sep-87 22:53:15-EDT,1926;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 14 Sep 87 22:53-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Mon, 14 Sep 87 19:38:35 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Mon, 14 Sep 87 19:36:10 EDT
Received: by marlin.nosc.mil (5.58/1.27)
    id AA17067; Mon, 14 Sep 87 16:36:40 PDT
Date: Mon, 14 Sep 87 16:36:40 PDT
From: [e-mail] (James N. Price)
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Cc: [e-mail], [e-mail]
Subject: Yaesu FT727 on packet

-------
First a thanks to the rec.ham-radio folks who responded to my
request for info on the FT727.  Two bands for a little more than
the price of one seemed like a good deal, and I bought one last
week.

Now, I'd like to use the thing on packet.  A while back some
kindly soul here on the net posted an RC coupling circuit that
would allow use of Icom HTs (e.g.  IC-2AT) on packet.  The
circuit coupled the mic line from the TNC (thru a .01 capacitor)
with the PTT line (thru a 22K resistor) which then plugged into
the HT's mic jack as a combined signal.  This odd arrangement is
necessitated by Icom (and Yaesu) not bringing a PTT line out to a
connector.

Now, the AEA PK-232 booklet says the SAME circuit will also allow
the FT727 to work on packet.  But mine doesn't.  I can receive
packets fine, but the HT won't key in response to the TNC's PTT
signal.  Do I need to diddle the value of the resistor?  Is there
some fundamental difference the in mic keying circuits that AEA
is unaware of?

Bottom line: has anyone got an FT727 working on packet, and if so
how'd you do it?  I have an MFJ-1270 TNC, by the way, whose
documentation suggests a transformer coupler.

Thanks in advance.

Jim Price, K6ZH, [e-mail]
-------

14-Sep-87 23:56:20-EDT,1329;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 14 Sep 87 23:56-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Mon, 14 Sep 87 22:45:20 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Mon, 14 Sep 87 22:45:02 EDT
Received: by june.cs.washington.edu (5.52.1/6.6)
    id AA12657; Mon, 14 Sep 87 19:47:00 PDT
Return-Path: <ihnp4!homxb!hotps!ka2qhd![e-mail]>
Message-Id: <[e-mail]>
Date: 14 Sep 87 13:22:23 GMT
From: ihnp4!homxb!hotps!ka2qhd![e-mail] (Tom)
To: [e-mail]
Subject: Re: TCP/OSI/Standards/"Get Real, People!"
References: <[e-mail]> <[e-mail]> <[e-mail]>


i think you'll find that the PTT's allow it's usage as an intrem solution
until the ISO protocols are ready.
(YOU may say they'll never be ready... i disagree)
also i think you'll find that for anything other than local traffic that
they MUST use x.25, and I bet that as the upper layers get commonly available
they will have to progress with the PTT's network, instead of staying stagnent
--
Life is too short to be mad about things.
Thomas A. Moulton, W2VY             Packet: w2vy@kd6th
(201) 779-W2VY                      uucp !bellcore!hotsp!tsdiag!tom


15-Sep-87 00:04:07-EDT,1346;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 15 Sep 87 00:04-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Mon, 14 Sep 87 22:46:39 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Mon, 14 Sep 87 22:46:23 EDT
Received: by june.cs.washington.edu (5.52.1/6.6)
    id AA12686; Mon, 14 Sep 87 19:48:21 PDT
Return-Path: <ihnp4!homxb!hotps!ka2qhd![e-mail]>
Message-Id: <[e-mail]>
Date: 14 Sep 87 13:35:22 GMT
From: ihnp4!homxb!hotps!ka2qhd![e-mail] (Tom)
To: [e-mail]
Subject: Re: More on Internationally Blessed Protocols
Summary: bitches about a protocol without reading the doc
References: <[e-mail]>

X.25 does include a protocol identification field, the General Format Id
has values to be used for Non-X.25 level 3 protocol data

ALSO From what I heard about the meeting where AX.25 was "created" it was
a VERY POLITICAL meeting, hell the protocol wars started there!

Ok Phil, since you seem to know SOOOOOOOO much about COSI why don't you
tell me what it is going to do!
--
Life is too short to be mad about things.
Thomas A. Moulton, W2VY             Packet: w2vy@kd6th
(201) 779-W2VY                      uucp !bellcore!hotsp!tsdiag!tom


15-Sep-87 21:20:14-EDT,3110;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 15 Sep 87 21:20-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Tue, 15 Sep 87 16:49:26 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Tue, 15 Sep 87 16:48:53 EDT
Received: by june.cs.washington.edu (5.52.1/6.6)
    id AA00604; Tue, 15 Sep 87 13:50:50 PDT
Return-Path: <bellcore!faline![e-mail]>
Message-Id: <[e-mail]>
Date: 14 Sep 87 23:21:17 GMT
From: bellcore!faline![e-mail] (Phil R. Karn)
To: [e-mail]
Subject: Re: The Realities of Networking
Summary: "AX.25" Protocol IDs explained
References: <[e-mail]>

The presently defined values for the AX.25 Level 3 PID are as follows
in hex:

F0 - No higher layer protocol; send directly to terminal. (WB6CYT has coined
     the term "AX.25 streams" here.)

CC - DoD/ARPA Internet Protocol (IP).

CD - DoD/ARPA Address Resolution Protocol (ARP).

CF - NET/ROM inter-node traffic.

Unfortunately, the PID scheme isn't as clean as it should be. When AX.25
Level 2 was originally specified, it was assumed that X.25 Level 3 (the
Packet layer) would soon follow, and that the PID would become the first
byte of the X.25 Level 3 (Packet layer) header.  Therefore, only those
PID values representing illegal X.25 Packet Layer headers could be used
to denote protocols other than X.25 Level 3.

The first nibble (4 bits) of an X.25 Level 3 header is the General
Format Identifier (GFI). It can take on 12 of the 16 possible values.
The other nibble is the beginning of the 12-bit Logical Channel
Identifier field, which can take on all possible values. Therefore, the
only values for the PID that can be assigned to protocols other than
X.25 Level 3 are 00-0F, 40-4F, 80-8F and C0-CF.

It's interesting that the most popular PID, F0, isn't in these groups.
X.25 General Format Indicators 3, 7, B and F are listed as "General
Format Identifier Extension", i.e., they're presently unused but are
reserved for possible future use. So if CCITT decides to "extend" X.25
in the next revision, F might very well become a valid, assigned GFI.
And then we'd be violating an Internationally Accepted Standard
Protocol! Horrors!! :-)

Texnet appears to use the value C0 for its routing updates, although I
don't think this is formally assigned. Texnet also violates layering
pretty badly, in that some of the unused bits in the AX.25 datagram
(address) header are used to tell Texnet's network layer whether the
data is between Texnet nodes or not. (See the paper by N5EG in the 6th
ARRL conference proceedings).

Since the AX.25 spec is under revision, I think this would be a good
time to establish a cleaner policy regarding PIDs. It is unfair for a
single protocol to gobble up 3/4 of all possible PIDs just so it can
save a byte of header overhead. One PID per protocol seems much more
fair, especially since X.25 Layer 3 is ill-suited to amateur radio and
hardly anybody uses it anyway.

Phil


15-Sep-87 21:38:46-EDT,3110;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 15 Sep 87 21:38-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Tue, 15 Sep 87 16:49:26 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Tue, 15 Sep 87 16:48:53 EDT
Received: by june.cs.washington.edu (5.52.1/6.6)
    id AA00604; Tue, 15 Sep 87 13:50:50 PDT
Return-Path: <bellcore!faline![e-mail]>
Message-Id: <[e-mail]>
Date: 14 Sep 87 23:21:17 GMT
From: bellcore!faline![e-mail] (Phil R. Karn)
To: [e-mail]
Subject: Re: The Realities of Networking
Summary: "AX.25" Protocol IDs explained
References: <[e-mail]>

The presently defined values for the AX.25 Level 3 PID are as follows
in hex:

F0 - No higher layer protocol; send directly to terminal. (WB6CYT has coined
     the term "AX.25 streams" here.)

CC - DoD/ARPA Internet Protocol (IP).

CD - DoD/ARPA Address Resolution Protocol (ARP).

CF - NET/ROM inter-node traffic.

Unfortunately, the PID scheme isn't as clean as it should be. When AX.25
Level 2 was originally specified, it was assumed that X.25 Level 3 (the
Packet layer) would soon follow, and that the PID would become the first
byte of the X.25 Level 3 (Packet layer) header.  Therefore, only those
PID values representing illegal X.25 Packet Layer headers could be used
to denote protocols other than X.25 Level 3.

The first nibble (4 bits) of an X.25 Level 3 header is the General
Format Identifier (GFI). It can take on 12 of the 16 possible values.
The other nibble is the beginning of the 12-bit Logical Channel
Identifier field, which can take on all possible values. Therefore, the
only values for the PID that can be assigned to protocols other than
X.25 Level 3 are 00-0F, 40-4F, 80-8F and C0-CF.

It's interesting that the most popular PID, F0, isn't in these groups.
X.25 General Format Indicators 3, 7, B and F are listed as "General
Format Identifier Extension", i.e., they're presently unused but are
reserved for possible future use. So if CCITT decides to "extend" X.25
in the next revision, F might very well become a valid, assigned GFI.
And then we'd be violating an Internationally Accepted Standard
Protocol! Horrors!! :-)

Texnet appears to use the value C0 for its routing updates, although I
don't think this is formally assigned. Texnet also violates layering
pretty badly, in that some of the unused bits in the AX.25 datagram
(address) header are used to tell Texnet's network layer whether the
data is between Texnet nodes or not. (See the paper by N5EG in the 6th
ARRL conference proceedings).

Since the AX.25 spec is under revision, I think this would be a good
time to establish a cleaner policy regarding PIDs. It is unfair for a
single protocol to gobble up 3/4 of all possible PIDs just so it can
save a byte of header overhead. One PID per protocol seems much more
fair, especially since X.25 Layer 3 is ill-suited to amateur radio and
hardly anybody uses it anyway.

Phil


16-Sep-87 02:48:52-EDT,1193;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 16 Sep 87 02:48-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Tue, 15 Sep 87 22:35:09 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Tue, 15 Sep 87 22:34:38 EDT
Date: Tue, 15 Sep 87 22:34:15 EDT
From: [e-mail] (Michael Chepponis)
Message-Id: <[e-mail]>
Received: by csl3.wisc.edu; Tue, 15 Sep 87 22:34:15 EDT
To: [e-mail]
Subject: Peace!

I think it's amusing that the protocol wars have moved from the (now defunct)
DRNET to this group...

Folks, we're all working on the SAME goal:  to build a kick-ass network for
all of our data needs, one which is especially useful during emergencies.
It's just that some folks see different routes to that goal; these differences
are really trivial in the Grand Scheme of things.

Why don't we all retire to our basements & generate tons of code and make this
happen, instead of flaming on this group?

On the other hand, flaming here can me thereputic; for me, I can hit the "n"
key...

If you want me, I'll be in my basement...  -Mike

16-Sep-87 07:17:53-EDT,1216;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 16 Sep 87 07:17-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Wed, 16 Sep 87 03:00:43 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Wed, 16 Sep 87 03:00:32 EDT
Message-Id: <[e-mail]>
Received: from (MAILER)MITVMA.BITNET by MITVMA.MIT.EDU on 09/16/87 at
  03:03:01 EDT
Received: from NDSUVM1.BITNET by MITVMA.MIT.EDU (Mailer X1.25) with
  BSMTP id
 8411; Wed, 16 Sep 87 03:01:44 EDT
Received: by NDSUVM1 (Mailer X1.24) id 9473; Wed, 16 Sep 87 00:19:31 CDT
Date:         Wed, 16 Sep 87 00:14:30 CDT
From: Todd Enders WD0BCI
  <[e-mail]>
Subject:      Re: More on Internationally Blessed Protocols
To: [e-mail]
In-Reply-To:  Message of 12 Sep 87 08:58:40 GMT from
  <faline![e-mail]>


     Maybe we should just call TCP/IP AOSI xx.xx!  The european PTT folk
would probably be just as fooled as AX.25........(could they actually be that
gullible?)

     By the way, AOSI = Actual Open System Interconnect, which TCP/IP
appears to do quite well......

73,

Todd, WD0BCI
16-Sep-87 17:08:04-EDT,1443;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 16 Sep 87 17:08-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Wed, 16 Sep 87 11:59:45 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Wed, 16 Sep 87 11:58:19 EDT
Received: by june.cs.washington.edu (5.52.1/6.6)
    id AA12661; Wed, 16 Sep 87 09:00:05 PDT
Return-Path: <ihnp4!homxb!hotps!ka2qhd![e-mail]>
Message-Id: <[e-mail]>
Date: 15 Sep 87 12:24:31 GMT
From: ihnp4!homxb!hotps!ka2qhd![e-mail] (Tom)
To: [e-mail]
Subject: Re: The Realities of Networking
Summary: corrections
References: <[e-mail]> <[e-mail]> <[e-mail]>

In article <[e-mail]>, [e-mail] (Tom) writes:
>
> in other words, it will never be an alias, just routing information for the
> level 2 user.
>
> ie. 201010 would be the digi that is taken as the transmitter or the receiver
<<<<<<<<<        NEVER be >>>>>>>>>
>
> even our friend in new england won't be confused when he sees it.

sorry for the omitted word, it changes the idea completely
--
Life is too short to be mad about things.
Thomas A. Moulton, W2VY          Packet: w2vy@kd6th  Voice: 145.190 (r)
(201) 779-W2VY                   uucp: ...!ihnp4!bellcore!hotps!ka2qhd!w2vy
FAX: [phone]              [phone] x3226 (w)


16-Sep-87 17:22:08-EDT,3344;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 16 Sep 87 17:22-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Wed, 16 Sep 87 11:55:32 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Wed, 16 Sep 87 11:53:55 EDT
Received: by june.cs.washington.edu (5.52.1/6.6)
    id AA12564; Wed, 16 Sep 87 08:55:32 PDT
Return-Path: <bellcore!faline![e-mail]>
Message-Id: <[e-mail]>
Date: 15 Sep 87 23:18:10 GMT
From: bellcore!faline![e-mail] (Phil R. Karn)
To: [e-mail]
Subject: Re: More on Internationally Blessed Protocols
References: <[e-mail]> <[e-mail]>

> X.25 does include a protocol identification field, the General Format Id
> has values to be used for Non-X.25 level 3 protocol data

The closest thing to a "Protocol ID" in X.25 is the "Call User Data"
field in the Call Request packet. For example, the convention for
indicating that an X.25 circuit will be used to pass IP datagrams is to
put hex CC in the X.25 Call User Data field. (Now you know where the
AX.25 Level 3 PID value for IP came from).  However, Call User Data is
present only in call requests; it isn't present in every packet.

There is *nothing* in my copy of the X.25 spec (1980 version) that
implies in any way that the GFID is meant to be a "protocol ID". It is
an integral part of the X.25 Level 3 header. There is *no* provision for
running any protocol other than X.25 Level 3 above X.25 Level 2. I
suspect that rather strange things would happen if you sent a GFID of C
or F across Telenet; it would not be delivered transparently, as would a
true protocol ID. It is merely fortuitous that certain values of the
GFID are undefined (Horrors! Wasted bits! Overhead!! :-)) so we can use
them in our own software to indicate without conflict that something
other than X.25 Level 3 is running atop AX.25 Level 2. However, at this
point I would abandon any remaining pretense of AX.25 being "CCITT
standard" and free up all 256 possible PIDs for assignment to higher
level protocols. If you guys want to implement X.25 Level 3, fine, we'll
assign you your very own AX.25 Level 3 PID and you can put your GFID in
the byte FOLLOWING the PID.

> ALSO From what I heard about the meeting where AX.25 was "created" it was
> a VERY POLITICAL meeting, hell the protocol wars started there!

I was there. No, it wasn't really all that political. Those of us who
were networking neophytes just sat there in silent awe of the Commercial
Networking Professionals. (Why, gosh, one even sat on the CCITT
committee that designed X.25 -- clearly an infallible group. This same
person, as I recall, was the one responsible for "shifted ASCII" in the
address field.) They just handed us stone tablets and told us that
whatever was good for point-to-point telephone lines was automatically
good for amateur radio. The rest of us didn't know any better (yet).
Plus Jamais.

> Ok Phil, since you seem to know SOOOOOOOO much about COSI why don't you
> tell me what it is going to do!

I only know what I read in your papers, and hear you and Gordon say at
the RATS meetings.  Or what I attempt to piece together from what I read,
and what I hear...

Phil


16-Sep-87 19:34:12-EDT,3178;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 16 Sep 87 19:34-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Wed, 16 Sep 87 11:47:18 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Wed, 16 Sep 87 11:46:28 EDT
Received: by june.cs.washington.edu (5.52.1/6.6)
    id AA12370; Wed, 16 Sep 87 08:48:19 PDT
Return-Path: <bellcore!faline![e-mail]>
Message-Id: <[e-mail]>
Date: 15 Sep 87 22:32:59 GMT
From: bellcore!faline![e-mail] (Phil R. Karn)
To: [e-mail]
Subject: Re: TCP/OSI/Standards/"Get Real, People!"
Summary: PTT's "allowing" usage
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>

> i think you'll find that the PTT's allow it's usage as an intrem solution
> until the ISO protocols are ready.

I assume by "it" you mean "TCP/IP".

> (YOU may say they'll never be ready... i disagree)
> also i think you'll find that for anything other than local traffic that
> they MUST use x.25, and I bet that as the upper layers get commonly available
> they will have to progress with the PTT's network, instead of staying stagnent

It is certainly true that to "use" a network, you have to speak its
protocols -- at some level. It is also true that in Europe the only wide
area networks around will probably continue to be the PTT X.25
monopolies. However, the most basic and fundamental notion in
internetworking is that IP datagrams are carried transparently as USER
DATA by whatever network they ride on. So just how does a PTT
legitimately justify dictating to its customers the format of data they
must use when communicating among themselves?

By analogy, when I use the phone system in a foreign country I certainly
must learn to "speak" its low level protocols. For example, I must use
the correct dialing codes and understand the call progress tones; if I
talk to an operator, I must use a language the operator can understand.
However, once my call goes through the PTT has absolutely no business
telling me what languages I can use in my conversation; that's a
strictly private matter between the person I'm talking to and myself.

Part of the problem with data communications is that the PTTs aren't
content just to carry other people's communications. They want to be a
party to as much of this communicating as they can. They can make money
by selling information, and (more importantly) generate extra revenues
for the communications side of the business.  Given this latter
consideration, putting the PTTs in charge of protocol standards is like
putting a fox in charge of a henhouse. You can be damned sure that they
will do their very best to keep people from bypassing their
communications facilities while accessing their services.  It's not
likely that I'll be able to reach the French Minitel service across an
Internet (either TCP/IP or TP-4/ISO IP) any time soon.

The classic paper on this subject is "Datagrams and Virtual Circuits:
Technical and Political Problems" by Louis Pouzin, NCC 1976.

Phil


17-Sep-87 04:49:07-EDT,2604;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 17 Sep 87 04:49-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Wed, 16 Sep 87 22:35:25 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Wed, 16 Sep 87 22:34:24 EDT
Received: by june.cs.washington.edu (5.52.1/6.6)
    id AA00128; Wed, 16 Sep 87 19:35:46 PDT
Return-Path: <husc6!sri-unix![e-mail]>
Message-Id: <[e-mail]>
Date: 17 Sep 87 01:17:21 GMT
From: husc6!sri-unix![e-mail] (Alan Larson)
To: [e-mail]
Subject: Re: Packet software
References: <[e-mail]>

In article <[e-mail]> [e-mail] writes:

>Is there anybody out there who is able to supply me with information
>about a source for NO TNC SOFTWARE for packet on IBM/PC.

You didn't indicate what sort of hardware you have to connect the IBM/PC
to the radio.  Since nobody else has answered this in several days, I will
take shot at it.

You are very unlikely to find such software -- I do not know of any existing.
I am working on some that may eventually reach that state for the Macintosh,
but it is far from happening.  Even so, it will require some special hardware.
(Present tests are using a TNC as that hardware.)

Most amateur packet radio is transmitted using Bell 202 modem tones and
a normal FM transceiver.  These tones are converted into data levels
(generally without clock signals) by the modem.  The unclocked signals
are encoded in the form of an HDLC data frame, complete with bit-stuffing,
flag bytes, and CRC error checking.  This is decoded by use of an HDLC
controller chip, preferably one of the subset that is able to produce
the needed clock signal internally (typically by a digital phase locked
loop, as I understand it).  The HDLC chip then provides the byte stream
of the AX.25 format packet to the processor, which must decode the address
and protocol control bytes, and implement the AX.25 protocol features.

For transmission, the process is reversed.

The HDLC controller chip is not the same as the serial I/O controller that
is present in many IBM PCs.  The 202 modem tones are not the same as used
by your normal 300, 1200, or 2400 bit/sec modems; thus, those modems are
not suitable for this purpose.

It would be possible to build a card that provided these that could be
used in the IBM PC.  However, unless you have some special hardware,
it is very unlikely that you would be doing packet.

    Alan


17-Sep-87 11:30:25-EDT,1190;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 17 Sep 87 11:30-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Thu, 17 Sep 87 08:16:56 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Thu, 17 Sep 87 08:16:47 EDT
Message-Id: <[e-mail]>
Received: from (MAILER)MITVMA.BITNET by MITVMA.MIT.EDU on 09/17/87 at
  08:19:20 EDT
Received: from VTVM1.BITNET by MITVMA.MIT.EDU (Mailer X1.25) with BSMTP
  id
 2271; Thu, 17 Sep 87 08:15:07 EDT
Received: by VTVM1 (Mailer X1.24) id 6788; Thu, 17 Sep 87 08:14:06 EDT
Date:         Thu, 17 Sep 87 08:11:04 EDT
From: Gary Kendall  <[e-mail]>
Subject:      Packet BBS Software
To: [e-mail]

Does anyone know of a good source (preferably something over the network(s)
here) for packet BBS software?  My roommate recently bought a Mac-II running
Unix and he's interested in running something like W0RLI on it, preferably a
source version in C.

Also, anyone know of any good ham file servers in general on the network?

Thanks in advance for your help!

'73,

--gary  KB4GCF
17-Sep-87 16:25:31-EDT,1174;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 17 Sep 87 16:25-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Thu, 17 Sep 87 12:44:36 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Thu, 17 Sep 87 12:44:27 EDT
Message-Id: <[e-mail]>
Received: from (MAILER)MITVMA.BITNET by MITVMA.MIT.EDU on 09/17/87 at
  12:46:59 EDT
X-Delivery-Notice:  SMTP MAIL FROM does not correspond to sender.
Received: from YMIR.BITNET (SMTPUSER) by MITVMA.MIT.EDU (Mailer X1.25)
  with
 BSMTP id 3445; Thu, 17 Sep 87 12:46:19 EDT
Received: from HMCVAX.BITNET by YMIR.BITNET; Thu, 17 Sep 87 09:28 PDT
Date: Thu, 17 Sep 87 09:26 PDT
From: Death to the Daleks!  <[e-mail]>
Subject: Mailing List Removal
To: [e-mail]
X-Vms-To: IN%"[e-mail]"

To whom it may concern:

    Please remove me from you mailing list.

        Thanks and 73     - John Lulejian (KA6TCY)

                    ([e-mail])
                    ([e-mail])
17-Sep-87 18:32:00-EDT,1973;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 17 Sep 87 18:32-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Thu, 17 Sep 87 13:33:01 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Thu, 17 Sep 87 13:32:41 EDT
Received: by june.cs.washington.edu (5.52.1/6.6)
    id AA11255; Thu, 17 Sep 87 10:34:37 PDT
Return-Path: <ihnp4!homxb!hou2d![e-mail]>
Message-Id: <[e-mail]>
Date: 16 Sep 87 18:04:18 GMT
From: ihnp4!homxb!hou2d![e-mail] (G.BEATTIE)
To: [e-mail]
Subject: Re:  The Realities of Networking
Summary: Moratorium Realized ?
Keywords: moratorium  rationality
References: <[e-mail]> <[e-mail]>

Patty et al,

   You may have noticed that I have backed away (again !)
>from the exchanges here.  I thought my comments were minimal
and somewhat non-combative.  I guess I should know better.
In any case, the detractors have stated a variety of points
which vary from accurate, to ignorant, to absurd.  As a
result, we folks who are working hard to make OSI
protocols available to a broad group have been called
upon to "filter the noise" generated by detractors who
This is a pain in the tail and takes time away from our
stated goal.

One comment:

 The stated "illegality" of some of our proposals is absurd !

In future, specific issues will be PROPOSED here and on other
nets.  Comments are welcome, but DO NOT expect us to waste our
time cleaning "bullpen" mud from our outfielders' eyes.  In
others words we will be using our time more productively.

Thanks,

        J. Gordon Beattie, Jr.

        MAIL
Unix:       ihnp4!hou2d!n2dsy
Amateur:    n2dsy @ kd6th-4.a3100201.ampr

        TELEPHONE
Office:     201-615-2506
Home:       201-387-8896


Connection-oriented Open Systems Interconnection ---> COSI


17-Sep-87 23:24:48-EDT,3084;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 17 Sep 87 23:24-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Thu, 17 Sep 87 18:43:02 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Thu, 17 Sep 87 18:41:27 EDT
Received: by june.cs.washington.edu (5.52.1/6.6)
    id AA21790; Thu, 17 Sep 87 15:42:57 PDT
Return-Path: <bellcore!faline![e-mail]>
Message-Id: <[e-mail]>
Date: 17 Sep 87 18:57:38 GMT
From: bellcore!faline![e-mail] (Phil R. Karn)
To: [e-mail]
Subject: Re: Packet software
Summary: HDLC cards for the PC
References: <[e-mail]> <[e-mail]>

HDLC cards are in fact appearing for the IBM PC and clones.  Here's a list
of the ones I know about:

"Eagle" card. Available surplus, quantities somewhat limited. Cost ~$15.
Contains a Zilog 8530 and two serial port connectors.  Needs to have some
traces cut and patched (to fix non-standard serial pinout, also to change
interrupt vector and/or I/O address).  Requires external modem. TCP/IP
driver software under development by WA3CVG and KA9Q.

HAPN (Hamilton Area Packet Radio) card. Contains an Intel 8273 plus an
on-board 202 modem. Provides only ONE channel (vs the 8530 cards, which all
provide two).  Designed specifically for amateur packet radio, driver
software available from HAPN, TCP/IP driver already in my code courtesy of
KE3Z.

Pac-comm PC-100. Contains a Zilog 8530, two 202 modems, two serial port
connectors. Also designed specifically for amateur packet radio. Originally
designed by WB4JFI; revised prototypes were just built, software under
development. I have one and am working on the TCP/IP driver along with
N3EUA.

Regular IBM SLDC adaptor card. I believe these are no longer being made,
but are occasionally available surplus. Uses the Intel 8273. Provides only
one channel, no on-board modem. Requires TWO interrupt vectors (IRQ3 and 4),
which in my mind is a fatal flaw (you lose BOTH asynch comm ports!) I have
one, but have no software for it.

On my list of things to do in my TCP/IP package "net.exe" is to add full
AX.25 support, both for hop-by-hop acking of IP datagrams on bad links, and
to allow "conventional" packet operation while in net.exe. It's also needed
to inject IP datagrams into a NET/ROM network.

Editorial comment (you didn't think I'd let an article go out here without
one, now did you?) If slow speed amateur packet radio had adopted an
*asynchronous* packet framing protocol, it would have been a lot easier to
adapt commonly available personal computers to packet operation without
requiring external TNCs. You'd only need the modem.  HDLC is certainly nice
if you already have it, but it doesn't really buy you that much until you go
to high speed synchronous modems.  But then again, HDLC is a CCITT and ISO
standard, and who are we to risk thunderbolts from the heavens by flouting
an Established International Standard? :-)

Phil


18-Sep-87 20:51:03-EDT,3875;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 18 Sep 87 20:51-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Fri, 18 Sep 87 16:02:56 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Fri, 18 Sep 87 16:02:15 EDT
Received: by umix.cc.umich.edu (5.54/umix-2.0)
    id AA10418; Fri, 18 Sep 87 16:01:08 EDT
Received: from SFU.Mailnet by um.cc.umich.edu via MTS-Net; Fri, 18 Sep 87 15:02:29 EDT
Date: Fri, 18 Sep 87 11:32:26 PDT
From: [e-mail]
To: [e-mail]
Message-Id: <[e-mail]>
Subject: Re: HDLC vs. async framing on packet radio.

     Re: HDLC vs.  async framing on packet radio:

     I was a member of the (in)famous VADCG (Vancouver Amateur Digital Radio
Group) from close to its very beginning.  (1978?)  HDLC was chosen because
we were producing a high speed 220 Mhz digital radio "Real Soon Now", and
the surplus 202 modems that dropped into our hands were merely a "stop gap"
measure to get the average ham, who already owned a two metre radio,
interested enough to eventually acquire a 220 Mhz digital radio.  As usual,
the stop gap became the de facto standard (and we *all* know how dangerous
de facto standards are, don't we?  :-).  The VADCG (Bob Livingston, VE7CYB
did the work) produced a 202 modem designed with packet radio in mind, as
"Real" 202 modems were huge, becoming scarce on the surplus market, and
breaking down too often.  This, and then the large number of TAPR TNCs with
onboard 202 modems, sealed the fate of packet radio modulation standards for
some time to come.

     The VADCG board was (and is) designed for high speed packet without
modification, for the time when appropriate modems and radios become
available.  It was humourous to here about the mods required to get a
TAPR-style TNC working at 56 kbps.  A VADCG unit would have just "plugged
in".  (The software, on the other hand, may have been a completely different
matter.)

     The reason for building "smart" TNCs, as opposed to using a personal
computer to drive the modem directly: in 1978, personal computers were
*expensive*.  The goal of the original VADCG TNC project was to produce a
system that would allow the average ham to get into packet radio cheaply.
The original unit included a current loop interface so that old Miller code
teletypes could be used as terminals!  At that time, we expected to have a
personal computer or two available via packet radio, but that the bulk of
the traffic would still be RTTY replacement.  (Yes, we did expect that to
change over the years, although maybe not as quickly as it did.)  I agree
that if it makes more sense to some people to install HDLC hardware in their
personal computer (of whatever size) than it does to attach a TNC, then *DO
IT*!  The reasons for needing a TNC are dwindling.  (Also, Phil, if you feel
that async framing at 1200 bps on two metres is appropriate, then *DO IT*!
If the amateur community agrees with you, and you produce a commercial
product that does it, they'll buy it!  I had to include the dig about a
commercial product, since I feel that the main reason for the popularity of
the TAPR TNC over the VADCG TNC was easy availability of the former.)

     (I use the past tense when talking about my membership in VADCG since I
haven't attended a meeting in quite some time.  I do communicate with some
of the members occasionally, though.  At the early meetings, I was the lone
voice in support of datagram, rather than connection oriented protocols.  I
still feel that a datagram service is more appropriate for most amateur
packet communication, and I am strongly opposed to any service that
*requires* a central controller or server, which was another hot issue nine
years ago.)
20-Sep-87 03:05:59-EDT,1625;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 20 Sep 87 03:05-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Sun, 20 Sep 87 01:50:56 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Sun, 20 Sep 87 01:50:43 EDT
Received: by june.cs.washington.edu (5.52.1/6.6)
    id AA09283; Sat, 19 Sep 87 22:52:58 PDT
Return-Path: <pyramid!voder!apple![e-mail]>
Message-Id: <[e-mail]>
Date: 17 Sep 87 20:11:28 GMT
From: pyramid!voder!apple![e-mail] (Patty Winter)
To: [e-mail]
Subject: Re: Packet BBS Software
References: <[e-mail]>

In article <[e-mail]> [e-mail] (Gary Kendall) writes:
>Does anyone know of a good source (preferably something over the network(s)
>here) for packet BBS software?  My roommate recently bought a Mac-II running
>Unix and he's interested in running something like W0RLI on it, preferably a
>source version in C.

Gary:

Maybe your roommate knows something I don't: is he running Unix on
his Mac II *now*? When I sent you that email note yesterday, I assumed
he was waiting for A/UX. Is some company other than Apple offering
a Unix product for the II already?

Patty

p.s. I'm posting this as a followup because others may be wondering
the same thing.


--
          Patty Winter N6BIS                   [phone]
     M/S 2C, Apple Computer, Inc., 20525 Mariani Ave., Cupertino, CA 95014
              {decwrl,nsc,sun,dual}!apple!winter


20-Sep-87 03:27:47-EDT,1625;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 20 Sep 87 03:27-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Sun, 20 Sep 87 01:50:56 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Sun, 20 Sep 87 01:50:43 EDT
Received: by june.cs.washington.edu (5.52.1/6.6)
    id AA09283; Sat, 19 Sep 87 22:52:58 PDT
Return-Path: <pyramid!voder!apple![e-mail]>
Message-Id: <[e-mail]>
Date: 17 Sep 87 20:11:28 GMT
From: pyramid!voder!apple![e-mail] (Patty Winter)
To: [e-mail]
Subject: Re: Packet BBS Software
References: <[e-mail]>

In article <[e-mail]> [e-mail] (Gary Kendall) writes:
>Does anyone know of a good source (preferably something over the network(s)
>here) for packet BBS software?  My roommate recently bought a Mac-II running
>Unix and he's interested in running something like W0RLI on it, preferably a
>source version in C.

Gary:

Maybe your roommate knows something I don't: is he running Unix on
his Mac II *now*? When I sent you that email note yesterday, I assumed
he was waiting for A/UX. Is some company other than Apple offering
a Unix product for the II already?

Patty

p.s. I'm posting this as a followup because others may be wondering
the same thing.


--
          Patty Winter N6BIS                   [phone]
     M/S 2C, Apple Computer, Inc., 20525 Mariani Ave., Cupertino, CA 95014
              {decwrl,nsc,sun,dual}!apple!winter


22-Sep-87 15:09:41-EDT,1170;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 22 Sep 87 15:09-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Tue, 22 Sep 87 12:55:57 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Tue, 22 Sep 87 12:55:43 EDT
Received: by june.cs.washington.edu (5.52.1/6.6)
    id AA15937; Tue, 22 Sep 87 09:41:15 PDT
Return-Path: <bellcore!faline![e-mail]>
Message-Id: <[e-mail]>
Date: 21 Sep 87 19:57:40 GMT
From: bellcore!faline![e-mail] (Phil R. Karn)
To: [e-mail]
Subject: October Scientific American
Keywords: article on computer networking

I just received my copy of the October 1987 issue of Scientific
American. It is a special issue on computing.  One of the articles may
be of interest to this group: "Networks for Advanced Computing", by
Robert E. Kahn.  This is a layman's introduction to packet switching
(and why it is more suitable to computer networking than circuit
switching). He discusses things like Ethernet and token rings, virtual
circuits and datagrams, TCP/IP and OSI.

Phil


22-Sep-87 15:26:48-EDT,1557;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 22 Sep 87 15:26-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Tue, 22 Sep 87 13:03:53 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Tue, 22 Sep 87 13:03:32 EDT
Received: by june.cs.washington.edu (5.52.1/6.6)
    id AA16703; Tue, 22 Sep 87 10:05:51 PDT
Return-Path: <ihnp4!homxb!hotps!ka2qhd![e-mail]>
Message-Id: <[e-mail]>
Date: 17 Sep 87 14:40:07 GMT
From: ihnp4!homxb!hotps!ka2qhd![e-mail] (Thomas A. Moulton)
To: [e-mail]
Subject: Re: More on Internationally Blessed Protocols
References: <[e-mail]> <[e-mail]> <[e-mail]>

I never would mean to imply that AX.25 would be anything near a CCITT standard

There have been a number of improvements in X.25 since 1980, many of which
don't effect the implementation, but do specify usage of things like the GFI

COSI is a X.25 LEVEL 3 running on top of AX.25 (level 2) packet switch
also all that should be needed to connect it to Telenet is a box(PC) that
supports both AX.25 and X.25 Level 2, without any loss of packet level
features (since it's the same protocol at Level 3)
--
Life is too short to be mad about things.
Thomas A. Moulton, W2VY          Packet: w2vy@kd6th  Voice: 145.190 (r)
(201) 779-W2VY                   uucp: ...!ihnp4!bellcore!hotps!ka2qhd!w2vy
FAX: [phone]              [phone] x3226 (w)


22-Sep-87 15:27:46-EDT,1507;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 22 Sep 87 15:27-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Tue, 22 Sep 87 12:52:28 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Tue, 22 Sep 87 12:52:07 EDT
Received: by june.cs.washington.edu (5.52.1/6.6)
    id AA16296; Tue, 22 Sep 87 09:54:31 PDT
Return-Path: <bellcore!faline![e-mail]>
Message-Id: <[e-mail]>
Date: 18 Sep 87 22:49:13 GMT
From: bellcore!faline![e-mail] (Phil R. Karn)
To: [e-mail]
Subject: Re: Packet software
Summary: maybe there's more than one IBM SDLC card
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>

>       Sorry, Phil.  I have worked extensively with these guys, and I
> don't think you have it quite right.  It requires ONE interrupt (IRQ4--
> conflicts with your second serial port), and ONE DMA channel....

The card I'm referring to is described in the IBM PC Technical Reference
(Options and Adapters) under "SDLC Communications Adapter". Besides the
Intel 8273 SDLC Protocol Controller, it has an 8255 PPI and a 8253
timer. Page 6 (as well as the schematic) shows that the adapter uses
Interrupt Level 3 for Transmit/Receive interrupt, and Interrupt Level 4
for the timer and modem status interrupts. It also uses DMA channel 1.

Perhaps there's more than one design?

Phil


22-Sep-87 15:28:09-EDT,2325;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 22 Sep 87 15:28-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Tue, 22 Sep 87 12:57:19 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Tue, 22 Sep 87 12:56:37 EDT
Received: by june.cs.washington.edu (5.52.1/6.6)
    id AA16445; Tue, 22 Sep 87 09:58:40 PDT
Return-Path: <rutgers!labrea!Lindy![e-mail]>
Message-Id: <[e-mail]>
Date: 18 Sep 87 15:46:50 GMT
From: rutgers!labrea!Lindy![e-mail] (Andy Valencia)
To: [e-mail]
Subject: Re: Packet software
References: <[e-mail]> <[e-mail]> <[e-mail]>

In article <[e-mail]> [e-mail] (Phil R. Karn) writes:
>HDLC cards are in fact appearing for the IBM PC and clones.  Here's a list
>of the ones I know about:
> .....
>Regular IBM SLDC adaptor card. I believe these are no longer being made,
>but are occasionally available surplus. Uses the Intel 8273. Provides only
>one channel, no on-board modem. Requires TWO interrupt vectors (IRQ3 and 4),
>which in my mind is a fatal flaw (you lose BOTH asynch comm ports!) I have
>one, but have no software for it.
    Sorry, Phil.  I have worked extensively with these guys, and I
don't think you have it quite right.  It requires ONE interrupt (IRQ4--
conflicts with your second serial port), and ONE DMA channel.  It is also
designed for SDLC, which is a half-duplex protocol; trying to run full
duplex is extremely difficult.  IBM does indeed still sell these cards,
and for SDLC, they're a pretty good choice.  The technical reference for
the PC has a section on the card, if you're interested in programming
it, or I have some Modula-2 routines you could steal from.

    Another one is the Western Digital WD4025.  This provides a level-two
HDLC interface, with a number of level-two events processed for you by
the card.  However, do *NOT* buy the X.25 software they offer (it's called
"FleX.25")--the thing is a complete disaster, and WD doesn't even employ
anybody who can even talk about it.

    These opinions are my own, blah blah blah....

                    Andrew Valencia
                    [e-mail]
                    [e-mail]


22-Sep-87 15:35:17-EDT,4812;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 22 Sep 87 15:35-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Tue, 22 Sep 87 12:49:27 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Tue, 22 Sep 87 12:47:55 EDT
Received: by june.cs.washington.edu (5.52.1/6.6)
    id AA16127; Tue, 22 Sep 87 09:49:15 PDT
Return-Path: <bellcore!faline![e-mail]>
Message-Id: <[e-mail]>
Date: 20 Sep 87 02:02:12 GMT
From: bellcore!faline![e-mail] (Phil R. Karn)
To: [e-mail]
Subject: W3IWI report on LA conference

From: Tom Clark, W3IWI
Subject: 1987 Net Conference Report

This past weekend (8/29) several of us from the Balto/Wash/Philly area
(WB6RQN, N4HY, KA9Q, W3IWI) attended the ARRL Networking Conference in LA.
For more details, conference proceedings are available from ARRL, but here
are some personal observations.

The event was tied to the monthly TRW swapfest which started at 7AM and was
pretty well done by 10 AM. The combination of the swapfest, plus a lot of
packet activity in the Greater Disneyland Basin, plus the excellent tech-
nical program yielded an attendance around 300 for the all-day meeting.
Attendees from afar included LU and DL.

The protocol 'wars' continued unabated. The TCP/IP camp was represented in
papers by KA9Q, K3MC, N3EUA, PA0GRI, WB6RQN and N3CVL. The efforts by the
TCP group are quite spectacular and serve as a model of how a team can
function as well as how the network can work. N2DSY and W2VY presented
a status report on the COSI software development (which has already been
circlated thru MDCBBS channels) as well as showing off two prototypes of
GLB's 220 MHz digital radio and distributing KA2BQE's new PRMBS BBS code.
Texnet was represented by N5EG who told of the progress in tying the state
of Texas together in a large network. Although the NET/ROM folks made no
formal presentations, they were represented by both W6IXU and WA8DED who
held an ad hoc NET/ROM sysop meeting after the main meeting ended.  My
personal impression is that NET/ROM plus TCP/IP are on the verge of winning
the war, based on the state of development, proven robustness and public
acceptance.

There was a lot of discussions in the meeting about the lower layers ---
radios and modems. W3IWI was quoted as saying "the bit stuffers have shown
that they can do their job -- now packet radio's biggest problems are
radios!". The 56 kbaud efforts of WA4DSY in Atlanta have caught the attention
of a lot of people and certainly has set a standard of excellence to measure
future efforts against. In the measuring arena, K9NG described techniques
for measuring (and tweaking) bit error rate performance of modems. LU4DXT
told of his comparisons of the JARL/QEX/TAPR/IWI 1200 baud psk demod, the
G3RUH PSK demod, and XR2211 and AMD7910 AFSK demods. I was quite pleased
to see that mine 'won the contest' and was within 2 dB of a perfect
theoretical modem (the 2211 lost by a bunch!).

As part of the 'next wave' W3IWI and N4HY told of our efforts in digital
signal processing (DSP) using TMS32010 co-processors in stock PC's which
could be used to implement optimum modems, digital speech processors, weak
signal detection algorithms, test equipment, etc. all in software. W3IWI
told of weak signal tests (EME with Oscar-10 class stations) that were in
progress and N4HY told about his software implementation of a FO-12 PSK
demodulator. We then announced that AMSAT and TAPR were sponsoring a DSP
project for a team  hard-core intense experimentalists and that we are
now signing people up and taking orders for a group buy of 32010 boards.

NK6K and WB6YMH told of the software they have written (based on the KISS
TNC) which does an in depth statistical analysis of on-the-air performance
(measuring channel loading, number of retries, collisions, etc.) and showed
what 145.01 looks like in Smog City. We should get a copy of their code and
run similar tests in this area to see if our preconcieved notions are bourne
out in facts.

There were a number of 'applications' presentations -- full-duplex digis,
tracking of health and welfare information in emergencies (based in large
measure on our experiences last January after the train wreck, I was pleased
to note), message routing algorithms, etc. I refer you to the proceedings
for more details.

The out-of-towners stayed at one motel, so there was a lot of late night,
bleary-eyed discussions, disk copying, and generally poking barbed jabs
at each other that made the whole trip great.

Congratulations to NK6K, WA6JPR, WA2KDL and the TRW Radio Club for a
superb job.

73 de Tom, W3IWI


22-Sep-87 15:49:12-EDT,4787;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 22 Sep 87 15:49-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Tue, 22 Sep 87 12:56:40 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Tue, 22 Sep 87 12:56:18 EDT
Message-Id: <[e-mail]>
Received: from (MAILER)MITVMA.BITNET by MITVMA.MIT.EDU on 09/22/87 at
  12:58:53 EDT
X-Delivery-Notice:  SMTP MAIL FROM does not correspond to sender.
Received: from YMIR.BITNET (SMTPUSER) by MITVMA.MIT.EDU (Mailer X1.25)
  with
 BSMTP id 7640; Tue, 22 Sep 87 12:58:43 EDT
Received: from HMCVAX.BITNET by YMIR.BITNET; Tue, 22 Sep 87 09:52 PDT
Date: Tue, 22 Sep 87 09:50 PDT
From: PMDF Mail Server  <[e-mail]>
Subject: Undeliverable mail
To: [e-mail]

The message could not be delivered to:

Addressee: RICHAR_C
Reason:
  %MAIL-E-NOSUCHUSR, no such user RICHAR_C at node HMCVAX

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

Received: from JNET-DAEMON by HMCVAX.BITNET; Tue, 22 Sep 87 09:49 PDT
Received: From HMCVAX(POSTMAST) by HMCVAX with RSCS id 5352 for
 RICHAR_C@HMCVAX; Tue, 22-SEP-1987 09:48 PDT
Received: by UIUCVMD (Mailer X1.25) id 8970; Sat, 19 Sep 87 15:33:22 CDT
Date: Fri, 18 Sep 87 11:32:26 PDT
From: [e-mail]
Subject: Re: HDLC vs. async framing on packet radio.
Sender: Packet Radio <[e-mail]>
To: Packet operator <JLULEJIA@FOURCC>
Reply-to: [e-mail]
X-To:         [e-mail]

     Re: HDLC vs.  async framing on packet radio:

     I was a member of the (in)famous VADCG (Vancouver Amateur Digital Radio
Group) from close to its very beginning.  (1978?)  HDLC was chosen because
we were producing a high speed 220 Mhz digital radio "Real Soon Now", and
the surplus 202 modems that dropped into our hands were merely a "stop gap"
measure to get the average ham, who already owned a two metre radio,
interested enough to eventually acquire a 220 Mhz digital radio.  As usual,
the stop gap became the de facto standard (and we *all* know how dangerous
de facto standards are, don't we?  :-).  The VADCG (Bob Livingston, VE7CYB
did the work) produced a 202 modem designed with packet radio in mind, as
"Real" 202 modems were huge, becoming scarce on the surplus market, and
breaking down too often.  This, and then the large number of TAPR TNCs with
onboard 202 modems, sealed the fate of packet radio modulation standards for
some time to come.

     The VADCG board was (and is) designed for high speed packet without
modification, for the time when appropriate modems and radios become
available.  It was humourous to here about the mods required to get a
TAPR-style TNC working at 56 kbps.  A VADCG unit would have just "plugged
in".  (The software, on the other hand, may have been a completely different
matter.)

     The reason for building "smart" TNCs, as opposed to using a personal
computer to drive the modem directly: in 1978, personal computers were
*expensive*.  The goal of the original VADCG TNC project was to produce a
system that would allow the average ham to get into packet radio cheaply.
The original unit included a current loop interface so that old Miller code
teletypes could be used as terminals!  At that time, we expected to have a
personal computer or two available via packet radio, but that the bulk of
the traffic would still be RTTY replacement.  (Yes, we did expect that to
change over the years, although maybe not as quickly as it did.)  I agree
that if it makes more sense to some people to install HDLC hardware in their
personal computer (of whatever size) than it does to attach a TNC, then *DO
IT*!  The reasons for needing a TNC are dwindling.  (Also, Phil, if you feel
that async framing at 1200 bps on two metres is appropriate, then *DO IT*!
If the amateur community agrees with you, and you produce a commercial
product that does it, they'll buy it!  I had to include the dig about a
commercial product, since I feel that the main reason for the popularity of
the TAPR TNC over the VADCG TNC was easy availability of the former.)

     (I use the past tense when talking about my membership in VADCG since I
haven't attended a meeting in quite some time.  I do communicate with some
of the members occasionally, though.  At the early meetings, I was the lone
voice in support of datagram, rather than connection oriented protocols.  I
still feel that a datagram service is more appropriate for most amateur
packet communication, and I am strongly opposed to any service that
*requires* a central controller or server, which was another hot issue nine
years ago.)
22-Sep-87 15:50:19-EDT,1877;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 22 Sep 87 15:50-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Tue, 22 Sep 87 12:56:29 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Tue, 22 Sep 87 12:56:07 EDT
Received: by june.cs.washington.edu (5.52.1/6.6)
    id AA16235; Tue, 22 Sep 87 09:53:12 PDT
Return-Path: <bellcore!faline![e-mail]>
Message-Id: <[e-mail]>
Date: 18 Sep 87 22:41:19 GMT
From: bellcore!faline![e-mail] (Phil R. Karn)
To: [e-mail]
Subject: Re: HDLC vs. async framing on packet radio.
Summary: packet history
References: <[e-mail]>

Richard, thanks for the look back. Your recollection of the early VADCG
philosophy matches the understanding I had of it last year when I wrote
my Gateway article "Why Do We Even Need TNCs Anyway?"  Lots of things
have happened since the first TNC was built that should cause us to
reconsider the "TNC+terminal" model.

People often complain that although they have TNCs, they don't want to
get real computers to run protocols like TCP/IP. This is bass-ackwards!
A better question would be "I already have a general purpose computer.
So why do I need to buy this specialized computer called a TNC just to
put my computer on packet radio?"  We have to convince people that what
we really should be doing is COMPUTER networking, not just terminal
switching.  After all, concepts like "file transfer" and "mail transfer"
don't have much meaning without a file system!

It's now probably too late to use asynch framing for amateur packet
radio. TNCs (especially the KISS variety) are now widespread and
available enough to provide any computer having a serial port with
relatively inexpensive raw HDLC capability.

Phil


22-Sep-87 15:51:22-EDT,4812;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 22 Sep 87 15:51-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Tue, 22 Sep 87 12:49:27 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Tue, 22 Sep 87 12:47:55 EDT
Received: by june.cs.washington.edu (5.52.1/6.6)
    id AA16127; Tue, 22 Sep 87 09:49:15 PDT
Return-Path: <bellcore!faline![e-mail]>
Message-Id: <[e-mail]>
Date: 20 Sep 87 02:02:12 GMT
From: bellcore!faline![e-mail] (Phil R. Karn)
To: [e-mail]
Subject: W3IWI report on LA conference

From: Tom Clark, W3IWI
Subject: 1987 Net Conference Report

This past weekend (8/29) several of us from the Balto/Wash/Philly area
(WB6RQN, N4HY, KA9Q, W3IWI) attended the ARRL Networking Conference in LA.
For more details, conference proceedings are available from ARRL, but here
are some personal observations.

The event was tied to the monthly TRW swapfest which started at 7AM and was
pretty well done by 10 AM. The combination of the swapfest, plus a lot of
packet activity in the Greater Disneyland Basin, plus the excellent tech-
nical program yielded an attendance around 300 for the all-day meeting.
Attendees from afar included LU and DL.

The protocol 'wars' continued unabated. The TCP/IP camp was represented in
papers by KA9Q, K3MC, N3EUA, PA0GRI, WB6RQN and N3CVL. The efforts by the
TCP group are quite spectacular and serve as a model of how a team can
function as well as how the network can work. N2DSY and W2VY presented
a status report on the COSI software development (which has already been
circlated thru MDCBBS channels) as well as showing off two prototypes of
GLB's 220 MHz digital radio and distributing KA2BQE's new PRMBS BBS code.
Texnet was represented by N5EG who told of the progress in tying the state
of Texas together in a large network. Although the NET/ROM folks made no
formal presentations, they were represented by both W6IXU and WA8DED who
held an ad hoc NET/ROM sysop meeting after the main meeting ended.  My
personal impression is that NET/ROM plus TCP/IP are on the verge of winning
the war, based on the state of development, proven robustness and public
acceptance.

There was a lot of discussions in the meeting about the lower layers ---
radios and modems. W3IWI was quoted as saying "the bit stuffers have shown
that they can do their job -- now packet radio's biggest problems are
radios!". The 56 kbaud efforts of WA4DSY in Atlanta have caught the attention
of a lot of people and certainly has set a standard of excellence to measure
future efforts against. In the measuring arena, K9NG described techniques
for measuring (and tweaking) bit error rate performance of modems. LU4DXT
told of his comparisons of the JARL/QEX/TAPR/IWI 1200 baud psk demod, the
G3RUH PSK demod, and XR2211 and AMD7910 AFSK demods. I was quite pleased
to see that mine 'won the contest' and was within 2 dB of a perfect
theoretical modem (the 2211 lost by a bunch!).

As part of the 'next wave' W3IWI and N4HY told of our efforts in digital
signal processing (DSP) using TMS32010 co-processors in stock PC's which
could be used to implement optimum modems, digital speech processors, weak
signal detection algorithms, test equipment, etc. all in software. W3IWI
told of weak signal tests (EME with Oscar-10 class stations) that were in
progress and N4HY told about his software implementation of a FO-12 PSK
demodulator. We then announced that AMSAT and TAPR were sponsoring a DSP
project for a team  hard-core intense experimentalists and that we are
now signing people up and taking orders for a group buy of 32010 boards.

NK6K and WB6YMH told of the software they have written (based on the KISS
TNC) which does an in depth statistical analysis of on-the-air performance
(measuring channel loading, number of retries, collisions, etc.) and showed
what 145.01 looks like in Smog City. We should get a copy of their code and
run similar tests in this area to see if our preconcieved notions are bourne
out in facts.

There were a number of 'applications' presentations -- full-duplex digis,
tracking of health and welfare information in emergencies (based in large
measure on our experiences last January after the train wreck, I was pleased
to note), message routing algorithms, etc. I refer you to the proceedings
for more details.

The out-of-towners stayed at one motel, so there was a lot of late night,
bleary-eyed discussions, disk copying, and generally poking barbed jabs
at each other that made the whole trip great.

Congratulations to NK6K, WA6JPR, WA2KDL and the TRW Radio Club for a
superb job.

73 de Tom, W3IWI


22-Sep-87 15:54:36-EDT,4467;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 22 Sep 87 15:54-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Tue, 22 Sep 87 13:01:49 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Tue, 22 Sep 87 13:01:28 EDT
Received: by june.cs.washington.edu (5.52.1/6.6)
    id AA16606; Tue, 22 Sep 87 10:03:46 PDT
Return-Path: <bellcore!faline![e-mail]>
Message-Id: <[e-mail]>
Date: 18 Sep 87 02:37:20 GMT
From: bellcore!faline![e-mail] (Phil R. Karn)
To: [e-mail]
Subject: Re: The Realities of Networking
Keywords: moratorium  rationality
References: <[e-mail]> <[e-mail]> <[e-mail]>

>  The stated "illegality" of some of our proposals is absurd !

I would like to say that Tom's idea for "pseudo-source routing" in his
COSI code when the far-end user isn't running a higher layer protocol is
actually a rather clever hack.  As long as no packets are generated that
indicate a pseudo-address (e.g., "201101") instead of a real amateur
callsign as the source or transmitter, I don't see any real legal
problems with it. Tom deserves credit for a much better solution to the
problem than that used by NET/ROM.

However, as with all "clever hacks", it compromises the cleanliness of
the system design. You may not think such aesthetic issues are very
important, but believe me they have a way of coming back to bite you in
the future.  I much prefer (and I think Tom and Gordon agree with me)
that END USERS should support the higher level protocol themselves if at
all possible, avoiding the need for such "clever hacks".  Now as to
*which* higher level protocol should be used, well...

Ahem. While we're on "legality", consider a recent item I saw on the
local 2m PBBS. Apparently the Australians have been forced to shut down
their NET/ROM network because it doesn't meet government requirements
for identification.  As I understand their rules, each packet must
identify the sending station as well as the originating station, if the
two are distinct. The problem is not with NET/ROM's ad-hoc internal
protocols, but rather with the "user spoofing" technique NET/ROM uses on
its "downlinks" to ordinary AX.25 sites. (For those who are not familiar
with NET/ROM, it uses the initiating user's callsign in the source field
of the ordinary AX.25 packets it sends to the final destination, making
it "think" it's talking to you directly.)

Now consider that datagram (connectionless) protocols inherently
identify every packet. One example is the address sublayer of AX.25,
which carries full amateur callsigns in each packet. So does the
internal network layer of NET/ROM.  If end users ran NET/ROM's so-called
"transport" protocol on their own machines, it would become a *true*
transport protocol, eliminating "downlinks," address spoofing and
Australian legal objections. The AX.25 link layer addresses would
identify the immediate transmitter and receiver, while the NET/ROM
network layer addresses would identify the packet's originator and its
ultimate destination. This makes enforcement very straightforward. If
the transmission is QRMing half the TVs in town, you go after the guy in
the AX.25 Level 2 source field. If the packet contains excerpts from a
pornographic novel, you go after the guy in the NET/ROM network layer
source field (and probably the guy in the AX.25 source field too, sigh).

IP addresses are too small to contain callsigns, but you can always look
them up in the the (public) address table. (If this isn't sufficient,
it's easy to add the originating callsign to each IP header in the form
of an IP option that is otherwise ignored by the IP gateways. Or you can
run IP directly on top of NET/ROM's datagram network layer.)

On the other hand, virtual-circuit (connection-oriented) protocols go to
extreme lengths solely to keep addresses *out* of each packet. (Too much
header overhead, and all that.) If you miss the call setup packet, you
have no idea who's communicating. So it seems to me that if there are
legitimate regulatory and "international acceptance" factors to consider
in amateur packet radio protocol development, they are driving us toward
DATAGRAM protocols!

> "Connection-oriented Open Systems Interconnection..."

An oxymoron if I ever heard one... :-)

Phil


22-Sep-87 16:18:03-EDT,1557;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 22 Sep 87 16:18-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Tue, 22 Sep 87 13:03:53 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Tue, 22 Sep 87 13:03:32 EDT
Received: by june.cs.washington.edu (5.52.1/6.6)
    id AA16703; Tue, 22 Sep 87 10:05:51 PDT
Return-Path: <ihnp4!homxb!hotps!ka2qhd![e-mail]>
Message-Id: <[e-mail]>
Date: 17 Sep 87 14:40:07 GMT
From: ihnp4!homxb!hotps!ka2qhd![e-mail] (Thomas A. Moulton)
To: [e-mail]
Subject: Re: More on Internationally Blessed Protocols
References: <[e-mail]> <[e-mail]> <[e-mail]>

I never would mean to imply that AX.25 would be anything near a CCITT standard

There have been a number of improvements in X.25 since 1980, many of which
don't effect the implementation, but do specify usage of things like the GFI

COSI is a X.25 LEVEL 3 running on top of AX.25 (level 2) packet switch
also all that should be needed to connect it to Telenet is a box(PC) that
supports both AX.25 and X.25 Level 2, without any loss of packet level
features (since it's the same protocol at Level 3)
--
Life is too short to be mad about things.
Thomas A. Moulton, W2VY          Packet: w2vy@kd6th  Voice: 145.190 (r)
(201) 779-W2VY                   uucp: ...!ihnp4!bellcore!hotps!ka2qhd!w2vy
FAX: [phone]              [phone] x3226 (w)


22-Sep-87 18:51:56-EDT,959;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 22 Sep 87 18:51-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Tue, 22 Sep 87 16:29:53 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Tue, 22 Sep 87 16:29:34 EDT
Message-Id: <[e-mail]>
Posted-From: The MITRE Corp., Bedford, MA
To: [e-mail]
Subject: COCO on packet?
Date: Tue, 22 Sep 87 16:32:35 EDT
From: [e-mail]

Greetings and salutations...Having recently fallen prey to a REALLY CHEAPLY
priced 16k COCO on sale at R.S., I now need to find a use for it!  Strikes me
that someone MUST have put this device to work on packet.  Does anyone in
net-land have experience doing so??  (I've been reluctant to tie up my Apple
2-e on packet since it is running various things in my home 7X24 already).

    Thanks in advance...Jim KC0EL, Colo. Spgs., CO
22-Sep-87 19:17:47-EDT,959;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 22 Sep 87 19:17-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Tue, 22 Sep 87 16:29:53 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Tue, 22 Sep 87 16:29:34 EDT
Message-Id: <[e-mail]>
Posted-From: The MITRE Corp., Bedford, MA
To: [e-mail]
Subject: COCO on packet?
Date: Tue, 22 Sep 87 16:32:35 EDT
From: [e-mail]

Greetings and salutations...Having recently fallen prey to a REALLY CHEAPLY
priced 16k COCO on sale at R.S., I now need to find a use for it!  Strikes me
that someone MUST have put this device to work on packet.  Does anyone in
net-land have experience doing so??  (I've been reluctant to tie up my Apple
2-e on packet since it is running various things in my home 7X24 already).

    Thanks in advance...Jim KC0EL, Colo. Spgs., CO
22-Sep-87 19:36:28-EDT,940;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 22 Sep 87 19:36-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Tue, 22 Sep 87 17:27:56 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Tue, 22 Sep 87 17:27:45 EDT
Message-Id: <[e-mail]>
Received: from (MAILER)MITVMA.BITNET by MITVMA.MIT.EDU on 09/22/87 at
  17:30:28 EDT
X-Delivery-Notice:  SMTP MAIL FROM does not correspond to sender.
Received: from UBVMS (MAILER) by MITVMA.MIT.EDU (Mailer X1.25) with
  BSMTP id
 9090; Tue, 22 Sep 87 17:30:25 EDT
Date: Tue, 22 Sep 87 17:25 EDT
From: [e-mail]
Subject: Mailing list removal
To: [e-mail]
X-Vms-To: IN%"[e-mail]"


Please delete one of my entries in your mailing list. I'm receiving
two copies off Packet-Radio.

Thank you,

Nestor A. Vega

22-Sep-87 19:46:51-EDT,3837;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 22 Sep 87 19:46-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Tue, 22 Sep 87 17:26:37 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Tue, 22 Sep 87 17:26:21 EDT
Received: by june.cs.washington.edu (5.52.1/6.6)
    id AA24560; Tue, 22 Sep 87 14:28:26 PDT
Return-Path: <bellcore!faline![e-mail]>
Message-Id: <[e-mail]>
Date: 22 Sep 87 03:49:27 GMT
From: bellcore!faline![e-mail] (Phil R. Karn)
To: [e-mail]
Subject: Re: More on Internationally Blessed Protocols
Summary: internetworking X.25 isn't that simple
References: <[e-mail]> <[e-mail]> <[e-mail]>

In article <[e-mail]>, [e-mail] (Thomas A. Moulton) writes:

> COSI is a X.25 LEVEL 3 running on top of AX.25 (level 2) packet switch
> also all that should be needed to connect it to Telenet is a box(PC) that
> supports both AX.25 and X.25 Level 2, without any loss of packet level
> features (since it's the same protocol at Level 3)

It's not quite that simple. Telenet will give you one X.121 address per
interface that you buy from them. Where are you going to get all those
other X.121 addresses you need to assign to individual switches without
conflicting with the others that already exist in Telenet and the rest
of the world?  Even if you use "subaddresses" (or whatever they're
called) under a single Telenet address, you're constraining yourself to
only one access gateway. If it goes down you're stuck; so much for
emergencies.

So let's assume you have instead applied for an X.121 DNIC (Data Network
Identification Code) from the FCC so you can assign your own addresses.
I'll ignore for the moment that only 10 DNICs are allocated to the
entire United States (according to my admittedly old 1980 copy of X.121
-- another block could have been assigned since then). Even if you get
one, you've left all the non-US users to fend for themselves.  To do it
right, you really should go directly to the CCITT and formally ask them
to assign a "country code" to amateur radio. The PTTs are already
jealous and paranoid enough about things like "third party traffic" that
you may very well provoke them into banning amateur packet radio
altogether in their countries. Good luck.

Even if you get your DNIC, though, you have to interface with Telenet
(or any other Public Data Network) using the internetwork protocol X.75,
not X.25. This is how the carriers all connect to each other. While X.75
isn't *that* much different from or harder than X.25 to implement, I
have heard a Telenet person say that they install an X.75 gateway only
when it is in their own "business interest" to do so. In other words,
X.25 is a tariffed service that they must sell to anyone willing to pay
(and pay and pay...). As far as I know, X.75 is not. Good luck.

All this shows the beauty of *encapsulation* internetworking a la ARPA
IP (or ISO IP, for that matter). You are just another ordinary customer
on whatever subnetworks you decide to use, be they 10 mb Ethernets, 9600
bps X.25 nets, 1200 bps amateur packet radio links or tin cans and
strings (this list is not necessarily in descending order of speed and
reliability. :-) You need no special permissions, features or
non-tariffed services. The only addresses the carrier must assign are
those given to ordinary subscribers; you control and manage your own
internet address space. You, the group of users that simply want
transparent communication using whatever mix of technology that you (not
the carriers) consider appropriate, are able to do so despite the best
efforts of the carriers to stop you. :-)

Phil


22-Sep-87 21:49:55-EDT,1475;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 22 Sep 87 21:49-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Tue, 22 Sep 87 20:04:08 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Tue, 22 Sep 87 20:02:45 EDT
Received: by marlin.nosc.mil (5.58/1.27)
    id AA00661; Tue, 22 Sep 87 17:03:51 PDT
Date: Tue, 22 Sep 87 17:03:51 PDT
From: [e-mail] (James N. Price)
Message-Id: <[e-mail]>
To: [e-mail]
Cc: [e-mail]
Subject: How do I ring the bell?

-------
Compared to most of the erudite discussions on this net, the following
question will seem terribly mundane, but...

I have an MFJ TNC and am using a CP/M CPU with Modem/7 software.
I've been quite successful in setting up the TNC the way I want it,
with one exception:  how do I get the TNC to "ring the bell" on the
CPU when a connect takes place?  I've scoured the manual and can't
find an instruction that seems to fit the bill.  <CTRL-G> rings the
bell on my computer.

Another thing I haven't figured how to do is to write disk files.
I fear that my Modem/7 (Ward Christensen protocol) software precludes
that function since it waits for a handshake from a host computer,
and the TNC, as far as I know, doesn't know how to handshake.

Anywho--help on the bell would be appreciated.  Thanks--

Jim, K6ZH, [e-mail]
-------

22-Sep-87 22:42:23-EDT,916;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 22 Sep 87 22:42-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Tue, 22 Sep 87 20:37:55 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Tue, 22 Sep 87 20:37:35 EDT
Received: from Phobos.Caltech.Edu by DEImos.Caltech.Edu with DECNET ;
      Tue, 22 Sep 87 17:37:52 PDT
Date:     Tue, 22 Sep 87 17:36:54 PDT
From: [e-mail] (Martin Ewing)
Message-Id: <[e-mail]>
Subject:  seeing double
To: [e-mail]

Referring to the note from Nestor A. Vega:

WE WE GET GET TWO TWO, TOO TOO.

Perhaps a brother (sister?) packeteer can sort out the connectivity of
PACKET-RADIO as it appears on the Internet.  We most often receive two
copies of every message.

Martin, AA6E
22-Sep-87 23:08:33-EDT,1604;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 22 Sep 87 23:08-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Tue, 22 Sep 87 17:25:48 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Tue, 22 Sep 87 17:25:13 EDT
Received: by june.cs.washington.edu (5.52.1/6.6)
    id AA24528; Tue, 22 Sep 87 14:27:35 PDT
Return-Path: <ihnp4!homxb!hotps!ka2qhd![e-mail]>
Message-Id: <[e-mail]>
Date: 21 Sep 87 12:55:11 GMT
From: ihnp4!homxb!hotps!ka2qhd![e-mail] (Thomas A. Moulton)
To: [e-mail]
Subject: Re: The Realities of Networking
Summary: Users should run the upper level protocols
Keywords: moratorium  rationality
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>


Phil, We totally agree that users should run AN upper level protocol!

And as I told you at the last RATS meeting this extra routing info in
the digipeat field is ONLY FOR LEVEL 2 ONLY USERS! AND ONLY FOR THE
LEVEL 2 ONLY CONNECTION, the internodal connections will use the two
switch callsigns.

COSI does NOT have the identification problem that NET/ROM has

We agree on the general design of a network, it's just the bits/bytes
we disagree on...
c'ya

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


23-Sep-87 00:04:49-EDT,1310;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 23 Sep 87 00:04-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Tue, 22 Sep 87 22:32:45 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Tue, 22 Sep 87 22:32:34 EDT
Message-Id: <[e-mail]>
Received: from (MAILER)MITVMA.BITNET by MITVMA.MIT.EDU on 09/22/87 at
  22:35:13 EDT
X-Delivery-Notice:  SMTP MAIL FROM does not correspond to sender.
Received: from USU.BITNET (smtpuser) by MITVMA.MIT.EDU (Mailer X1.25)
  with
 BSMTP id 9882; Tue, 22 Sep 87 22:35:09 EDT
Date: Tue, 22 Sep 87 20:05 MDT
From: "BITNET BOBW@USU, Bob Wood WA7MXZ"
  <[e-mail]>
Subject: RE: How do I ring the bell?
To: [e-mail]
X-Vms-To: USU::IN%"[e-mail]"

To ring the bell on the computer to indicate a connect you must be running
version 1.1.3b or later Howie code for the TNC-2. That software update had the
Bell on connect feature. Set CBELL ON to activate it. Also I use SMODEM36 for
CPM to TNC communication and just set it to CAPTURE a file. This mode does
not require any handshake other than XON/XOFF. I am not sure if the same
CAPTURE command is in modem7.
73, Bob Wood  BOBW%USU.BITNET
23-Sep-87 01:17:14-EDT,1331;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 23 Sep 87 01:17-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Tue, 22 Sep 87 23:32:46 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Tue, 22 Sep 87 23:32:33 EDT
Message-Id: <[e-mail]>
Received: from (MAILER)MITVMA.BITNET by MITVMA.MIT.EDU on 09/22/87 at
  23:35:17 EDT
Received: from NDSUVM1.BITNET by MITVMA.MIT.EDU (Mailer X1.25) with
  BSMTP id
 0153; Tue, 22 Sep 87 23:35:14 EDT
Received: by NDSUVM1 (Mailer X1.24) id 7714; Tue, 22 Sep 87 22:31:37 CDT
Date:         Tue, 22 Sep 87 22:25:03 CDT
From: Todd Enders WD0BCI
  <[e-mail]>
Subject:      The challenge
To: [e-mail]


     O.K. folks, here's my *brilliant* idea to settle the protocol wars:

Set up 2 identical networks, one TCP/IP and one OSI (same speed, number of
nodes/users, etc.).  Using simulated traffic generated by computer created
users, bombard each network with traffic, and see who gets the most through-
put.  What say guys?

73,

Todd Enders WD0BCI  | BITNET: MN007334@NDSUVM1
            | ARPA: [e-mail]
            | UUCP: ...!ihnp4!psuvax1!ndsuvm1.bitnet!mn007334
23-Sep-87 01:43:19-EDT,1331;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 23 Sep 87 01:43-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Tue, 22 Sep 87 23:32:46 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Tue, 22 Sep 87 23:32:33 EDT
Message-Id: <[e-mail]>
Received: from (MAILER)MITVMA.BITNET by MITVMA.MIT.EDU on 09/22/87 at
  23:35:17 EDT
Received: from NDSUVM1.BITNET by MITVMA.MIT.EDU (Mailer X1.25) with
  BSMTP id
 0153; Tue, 22 Sep 87 23:35:14 EDT
Received: by NDSUVM1 (Mailer X1.24) id 7714; Tue, 22 Sep 87 22:31:37 CDT
Date:         Tue, 22 Sep 87 22:25:03 CDT
From: Todd Enders WD0BCI
  <[e-mail]>
Subject:      The challenge
To: [e-mail]


     O.K. folks, here's my *brilliant* idea to settle the protocol wars:

Set up 2 identical networks, one TCP/IP and one OSI (same speed, number of
nodes/users, etc.).  Using simulated traffic generated by computer created
users, bombard each network with traffic, and see who gets the most through-
put.  What say guys?

73,

Todd Enders WD0BCI  | BITNET: MN007334@NDSUVM1
            | ARPA: [e-mail]
            | UUCP: ...!ihnp4!psuvax1!ndsuvm1.bitnet!mn007334
23-Sep-87 04:13:12-EDT,986;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 23 Sep 87 04:13-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Wed, 23 Sep 87 03:03:02 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Wed, 23 Sep 87 03:01:06 EDT
Received: Wed, 23 Sep 87 00:02:38 PDT by orion.arpa (5.45/1.2)
Message-Id: <[e-mail]>
To: [e-mail]
Cc: [e-mail]
Subject: Re: The challenge
In-Reply-To: Your message of Tue, 22 Sep 87 22:25:03 -0500.
         <[e-mail]>
Date: Wed, 23 Sep 87 00:02:36 PDT
From: Milo S. Medin (NASA ARC Code ED) <[e-mail]>


Throughput is only one metric, and probably not the most important.
Functionality and availablity determine whether not throughput even
gets considered.  You have to view the network as a system, not just a
collection of parts...

                        Milo, KB6ADT

23-Sep-87 04:51:36-EDT,986;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 23 Sep 87 04:51-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Wed, 23 Sep 87 03:03:02 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Wed, 23 Sep 87 03:01:06 EDT
Received: Wed, 23 Sep 87 00:02:38 PDT by orion.arpa (5.45/1.2)
Message-Id: <[e-mail]>
To: [e-mail]
Cc: [e-mail]
Subject: Re: The challenge
In-Reply-To: Your message of Tue, 22 Sep 87 22:25:03 -0500.
         <[e-mail]>
Date: Wed, 23 Sep 87 00:02:36 PDT
From: Milo S. Medin (NASA ARC Code ED) <[e-mail]>


Throughput is only one metric, and probably not the most important.
Functionality and availablity determine whether not throughput even
gets considered.  You have to view the network as a system, not just a
collection of parts...

                        Milo, KB6ADT

23-Sep-87 16:10:37-EDT,1543;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 23 Sep 87 16:10-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Wed, 23 Sep 87 13:48:19 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Wed, 23 Sep 87 13:47:58 EDT
Received: by june.cs.washington.edu (5.52.1/6.6)
    id AA16288; Wed, 23 Sep 87 10:50:22 PDT
Return-Path: <rutgers!unirot![e-mail]>
Message-Id: <[e-mail]>
Date: 22 Sep 87 23:00:36 GMT
From: rutgers!unirot![e-mail] (Steve Miller)
To: [e-mail]
Subject: Yellow Pages for packet networks


I am wondering about methods used to find digipeaters that will create
a path between two nodes.  The Sun Microsystems NFS uses a scheme called
"Yellow Pages," where a master node broadcasts a database to several slave
nodes, any one of which can reply to requests from any node in the network
regarding addresses of a server.  Now, this idea is explicitly NOT for
creating multi-node paths (the idea is get you directly connected to
the node you want), but it could be expanded to multi-node paths (couldn't
it?).  I realize the problem is more complex that just finding a path;
load and propagation delays, as well as unreliable availability are all
factors.  Still, I wonder what is being done along these lines.

-WA4LDA fixed 2
--
        -Steve Miller  ihnp4!rutgers!unirot!srm

"The Fantasy Factory" is a trademark of Image Space, a New Jersey corporation.


23-Sep-87 16:19:58-EDT,1735;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 23 Sep 87 16:19-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Wed, 23 Sep 87 13:45:50 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Wed, 23 Sep 87 13:45:10 EDT
Received: by june.cs.washington.edu (5.52.1/6.6)
    id AA16130; Wed, 23 Sep 87 10:47:41 PDT
Return-Path: <bellcore!faline![e-mail]>
Message-Id: <[e-mail]>
Date: 23 Sep 87 00:00:33 GMT
From: bellcore!faline![e-mail] (Phil R. Karn)
To: [e-mail]
Subject: Re: The Realities of Networking
Summary: yes and no
Keywords: moratorium  rationality
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>

> And as I told you at the last RATS meeting this extra routing info in
> the digipeat field is ONLY FOR LEVEL 2 ONLY USERS! AND ONLY FOR THE
> LEVEL 2 ONLY CONNECTION, the internodal connections will use the two
> switch callsigns.

I fully understand that. I also think your solution is a better and more
clever one than the one NET/ROM uses.

> COSI does NOT have the identification problem that NET/ROM has

Yes and no. You avoid the specific problem that NET/ROM has in Australia
by adding extra information to the digipeat field. However, you're
creating a new and different problem INSIDE the network through your use
of connection oriented network layer protocols. This is a problem that
NET/ROM does not have. If the Australian "FCC" wants to see origination
information in every packet, then they have effectively banned
connection-oriented (virtual circuit) protocols, pure and simple.

Phil


23-Sep-87 16:25:19-EDT,4788;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 23 Sep 87 16:25-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Wed, 23 Sep 87 13:42:24 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Wed, 23 Sep 87 13:42:04 EDT
Received: by june.cs.washington.edu (5.52.1/6.6)
    id AA15987; Wed, 23 Sep 87 10:44:34 PDT
Return-Path: <bellcore!faline![e-mail]>
Message-Id: <[e-mail]>
Date: 23 Sep 87 06:20:14 GMT
From: bellcore!faline![e-mail] (Phil R. Karn)
To: [e-mail]
Subject: Re: The Realities of Networking
Summary: Another nail in the connection-oriented coffin
Keywords: australian packet
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>

I went rummaging through my ARRL Digital Committee files for some
background on "Australian rules" packet. :-) I found a paper entitled
"Review of Amateur Radio Service Packet Communications -- Policy Paper
>from the Wireless Institute of Australia" dated 20 October 1986.

The WIA is the Australian equivalent of the ARRL.  It drew up the policy
paper and filed it with the DoC (the Australian FCC) as a set of
recommendations for amateur packet radio regulations then being created.

The paper begins with an "executive summary" of what amateur packet
radio is all about.  It then discusses the two most popular protocols in
Australia at the time, V2 and AX.25.  V2 was the successor to the
original Vancouver (Canada) protocol, now known as V1.  Both V2 and
AX.25 use synchronous HDLC framing.  The major difference is in
addressing.  Unlike AX.25, which transmits full callsigns in every
frame, V2 transmits full callsigns only at the beginning and end of a
connection, and every N seconds during the QSO (where N is a settable
parameter).  Ordinary data packets contain only a "hashed" 16-bit
representation of the callsign.  Address collisions between stations
whose callsigns hash to the same value are possible, but statistically
unlikely.  V2 is about the closest we've come to a "virtual circuit"
link level packet radio protocol. The hashed addresses are similar
in some ways to the Logical Channel Number in a virtual circuit protocol,
though the comparison isn't perfect because radio is fundamentally a
connectionless medium and the hashed IDs are not allocated at a central
point.

While the summaries are mostly factual and accurate, a definite pro-V2,
anti-AX.25 bias is apparent.  All of the usual header overhead and
poor-channel arguments are made.  They even describe AX.25 as "following
datagram principles." (See, Gordon, I'm not the only one!)

The list of recommendations, however, asked that the DoC not limit or
specify any particular protocol, leaving that up to the amateurs to decide.

The 30 Sept 1986 response from the DoC is summarized at the end of the paper.
It stated that "packet radio is permitted in the Amateur Service", subject
to a list of conditions.  Number three on the list is the following:

    (3) EACH "PACKET" shall contain the originating stations identification,
    that of the destination station and the station transmitting (if
    different from the originating station). [emphasis mine]

and a note

    (A) Any protocol may be used for "packet" transmission provided it
    meets the identification requirements stipulated in (3) above.

And now, the clincher. Quoting from the DoC letter:

    Recognising that version "V2" of the Vancouver packet protocol can
    not meet the identification requirements stipulated until an updated
    version is released, the Department is prepared to authorise use of
    "V2" until 31 March 1987. It is anticipated that version "V3" will
    be available by this time and it is understood that "V3" will fully
    comply with the identification requirements."

Well, there you have it.  The Australian DoC ruled that identifying only
at the beginning and end of communication on a multiple access channel
isn't enough; you must identify the transmitter in EVERY packet.  This
basically requires a datagram-style link (level 2) header (e.g., AX.25).
Further, they consider it just as important that the ORIGINATOR (if
different than the transmitter) also be identified in EVERY packet.
Since originator/ultimate destination addressing is a network (level 3)
function, the inescapable conclusion is that the Australian DoC is
requiring datagram-style level 3 headers as well.

This is about as clear a statement as I can find about the
"international acceptability" of a network design methodology whose
overriding design goal is the elimination of network addresses from data
packets.

Phil


23-Sep-87 18:19:35-EDT,1989;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 23 Sep 87 18:19-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Wed, 23 Sep 87 13:43:28 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Wed, 23 Sep 87 13:43:06 EDT
Received: by june.cs.washington.edu (5.52.1/6.6)
    id AA16033; Wed, 23 Sep 87 10:45:28 PDT
Return-Path: <bellcore!faline![e-mail]>
Message-Id: <[e-mail]>
Date: 23 Sep 87 06:38:15 GMT
From: bellcore!faline![e-mail] (Phil R. Karn)
To: [e-mail]
Subject: Re: The challenge
Summary: throughput is only one dimension
References: <[e-mail]>

Todd, throughput is only one of many things to be evaluated. Just as
important, though perhaps not as easy to quantify, are attributes like
ease of use, flexibility, reliability, ease of implementation and
reconfiguration, etc.

In the near term, low level issues like modem speeds, channel access
techniques (and frequency allocations) and packet sizes are likely to
have a far greater impact on throughput than the specific type of
protocol being used.  However, as speeds reach the hundreds of kilobits
and the megabits region, connectionless protocols will pull ahead
because of the lower per-packet CPU processing overhead (not to mention
fewer low-level overhead packets to process).  This is one reason why
local area networks like Ethernet that operate at multi-megabit rates
are so overwhelmingly connectionless.


Just for the record, however, the current on-air amateur packet radio
speed record is (to my knowledge) held by the Atlanta group operating
TCP/IP at 56kbps rates on 70cm.  To be fair, the connection-oriented
crowd could probably do as well if they also used real computers and I/O
devices to run their protocols instead of trying to load everything on a
poor overworked 10-year-old Z-80 chip in a TNC.

Phil


23-Sep-87 19:32:21-EDT,1004;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 23 Sep 87 19:32-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Wed, 23 Sep 87 17:47:50 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Wed, 23 Sep 87 17:47:37 EDT
Received: from huey.udel.edu by Louie.UDEL.EDU id aa01338; 23 Sep 87 17:48 EDT
Date:     Wed, 23 Sep 87 17:39:50 EDT
From: [e-mail]
To: Steve Miller <rutgers!unirot![e-mail]>
Cc: [e-mail]
Subject:  Re:  Yellow Pages for packet networks
Message-Id:  <[e-mail]>

Steve,

See RFC-981, available from the Network Information Center via FTP. This
report discusses a multi-path routing algorithm and data-base maintenance protocol
call the "wiretap" algorithm. It listens for local traffic, including beacons,
ordinary traffic and possibly active probes, then constructs a data base
similar to what you might want the YP to do.

Dave
23-Sep-87 19:35:22-EDT,2189;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 23 Sep 87 19:35-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Wed, 23 Sep 87 17:44:22 EDT
Received: from ai.ai.mit.edu by EDDIE.MIT.EDU via Chaosnet with SMTP with sendmail-5.45/4.7 id <[e-mail]>; Wed, 23 Sep 87 17:44:04 EDT
Date: Wed, 23 Sep 87 17:54:01 EDT
From: Henry Minsky <[e-mail]>
To: [e-mail]
Message-Id: <[e-mail]>


      From InfoWorld, September 21, 1987

      Wireless LAN Communicates At 19.2 KBS Withing 300 Feet

       A wireless network that accomplishes communications through
      radio-frequency waves has been jointly developed Technology Development
      of Spokane, Washington, and RayNet Communications Systems Inc. of
      Vancouver, British Columbia.

       RAY-LAN uses Novell Netware-compatible software and includes an adapter
      card and independent, video-cassette size RF transciever for each
      computer. Inside a building, computers within 300 feet of each other
      communicate at 72 MHZ at speeds of up to 19.2 kilobits per second.

       Availability is scheduled for the first quarter of 1988, and the price
      will be competitive with comparable systems, said Al Turtle, project
      manager.

       Turtle said the system will be able to support users working at home at
      distances up to five miles given proper conditions. He added that the
      company sees Ray-LAN as useful as a subnetwork, bridging new
      installations to wired topologies, including Netbios, Microsoft's Net
      and LAN manager, TCP/IP, and other layered LAN standards.

       The company said FCC licensing for Ray-LAN involves a one-time license
      for the entire site, including all units. Turtle said the licensing
      chore is the same as that for CB radio.

       Ray-Net Communications Systems, Inc., E. 12806 Nora Ave., Spokane, WA
      99216.


I thought people would be interested in this. Particularly the statement
about the five mile range.

Henry, N1EZP

23-Sep-87 21:18:38-EDT,1424;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 23 Sep 87 21:18-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Wed, 23 Sep 87 17:11:17 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Wed, 23 Sep 87 17:11:00 EDT
Received: by umix.cc.umich.edu (5.54/umix-2.0)
    id AA00184; Wed, 23 Sep 87 17:14:52 EDT
Received: from SFU.Mailnet by um.cc.umich.edu via MTS-Net; Wed, 23 Sep 87 17:00:45 EDT
Date: Wed, 23 Sep 87 12:40:50 PDT
From: [e-mail]
To: [e-mail]
Message-Id: <[e-mail]>
Subject: Re: More on Internationally Blessed Protocols

     Phil, our campus X.25 network has neither its own DNIC or country
code.  We assign our own X.25 addresses, and interoperate with Datapac (and
the rest of the world) just fine, thank you.  The method of accessing a
particular X.25 address on our campus is to put the local address in the
Call Data field when establishing a call, but this is because Datapac does
not yet support subaddressing.

     It is not necessary to stack another protocol on top of X.25 to
internetwork with the existing X.25 packet-switched community, and by using
X.25 at the end points, you can communicate with *any* other X.25 host, not
just those who have also chosen to implement such kludged protocol stacks.

   - Richard Chycoski
24-Sep-87 20:00:47-EDT,1015;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 24 Sep 87 20:00-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Thu, 24 Sep 87 16:29:19 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Thu, 24 Sep 87 16:25:59 EDT
Received: by june.cs.washington.edu (5.52.1/6.6)
    id AA18338; Thu, 24 Sep 87 13:03:46 PDT
Return-Path: <somewhere![e-mail]>
Message-Id: <[e-mail]>
Date: 23 Sep 87 22:58:24 GMT
From: [e-mail]
Apparently-To: [e-mail]

To [e-mail]
Subject: MULTI-MODE TNCs


    Has anyone done a comparison between the three multi-mode TNCs
available now?  I'm thinking of getting one and would like to know of
any first hand experience with the AEA-232, HEATH-232 or the Kantronics
KAM.

    Any ideas on these would be appreciated.  Thanks.

    73, AHMAD N3FLX.





24-Sep-87 21:12:18-EDT,4536;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 24 Sep 87 21:12-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Thu, 24 Sep 87 17:04:32 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Thu, 24 Sep 87 17:03:42 EDT
Received: by june.cs.washington.edu (5.52.1/6.6)
    id AA18292; Thu, 24 Sep 87 13:02:10 PDT
Return-Path: <bellcore!faline![e-mail]>
Message-Id: <[e-mail]>
Date: 24 Sep 87 02:15:21 GMT
From: bellcore!faline![e-mail] (Phil R. Karn)
To: [e-mail]
Subject: Re: More on Internationally Blessed Protocols
References: <[e-mail]>

>      Phil, our campus X.25 network has neither its own DNIC or country
> code.  We assign our own X.25 addresses, and interoperate with Datapac (and
> the rest of the world) just fine, thank you.  The method of accessing a
> particular X.25 address on our campus is to put the local address in the
> Call Data field when establishing a call, but this is because Datapac does
> not yet support subaddressing.

>      It is not necessary to stack another protocol on top of X.25 to
> internetwork with the existing X.25 packet-switched community, and by using
> X.25 at the end points, you can communicate with *any* other X.25 host, not
> just those who have also chosen to implement such kludged protocol stacks.

>From your brief description, it appears you are indeed "stacking another
protocol on top of X.25", namely the special requirement to stick the
local address inside the Call Data field on incoming calls. This is
something I don't have to do when calling an "ordinary" X.25 site (one
with a regular X.121 address). Or, another way to look at it is that I
must "source route" my call to you, by first specifying your X.121
address on Datapac, and then *encapsulating* (magic word) the protocol
to access your local address as ordinary data in Datapac.

Your campus net is analogous to a voice PBX without "direct inward
dialing". The only problem with this (to carry the analogy further) is
that when I call you I had better be prepared to speak your attendant's
language (English? French?) so I can tell him/her the extension number.
This is something I don't have to do if your "extensions" all had their
own private directory numbers.  Now I don't know whether most public
dialup PADs have the ability to put "extension numbers" into the Call
Data field. If they do, fine. Otherwise I would be in as much trouble as
if your voice PBX attendant spoke only French, or if I tried calling a
modem on one of your PBX extensions with an autodialer, and kept
blasting him or her with touch tones.

NET/ROM in its present form has a similar problem caused by the
"backward compatibility" requirement. I have to set up the connection in
a step-by-step fashion, by first connecting to the local NET/ROM node
and then using that connection to carry a NET/ROM internal connect
command to that node's command parser, and so on until I finally reach
my destination. I must learn NET/ROM's internal command langugage, and I
must still use "source routing" for the NET/ROM entry and exit points.
Most human users can eventually learn this sort of thing (some may even
tolerate it), but computers find it extremely clumsy. True
computer-to-computer networking requires a *uniform*, clean and
transparent communications facility well suited for things like
transactions and file transfers, and that's why TCP/IP was developed.

By the way, this Sun workstation I'm typing on supports only TCP/IP and
Ethernet, but I use it all the time to communicate with several X.25
hosts that don't support that particular "kludged protocol stack". I
simply telnet (log in remotely) to another machine that has both
Ethernet/TCP/IP and an X.25 interface to Telnet, and then I originate a
PAD connection to Compuserve or Telemail or whatever. This sort of thing
is alright for "remote login" style operation, where a a human on one
end of the connection initiates everything and can recover from various
errors, but boy, it sure would be a heck of a lot easier if those
services supported TCP/IP. Why, it might even be practical to have my
EasyPlex and Telemail messages automatically delivered to my local
computer mailbox instead of having to go over to those services manually
and tediously wade through their "user friendly" user interfaces. What a
concept! :-)

Phil


27-Sep-87 20:03:17-EDT,1345;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 27 Sep 87 20:03-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Sun, 27 Sep 87 18:55:45 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Sun, 27 Sep 87 18:55:28 EDT
Received: from Phobos.Caltech.Edu by DEImos.Caltech.Edu with DECNET ;
      Sun, 27 Sep 87 16:01:32 PDT
Received: from DEImos.Caltech.Edu by Phobos.Caltech.Edu with DECNET ;
      Sun, 27 Sep 87 16:00:45 PDT
Received: from june.cs.washington.edu by DEImos.Caltech.Edu with INTERNET ;
      Sun, 27 Sep 87 15:59:47 PDT
Received: by june.cs.washington.edu (5.52.1/6.6)
    id AA04607; Sun, 27 Sep 87 15:58:10 PDT
Date: Sun, 27 Sep 87 15:58:10 PDT
From: [e-mail] (Clifford Neuman)
Return-Path: <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail]
Cc: [e-mail]
In-Reply-To: Martin Ewing's message of Tue, 22 Sep 87 17:36:54 PDT <[e-mail]>
Subject: seeing double

I have not been seeing the double message you are referring to on the
packet radio mailing list.  Please send me both copies of the next
message you receive on the list. Thanks,

    ~ Cliff
27-Sep-87 20:20:38-EDT,2059;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 27 Sep 87 20:20-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Sun, 27 Sep 87 19:15:24 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Sun, 27 Sep 87 19:15:06 EDT
Received: by june.cs.washington.edu (5.52.1/6.6)
    id AA04890; Sun, 27 Sep 87 16:20:30 PDT
Return-Path: <ihnp4!homxb!hou2d![e-mail]>
Message-Id: <[e-mail]>
Date: 24 Sep 87 20:57:13 GMT
From: ihnp4!homxb!hou2d![e-mail] (G.BEATTIE)
To: [e-mail]
Subject: Telenet Addresses vs Ports
Keywords: Telenet X.25

I am truely amazed at the fist-fighting that goes on here...

Regarding Telenet addressing...

You're all WRONG !

TELENET will provide multiple addresses to a single DTE
or groups of DTEs.  A variety of arrangements can be made
available at little or no cost.  Check their price list or
a Systems Engineer.

The WORST CASE example is that they charge SOME customers
for LARGE address spaces.

For example:  3110-201-00025-00 is a typical address.

The 3110 is the DNIC (Data Network Identification Code).
The 201 is the Telephone Area Code.
The 00025 is the subscriber number.
The 00 is the subaddress (which is useable by the host for
local routing within a small number of DTEs sharing an
address on the public network.)

In the case of several companies Telenet assigns them an
"unused" Area Code (eg. 102) and leaves them with 7 digits.
These digits are used for internal mappings in the customer's
network.  As stated before, some pay for this, some don't.
This is also on Telenet's price list.

I would appreciate it if folks would be a bit more humble
and start ASKING questions before shooting off their mouths !

Thanks,

        J. Gordon Beattie, Jr.

        MAIL
Unix:       ihnp4!hou2d!n2dsy
Amateur:    n2dsy @ kd6th/3100201

        TELEPHONE
Office:     201-615-2506
Home:       201-387-8896


27-Sep-87 20:37:29-EDT,2379;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 27 Sep 87 20:37-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Sun, 27 Sep 87 19:10:35 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Sun, 27 Sep 87 19:10:23 EDT
Received: by june.cs.washington.edu (5.52.1/6.6)
    id AA04806; Sun, 27 Sep 87 16:15:48 PDT
Return-Path: <rutgers!mcnc!ece-csc!ncrcae!ncr-sd!ncrlnk!ncrcam!ncrcpx![e-mail]>
Message-Id: <[e-mail]>
Date: 23 Sep 87 16:23:18 GMT
From: rutgers!mcnc!ece-csc!ncrcae!ncr-sd!ncrlnk!ncrcam!ncrcpx![e-mail] (R. Craig Peterson)
To: [e-mail]
Subject: Getting TCP/IP up on a TNC-2, and a UNIX processor
Keywords: TCP/IP TNC-2 help

I've got two MFJ TNC-2 clones which work quite nicely.  I've used
cu to talk to them and have made some split screen stuff that's
set up to work like talk.  That's nice.

I'd like to get into the real world of networking as available on the
ham airwaves.  I've got a 68010-based UNIX machine running SYSVR2.
I've got a TNC (or two) which would most likely need some new proms.
I need the software for the host to implement the necessary protocols.

Can anyone help me????  I've posted a few messages over the last four
months and haven't received any help yet (except some messages saying:
send xxx a message, or post to group yyy).  I'd REALLY like to try and
move up.

Another problem that I may well have around here is the fact that I am
somewhat isolated from civilization.  I'm about 40 Miles from
Columbus.  There's a couple of hams in town who would most likely get
involved with me in setting things up on their PC's, and we could most
likely get a link going to this part of the world, but I need a
starting point.

I'm quite familiar with UNIX, C, and have had exposure to various
protocols.  I've subscribed to the tcp-ip mailing list and have
gleaned some good information from there, however I don't feel that
this sort of question belongs there.  Maybe I'm wrong...

Please let me know what I can do.

Signed discouraged.

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


27-Sep-87 20:38:47-EDT,2172;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 27 Sep 87 20:38-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Sun, 27 Sep 87 19:17:18 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Sun, 27 Sep 87 19:16:59 EDT
Received: by june.cs.washington.edu (5.52.1/6.6)
    id AA04915; Sun, 27 Sep 87 16:22:21 PDT
Return-Path: <ihnp4!homxb!hou2d![e-mail]>
Message-Id: <[e-mail]>
Date: 24 Sep 87 21:31:07 GMT
From: ihnp4!homxb!hou2d![e-mail] (G.BEATTIE)
To: [e-mail]
Subject: OSI and X.25 Network Addressing and Gateways
Keywords: OSI X.25 X.75 Addressing Gateway Routing

I have seen a few messages regarding interoperability between
private and public nets.  Here are a few of my thoughts on
the subject...


With regard to interconnected X.25 subnetworks...

The situation is well in hand for the OSI community.


Case 1: X.75 Gateway

This is the way PTTs do their thing...it's not bad, but it
is a little different from X.25 in the way the bytes are banged out...
The X.75 gateway uses the X.121 address to route the call
request to the gateway node of the other network.  When the
packet arrives at the other network's gateway is is converted
back to X.25 and sent on through.

I frankly think that there is a better way.


Case 2: X.25 Gateway

This is a method which uses the X.121 addresses inside of a
X.25 subnetwork.  When the call request packet hits the
gateway, the gateway examines the Destination Network
Address Facility for the OSI Network Service Access Point
Address (NSAP Address).  This is used to determine the best
X.25 subnetwork to route the call request.  When the
link/network is selected, an appropriate X.121 address is
provided and the packet sent on its way.

NOTE:  THE NSAP ADDRESS IS NOT MANGLED !

Hope this helps !


Thanks,

        J. Gordon Beattie, Jr.

        MAIL
Unix:       ihnp4!hou2d!n2dsy
Amateur:    n2dsy @ kd6th/3100201

        TELEPHONE
Office:     201-615-2506
Home:       201-387-8896


27-Sep-87 20:39:17-EDT,2024;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 27 Sep 87 20:39-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Sun, 27 Sep 87 19:27:15 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Sun, 27 Sep 87 19:26:54 EDT
Received: by june.cs.washington.edu (5.52.1/6.6)
    id AA05244; Sun, 27 Sep 87 16:32:14 PDT
Return-Path: <labrea!Shasta![e-mail]>
Message-Id: <[e-mail]>
Date: 25 Sep 87 21:19:55 GMT
From: labrea!Shasta![e-mail] (Paul A. Flaherty)
To: [e-mail]
Subject: Protocol Wars: The Return of the ARPA-I
Reply-To: [e-mail] (Paul A. Flaherty)

I'll throw my hat into the protocol ring with this short note:

I'm currently designing the DCAS system for AMSAT Phase IV; many months
ago while I was considering protocols for the network, it became very
apparrent to me that the Internet Protocols were the only way to go.  I base
this on two readily obvious facts:

1) The Internet Protocols are well known, well defined, and empirically over-
    studied.  We know what they do, what they don't do, and what they do
    when improperly implemented.

2) The architectural paradigm of the ARPA Internet is much closer to AMNET
    than the paradigm of a PTT.  The ARPA-I is an amorphous collection
    of nets run by different organizations with different goals and
    presumably different amount of cash.  PTTs, on the other hand, have
    the advantage of complete control, and complete a priori knowledge
    (or damn close to it).

Hey, I'll welcome anyone with any protocol to run a section of the AMNET.
But when it comes down to the protocol used to stick the whole thing together,
the only practical alternative is IP.

--
-=Paul Flaherty, N9FZX           |Engineer(n) --
Computer Systems Lab -- Stanford |              A machine for converting beer
ARPA: [e-mail]  |              into blueprints.
UUCP: shasta!n9fzx!paulf@umunhum |


27-Sep-87 20:40:47-EDT,2511;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 27 Sep 87 20:40-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Sun, 27 Sep 87 19:12:07 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Sun, 27 Sep 87 19:11:52 EDT
Received: by june.cs.washington.edu (5.52.1/6.6)
    id AA04858; Sun, 27 Sep 87 16:17:11 PDT
Return-Path: <ihnp4!homxb!hotps!ka2qhd![e-mail]>
Message-Id: <[e-mail]>
Date: 22 Sep 87 18:07:17 GMT
From: ihnp4!homxb!hotps!ka2qhd![e-mail] (Thomas A. Moulton)
To: [e-mail]
Subject: Re: More on Internationally Blessed Protocols
Summary: Statement was to say that the protocol is totally conformant
     and not just a kluge
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>


The statements you quoted were to state that the X.25 Level 3 I am producing
is going to be 100% pure X.25, not some kluge slopped together; but now that
you meantion it... the idea of using Telenet as a "worm-hole" would work...



Phil, again you prove how little you know about the protocols you attack

The address of the netowrk server/network user will be in the CCITT Facility
Network Server Access Point (NSAP) address, this is an X.25 call request
facility that gets passed end-to-end during call set-up and a gateway node
can examine this address and determine the correct Network address to place
in the Calling address field of the X.25 call request packet.

It does require that the network is PLANNED, not ad-hoc, so you would have
routing information in the gateway, and yes the gateway would have to know
what Telenet addresses brought you to where in the Amateur network.
(it Could be derived from the area code in the Telenet address)

If you would like to get more current information on what the protocols are
let me know.

The funny thing is that I do not attack your protocol simply
because I disagree with it's basic assumptions and you attack the approach
RATS is following (along with many other groups/companies);
   vent you steam, I don't care!

   let's all remember this is only a hobby...
--
Life is too short to be mad about things.
Thomas A. Moulton, W2VY          Packet: w2vy@kd6th  Voice: 145.190 (r)
(201) 779-W2VY                   uucp: ...!ihnp4!bellcore!hotps!ka2qhd!w2vy
FAX: [phone]              [phone] x3226 (w)


27-Sep-87 20:41:21-EDT,1961;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 27 Sep 87 20:41-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Sun, 27 Sep 87 19:13:49 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Sun, 27 Sep 87 19:13:37 EDT
Received: by june.cs.washington.edu (5.52.1/6.6)
    id AA04874; Sun, 27 Sep 87 16:19:03 PDT
Return-Path: <ihnp4!homxb!hou2d![e-mail]>
Message-Id: <[e-mail]>
Date: 24 Sep 87 20:43:31 GMT
From: ihnp4!homxb!hou2d![e-mail] (G.BEATTIE)
To: [e-mail]
Subject: Challenge...sigh
Keywords: COSI RATS

Regarding the challenge...

There were some rules laid down by the ARRL Digital
Committee that ARE IN PLACE.  They are loosely
defined and hold only a rough moral force.

I frankly forget the rules, but
they go something like this:

 * Aztec or similar C for the Z-80 !
 * Target machine: a Z80 with 32k EPROM, 32K RAM
 * Must support regular old level 2 TNC users
 * Must support level 3 users (your choice of flavor)

Now, frankly I will say that these are TOUGH goals.

We've failed once due to code space problems.  Now were are in
the testing phase of a re-worked approach and we WILL
make it with SPACE to spare.

RATS is a group which has responsibilities to existing users
and to advancing the state of the network and its services.
We feel that our success in meeting the above stated goals
>from a few years ago is a demonstration that we meet our
responsibilities.

We are looking forward to porting this same code to other
machines including the PS-186 and 68K-based machines.

OSI has taken time but the future is now.


Thanks,

        J. Gordon Beattie, Jr.

        MAIL
Unix:       ihnp4!hou2d!n2dsy
Amateur:    n2dsy @ kd6th/3100201

        TELEPHONE
Office:     201-615-2506
Home:       201-387-8896


27-Sep-87 21:04:10-EDT,2172;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 27 Sep 87 21:04-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Sun, 27 Sep 87 19:17:18 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Sun, 27 Sep 87 19:16:59 EDT
Received: by june.cs.washington.edu (5.52.1/6.6)
    id AA04915; Sun, 27 Sep 87 16:22:21 PDT
Return-Path: <ihnp4!homxb!hou2d![e-mail]>
Message-Id: <[e-mail]>
Date: 24 Sep 87 21:31:07 GMT
From: ihnp4!homxb!hou2d![e-mail] (G.BEATTIE)
To: [e-mail]
Subject: OSI and X.25 Network Addressing and Gateways
Keywords: OSI X.25 X.75 Addressing Gateway Routing

I have seen a few messages regarding interoperability between
private and public nets.  Here are a few of my thoughts on
the subject...


With regard to interconnected X.25 subnetworks...

The situation is well in hand for the OSI community.


Case 1: X.75 Gateway

This is the way PTTs do their thing...it's not bad, but it
is a little different from X.25 in the way the bytes are banged out...
The X.75 gateway uses the X.121 address to route the call
request to the gateway node of the other network.  When the
packet arrives at the other network's gateway is is converted
back to X.25 and sent on through.

I frankly think that there is a better way.


Case 2: X.25 Gateway

This is a method which uses the X.121 addresses inside of a
X.25 subnetwork.  When the call request packet hits the
gateway, the gateway examines the Destination Network
Address Facility for the OSI Network Service Access Point
Address (NSAP Address).  This is used to determine the best
X.25 subnetwork to route the call request.  When the
link/network is selected, an appropriate X.121 address is
provided and the packet sent on its way.

NOTE:  THE NSAP ADDRESS IS NOT MANGLED !

Hope this helps !


Thanks,

        J. Gordon Beattie, Jr.

        MAIL
Unix:       ihnp4!hou2d!n2dsy
Amateur:    n2dsy @ kd6th/3100201

        TELEPHONE
Office:     201-615-2506
Home:       201-387-8896


27-Sep-87 23:51:25-EDT,2448;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 27 Sep 87 23:51-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Sun, 27 Sep 87 22:50:59 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Sun, 27 Sep 87 22:50:33 EDT
Date: Sun, 27 Sep 1987  20:55 MDT
Message-Id: <[e-mail]>
Sender: [e-mail]
From: Keith Petersen <[e-mail]>
To: [e-mail]
Subject: WA8DED version 1.2 for TNC-1 TNC2 and PK-87 now available

Now available from SIMTEL20...

Filename                        Type     Bytes   CRC

Directory PD:<CPM.PACKET>
DEDTNC1.ARK.1                   BINARY   44836  7A7BH
DEDTNC2.ARK.1                   BINARY   60248  6004H
DEDPK87.ARK.1                   BINARY   97499  4B5DH

DEDTNC1.ARK contains version 1.2 of the WA8DED AX.25 version 2
firmware for the TNC-1 packet radio controller.  This implementation
supports up to four multiple simultaneous link connections with either
version 1 or version 2 of the AX.25 protocol.  The firmware supplied
is intended to be installed on a TAPR TNC-1 or equivelent such as the
AEA PKT-1 or Heath HD-4040.

DEDTNC2.ARK contains version 1.2 of the WA8DED AX.25 version 2
firmware for the TNC-2 packet radio controller.  This implementation
supports up to four multiple simultaneous link connections with either
version 1 or version 2 of the AX.25 protocol.  This formware supplied
is intended to be installed in a TAPR TNC-2 or equivelent such as the
MFJ-1270 or AEA PK-80.

DEDPK87.ARK contains version 1.2 of the WA8DED AX.25 version 2
firmware for the PK-87 packet radio controller.  This implementation
supports up to four multiple simultaneous link connections with either
version 1 or version 2 of the AX.25 protocol.  The firmware supplied
is intended to be installed in a PK-87 packet controller.  Two versions
of the firmware are supplied: one for use with 16K or RAM, the other
for use with 32K of RAM.  You will need the DOC file from DEDTNC2.ARK
as only a short note about differences between it and this version is
included in DEDPK87.ARK.

-------------------------------------
These files are available via standard anonymous FTP to those with
Internet FTP capability.  They are also available on GEnie's CP/M
RoundTable.

--Keith Petersen
Arpa: [e-mail]
Uucp: {bellcore,decwrl,harvard,lll-crg,ucbvax,uw-beaver}!simtel20.arpa!w8sdz
GEnie: W8SDZ
28-Sep-87 00:20:57-EDT,2448;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 28 Sep 87 00:20-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Sun, 27 Sep 87 22:50:59 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Sun, 27 Sep 87 22:50:33 EDT
Date: Sun, 27 Sep 1987  20:55 MDT
Message-Id: <[e-mail]>
Sender: [e-mail]
From: Keith Petersen <[e-mail]>
To: [e-mail]
Subject: WA8DED version 1.2 for TNC-1 TNC2 and PK-87 now available

Now available from SIMTEL20...

Filename                        Type     Bytes   CRC

Directory PD:<CPM.PACKET>
DEDTNC1.ARK.1                   BINARY   44836  7A7BH
DEDTNC2.ARK.1                   BINARY   60248  6004H
DEDPK87.ARK.1                   BINARY   97499  4B5DH

DEDTNC1.ARK contains version 1.2 of the WA8DED AX.25 version 2
firmware for the TNC-1 packet radio controller.  This implementation
supports up to four multiple simultaneous link connections with either
version 1 or version 2 of the AX.25 protocol.  The firmware supplied
is intended to be installed on a TAPR TNC-1 or equivelent such as the
AEA PKT-1 or Heath HD-4040.

DEDTNC2.ARK contains version 1.2 of the WA8DED AX.25 version 2
firmware for the TNC-2 packet radio controller.  This implementation
supports up to four multiple simultaneous link connections with either
version 1 or version 2 of the AX.25 protocol.  This formware supplied
is intended to be installed in a TAPR TNC-2 or equivelent such as the
MFJ-1270 or AEA PK-80.

DEDPK87.ARK contains version 1.2 of the WA8DED AX.25 version 2
firmware for the PK-87 packet radio controller.  This implementation
supports up to four multiple simultaneous link connections with either
version 1 or version 2 of the AX.25 protocol.  The firmware supplied
is intended to be installed in a PK-87 packet controller.  Two versions
of the firmware are supplied: one for use with 16K or RAM, the other
for use with 32K of RAM.  You will need the DOC file from DEDTNC2.ARK
as only a short note about differences between it and this version is
included in DEDPK87.ARK.

-------------------------------------
These files are available via standard anonymous FTP to those with
Internet FTP capability.  They are also available on GEnie's CP/M
RoundTable.

--Keith Petersen
Arpa: [e-mail]
Uucp: {bellcore,decwrl,harvard,lll-crg,ucbvax,uw-beaver}!simtel20.arpa!w8sdz
GEnie: W8SDZ
28-Sep-87 10:13:45-EDT,1430;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 28 Sep 87 10:13-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Mon, 28 Sep 87 08:50:52 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Mon, 28 Sep 87 08:50:39 EDT
Received: from WPI.BITNET by wiscvm.wisc.edu ; Mon, 28 Sep 87 07:56:33 CDT
From: [e-mail]
Received: by wpi (4.12/4.7)
    id AA18834; Mon, 28 Sep 87 08:56:15 edt
Date: Mon, 28 Sep 87 08:56:15 edt
Message-Id: <8709281256.AA18834@wpi>
To: [e-mail]
Subject: KAM questions

Although this note is not strictly packet related I suspect there
are many KAM users in the audience.

I picked up a KAM a while ago and have been satisfied except for
one point: AMTOR ARQ mode.  I am running an Icom IC-751 (allegedly
capable of "out of the box" AMTOR operation), AGC fast or OFF, full
break-in, etc.  When calling stations in ARQ mode I am able to
synchronize with the other fellows signal but am not able to maintain
a valid link.  I have only been able to have 2 ARQ QSOs (both operators
were using TONO ZETA 7070 modems).  Before I send a letter to
Kantronics I wanted to see if anyone has any suggestions (other than
deep sixing the KAM!).  Thanks in advance.
Bill Michalson, AA2S     Bitnet:   wrm@wpi
             ARPAnet:  [e-mail]
28-Sep-87 12:56:37-EDT,1430;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 28 Sep 87 12:56-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Mon, 28 Sep 87 08:50:52 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Mon, 28 Sep 87 08:50:39 EDT
Received: from WPI.BITNET by wiscvm.wisc.edu ; Mon, 28 Sep 87 07:56:33 CDT
From: [e-mail]
Received: by wpi (4.12/4.7)
    id AA18834; Mon, 28 Sep 87 08:56:15 edt
Date: Mon, 28 Sep 87 08:56:15 edt
Message-Id: <8709281256.AA18834@wpi>
To: [e-mail]
Subject: KAM questions

Although this note is not strictly packet related I suspect there
are many KAM users in the audience.

I picked up a KAM a while ago and have been satisfied except for
one point: AMTOR ARQ mode.  I am running an Icom IC-751 (allegedly
capable of "out of the box" AMTOR operation), AGC fast or OFF, full
break-in, etc.  When calling stations in ARQ mode I am able to
synchronize with the other fellows signal but am not able to maintain
a valid link.  I have only been able to have 2 ARQ QSOs (both operators
were using TONO ZETA 7070 modems).  Before I send a letter to
Kantronics I wanted to see if anyone has any suggestions (other than
deep sixing the KAM!).  Thanks in advance.
Bill Michalson, AA2S     Bitnet:   wrm@wpi
             ARPAnet:  [e-mail]
29-Sep-87 13:31:45-EDT,1183;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 29 Sep 87 13:31-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Tue, 29 Sep 87 10:39:34 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Tue, 29 Sep 87 10:36:12 EDT
Message-Id: <[e-mail]>
Posted-From: The MITRE Corp., Bedford, MA
To: [e-mail]
Cc: [e-mail]
Subject: msg for Frank Warren
Date: Tue, 29 Sep 87 10:44:11 EDT
From: [e-mail]

Sorry to have to post to the net but Frank's host isn't in my host's host
table!
------- Forwarded Message

To: "Frank F. Warren Jr." <[e-mail]>
Cc: jrt
Subject: Re: COCO on packet?
In-Reply-To: Your message of Fri, 25 Sep 87 15:33:35 -0400.
         <[e-mail]>
Date: Mon, 28 Sep 87 15:33:18 EDT
From: jrt

Frank,

    Thanks for the info...My COCO is the "basic" version and I already
have planed to upgrade to the Extended Color Basic.  The memory upgrade sounds
simple so I'll give it a go...

    Thanks again,

    73...Jim

------- End of Forwarded Message

29-Sep-87 13:48:21-EDT,1183;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 29 Sep 87 13:48-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Tue, 29 Sep 87 10:39:34 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Tue, 29 Sep 87 10:36:12 EDT
Message-Id: <[e-mail]>
Posted-From: The MITRE Corp., Bedford, MA
To: [e-mail]
Cc: [e-mail]
Subject: msg for Frank Warren
Date: Tue, 29 Sep 87 10:44:11 EDT
From: [e-mail]

Sorry to have to post to the net but Frank's host isn't in my host's host
table!
------- Forwarded Message

To: "Frank F. Warren Jr." <[e-mail]>
Cc: jrt
Subject: Re: COCO on packet?
In-Reply-To: Your message of Fri, 25 Sep 87 15:33:35 -0400.
         <[e-mail]>
Date: Mon, 28 Sep 87 15:33:18 EDT
From: jrt

Frank,

    Thanks for the info...My COCO is the "basic" version and I already
have planed to upgrade to the Extended Color Basic.  The memory upgrade sounds
simple so I'll give it a go...

    Thanks again,

    73...Jim

------- End of Forwarded Message

29-Sep-87 19:57:15-EDT,2931;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 29 Sep 87 19:57-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Tue, 29 Sep 87 16:27:55 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Tue, 29 Sep 87 16:27:39 EDT
Date: Tue, 29 Sep 1987 15:57-EDT
From: [e-mail]
To: [e-mail]
Cc: [e-mail]
Subject: Re: COCO on packet?
Summary: probably not useful unless it has at least 64K
Message-Id: <559943885/[e-mail]>
In-Reply-To: <[e-mail]>

>Greetings and salutations...Having recently fallen prey to a REALLY CHEAPLY
>priced 16k COCO on sale at R.S., I now need to find a use for it!  Strikes me
>that someone MUST have put this device to work on packet.  Does anyone in
>net-land have experience doing so??

I heard that a local (Pittsburgh) ham KC3KB, Tom [not on the net, apparently]
implemented AX.25 for it using an external modem connected to the bit
banger port, but I decided against buying a 16K CoCo recently because of
the temptation to spend even more $ to make it a Real computer; plus the
difficulty of software development.  (This is why the TNC-2 sports
a Z-80 rather than the 6809 used in the CoCo and TNC-1.)

By the time you get to the point you can do something useful, you will find
that you're out of memory.  Maybe the best you can hope for is to run SLIP
on the thing and hook it up to a more powerful machine which can run the
higher level protocols you will want.  But then you'd need to add a serial
port, so it's sort of a vicious cycle unless you can be content with just
RTTY packet. You may end up wishing you had a CoCo 3 to start with.

I've never tracked down the guy who did the implementation, maybe you could
lookfi him up in the Callbook.  [I'd appreciate a phone #, at least]
Seems like you could use a lot of the TAPR TNC-1 code, but I don't
believe sources are available.  Here's the original message:

30-Aug-85 12:35:57-EDT,862;000000000011
Received: ID <[e-mail]>; Fri 30 Aug 85 12:35:48-EDT
Date: Fri 30 Aug 85 12:35:48-EDT
From: Mike Chepponis <[e-mail]>
Subject: Re: Packet, amateur radio questions
To: [e-mail]
In-Reply-To: Message from "Ralph W. Hyre Jr. <[e-mail]>" of Fri 30 Aug 85 11:53:15-EDT

Ralph, indeed this ought to be possible.  You'll need to take the individual
bits from the modem and convert HDLC into something you can work with - but
this is simple.  Even the state tables for the protocol are not a big deal.
Most people say the most amount of work is in the user interface.  A local
ham, KC3KB, Tom, has implemented something like this for his CoCo - he
homebrewed a xr2206/xr2211 mod/demod and runs the bits into his software,
which does the rest - so it CAN be done.  73 & gl,      -Mike
30-Sep-87 15:08:10-EDT,1904;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 30 Sep 87 15:08-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Wed, 30 Sep 87 12:06:30 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Wed, 30 Sep 87 12:06:15 EDT
Received: by june.cs.washington.edu (5.52.1/6.6)
    id AA20405; Wed, 30 Sep 87 09:17:05 PDT
Return-Path: <uunet!mcvax!cernvax!ethz![e-mail]>
Message-Id: <[e-mail]>
Date: 29 Sep 87 14:12:03 GMT
From: uunet!mcvax!cernvax!ethz![e-mail] (Markus Mueller)
To: [e-mail]
Subject: AX.25 Level 3 specs wanted

I just bought a used TNC that supports AX.25 Level 2 in version 2.0. However
I have seen various references to level 3 (networking layer) software for
TNC's that does true packet forwarding with an immediate acknowledge of
packet reception beetween digipeaters. This allows you to send packets over
as many digipeatres as you wish to with equal performance (it simply gets
slower); however you have no direct indication of whether and when your
packets have reached the destination.

After some manufactors have started to sell interfaces that upgrade your
old TNC to level 3 digipeating, I assume there is at least some de-facto
standard networking layer protocol. Therefor my question:

   Is there an ARRL-accepted standard for level 3 (networking layer)
   software? If yes: where can I get specs? If no: what protocol do
   these interfaces (in particular the one marketed by MFJ) use?

Please reply by mail; I will posts a summary if there is enough interest
in this subject.

   Markus Mueller
   Institut fuer Informatik
   Swiss Federal Institute of Technology
   Zurich
   Switzerland


Disclaimer: All of above represents my personal point of view and not that one
of my employer.


30-Sep-87 15:11:16-EDT,1409;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 30 Sep 87 15:11-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Wed, 30 Sep 87 12:05:52 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Wed, 30 Sep 87 12:05:26 EDT
Received: by june.cs.washington.edu (5.52.1/6.6)
    id AA20322; Wed, 30 Sep 87 09:16:14 PDT
Return-Path: <uunet!epiwrl!chemo![e-mail]>
Message-Id: <[e-mail]>
Date: 29 Sep 87 23:50:17 GMT
From: uunet!epiwrl!chemo![e-mail] (Brian J. McGinness)
To: [e-mail]
Subject: tcp/ip

I just got a copy of the KA9Q tcp/ip package and find the documentation
very sparse (or else I didn't get it). I got several RFCs, but they
don't answer my questions. How do I get an address? I picket 44.96.50.1
as a vacant DC address, do you just pick one or is it coordinated by
someone? Which program does what, and how do u use them? And, the
line in autoexec.net that says "attach asy 3e8 ax0 etc etc" always
chokes with the message "asy not attached, unknown interface ax0"
So as you see, I am totally confused. I am used to this uucp stuff
but I haven't has any exposure to tcp/ip.

Please email responses, I dont always get time to follow the net.

uunet!epiwrl!chemo!brian        :UUCP
[e-mail]                 :InterNet

73,
Brian WA3WJD


30-Sep-87 17:13:31-EDT,1904;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 30 Sep 87 17:13-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Wed, 30 Sep 87 12:06:30 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Wed, 30 Sep 87 12:06:15 EDT
Received: by june.cs.washington.edu (5.52.1/6.6)
    id AA20405; Wed, 30 Sep 87 09:17:05 PDT
Return-Path: <uunet!mcvax!cernvax!ethz![e-mail]>
Message-Id: <[e-mail]>
Date: 29 Sep 87 14:12:03 GMT
From: uunet!mcvax!cernvax!ethz![e-mail] (Markus Mueller)
To: [e-mail]
Subject: AX.25 Level 3 specs wanted

I just bought a used TNC that supports AX.25 Level 2 in version 2.0. However
I have seen various references to level 3 (networking layer) software for
TNC's that does true packet forwarding with an immediate acknowledge of
packet reception beetween digipeaters. This allows you to send packets over
as many digipeatres as you wish to with equal performance (it simply gets
slower); however you have no direct indication of whether and when your
packets have reached the destination.

After some manufactors have started to sell interfaces that upgrade your
old TNC to level 3 digipeating, I assume there is at least some de-facto
standard networking layer protocol. Therefor my question:

   Is there an ARRL-accepted standard for level 3 (networking layer)
   software? If yes: where can I get specs? If no: what protocol do
   these interfaces (in particular the one marketed by MFJ) use?

Please reply by mail; I will posts a summary if there is enough interest
in this subject.

   Markus Mueller
   Institut fuer Informatik
   Swiss Federal Institute of Technology
   Zurich
   Switzerland


Disclaimer: All of above represents my personal point of view and not that one
of my employer.