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

Text File | 1993-12-31 | 186.6 KB | 4,467 lines

3-Oct-89 15:16:38-MDT,7825;000000000000
Return-Path: <[e-mail]>
Date: Tue,  3 Oct 89 15:00:39 MDT
From: [e-mail]
Reply-To: [e-mail]
Subject: PACKET-RADIO Digest V89 #206
To: [e-mail]

PACKET-RADIO Digest         Tue,  3 Oct 89       Volume 89 : Issue 206

Today's Topics:
             (NOS)net.exe package
               computer viruses
                Heath 4040 TNC
              how to get started
      KA9Q 890421.1 XOBBS problem on Microport SysV/286
             Macintosh & PK-232 Software
             Problem with TNC-1 KISS ROM
----------------------------------------------------------------------

Date: 2 Oct 89 23:05:47 GMT
From: hpfcso!hpldola!hp-lsd!col![e-mail]  (Bdale Garbee)
Subject: (NOS)net.exe package

>Can anyone direct me to the latest version of the NOS version
>of net.exe that is available for anonymous FTP?  I'm looking
>for the "complete" package or at least as much as I can get.

No such thing exists.  NOS is not officially released yet, and must be
considered "beta-test" software at best.  There is *no* user documentation
specific to NOS yet.

>Also, I'm looking for a short tutorial on the operation
>of NOS.

This should be available sometime in November.  For now, the specific problem
you are having is likely related to the change from a "hosts file" format
hosts.net file to a "resource record" format domain.txt file for host info.
Talk to your local nameserver wizard for help.

The latest source, bugs and all, is available from flash.bellcore.com, in
the directory ~ftp/pub/ka9q as file src.arc, caveat emptor!

73 - Bdale, N3EUA

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

Date: 2 Oct 89 14:08:18 GMT
From: philmtl!philabs!briar.philips.com![e-mail]  (Robert Casey;6282;3.57;$0201)
Subject: computer viruses

 Msg# TSP  Size #Rd Date/Time MsgID        From   To
  5231 BN$  2748   1 0930/1151 5486_KJ6EO   WA4EGT [e-mail]
   Sb: Computer Virus: Jail Time & Fines


    On November 2, 1988 the great Internet Worm attack disabled
    approximately 6,000 UNIX machines across the country.

    On July 26, 1989, Robert Morris Jr., a graduate student
    at Cornell was indicted by a federal grand jury on a single
    felony count of violating the Computer Security Act of 1987.
    If convicted, Morrris could spend five (5) years in prison,
    and be fined $250,000.

    Mr. Morris has also been found guilty of violating Cornell's
    Code of Academic Integrity and has been suspended until
    the Fall of 1990.

    If you know of anyone manufacturing computer viruses, or
    that is contemplating them, be sure they're not ignorant
    of the potential penalties.

    As for the reports on packet that you should be concerned
    about BBS systems, etc., hogwash.  The virus requires that
    you EXECUTE a program containing infected code.  Reading
    data messages on BBS systems does not run the risk of
    acquiring a computer virus.  If, on the other hand, you
    download some .EXE or .COM program, and run it, all bets
    are off.  At that point, a program can alter sections of
    code in the operating system software (IBMBIOS.COM, IBMDOS.COM
    COMMAND.COM, or their equivalent Microsoft files).  The two
    hidden files (BIOS and DOS) are loaded everytime your system
    boots up, and of course the command interpreter is run as well.

    You can Unhide your hidden files, and run COMP (file compare)
    on your own systems to check for any changes to these operating
    system programs, as well as run COMParisons on other EXE or COM
    programs if you suspect that one of your programs has been
    infected.

    If you believe you are the victim of a computer virus program,
    it may be possible to trace it back to the author.  If the
    program has phrases like "Gotcha" or some such, it's possible
    to scan EXE and COM files for the phrase (or phrases), find
    the original program, figure out where you got it, and work
    on its ancestry.  Eventually, the source may be found, fined,
    and jailed.

    Good luck.
    Jeff.
    1416z, 934 msgs, #5237 last @KD6TH-4 MailBox>

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

Date: 2 Oct 89 23:17:16 GMT
From: hpfcso!hpldola!hp-lsd!col![e-mail]  (Bdale Garbee)
Subject: Heath 4040 TNC

The Heath 4040 is a TNC-1 clone.  Look for the tnc_tnc1.arc file included in
the KA9Q package, and follow the instructions in the doc file.

Holler if it doesn't work.

73 - Bdale, N3EUA

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

Date: 29 Sep 89 18:50:48 GMT
From: cscnj![e-mail]  (Dave Douglass)
Subject: how to get started

I recently got a copy of KA9Q-TCPIP, and in reading the documentation
learned about the existence of a neat thing called "packet radio".
My impression is that it's like ethernet over the airwaves.

How can I get started?  What should I read?
What components would make up a good "beginner's system" and how
much would they cost?
I imagine I would need a HAM radio license.  OK, so what does that entail?

Any info would be appreciated.  Thanks.

--
---------
Dave Douglass  Computer Sciences Corporation  Piscataway, NJ  08854
....!rutgers.rutgers.edu!cscnj!daved

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

Date: 2 Oct 89 23:16:11 GMT
From: hpfcso!hpldola!hp-lsd!col![e-mail]  (Bdale Garbee)
Subject: KA9Q 890421.1 XOBBS problem on Microport SysV/286

>I've laid hands on the 890421.1 source code, and have gotten it compiled
>on my system, which runs Microport System V/AT (286 version) 2.4 with
>DOSMerge.  When I fire it up, though, it complains:
>msgget smsgqid:: No such file or directory

Hmmm.  I had some mail a while back that I've since deleted from someone in
Illinois who had similar problems with SCO Xenix, it turned out to be a bug
in the IPC code, and they sent him a new rev of the kernel to fix it... dunno
if that helps or not...

73 - Bdale, N3EUA

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

Date: 28 Sep 89 18:31:02 GMT
From: swrinde!cs.utexas.edu!mailrus!sharkey!cfctech!teemc!mibte!gamma!thumper![e-mail]  (Peter Ferris)
Subject: Macintosh & PK-232 Software

I've just purchased an AEA PK-232 (as well as some other goodies!). I don't
have possesion of the unit yet as I've been told that AEA is in the process
of modifying the unit with a new "mailbox" feature.

Anyhow, I've been told that the MacRatt software for it (the Mac-ware that
AEA flogs for the '232) is pretty difficault to get hold of... that PC ware was
in greater supply. Also, frankly, after buying the '232, etc; I don't have $60
to spare for the blasted thing (even if I COULD get it!). Sooo, I'm looking
elsewhere. Especially interested in WEFAX-ware.

Preferably something that could run under MultiFinder and happy with 6.0.3
would be nice. Any leads?

Many thanks,
Pete Ferris, N5KBD

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

Date: 2 Oct 89 22:59:03 GMT
From: hpfcso!hpldola!hp-lsd!col![e-mail]  (Bdale Garbee)
Subject: Problem with TNC-1 KISS ROM

>I'm using the TNC-1 KISS code for my ancient, but reliable TNC-1.  The
>problem I have is that I can't seem to get the ROM bits to operate but the
>RAM-based version (downloaded to the tnc via the TNCBUG monitor) works fine.

Hmmm.  Have you got the latest bits?  There have been a couple of problems
over time that got fixed.  Try grabbing ~ftp/ka9q/890421.1/tnc_tnc1.arc from
col.hp.com if you have Internet access...

Bdale, N3EUA

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

End of PACKET-RADIO Digest V89 Issue #206
*****************************************
 5-Oct-89 10:34:15-MDT,7690;000000000000
Return-Path: <[e-mail]>
Date: Thu,  5 Oct 89 10:00:17 MDT
From: [e-mail]
Reply-To: [e-mail]
Subject: PACKET-RADIO Digest V89 #207
To: [e-mail]

PACKET-RADIO Digest         Thu,  5 Oct 89       Volume 89 : Issue 207

Today's Topics:
       Another enquiry about Packet Radio. Please help.
               computer viruses
      KA9Q 890421.1 XOBBS problem on Microport SysV/286
             THE ADDRESS OF TAPR?
             WORLI for a TRS-80?
----------------------------------------------------------------------

Date: Wed,  4 OCT 89 13:12:25 GMT
From: [e-mail]
Subject: Another enquiry about Packet Radio. Please help.

I am a third year student here in King's College London, UK, and
I am doing a third year project which consists of designing and
building both hardware and software for an X.25 packet radio modem.

Unfortunately, at the moment I know very little about this. In fact,
I can say that I don't know anything about packet radio.

Could you please send me information about packet radio. How to
design a packet radio modem, writing of the software, etc.
In a word: help !

In order not to bore other people on this list, please send the information
DIRECTLY TO ME. I'll acknowledge all mail I receive, but please warn me before
sending me large amounts of data in one go (ie: large files/manuals...)

Many thanks for your help.

Olivier Crepin-Leblond, Computer Systems & Electronics III,
Electrical & Electronic Eng., King's College London , UK

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| Olivier M.J. Crepin-Leblond                         | DISCLAIMER:            |
| JANET   : <[e-mail]>                |   Don't even believe   |
| BITNET  : <zdee699%elm.cc.kcl.ac.uk@ukacrl>         |   the signature ! ! !  |
| INTERNET: <[e-mail]-relay>|                     |
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

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

Date: 4 Oct 89 14:06:37 GMT
From: cadnetix.COM!cadnetix![e-mail]  (Rusty Carruth)
Subject: computer viruses

In article <[e-mail]> WA4EGT@KJ6EO writes:
>
> Msg# TSP  Size #Rd Date/Time MsgID        From   To
>  5231 BN$  2748   1 0930/1151 5486_KJ6EO   WA4EGT [e-mail]
>
>    As for the reports on packet that you should be concerned
>    about BBS systems, etc., hogwash.  The virus requires that
>    you EXECUTE a program containing infected code.  Reading
>    data messages on BBS systems does not run the risk of
>    acquiring a computer virus.

True as far as it goes, however if you run a terminal program which
has ansi escape sequences (or vt100 emulation or some other such
thing), jerks can still do bad things to your computer.  Have you
heard of the 'christmas card bomb' which was a bunch of text you
displayed on your screen and which would use some 'nifty' :-(
escape sequences and operating system commands to attempt to delete
all files on your system.  True, it was computer and OS specific,
but those people having the computer for which the bomb was designed
lost their files.

Of course, if you are using a terminal emulator, turning off ansi
(and other such emulation modes) should keep you safe.

If you are running an IBM (or compatible) computer, it would
be wise to (1) back up your computer prior to Friday the 13th
(Ahh, you forgot we have a friday the 13 coming up next week?
We do), (2) get a virus scanner or two and run them just to be
'sure' (is there any such thing?) you are clean, (3) perhaps
subscribing to comp.virus where you get the latest news of
viruses would not be a bad idea, (4) don't panic, its probably
not quite as bad as the anti-virus screamers would like you to
think, but then if you get hit by a destructive virus it would
be better to be prepared and watchful than blissfully ignorant
until your data went away....  So be prepared and don't panic.

Disclaimer - the above information is second-hand and probably has
some inaccuracies in it.  Your mileage may vary.  Poster not
responsible for bombs, trojans, or viruses which get loose on
your system.  (Add more disclaimers here)

For good, solid info on viruses, bombs, trojans, and the like,
check out the newsgroup comp.viruses  (which is where I heard
about the 'christmas card bomb').

'nuff for now.  Don't panic.  But do backup data, its a good
habit anyhow!

---Join the usenet un-net, 28.410 and/or 28.390, 1500Z to 1600Z saturdays!
Rusty Carruth.                  Radio: N7IKQ              ^^ or later :-)
DOMAIN: [e-mail]      UUCP:{uunet,boulder}!cadnetix!rusty
home: POB. 461, Lafayette 80026

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

Date: 4 Oct 89 23:36:57 GMT
From: gem.mps.ohio-state.edu!wuarchive!texbell!splut![e-mail]  (Jay Maynard)
Subject: KA9Q 890421.1 XOBBS problem on Microport SysV/286

In article <[e-mail]> [e-mail] (Bdale Garbee) writes,
in response to my recent plea for help:
>Hmmm.  I had some mail a while back that I've since deleted from someone in
>Illinois who had similar problems with SCO Xenix, it turned out to be a bug
>in the IPC code, and they sent him a new rev of the kernel to fix it... dunno
>if that helps or not...

This jives with mail I got from Dave Toth, who says that Microport's
message queues are broken. Rolfe Tessem, however, says that he has it
running on his Microport SysV/286 system, also at 2.4.

No matter what I try, though, I can't get it to run, and I suspect I'll
never see another kernel revision. :-( Guess I'll have to give up on
XOBBS, not through any fault of the code, but because of my
once-more-buggy system. Oh well.

--
Jay Maynard, EMT-P, K5ZC, PP-ASEL   | Never ascribe to malice that which can
[e-mail]       (eieio)| adequately be explained by stupidity.
{attctc,bellcore}!texbell!splut!jay +----------------------------------------
           America works less when you say..."Union Yes!"

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

Date: 23 Sep 89 06:23:54 GMT
From: eru!luth!sunic!tut!oulu!tolsun![e-mail]  (Marko Wirtanen)
Subject: THE ADDRESS OF TAPR?

Doeas anyone know the address (or fax number) of TAPR office ?

73 Marko /OH8WM

--

 ------------------------------------------------------------------------
   Marko Wirtanen                        E-mail: [e-mail]
     Rakentajantie 5C 406                  Phone: [phone]
       SF-90570 Oulu
     FINLAND                               Ham Radio Call: OH8WM
 ------------------------------------------------------------------------

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

Date: 4 Oct 89 18:53:33 GMT
From: sun-barr!newstop!east!hienergy![e-mail]  (Jim Vienneau - CSD Program Manager)
Subject: WORLI for a TRS-80?

A friend recently was given a TRS-80 model II with a 12MB hard drive. It
appears to run both TRSDOS and CP/M. He would like to use the machine
to run a WORLI (or similar) packet BBS. Since WORLI was originally
written for CP/M it would seem likely that a version exists. Does anybody
know if this is available and how to get it?


Jim Vienneau - KC1OU
Sun Microsystems - Billerica, MA
sun!suneast!jimv
[phone]

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

End of PACKET-RADIO Digest V89 Issue #207
*****************************************
 9-Oct-89 10:15:34-MDT,7740;000000000000
Return-Path: <[e-mail]>
Date: Mon,  9 Oct 89 10:00:15 MDT
From: [e-mail]
Reply-To: [e-mail]
Subject: PACKET-RADIO Digest V89 #208
To: [e-mail]

PACKET-RADIO Digest         Mon,  9 Oct 89       Volume 89 : Issue 208

Today's Topics:
               computer viruses
               Ham Radio at sea. Help!
               Part 15 (2 msgs)
        Unrestricted access (was Re: Part 15)
          What has become of WB3FFV's XBBS?
----------------------------------------------------------------------

Date: Thu, 5 Oct 1989 16:01:52 CDT
From: Rick Troth <@rice.edu:[e-mail]>
Subject: computer viruses

>Date: 4 Oct 89 14:06:37 GMT
>From: cadnetix.COM!cadnetix![e-mail]  (Rusty Carruth)
>Subject: computer viruses
>
>In article <[e-mail]> WA4EGT@KJ6EO writes:
>>
>>    As for the reports on packet that you should be concerned
>>    about BBS systems, etc., hogwash.  The virus requires that
>>    you EXECUTE a program containing infected code.  Reading
>>    data messages on BBS systems does not run the risk of
>>    acquiring a computer virus.
>
>True as far as it goes, however if you run a terminal program which
>has ansi escape sequences (or vt100 emulation or some other such
>thing), jerks can still do bad things to your computer ...
>
>Of course, if you are using a terminal emulator, turning off ansi
>(and other such emulation modes) should keep you safe.

    In defense of ANSI protocol, the ability to invoke commands on
your PC from 'nifty' sequences emitted by the host is NOT in the spec.
Several terminal emulators add this ability by using sequences defined
as 'private use' in the ANSI specification. ANSI X3.64 is the best
thing going for a standard terminal protocol.

    I see the "start up a command on the PC automagically" function
as highly desirable. Although it can lead to "hand-holding" where the
user won't bother to read the manual. When the user doesn't know what is
really going on, he is a LOT more likely to get hit by a virus. But don't
shun ANSI protocol because of some bimbo with another bomb.

>Rusty Carruth.                  Radio: N7IKQ
>DOMAIN: [e-mail]      UUCP:{uunet,boulder}!cadnetix!rusty
>home: POB. 461, Lafayette 80026

 "Were not the right man on our side, our striving would be losing."
 Rick Troth <[e-mail]> ------------- Rice ONCS VM Systems Support

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

Date: 9 Oct 89 01:48:47 GMT
From: att!mcdchg!motmpl![e-mail]  (Ron Widell)
Subject: Ham Radio at sea. Help!

I'm posting this for a friend who has no Usenet access, and I don't
normally read this group (it's at the bottom of my .newsrc), so please
respond by e-mail if at all possible. Thanks.

I have a friend who is planning on checking out of the day-to-day world
next year and take off for the Carribean on his sailboat. (tough huh?)
However, he and his wife don't want to be totally out of touch and have
been thinking of getting some ham gear ( and the appropriate general
license) to facilitate this. When he was there last year on vacation,
he saw one of the big problems with the ham setup was that everybody
was virtually married to the radio at certain times of the week and day;
and it may have been for naught if there had been no messages for you.
So, I mentioned that there was a possibility that packet-switched radio
would take care of this problem.
So the question is: will it fill the bill? Can things be set up so that
he can just turn on the ham gear, a laptop PC and some type of modem at
certain times of the day (maybe even leave the laptop on and let it turn
everything else on and off at the appropriate times)? I'm getting Phil Karn's
ka9q S/W down via anon UUCP, as I've heard that that is the s/w used for
this type of thing, but what else is needed?
Since everything has to fit in a 30 foot sailboat that's also their home,
space is at a real premium (so is money, but everbody has that problem :-))

Well, that's probably enough for the  first round of questions. I'm being
intentionally vague in some areas, cause I don't even know enough to ask
all of the right questions, but I *THINK* I'll be able to understand most
of the answers.

Thanks in advance, and remember please respond via e-mail.
--
Ron Widell, Field Applications Eng.     |UUCP: {...}mcdchg!motmpl!ron
Motorola Semiconductor Products, Inc.,  |Voice:[phone]
9600 W. 76th St., Suite G               | I'm from Silicon Tundra,
Eden Prairie, Mn. 55344 -3718           | what could I know?

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

Date: 7 Oct 89 12:43:45 GMT
From: [e-mail]  (Brian Kantor)
Subject: Part 15

An admittedly cursory glance at the new (proposed? accepted?) part 15
rules leads one to believe that we hams interested in digital
transmission can legally avoid all the ham radio restrictions on signal
content by just turning down the power and ceasing to identify.

Bizarre thought, isn't it?  (Thanks to K3MC for the inspiration.)
    - Brian

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

Date: 7 Oct 89 23:57:30 GMT
From: att!cbnewsm![e-mail]  (william.r.clegg)
Subject: Part 15

In article <[e-mail]>, [e-mail] (Brian Kantor) writes:
> An admittedly cursory glance at the new (proposed? accepted?) part 15
> rules leads one to believe that we hams interested in digital
> transmission can legally avoid all the ham radio restrictions on signal
> content by just turning down the power and ceasing to identify.
>
> Bizarre thought, isn't it?  (Thanks to K3MC for the inspiration.)
>       - Brian

And you can do all that without moving out of the ham bands i.e. in the
902-928 MHz band.

Bill

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

Date: 9 Oct 89 05:24:39 GMT
From: mintaka!oliveb!amdahl!pacbell!noe![e-mail]  (Marc de Groot)
Subject: Unrestricted access (was Re: Part 15)

In article <[e-mail]> [e-mail] (Brian Kantor) writes:
>An admittedly cursory glance at the new (proposed? accepted?) part 15
>rules leads one to believe that we hams interested in digital
>transmission can legally avoid all the ham radio restrictions on signal
>content by just turning down the power and ceasing to identify.

I've been thinking about this for a while.  Remember, there's no
restrictions on the size of RECEIVING antennas...how far can we get
if we use big beams to receive minuscule signals?

--
Marc de Groot (KG6KF)                   These ARE my employer's opinions!
Noe Systems, San Francisco
UUCP: uunet!hoptoad!noe!marc
Internet: [e-mail]

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

Date: 8 Oct 89 12:16:57 GMT
From: texbell!attctc!mjbtn![e-mail]  (Mark J. Bailey)
Subject: What has become of WB3FFV's XBBS?

Could someone please tell me what has happened to WB3FFV's XBBS bbs that
he ran up in New Jersey?  I have not been able to get an answer for many
months now.

Any information would be most appreciated.

Thanks,

Mark.

--
Mark J. Bailey                                    "Ya'll com bak naw, ya hear!"
USMAIL: 511 Memorial Blvd., Murfreesboro, TN 37129 ___________________________
VOICE:  [phone]                            |         JobSoft
UUCP:   ...!{ames,mit-eddie}!attctc!mjbtn!mjb      | Design & Development Co.
DOMAIN: [e-mail]                       |  Murfreesboro, TN  USA

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

End of PACKET-RADIO Digest V89 Issue #208
*****************************************
11-Oct-89 15:34:33-MDT,6670;000000000000
Return-Path: <[e-mail]>
Date: Wed, 11 Oct 89 15:01:19 MDT
From: [e-mail]
Reply-To: [e-mail]
Subject: PACKET-RADIO Digest V89 #209
To: [e-mail]

PACKET-RADIO Digest         Wed, 11 Oct 89       Volume 89 : Issue 209

Today's Topics:
               Ham Radio at sea. Help!
            Net/Rom Protocol Spec. Wanted
                   Part 15
               Tandy Model 102
               the WB3FFV XBBS
          VT100 emulation for KA9Q net code
         Where do I get info on new packet addressing
----------------------------------------------------------------------

Date: 10 Oct 89 04:42:48 GMT
From: pilchuck!ssc![e-mail]  (Tad Cook)
Subject: Ham Radio at sea. Help!

Regarding the query from the party who was interested in taking
messages at sea without having to meet schedules and nets on the
air, my friend NA7P has solved this problem neatly and without
complication.

He uses the WA8DRZ APLINK BBS, which has both a packet and AMTOR
port.  The packet side is tied into the VHF packet network that
can send and receive mail from mailboxes all over North America
(and elsewhere) and the HF side uses AMTOR on 20 mtrs, which is
a lot easier for him to use at sea under normal HF radio conditions.

His wife at home, who is also a ham, addresses messages to
NA7P @ WA8DRZ on a local VHF BBS in the Seattle area.  The messages
go via the packet network to WA8DRZ, and NA7P picks them up on
20 mtr AMTOR.

This way any ham with a computer, TNC and a 2 mtr radio can send
him mail.  He uses an AEA PK232, an HF SSB transceiver and a computer
on the boat.  Works real slick!

Tad Cook
KT7H @ N7HFZ
[e-mail]

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

Date: 11 Oct 89 12:48:26 GMT
From: ad.dec.com![e-mail]  (11-Oct-1989 0837)
Subject: Net/Rom Protocol Spec. Wanted

Is there a description of the Net/Rom protocol available anywhere?

I know that there is some Net/Rom stuff imbedded in KA9Q's TCP/IP package
written by W9NK.  Where did he get the info on the Net/Rom internals?

I am interested in writing some stuff that interfaces with Net/Rom and am
looking for some sort of "standard" (though I suspect this may be wishful
thinking on my part).

Any ideas?  Thanks,

= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =
Andrew C. Payne, N8KEI          [e-mail]        (OR)
                [e-mail]

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

Date: 10 Oct 89 08:23:31 GMT
From: agate!shelby!unix![e-mail]  (Alan Larson)
Subject: Part 15

In article <[e-mail]> [e-mail] (Brian Kantor) writes:
>An admittedly cursory glance at the new (proposed? accepted?) part 15
>rules leads one to believe that we hams interested in digital
>transmission can legally avoid all the ham radio restrictions on signal
>content by just turning down the power and ceasing to identify.
>
>Bizarre thought, isn't it?  (Thanks to K3MC for the inspiration.)
>       - Brian

I mentioned this to Mike and Phil last year, but we wondered if there
might be more problems than would be immediately apparent.

There are some problems that I was not aware of at the time I proposed
it then.  The signals need to be spread spectrum, the spreading must
meet some particular standards of energy dispersal, and there may be
some FCC approval requirements of particular systems, such as type
approval.

The spread spectrum nature would provide some protection against
collisions, but would add the synchronizing time to each transmission.
As such, it is much better suited to backbone transmitters which
transmit continuously.  At the 1 watt power level, reasonable range
for links between mountaintops should be possible.

I have a method for using this with intermittent transmitters, but
that would take a much longer article than this to describe.

    Alan

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

Date: 10 Oct 89 15:28:56 GMT
From: fluke![e-mail]  (Paul Baldock)
Subject: Tandy Model 102

Does anybody have ham radio related programs for the Model 102. I am
particularly interested in Satellite and Packet.

Paul
KW7Y

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

Date: Wed, 11 Oct 89 01:24:40 GMT
From: [e-mail] (David B. Toth)
Subject: the WB3FFV XBBS

Howard suffered a hard disk failure. When I spoke to him last week, he
was hoping that a replacement controller would be here "real soon now".
He has not been down "for several months" ... more like 3-4 weeks.
Hope this helps all those folks wondering.
73, Dave VE3GYQ

UUCP: julian!toth!dave
Internet: julian.uwo.ca!toth!dave

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

Date: 11 Oct 89 17:05:41 GMT
From: bronze![e-mail]  (Ed Brill)
Subject: VT100 emulation for KA9Q net code

I use KA9Q net code to connect to our various network resources here at IU
from time to time.  Things like the emacs editor, though, have real trouble
trying to work with KA9Q (through no fault in the software, that's not really
something hams often have to worry about).

Is there an ANSI.SYS driver or something like that, or a code modification I
could use to get net to work better with emulation?

Thanks
and 73,


Ed Brill                              |  SysOp, the IU PC-Link Central BBS
Indiana University Computing Services |  [phone]
[e-mail]       |  KA9TAW @ K9IU (ham radio packet)
[e-mail]                  |  ...!pur-ee!iuvax!silver!ebrill

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

Date: 11 Oct 89 04:24:00 GMT
From: att!cbnewsk![e-mail]  (steven.m.wheatley)
Subject: Where do I get info on new packet addressing

I recently notice that packet addressing follows a format similar
to this.....

[e-mail]

is there a reference to this new addressing .... is the IN always
the state, or section, or what?  Also, does anyone have a good
source for worldwide gateways?  For example, I am told that, to
send a message to Hong Kong, there is a Amtor gateway in the west
coast.  How do I access it, or use it, to send a packet from Indy
to Hong Kong?

thanks in advance!
steve wheatley
--
Steven Wheatley    AT&T Consumer Products    [phone]

....!att!inuxz!wheatley

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

End of PACKET-RADIO Digest V89 Issue #209
*****************************************
12-Oct-89 15:28:58-MDT,8924;000000000000
Return-Path: <[e-mail]>
Date: Thu, 12 Oct 89 15:01:19 MDT
From: [e-mail]
Reply-To: [e-mail]
Subject: PACKET-RADIO Digest V89 #210
To: [e-mail]

PACKET-RADIO Digest         Thu, 12 Oct 89       Volume 89 : Issue 210

Today's Topics:
        Net/Rom Protocol Spec. Wanted (2 msgs)
        packet/fido between north and central america
    Packet Controller Selection - Recomendations Solicited
          VT100 emulation for KA9Q net code
         WA4SIR Reports On STS-35/SAREX Orbit
          What has become of WB3FFV's XBBS?
----------------------------------------------------------------------

Date: 12 Oct 89 18:29:54 GMT
From: [e-mail]  (Dan Frank)
Subject: Net/Rom Protocol Spec. Wanted

In article <[e-mail]> [e-mail] (11-Oct-1989 0837) writes:
>Is there a description of the Net/Rom protocol available anywhere?

   The only "official" description is of the header formats, and is
in the NET/ROM manual.  This is not the same as a protocol specification.

>I know that there is some Net/Rom stuff imbedded in KA9Q's TCP/IP package
>written by W9NK.  Where did he get the info on the Net/Rom internals?

   I started with the header formats, and developed an understanding
of the network layer by watching packet traces and fooling around.  The
network layer is much simpler than the transport layer.  When I did
the transport support I used the sliding windows sequenced packet protocol
from Tanenbaum ("Protocol 6") with some slight modifications to sequence
number handling, and a fairly clever (I think) original algorithm for doing
exponential backoff in the presence of out-of-order acknowledgements.
Adding exponential backoff really improves the transport protocol.  One of
the real numb-nuts features of "classic" NET/ROM is fixed transport
timeouts.  I can't believe anyone thought that would work in a
radio network.  Luckily transport timeout handling is something you
can add and stay compatible with existing implementations.

   Transport setup and teardown is very badly done in NET/ROM, and
the way it works is not obvious.  It would be very hard to get a picture
of the boundary conditions by observing normal network behavior.  Here
is one place I had to crib some details from TheNet, although my
implementation is a bit different.

>I am interested in writing some stuff that interfaces with Net/Rom and am
>looking for some sort of "standard" (though I suspect this may be wishful
>thinking on my part).

   If the stuff you're doing is non-commercial you may use my C code
from the KA9Q package as long as your software acknowledges the source
of the NET/ROM support in a banner somewhere (e.g. the startup message).
At the very least you can read the code, which is several orders of
magnitude more lucid than that in TheNet.

   By the way, please don't ask me for a copy.  I no longer have any
of the code on my drives, having given up packet radio until such time
as 1200 baud half-duplex is a distant memory.

   73, Dan, W9NK

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

Date: 12 Oct 89 18:16:08 GMT
From: idacrd![e-mail]  (Robert McGwier)
Subject: Net/Rom Protocol Spec. Wanted

From article <[e-mail]>, by [e-mail] (11-Oct-1989 0837):
> Is there a description of the Net/Rom protocol available anywhere?
>
> I know that there is some Net/Rom stuff imbedded in KA9Q's TCP/IP package
> written by W9NK.  Where did he get the info on the Net/Rom internals?
>

In my NET/ROM manual, the complete protocol spec is given.

W9NK did a totally independent derivation of NET/ROM from this spec.

73
Bob N4HY


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

Date: 12 Oct 89 13:19:50 GMT
From: vicorp![e-mail]  (Scott Reed)
Subject: packet/fido between north and central america

I have been working on some small development projects in central
america as a volunteer. Communication is a big barrier to doing
the work remotely.  I'm not a ham, yet, but have considered getting
a license for communicating with our counterparts abroad. Does anyone
have experience or information in using packet radio and fidonet
communications in an international context? Are there legal issues?
Would satellites be necessary? If so how would they be used?
            - scott

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

Date: 11 Oct 89 06:21:03 GMT
From: virgin!ubbs-nh![e-mail]  (N. Del More)
Subject: Packet Controller Selection - Recomendations Solicited

I have developed an interest in packet radio, in particular I am
interested in the operation of same under Unix/Xenix.

I am however, a bit bewildered by the selection of packet controllers on
the market.

I would appreciate hearing your views or experiances with various brands
and/or models.

I am concerned with reliability, flexibitity and upgradability as well as
the ease of use.

To date I am leaming towards the KAM and PK-232 but I may be making a
mistake in either case.  Your input would be greatly appreciated!

Thanks,

Noel
N2AXI
--
Noel B. Del More             |                             decvax!ubbs-nh!noel
17 Meredith Drive            |                             [e-mail]
Nashua, New Hampshire  03063 | It's unix me son!  `taint spozed tah make cents

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

Date: Thu, 12 Oct 89 15:17:56 CDT
From: Rick Troth <[e-mail]>
Subject: VT100 emulation for KA9Q net code

On 11 Oct 89 17:05:41 GMT Ed Brill said:
>                   ... Things like the emacs editor, though, have real
>trouble trying to work with KA9Q ...
>
>Is there an ANSI.SYS driver or something like that, or a code
>modification I could use to get net to work better with emulation?

    I know of FANSI.SYS (Fancy ANSI driver) and NANSI.SYS (New ANSI
driver?), but it has been at least three years since I tried either of
them. With either of these, you would probably still have to re-define
the keys (the same way ANSI.SYS will let you re-define keys) to make
a real VT100-looking terminal, and that will break some MS-DOS programs
that expect standard IBM-PC function key sequences.

 Rick Troth <[e-mail]> ------------- Rice ONCS VM Systems Support

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

Date: 9 Oct 89 01:13:56 GMT
From: pacbell!hoptoad!peora!tsdiag!ka2qhd![e-mail]  (John Magliacane Wall Township NJ)
Subject: WA4SIR Reports On STS-35/SAREX Orbit

Ron Parise, WA4SIR has provided the following information on his flight
aboard the Shuttle on STS-35 as a Payload Specialist for the ASTRO experiment.
Ron is hoping to carry the SAREX (Shuttle Amateur Radio EXperiment) Packet
radio hardware with him.

---

Howdy folks!

Here are a set of prelaunch predicts for STS-35. They might change
slightly prior to launch due to some new ascent performance predictions
but not by much. These should do fine for any planning excercises
you might wish to do. Also feel free to publish, E-mail, or otherwise
scatter these numbers far and wide to get people started thinking
about the mission. These are preliminary and are NOT yet official.
By the way, our launch time is now April 26, 1990 at 05:02 GMT.


   Satellite:                  STS-35
   Epoch time:          90116.2398947
   Element set:             Prelaunch
   Inclination:           28.4614 deg
   RA of node:           121.1687 deg
   Eccentricity:             .0000811
   Arg of perigee:       318.7728 deg
   Mean anomaly:         283.2833 deg
   Mean motion:   15.75083130 rev/day
   Decay rate:      0.00000 rev/day^2
   Epoch rev:                      01
   Semi Major Axis:        6736.21 Km

73 de Ron, WA4SIR

--
 UUCP   : ucbvax!rutgers!petsd!tsdiag!ka2qhd!kd2bd
 PACKET : KD2BD @ NN2Z (John)
      ..."There is no expedient to which a man will not resort to
      avoid the real labor of thinking." ....Sir Joshua Reynolds.

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

Date: 12 Oct 89 01:23:28 GMT
From: att!cbnewsm![e-mail]  (william.r.clegg)
Subject: What has become of WB3FFV's XBBS?

> Could someone please tell me what has happened to WB3FFV's XBBS bbs that
> he ran up in New Jersey?  I have not been able to get an answer for many
> months now.
>
> Mark.
>
> --
> Mark J. Bailey                                    "Ya'll com bak naw, ya hear!"
I've noticed the same thing the last few times that I have tried to get into
it also although I don't try on a regular basis.

Bill
KD2XK

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

End of PACKET-RADIO Digest V89 Issue #210
*****************************************
14-Oct-89 01:22:45-MDT,7082;000000000000
Return-Path: <[e-mail]>
Date: Sat, 14 Oct 89 01:01:00 MDT
From: [e-mail]
Reply-To: [e-mail]
Subject: PACKET-RADIO Digest V89 #211
To: [e-mail]

PACKET-RADIO Digest         Sat, 14 Oct 89       Volume 89 : Issue 211

Today's Topics:
   Back to Part 15 (was Re: Unrestricted access (was Re: Part 15))
                 KAM or KPC-4
                KPC-2 is mute
        Net/Rom Protocol Spec. Wanted (3 msgs)
               TCP for CP/M???
----------------------------------------------------------------------

Date: 13 Oct 89 17:55:40 GMT
From: cadnetix.COM!cadnetix![e-mail]  (Rusty Carruth)
Subject: Back to Part 15 (was Re: Unrestricted access (was Re: Part 15))

In article <[e-mail]> [e-mail] (Marc de Groot) writes:
>In article <[e-mail]> [e-mail] (Brian Kantor) writes:
>>... part 15 rules
>

I was down at Pace (kinda like Price Club, if you know what that is)
yesterday and saw something which really worried me.

    "AT&T Cellular Style Walkie-Talkies"

(Not made by AT&T, of course)  They used 2 9-v batteries
for power.  They are 'part 15' devices.  They had a 'nifty'
feature in that they had a tone oscillator you could use to
send morse code with (you keyed the radio then pushed the button
to send code), and even included the morse alphabet in the
(extremely short) instruction thingy.

There was no mention of what freq they used.

There was no mention of how much power they radiated.


While I liked the fact that they included the morse code stuff,
I'm worried about what freqs these things are on.

If these things are on ham bands, we are in deep trouble!
(And even if they are not, I can imagine how much fun
we will have with them and RFI...)

Just what we need - thousands of kids playing 'cellular phone'
on the ham bands, screaming to their folks because some big
mean man interfered with their playing...

Guess who loses in such a situation?

---rusty
---Join the usenet un-net, 28.410 and/or 28.390, 1500Z to 1600Z saturdays!
Rusty Carruth.                  Radio: N7IKQ              ^^ or later :-)
DOMAIN: [e-mail]      UUCP:{uunet,boulder}!cadnetix!rusty
home: POB. 461, Lafayette 80026

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

Date: 13 Oct 89 20:17:00 GMT
From: ux1.cso.uiuc.edu!ux1.cso.uiuc.edu![e-mail]
Subject: KAM or KPC-4

I am fairly sure at the present time that a Kantronics TNC is the one I would
like to get, but I am not sure yet which one:

The KPC-4 is a dual port TNC, a feature I want to have.

The KAM has two ports, and advertisements say it is HF+VHF capable.  Does that
mean one of them will be only for HF while the other is for VHF?

I'd like to have some of the other features of KAM, but I want dual ports
that will both be concurrently operating on VHF.

Does anyone have these radios and can explain what they REALLY do as opposed
to what the "slick ads" and "glossy brochures" imply?

--Phil howard--  <[e-mail]>
-.-- . ...   - .... .. ...   .. ...   -- -.--
.-.-.- ... .. --. -. .- - ..- .-. .   ..-. .. .-.. .

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

Date: 14 Oct 89 04:51:51 GMT
From: unmvax!ariel!hydra.unm.edu![e-mail]  (David Oliver Eisman STUDEN)
Subject: KPC-2 is mute

Hi.  I have a problem.  My Kantronics TNC-2 clone isn't sending
out any audio to the microphone jack on my transceiver.

It works fine in every other respect: ptt works, receive works,
data comes in, etc.... just no data going out.

Any ideas?  What should I look for before popping the hood.

73



-----------------------------------------
Ollie Eisman - N6LTJ  [e-mail]
3505 Lafayette Rd. NE #3, Albuq, NM 87107
[phone]     or    [phone]

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

Date: 12 Oct 89 11:33:50 GMT
From: mcsun!ukc!slxsys!ibmpcug!cix![e-mail]  (Keith J Brazington)
Subject: Net/Rom Protocol Spec. Wanted

Most of the information about NET/ROM internals was contained in the
NET/ROM manual. This is probably the best source of info...

Keith G4LZV


--
Keith Brazington                                        Cix 01 399 5252.
System Manager                                         (v21,v22,v23,v22bis)
Cix (Compulink Infomation eXchange)
#disclaimer <My boss think my ideas are crazy, at times I agree, but not always>

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

Date: 13 Oct 89 20:12:00 GMT
From: ux1.cso.uiuc.edu!ux1.cso.uiuc.edu![e-mail]
Subject: Net/Rom Protocol Spec. Wanted

> >By the way, please don't ask me for a copy.  I no longer have any
> >code on my drives, having given up packet radio until such time
> >as 1200 baud half-duplex is a distant memory.
>
> I'm waiting for the same thing before I get into packet radio for the
> first time.  Throughput just isn't up to reasonable levels yet.  Keep on
> working on it, guys, and I'll join you in a few years.

I can't imagine it will take that long, unless you insist on staying only
on the 144 Mhz band.  The higher bands have the space for less efficient
(in terms of bits per square meter) modulation and transmission, so the
faster bit rates will surely be seen there first.

Still 2400 baud is readily available now.

--Phil howard--  <[e-mail]>
-.-- . ...   - .... .. ...   .. ...   -- -.--
.-.-.- ... .. --. -. .- - ..- .-. .   ..-. .. .-.. .

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

Date: 13 Oct 89 13:11:47 GMT
From: tank!eecae!cps3xx![e-mail]  (Usenet file owner)
Subject: Net/Rom Protocol Spec. Wanted

In article <[e-mail]> [e-mail] (Dan Frank) writes:
>[stuff deleted]
>By the way, please don't ask me for a copy.  I no longer have any
>code on my drives, having given up packet radio until such time
>as 1200 baud half-duplex is a distant memory.

I'm waiting for the same thing before I get into packet radio for the
first time.  Throughput just isn't up to reasonable levels yet.  Keep on
working on it, guys, and I'll join you in a few years.

>73, Dan, W9NK

In the rare case that original ideas   Kenneth J. Hendrickson    N8DGN
are found here, I am responsible.      Owen W328, E. Lansing, MI 48825
Internet: [e-mail]   UUCP: ...!uunet!frith!hendrick

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

Date: 13 Oct 89 18:42:43 GMT
From: beacon![e-mail]  (Mark W. Eichin)
Subject: TCP for CP/M???

I've heard of the KA9Q TCP package written in C, and had heard it will
run on PCDOS and similar machines, but recently I caught a mention
that there was once a CP/M version of it... Is this still available?
What was it written in?  Does anyone use it and have comments? email
me, and I'll summarize. Tnx & 73s...
                    Mark Eichin N1DPU
                    <[e-mail]

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

End of PACKET-RADIO Digest V89 Issue #211
*****************************************
16-Oct-89 16:06:39-MDT,9581;000000000000
Return-Path: <[e-mail]>
Date: Mon, 16 Oct 89 15:00:20 MDT
From: [e-mail]
Reply-To: [e-mail]
Subject: PACKET-RADIO Digest V89 #212
To: [e-mail]

PACKET-RADIO Digest         Mon, 16 Oct 89       Volume 89 : Issue 212

Today's Topics:
             Comments on Net/Rom
              PK-232 PACMAIL Tip
           Systems Linked Into Packet Radio
          VT100 emulation for KA9Q net code
----------------------------------------------------------------------

Date: 16 Oct 89 18:52:56 GMT
From: ad.dec.com![e-mail]  (16-Oct-1989 1450)
Subject: Comments on Net/Rom

Thanks to all who replied to my query on the Net/Rom protocol.  To summarize:

- The protocol *is* documented in the Net/Rom manual.  However, the
  documentation is not complete enough to be considered a "specification"

- There is an implementation of the Net/Rom protocol written by Dan, W9NK
  inside the KA9Q TCP/IP package.

- And finally, there is the German commented 'C' source for TheNET, the
  Net/Rom clone/rip-off (depending on your point of view).  Perhaps someone
  could take this code and write a description of the Net/Rom protocol
  complete enough to be considered a specification.  I could do this, but
  it would put any future Net/Rom code what I would write under a cloud...


And just a few of my own observations:

- I was suprised to find out that Net/Rom is a datagram style network with
  an end-to-end transport protocol on top.  For some reason or other, I
  had always assumed that Net/Rom was a virtual-circuit style network.

- I was also suprised to see how dumb Net/Rom was in some areas.  Dan, W9NK,
  addressed some of the shortcomings (like adding exponential backoff for
  timeouts, etc) in his implementation.

- Advantages I see (compared to other networking protocols):

    - It runs on minimal hardware (TNC 2 box).  Also, all of the
      networking stuff is in the switch nodes, the user's nodes don't
      even have to know about the prococol.  However, you can use only
      the datagram layer (say, for IP) if you want.  Or, you can go
      all the way and implement the Net/Rom transport protocols on your
      user node.

    - You can "see" the innards of the network and play with the switches:
      IP and ROSE attempt to make the network as transparent as possible,
      which is all fine and dandy, but kind of boring.

    - Net/Rom works farily well NOW, even with its shortcomings.  With
      the shortcomings fixed, it should work even better.


- And, disadvantages (again as I see):

    - No "no strings attached" implementation for the TNC 2 box

    - No way to optionally make the network transparent like ROSE or IP.
      Connecting to Netrom node A, thru to Netrom node B, then out to
      user node C gets kind of tedious.  A connect scheme that uses the
      digipeater fields (like ROSE does) would be nice.

    - Dumb, fixed timing values

    - Routing news travels too slowly.  "Good news" (e.g. new nodes)
      travels throughout the network rapidly, but "bad news" (e.g. nodes
      that can no longer be reached) takes a while to make its way
      around.


So, for those of you that have worked with the various Network/Transport
protocols (TexNet, ROSE, and TCP/IP), how do you think Net/Rom stacks against
the rest?

=  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =
Andrew C. Payne, N8KEI          Internet:  [e-mail]
                    UUCP:  ...!decwrl!ad.enet!payne

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

Date: 15 Oct 89 03:24:49 GMT
From: usc!ginosko!cs.utexas.edu!ut-emx!lad-shrike![e-mail]  (R M Kriss)
Subject: PK-232 PACMAIL Tip

PK-232 PACMAIL Tip 14-Oct-89 by Dick Kriss, KD5VU

If you have the new AEA PK-232MBX (with Mailbox) and are a Macintosh user
running Scott Watson's Red Ryder v10.3 application, save this posting.

The new PK-232MBX works great and has many neat features that make the
upgrade worth the investment; however, it has three shortcomings:

    1. No 'Help' message
    2. No Subject lines for messages
    3. Kills (trashes) all messages when you give it a RESTART command.

The RESTART command is automatic when the ON/OFF button is pushed or if
power is disconnected. This is a serious drawback and a dumb design from
AEA.

Since I do not leave my PK-232 in operation 24 hours a day, I prepared
three Macintosh Red Ryder procedures and two TEXT files that solve most of
the shortcomings mentioned above. For unattended operation, I pull down a
custom PK-232 Menu and mouse on MBX ON, then mouse on another item labeled
Reset MBX Msgs. Thats it! The procedures can be called from a macro key if
you wish.

If someone connects to my station, the CTEXT message tells them I may not
be available and tell them to get HELP by entering L for list, B for Bye
or S to send a msg to me. I would like to add more to the CTEXT message,
but we are limited to 120 characters. (May change the text to say enter
'R 1' to get help) The next thing they see on the screen is the (B,K,L,R,S) >
standard users prompt.

If they enter 'B', they are history, normal disconnect. If the enter 'L',
the PK-232MBX presents them with a standard listing of messages with one
minor change. Message #1 is addressed to 'ALL' from 'HELP' and Message #2
is addressed to 'ALL' from 'BRAG'. I forced this since the PK-232MBX does
not have a subject line. The script for the Reset MBX Msg procedure first
changes the MYCALL to HELP, sends the prepared TEXT, then resets the
MYCALL to BRAG, sends a second TEXT file, then resets MYCALL back to
mycall.

If they enter R 1 (for Read Msg#1), they get a fairly detailed HELP file
that I prepared from the AEA manual. Message #1 contain a KD5UV station
description. The neat part of this procedure, macro or whatever you want
to call it is I can reload standard messages in about three seconds with
one mouse click.

The MBX ON macro makes several PK-232 setting changes CTEXT, BTEXT, MAI
ON, MPROMPT, 3RDPARTY etc. The MBX OFF macro turn MAIL OFF and resets some
of the other settings for non-Mailbox operation.

If you would like a text file copy of my procedures, you have several
options: send me a disk and sase, request by E-mail (ARPANET), send me a
packet message with your home BBS or download MBXTIP.sit from the
MacScience BBS (408-866-4933). If you like it, use it and pass it to
others. If you don't like it, trash it. This simple procedure was fun to
write and make operation of the PK-232MBX even easier.  I may write one
that saves all messages and that can be restored with one mouse click.
Just ran out of gas messing with this one.

PS: If someone knows how to fix the PK-232MBX memory, please send me a
note, and a copy to AEA!

To quote Andy Rooney, "Computers make it easier to do a lot of things, but
most of the things they make it easier to do don't need to be done."
=====================================================================
   Richard (Dick) Kriss: : ARPANET: [e-mail]
      904 Dartmoor Cove: : Packet Radio: KD5VU @ KB5PM.TX.USA.NA
    Austin, Texas 78746: : Phone: [phone] (O) or 327-9566 (H)
  My employer has nothing to do with this message! ...  _._
=====================================================================

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

Date: 15 Oct 89 21:32:47 GMT
From: attctc!jolnet!ramrez![e-mail]  (Bill Clark)
Subject: Systems Linked Into Packet Radio

I am interested in links to packet radio.  I Would like to send some mail to some folks tied only to packet.  Any help would be appreciated.

send advise to

UUCP: {attctc|netsys|igloo}!jolnet!ramrez!clark
Name: Bill Clark, (clark)
USPS: 111 Dow Lane, Whiteman AFB, Mo 65305
Phone:  [phone]


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

Date: 15 Oct 89 21:23:01 GMT
From: ka9q.bellcore.com![e-mail]  (Phil Karn)
Subject: VT100 emulation for KA9Q net code

In article <[e-mail]> [e-mail] (Ed Brill KA9TAW) writes:
>I use KA9Q net code to connect to our various network resources here at IU
>from time to time.  Things like the emacs editor, though, have real trouble
>trying to work with KA9Q (through no fault in the software, that's not really
>something hams often have to worry about).
>
>Is there an ANSI.SYS driver or something like that, or a code modification I
>could use to get net to work better with emulation?

Ed,

Get the nansi.sys driver from SIMTEL20 (or from the mirror archives on
wuarchive.wustl.edu). Load it as a device driver in your MS-DOS config.sys.
Also fetch the termcap entry for nansi that's available from the same
places, and install it on your UNIX machine.

I'm using that combination right now, and it works great. I've often thought
about putting additional terminal emulation capabilities into the KA9Q
package, but I can't figure out how to do so without greatly reducing the
portability of the package. And, I'm sure that once I implemented one
particular terminal type, I'd be deluged with requests to support every
other one known to mankind...

Phil

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

End of PACKET-RADIO Digest V89 Issue #212
*****************************************
18-Oct-89 10:39:44-MDT,5448;000000000000
Mail-From: KPETERSEN created at 18-Oct-89 10:29:30
Return-Path: <[e-mail]>
Date: Wed, 18 Oct 89 10:29:30 MDT
From: [e-mail]
Reply-To: [e-mail]
Subject: PACKET-RADIO Digest V89 #213
To: [e-mail]

PACKET-RADIO Digest         Wed, 18 Oct 89       Volume 89 : Issue 213

Today's Topics:
               PK-88 and MacNet works!
               TCP for CP/M???
        Unrestricted access (was Re: Part 15)
----------------------------------------------------------------------

Date: 17 Oct 89 00:10:40 GMT
From: [e-mail]  (Richard Clemens)
Subject: PK-88 and MacNet works!

Earlier this year I wrote:

>I am still have problems with the PK-88 talking to the Macintosh
>when using MacNet Version 1.0.  The information is still stuck in
>the PK-88s buffer and will not dump to the computer until an exit
>from host mode occurs.

And got several responses but none worked.  Now Dick Rucker, KM4ML,
checked with AEA and they suggested a jumper between R5 and R7 on
their leads nearest the serial port connector for Macket and MacRatt
host mode and so I tried it for MacNet and it seems to work just fine
(no pun intended Steve)!

My cable is:

DB-25         MacPlus
          Mini-8
  1             4,6
  2             5
  3             3
  7             4,6
  8             1
 20             2

________________________________________________________________________
Rich Clemens                    Associate Professor, WV Wesleyan College
Phone:  [phone] office            Bitnet: [e-mail]
    304-472-3029 home                           [e-mail]
TCP/IP: [44.058.000.003]                         Packet: KB8AOB @ WB8CQV
________________________________________________________________________

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

Date: 16 Oct 89 21:16:20 GMT
From: ka9q.bellcore.com![e-mail]  (Phil Karn)
Subject: TCP for CP/M???

[e-mail] (Mark W. Eichin) writes:
>I've heard of the KA9Q TCP package written in C, and had heard it will
>run on PCDOS and similar machines, but recently I caught a mention
>that there was once a CP/M version of it... Is this still available?
>What was it written in?  Does anyone use it and have comments? email
>me, and I'll summarize. Tnx & 73s...

Mark,

What you probably heard about was the very early origins of my code,
which indeed ran on a CP/M machine. A Xerox 820, to be exact. I threw it
together in late 1985, mainly in response to a challenge by WB4JFI who
had been loudly claiming that TCP was far too complicated to ever be
implemented on a machine that hams could afford. I had it going in time
for a Telnet and FTP demo in early 1986 at the ARRL Computer Networking
Conference in Orlando.

Although the TCP/IP code itself had no trouble fitting (it's actually
smaller than the AX.25 code, for those who like to argue about whose
protocol is more gratuitously complex) the rest of the package (servers,
clients, buffer management, kernel, session control, device drivers,
ax25, etc) quickly outgrew the limited memory available on the 820. When
I got a PC the following year I moved the code to the PC platform where
it has remained since. Not only is there 10x as much total memory
available, but the same C code typically compiles into half as much
code space on the PC's 8088 as it did on the 820's Z-80.

So the short answer is that yes, somewhere around here on 8" disk I have
the very early version of my code during its short stay on the 820, but
no, you don't want it. Go buy a PC; XT clones are now dirt cheap, and
CP/M is just not worth the hassle.

Phil

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

Date: 13 Oct 89 16:17:39 GMT
From: hpl-opus!hpnmdla![e-mail]  (Glenn Elmore)
Subject: Unrestricted access (was Re: Part 15)

Assuming omni transmit antennas with 1 W ERP and the transmitter not
buried inside a building and a 1 Meter receive antenna:

running this at 900 mHz the 1 Meter receive antenna has about 17 dB
of gain, for a separation of 10 kM ( I just picked a number)
 "path loss" is about 111.5 dB so power at the antenna
terminals is -81.5 dBm. KTB in 1 MHz BW to support? 1 Mbps is -114 dBm.

This leaves 33 dB of S/N to make up for non LOS paths, increase noise
floor from all the other blasted 1W spread sources etc etc.

Frequency is not an issue here (as far as "path loss" goes) because
we are radiating constant flux, 1 W ERP, and receiving with constant
physical aperture, 1 Meter diameter. "path loss" goes up with frequency
but antenna gain goes up also for the constant size and they cancel.

Actually using 5700 MHz would be better because if we can still generate the
1W ERP ( I think it has to be 1W of RF and an omni antenna, not 10 mW and
20 dB gain but I'm not sure) the receive antenna provides a lot lower
beamidth and discriminates against the other QRM.

It looks like we could support full Ethernet speeds on a 10 kM path and
still have 10 dB of margin above threshold for tolerable BER.

Amazing, isn't it?

Glenn Elmore -N6GN-

N6GN @ K3MC
[e-mail]
[e-mail]

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

End of PACKET-RADIO Digest V89 Issue #213
*****************************************
19-Oct-89 11:30:15-MDT,20476;000000000000
Mail-From: KPETERSEN created at 19-Oct-89 11:16:56
Return-Path: <[e-mail]>
Date: Thu, 19 Oct 89 11:16:55 MDT
From: [e-mail]
Reply-To: [e-mail]
Subject: PACKET-RADIO Digest V89 #214
To: [e-mail]

PACKET-RADIO Digest         Thu, 19 Oct 89       Volume 89 : Issue 214

Today's Topics:
                More comments
        More Net/Rom & ROSE comments (2 msgs)
               TCP for CP/M???
          Time for a new design for packet?
----------------------------------------------------------------------

Date: 19 Oct 89 13:45:31 GMT
From: ad.dec.com![e-mail]  (19-Oct-1989 0943)
Subject: More comments

*** Phil, KA9Q writes:
>For perhaps the first time on this forum, I agree fully with Gordon Beattie.
>The notion that a packet network that *requires* the users to do manual
>routing is somehow superior to an automatically routed network is ludicrous!

    I don't know where this notion came from, but I hope I explained
myself clearly in my earlier post.  I just like having options....

>I don't think the people who operate the ARPA Internet and do networking
>research with it consider it "boring" that the Internet provides automatic
>routing. Nor do its users. Of all the networking packages available for

    I use the Internet and DEC's internal network daily and I don't
find it boring at all.  I do find it "boring" when something doesn't work
("node not responding", or "connect failed") and there is no way for me
to find out more (I love to tinker with these things!)

[ ... stuff deleted ...]

>So there are still plenty of "hooks" in the Internet to play with if you
>want to see what's going on. These facilities all fall in the rather
>nebulously defined area of "network management", which is a pretty hot topic
>right now.

    Yep, I've been wanting to play with some of the "hooks" in IP for
a while now, but haven't been able to on the ARPA Internet because I've
always lacked the privs.  I've gotta dig my Mac out of storage and get on
TCP/IP using it as a dedicated box....

    Phil, I think you hit the nail on the head by saying that "network
management ... is a pretty hot topic".  Things are still so very young, and
my top two things I'm currently looking for in a network are:

    1) Transparency
    2) Optional hooks to make it untransparent

    (For me, #2 is really close behind #1)

    Also, thanks Phil for your summary of the various routing issues --
I'm saving that one.

    Well, enough of my ramblings for now.  As usual, comments appreciated.

=  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =
Andrew C. Payne, N8KEI          Internet:  [e-mail]
                    UUCP:  ...!decwrl!ad.enet!payne

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

Date: 19 Oct 89 05:28:30 GMT
From: ka9q.bellcore.com![e-mail]  (Phil Karn)
Subject: More Net/Rom & ROSE comments

For perhaps the first time on this forum, I agree fully with Gordon Beattie.
The notion that a packet network that *requires* the users to do manual
routing is somehow superior to an automatically routed network is ludicrous!

I don't think the people who operate the ARPA Internet and do networking
research with it consider it "boring" that the Internet provides automatic
routing. Nor do its users. Of all the networking packages available for
amateur packet radio, mine is the only one I know of where it is standard
practice for the end users and applications to specify ONLY the ultimate
destination of a network request when opening an end-to-end connection or
sending a datagram.  This goes well beyond NET/ROM and ROSE in that you
don't even need to specify the entry and exit points of the "backbone"
network; the connection is truly end-to-end. (To be fair, the NET/ROM and
ROSE protocols COULD both be used in a true end-to-end mode analogous to
TCP/IP. But at present, the only package that supports the NET/ROM protocols
in this mode is mine, thanks to W9NK's contribution, and I do not believe
that RATS has yet produced an end-host implementation of ROSE -- Gordon,
correct me if I'm wrong.)

Even though they don't have to specify a route each time they establish a
connection, it is true that most users of my code have to configure their
local routing tables manually when they come up on the air for the first
time.  I certainly don't consider this a feature. I consciously decided to
defer *fully* automatic routing because I knew that the job was a difficult
one.  (Just *how* difficult, I'm only learning now!) Most of the TCP/IP
users are at fixed locations, so statically maintained tables do not need to
be updated frequently.  Nevertheless, fully automatic routing is definitely
in the works thanks to several contributors to the project.  (The current
NOS code does support BSD-style RIP, but I do not recommend its use over
radio for anything except small-scale experimentation).

With or without automatic routing table maintenance, the Internet Protocol
(IP) provides facilities for source routing (the user picks the route),
although they are very seldom used. My code supports source routing at the
IP layer, although there is at present no way for the end user to actually
specify a route.  (There just hasn't been any demand for it.) The Internet
Control Message Protocol (ICMP) is used to notify users of the Internet when
packets cannot be delivered for any of a number of reasons, including
routing problems; you can have my package display these if you want.  There
are some clever tricks you can play with IP and ICMP to determine the route
the network is taking to reach a given destination; they are used in the
"traceoute" package that is popular in the Internet. I haven't yet
implemented such a feature in my code, but I've been thinking about it.

So there are still plenty of "hooks" in the Internet to play with if you
want to see what's going on. These facilities all fall in the rather
nebulously defined area of "network management", which is a pretty hot topic
right now.

Phil

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

Date: 19 Oct 89 06:40:36 GMT
From: ka9q.bellcore.com![e-mail]  (Phil Karn)
Subject: More Net/Rom & ROSE comments

It occurred to me after sending my last message that a discussion of routing
related terms might be useful in explaining just what the features are of
various networks, since I often find that people are confused easily by
terms like "static routing" and "incremental routing".

1. Source Routing vs Incremental Iouting

Source routing - the originator of a packet specifies the entire route it is
to take through the network.  The major advantage of source routing is that
a knowledgeable user can take manual control and bypass a broken automatic
routing mechanism. Another advantage is that unintentional routing loops are
impossible.  AX.25 digipeater paths are the obvious example in the amateur
world, although those who use UUCP are also familiar with the "bang paths"
used there. The Internet supports it as a rarely-used option, and IBM has
proposed a bridging technique for token-passing ring LANs that uses source
routing.  Note that HOW the end system puts the route into the packet is not
specified; the user at the keyboard might have to specify it manually, or it
might be kept in a local database and invoked automatically when the user
specifies just the destination. (My code allows both forms of operation in
the AX.25 layer.)

Incremental routing - the opposite of source routing.  Each node need know
only the next node to which a given packet or message should be sent to take
it closer towards its destination; where it goes once it reaches the next
node is the decision of that next node.  The main advantages of incremental
routing: smaller routing tables in each node and less packet overhead since
no source route must be carried.  This is by far the most popular approach
taken in modern packet networks; it's used by default in IP (though source
routing is available as an option), it's used inside a NET/ROM backbone, and
I believe it's used in ROSE. Note that even though a NET/ROM network uses
incremental routing internally, the AX.25 end user is still required to
*partially* source route his traffic by specifying the entry and exit points
to and from the NET/ROM backbone. This can be avoided if the end users run
the NET/ROM protocol stack on their own machines.

2. Static Routing vs Dynamic Routing

Static routing - the node routing tables used in either a source routed or
incrementally routed network are maintained manually. Advantage: simple and
stable; requires no network overhead. If done properly, routing loops are
easily avoided. Disadvantage: requires manual reconfiguration whenever the
network topology changes.  ROSE and (most) amateur TCP/IP stations are
currently using static routing.

Dynamic routing - the opposite of static routing.  The routing tables in the
nodes are maintained automatically by real-time information received about
the nodes and links in the network. Advantages: automatic adaptation to link
and node failures, automatic incorporation of new nodes and links into the
network, ability to reroute traffic automatically in event of congestion in
parts of the network. Disadvantages: can be difficult to implement, requires
network bandwidth for passing routing information (can be considerable if
the protocols are not properly designed or tuned, e.g., RIP.) The (real)
TCP/IP internet uses dynamic routing, as does NET/ROM and virtually every
large packet network. (Virtual circuit based networks that use dynamic
routing generally fix the path taken by a call once it is established;
it is subsequent calls that may take different paths to a given destination.
Datagram networks can dynamically route on a per-packet basis.)

2.1. Centralized dynamic routing vs distributed dynamic routing

There are two major categories of dynamic routing algorithms: centralized
and distributed. In centralized routing, the network status information is
funneled to a central point where routes are calculated for each node in the
network and fed out to the various nodes. In distributed routing, there is
no central node; the nodes exchange information among themselves and they
each compute their own routing tables on the basis of this information.  The
main advantage of centralized routing is that coordinated, network-wide
policies and strategies can be implemented more easily, but in general the
severe vulnerability of the centralized approach to failures (particularly
of the central node) has made the distributed approach more attractive even
though it is harder to implement properly.

The TYMNET X.25 network and IBM networks are among the only networks I know
of that rely heavily on centralized routing; the rest (the telephone
network, Telenet, the Internet, NET/ROM) are all distributed. I think it's
safe to say that distributed routing is clearly the way to go in the amateur
world.

2.2.1 Distance vector distributed routing vs link state distributed routing

Moving down a level, there are two major categories of distributed routing
algorithms: distance vector and link state.  In distance vector routing, the
neighbors periodically exchange their routing tables with each other, often
by broadcasting them on a common channel (radio, Ethernet). Each entry in
the table specifies a destination and the "distance" (cost, number of hops,
etc) to that destination, hence the name "distance vector". Each node
receiving a routing broadcast compares the distances advertised by its
neighbor to those already in its own table. If a neighbor's route to a given
destination is better, it is incorporated into the node's routing table and
passed on in its own routing broadcasts.  The major advantage of the
distance vector technique is simplicity and minimum memory requirements, but
a major disadvantage is slow adaptation to change (especially link failures)
and a strong tendency to form routing loops just after link failures have
occurred.  Enhancements to the algorithm that reduce the frequency of
routing loops do exist, but they sometimes cause outright outages between
given pairs of points when things are rapidly changing in between.  RIP (the
de-facto Ethernet routing protocol) and NET/ROM routing are examples of
distance vector routing. Cisco Systems uses a proprietary distance vector
algorithm called IGRP.

The other type of distributed routing is the link state algorithm. In this
technique, each node issues information only about the state of its own
links. This information is propagated throughout the entire network using a
"flooding" technique very similar in concept to that used in USENET. Every
node keeps copies of the link state updates from every other node in the
network, and from this "link state database" each node can compute the
optimum route to every other destination.  The main advantage of this method
over the distance vector approach is much quicker adaptation to failures and
reconfigurations with much lower susceptibility to routing loops. The main
disadvantage is the more complex implementation, plus the extra memory
required to hold the link state database. Nevertheless, this method is
rapidly displacing the distance vector approach. Link state routing is used
internally in the ARPANET and MILNET, and in the new NSFNet that now forms
the backbone of the US Internet. The Internet community has just proposed a
link state algorithm that is intend to replace RIP.  Several people are now
working on link state implementations for amateur TCP/IP as well.

3. Flat vs Hierarchical addressing

Flat addressing - the address of a node in the network has no relation to
its topological location. This generally requires an individual entry in the
routing table of every node in the network for every other node.
Advantages: can support arbitrary topologies. Node addresses need not change
when they are moved.  Disadvantages: large routing tables (total memory
needed by all the nodes goes up as the number of nodes squared). Network
overhead for routing updates also goes up rapidly with increasing network
size. Flat addressing is used by NET/ROM and bridged Ethernet networks.

Hierarchical addressing - the address of a node gives at least a partial
hint as to the nodes location. Advantages: Nodes far away from a given area
can use a single routing table entry to refer to all the nodes in that
distant area, greatly reducing the rate at which routing tables and network
overhead increases as the network grows.  Virtually all large networks use
hierarchical addressing in various forms, including the telephone network,
the postal system, the Internet, the commercial X.25 networks and ROSE.

My own code allows the network designer to use a mixture of flat and
hierarchical addressing as he sees fit.

I hope this summary of the various pros and cons has helped people
understand the issues involved.

73, Phil

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

Date: 18 Oct 89 23:33:38 GMT
From: beacon![e-mail]  (Mark W. Eichin)
Subject: TCP for CP/M???

ka9q>So the short answer is that yes, somewhere around here on 8" disk I have
ka9q>the very early version of my code during its short stay on the 820, but
ka9q>no, you don't want it. Go buy a PC; XT clones are now dirt cheap, and
ka9q>CP/M is just not worth the hassle.

Well, dirt-cheap XT clones aren't portable. Expenseive portables still
draw gobs of power. I intend to port the stuff to my Cambridge Systems
Z88 -- 20 hours on 4AA batteries, and I'm already using it as a packet
terminal. The whole setup (terminal, tnc, 2m HT, and gelcell for the
TNC) ts in a small briefcase, or backpack -- I got at least three more
of my hacker friends interested in packet (and ham radio) when they
saw it. The Z88 has 128K of RAM (and can go to >1Meg) and a 3.5Mhz
Z80, plus some smart IO hardware, so it is a little bit upscale of a
CP/M system.

So, does anyone have a copy of the early stuff, or should I just go
ahead and port the C stuff by hand? (I've already got a few requests
to forward the stuff in any case...)
                    _Mark_ N1DPU
                    <[e-mail]>

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

Date: Wed, 18 Oct 89 08:26 MDT
From: Vern Cole -- Systems Manager <[e-mail]>
Subject: Time for a new design for packet?

The air seems to be full recently with comments reflecting on the limitations
of packet radio.  Perhaps it is time to broach a subject about which I have
been stewing for some time ... but have kept patient silence.

Computer Science people may remember a suggestion by Brooks {of Brooks' Law
fame*} that in any computer project you should "Plan to throw one away."
That is: when you finally finish a large computer project you will have found
out lots of errors you made in your early design assumptions which you can't
take out without completely redoing it.  The thing to do to get it right is to
immediatly get rid of the first system and then design its replacement using the
experience of the first as a prototype to correct the second.

Compare OS-MVS on the 370 archetecture with VMS on the VAX and you have an idea
what that means.  IBM kept ALL the old stuff and built on it, DEC threw away
the errors and kept only the good stuff.  Perhaps that it why IBM is now worried
about loosing market share to DEC.  -- Other examples are left as an exercise
to the reader.

Packet Radio is built using some wrong assumptions.  They weren't wrong when
TAPR and the other pioneers started work, but have been made wrong by the very
popularity of packet radio.  The success of packet has made the early
assumptions wrong.  Now that packet is prooven and experience is here, it is
time to throw the old design away and start over.

The TAPR design assumes that:
 1)  HAM operators would be communicating interactively with each other via
dumb terminals -- human to human.
 2)  Voice radios would be adequate for digital communications.
 3)  The X.25 and HDLC protocols widely used in wire communications would also
be efficient when used on radio.

Actual communications is usually either electronic messaging (human to machine
on BBSes but more efficient machine to machine), and data transfer (machine
to machine).  Store and forward would be much more effective that end-to-end
packets for machine to machine work.

Voice radios are too narrow band and much too slow in "Clear to send" time to
do effective data comm.  ("I'm going to forget about packet until 1200 baud
half-duplex is a memory.")

One shot error-detect-and-retry protocol to single addressees is not an
effective use of a broadcast media.  The media calls for error CORRECTING
redundancy codes and multi-address communications.  I should be able to do a
QST or club meeting by packet.

If I want to send an announcement to all the members of my {whatever} club, why
should it be transmitted 31 times; once to the BBS and then read by each of 30
members over the air?  My station should broadcast it ONCE.  If any receiving
stations get errors, its computer should fix it, or flag it.  If Joe, across
town, can't make sence out of his copy (remember, Joe can read CW with one
third of the characters missing) his computer can ask mine (or, perhaps the
clubs) for a clean copy.

Perhaps we should even use a dreaded UNbalanced protocol, where the central
(BBS - net control) station has more "authority" than the end nodes.

I think it's time for a new plan, based on computer-to-computer communication
using radios designed from the  antenna down to do nothing but digial
communication. I want to receive this newletter on my radio.

What think ye?
---------------------
Vern Cole -- Systems Manager -- Utah Valley Community College
snailmail: 800 W. 1200 South, Orem, UT 84058
Voice: [phone] ext 160
Radio: KF7XM @ 145.37(-)mhz
Bitnet: VCOLE@UTAHCCA
Internet: [e-mail]

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

End of PACKET-RADIO Digest V89 Issue #214
*****************************************
19-Oct-89 16:35:49-MDT,17623;000000000000
Mail-From: KPETERSEN created at 19-Oct-89 15:43:03
Return-Path: <[e-mail]>
Date: Thu, 19 Oct 89 15:43:02 MDT
From: [e-mail]
Reply-To: [e-mail]
Subject: PACKET-RADIO Digest V89 #215
To: [e-mail]

PACKET-RADIO Digest         Thu, 19 Oct 89       Volume 89 : Issue 215

Today's Topics:
             Comments on Net/Rom (2 msgs)
        More Net/Rom & ROSE comments (2 msgs)
               TCP for CP/M???
          Time for a new design for packet?
          What has become of WB3FFV's XBBS?
----------------------------------------------------------------------

Date: 18 Oct 89 17:34:55 GMT
From: [e-mail]  (Dan Frank)
Subject: Comments on Net/Rom

   One thing I didn't note in my posting:  NET/ROM routing stinks.
There is nothing good to be said about it.  For more information
read my 7th Networking Conference paper.

   Dan, W9NK

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

Date: 17 Oct 89 22:23:41 GMT
From: att!cbnewsh![e-mail]  (j.gordon.beattie)
Subject: Comments on Net/Rom

The reference made to the the boring nature of ROSE X.25 and IP networks
is absurd!   Come on already, do we really need to have almost manual
networking to interest folks?  I don't think so.  In fact our users are
thrilled that they don't need to patch connections together like Net/Rom
NETWORKS regularly require.  Fact 1: A Net/Rom user must connect to an
access switch, then call to the terminating (or intermediate) switch,
then call the user with whom a dialogue is desired.  Three steps!
If the network gets chopped up then the user must place calls between
sites in order to get the connection built!  This means four or more
steps!...uuuugh!  Conclusion: Net/Rom is, from a user perspective
similar to calling Mabel and asking her to place a call to your
cousin in Tombstone.
Fact 2: ROSE X.25 Network users place one call to their party via
and access switch and egress address.  ONE STEP.  Boring maybe, but
it works real well for the users. (REMEMBER THEM?)
Conclusion:  When two systems work well choose the simpler one even
if it is "boring".

One other point Net/Rom networks often get trashed by dumb users
who route their own calls (uuugh!).  This can take several forms
including routing loops, poor trunks etc.  The ROSE X.25 Switch
doesn't let that happen.  It clears call loops and tries the next path.
It also chooses routes that have been tested and are known to work
well, no dynamic path roulette with user calls.

The ROSE X.25 Switch runs in a TNC-2 (or clone) and a PAC-COMM DR-200.
Soon it will run in MS-DOS and similar machines.
If you would like the software, then contact me via telephone.
73,
Gordon Beattie, N2DSY
201-615-4168(O)
201-387-8896(H)

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

Date: 18 Oct 89 22:15:55 GMT
From: ad.dec.com![e-mail]  (18-Oct-1989 1804)
Subject: More Net/Rom & ROSE comments

(First, a disclaimer on my part. I have never used ROSE.  I have the source
to beta version of ROSE that I have looked at briefly.  I have used Net/Rom
and have looked at W9NK's implementation in the KA9Q package).

*** Gordon Beattie, N2DSY writes:
>The reference made to the the boring nature of ROSE X.25 and IP networks
>is absurd!   Come on already, do we really need to have almost manual
>networking to interest folks?  I don't think so.  In fact our users are

    I personally am more interested in how the network works than actually
using the network.  This interest is analogous to those who are interested
in ham radio for the "art" of radio (couldn't think of a better word :-)
instead of just for ragchewing.  Given these interests, a totally transparent
network is a little less interesting to me than one in which I can get my
hands on the internals.


>thrilled that they don't need to patch connections together like Net/Rom
>NETWORKS regularly require.  Fact 1: A Net/Rom user must connect to an
>access switch, then call to the terminating (or intermediate) switch,
>then call the user with whom a dialogue is desired.  Three steps!

    I know that this procedure is a little tedious.  I put this problem
on my "disadvantages" list of things to be improved:  I proposed adding a
scheme to Net/Rom similiar to the scheme used in ROSE: it wouldn't be that
hard.


>If the network gets chopped up then the user must place calls between
>sites in order to get the connection built!  This means four or more
>steps!...uuuugh!  Conclusion: Net/Rom is, from a user perspective
>similar to calling Mabel and asking her to place a call to your
>cousin in Tombstone.

    One advantage of this scheme is that the user immediately knows where
of three places his connect attempt failed:  from his home station to the
network entry point, through the network, or from the exit point to his
destination station.


>Fact 2: ROSE X.25 Network users place one call to their party via
>and access switch and egress address.  ONE STEP.  Boring maybe, but

    I like this feature.  What kind of call progress messages does ROSE
generate?  In other words, will ROSE tell me where a failed call failed?


>it works real well for the users. (REMEMBER THEM?)
>Conclusion:  When two systems work well choose the simpler one even
>if it is "boring".

>One other point Net/Rom networks often get trashed by dumb users
                               ^^^^ ^^^^^
    This I take a slight offense to -------------------^^^^
    and I'll try to explain why.

    I consider myself a "user", but far from a dumb one.  And no network
is so smart as to be able to find the best path all of the time.  I *like*
having escape hatches where I can sieze some control over what's going on.
Net/Rom allows me to do this.  What features does ROSE have for manually
routing calls?


>who route their own calls (uuugh!).  This can take several forms
>including routing loops, poor trunks etc.  The ROSE X.25 Switch
>doesn't let that happen.  It clears call loops and tries the next path.
>It also chooses routes that have been tested and are known to work
>well, no dynamic path roulette with user calls.

    Net/Rom is pretty dumb sometimes when it comes to routing.  I'll
have to take a closer look at how ROSE does routing.


>The ROSE X.25 Switch runs in a TNC-2 (or clone) and a PAC-COMM DR-200.

    This is a good feature.  It is still cheaper to put 2 or 3 TNC 2
clones on a mountaintop than some cheap PC/XT box.  The TNC 2's become even
more attractive if you want to battery back-up the sytem.  Where are you
PS-186???


>Soon it will run in MS-DOS and similar machines.

    This is good too.  I'm curious, is the MS-DOS implementation
intended for end users, or for network switches?

***
    I guess what it comes down to is that I like to drive a stick shift
car instead of an automatic.  I like having some control, instead of being
at the mercy of the network.  I said that completely transparent networks
are "boring" for the same reason I find driving an automatic "boring" --
lack of control.
    I like Net/Rom because it gives me some control.  I can see the
uplinks to a distant node and say:  "Ah, 3 users at 1200 baud, that's why
things are slow!"  Or, I can probe around the network and find routes that
are up or down, etc.  Or I can test a remote node's connectivity _into_
some area.

    Now that you ROSE users know where I'm coming from, what features
does ROSE have to accomodate a user like me?  In the meantime, I'll have to
dig out my ROSE sources and study them in a little more detail.  I'd like to
see a network that has the good features of both Net/Rom and ROSE, yet still
runs on a TNC 2 box (since there are so many of them around).

    As usual, comments?

=  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =
Andrew C. Payne, N8KEI          Internet:  [e-mail]
                    UUCP:  ...!decwrl!ad.enet!payne

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

Date: 19 Oct 89 09:41:17 GMT
From: pacific.mps.ohio-state.edu!gem.mps.ohio-state.edu!wuarchive!uwm.edu!ux1.cso.uiuc.edu!ux1.cso.uiuc.edu![e-mail]
Subject: More Net/Rom & ROSE comments

>       I personally am more interested in how the network works than actually
> using the network.  This interest is analogous to those who are interested
> in ham radio for the "art" of radio (couldn't think of a better word :-)
> instead of just for ragchewing.  Given these interests, a totally transparent
> network is a little less interesting to me than one in which I can get my
> hands on the internals.

You are not alone.  I like transparent networks, but my personal interest is
more into designing things for them.

>       I know that this procedure is a little tedious.  I put this problem
> on my "disadvantages" list of things to be improved:  I proposed adding a
> scheme to Net/Rom similiar to the scheme used in ROSE: it wouldn't be that
> hard.

The hard part is getting it to do it with.  If I had (been so nieve as to have)
written Net/ROM as it is now, I'd very easily be able to add this feature.

> >If the network gets chopped up then the user must place calls between
> >sites in order to get the connection built!  This means four or more
> >steps!...uuuugh!  Conclusion: Net/Rom is, from a user perspective
> >similar to calling Mabel and asking her to place a call to your
> >cousin in Tombstone.
>
>       One advantage of this scheme is that the user immediately knows where
> of three places his connect attempt failed:  from his home station to the
> network entry point, through the network, or from the exit point to his
> destination station.

Facilities can be built in to report this.  Of course reporting it will be
in the context of the route and no longer be transparent.  One might want to
know where their connections get routed through anyway.

>       This is a good feature.  It is still cheaper to put 2 or 3 TNC 2
> clones on a mountaintop than some cheap PC/XT box.  The TNC 2's become even
> more attractive if you want to battery back-up the sytem.  Where are you
> PS-186???

One of the reason's I'd like to be able to program code to go into a TNC box,
but so far I've not had much luck in getting specifications of the internal
environment such programs have to work in (e.g. what address is the serial
port, etc).

>       I guess what it comes down to is that I like to drive a stick shift
> car instead of an automatic.  I like having some control, instead of being
> at the mercy of the network.  I said that completely transparent networks
> are "boring" for the same reason I find driving an automatic "boring" --
> lack of control.

How about one who designs automatic transmission for a living, but only
drives a stick?  You know when to shift into 4th, you can make a machine
do it, but you don't care to actually have the machine do it for you (all
the time anyway).

>       I like Net/Rom because it gives me some control.  I can see the
> uplinks to a distant node and say:  "Ah, 3 users at 1200 baud, that's why
> things are slow!"  Or, I can probe around the network and find routes that
> are up or down, etc.  Or I can test a remote node's connectivity _into_
> some area.

I, too, would like control, but at an even lower level than Net/Rom gives
me (and not vanilla AX.25 either).  I want bit banging control.

This is not a criticism against Net/Rom, but it is obvious the author had
some info I can't seem to get, and he doesn't seem to want to part with
some things I'd like to have, like Net/Rom sources so I can try hacking
in some improvements.  I'd rather smooth out round tires instead of trying
to cut squares one, if you know what I mean.

--Phil Howard, KA9WGN--
<[e-mail]>

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

Date: 19 Oct 89 04:36:48 GMT
From: ka9q.bellcore.com![e-mail]  (Phil Karn)
Subject: TCP for CP/M???

>Well, dirt-cheap XT clones aren't portable.

I've run TCP/IP out of my car several times for demos using a NEC multispeed
laptop and a TNC-2 that I plug into the Icom mobile rig.  (It was fun to
look up the callsigns of the bystanders at our Field Day site in the callbook
database on the system at home).

Others frequently run my code on cheaper machines like Toshiba 1000s.  But
if you really want to run TCP/IP on cheap portable hardware, then my
recommendation is to start with my current code and try to port portions of
it to your hardware. Quite a few bug fixes have been applied to the code
that originally ran on the 820 four years ago.

Phil

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

Date: 19 Oct 89 19:08:54 GMT
From: shlump.nac.dec.com![e-mail]  (fred, k1io)
Subject: Time for a new design for packet?

In article <[e-mail]>, [e-mail] (Vern Cole -- Systems Manager) writes...
>Packet Radio is built using some wrong assumptions.  They weren't wrong when
>TAPR and the other pioneers started work, but have been made wrong by the very
>popularity of packet radio.  The success of packet has made the early
>assumptions wrong.  Now that packet is prooven and experience is here, it is
>time to throw the old design away and start over.

Actually, that's pretty much what the TCPers are doing... so we're in
agreement so far.

>The TAPR design assumes that:... (omitted for brevity)

Yes, your observation is valid.  There are reasons for supporting dumb
terminals (including PC emulation) and voice radios (available!) but
they shouldn't be the design center.

>One shot error-detect-and-retry protocol to single addressees is not an
>effective use of a broadcast media.  The media calls for error CORRECTING
>redundancy codes and multi-address communications.  I should be able to do a
>QST or club meeting by packet.
>
>If I want to send an announcement to all the members of my {whatever} club, why
>should it be transmitted 31 times; once to the BBS and then read by each of 30
>members over the air?  My station should broadcast it ONCE.  If any receiving
>stations get errors, its computer should fix it, or flag it.  If Joe, across
>town, can't make sence out of his copy (remember, Joe can read CW with one
>third of the characters missing) his computer can ask mine (or, perhaps the
>clubs) for a clean copy.

True, but not trivial.  You might want to check the hack I came up with
in RSPF, which does this for its routing updates.  Each route
advertisement is multicast, with each segment (=packet, in a
multi-packet message) numbered.  At the end, recipients know what they
have and what they don't.  I haven't put too too much thought into
selective retransmission yet (since RSPF repeats the cycle often enough
and allows some polling), but it's not that tough, or easy, a problem.
Bulk-transfer protocols like NETBLT overlap the issue.

>Perhaps we should even use a dreaded UNbalanced protocol, where the central
>(BBS - net control) station has more "authority" than the end nodes.

At the applications layer, yes, but that already occurs.  I hesitate to
apply this to a lower layer; it tends to make networks vulnerable when
the transmission is as crufty as packet radio's.  I observe, though,
that "packet cluster" software used by DXers is just as wasteful as
anything, and might be a good place to start.

>I think it's time for a new plan, based on computer-to-computer communication
>using radios designed from the  antenna down to do nothing but digial
>communication. I want to receive this newletter on my radio.
>
>What think ye?

Waddayathink Phil and the rest of the TCP/IP crowd has been doing all
these years?  Join in!

BTW I'm NOT saying that TCP/IP is the be-all and end all, just that the
TCPers are an example of hams who aren't following the TAPR/AX.25 model.
I have a personal notion of an OSI-IP ham network, f'rinstance... and
we could use some work on multicasting as per your observation.  73,
    fred

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

Date: 18 Oct 89 23:54:14 GMT
From: gem.mps.ohio-state.edu!wuarchive!uwm.edu!mailrus!jarvis.csri.toronto.edu!utgpu!utzoo!mnetor!tmsoft!nebulus![e-mail]  (Dennis S. Breckenridge)
Subject: What has become of WB3FFV's XBBS?

In article <[e-mail]>, [e-mail] (Mark J. Bailey) writes:
> Could someone please tell me what has happened to WB3FFV's XBBS bbs that
> he ran up in New Jersey?  I have not been able to get an answer for many
> months now.

Howard's new maxtor drive decided to commit silicon suicide about a month or
so ago. He had to send the drive out for service and you know what that
means. He assured me that he would have it up this weekend but I doubt it
He told me that his video card is causing some problems as well. I run the
same stuff here albiet I do not get the useage he does.


--
   ...- . ...-- --. ... ...   .--. .- -.-. -.- . -   --... ...-- .----. ...
    Dennis S. Breckenridge, VE3-GSS, Toronto, Ontario, Canada
    EMAIL: uunet!attcan!{tmsoft|telly}!nebulus!dennis
   ...- . ...-- --. ... ...   .--. .- -.-. -.- . -   --... ...-- .----. ...

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

End of PACKET-RADIO Digest V89 Issue #215
*****************************************
20-Oct-89 01:19:22-MDT,8717;000000000000
Return-Path: <[e-mail]>
Date: Fri, 20 Oct 89 01:01:02 MDT
From: [e-mail]
Reply-To: [e-mail]
Subject: PACKET-RADIO Digest V89 #216
To: [e-mail]

PACKET-RADIO Digest         Fri, 20 Oct 89       Volume 89 : Issue 216

Today's Topics:
      KA9Q 890421.1 XOBBS problem on Microport SysV/286
                KA9Q and Mail
                 KAM or KPC-4
            Net/Rom Protocol Spec. Wanted
               TCP for CP/M???
             THE ADDRESS OF TAPR?
              Using Tempo S-1 for Packet
          VT100 emulation for KA9Q net code (2 msgs)
----------------------------------------------------------------------

Date: 13 Oct 89 19:30:04 GMT
From: hpfcso!hpldola!hp-lsd!col![e-mail]  (Bdale Garbee)
Subject: KA9Q 890421.1 XOBBS problem on Microport SysV/286

>This jives with mail I got from Dave Toth, who says that Microport's
>message queues are broken. Rolfe Tessem, however, says that he has it
>running on his Microport SysV/286 system, also at 2.4.

Hmmm.  Wonder if Rolfe is running the XOBBS code, or just NET... NET by itself
obviously works fine...

Ain't "unsupported" unix in binary form fun?  :-)

Bdale

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

Date: 17 Oct 89 05:03:11 GMT
From: asuvax!stjhmc![e-mail]  (David Dodell)
Subject: KA9Q and Mail

I have recently installed the KA9Q tcp/ip package on my system.  In the mailbox
mode is on, it appears that the mbox can receive mail (including bulletins)
from a RLI style message forwarding system.

Is the tcp/ip only designed for receiving, or is there a way for it to send
mail to RLI style system for full bidirecitonal mail forwarding?

73,

David
wb7tpy@n7gll


--
   -------------------------------------------------------------------------
           uucp:  {decvax, ncar} !noao!asuvax!stjhmc!ddodell
    uucp:  {gatech, ames, rutgers} !ncar!noao!asuvax!stjhmc!ddodell
    Bitnet: ATW1H @ ASUACAD                    FidoNet=> 1:114/15
          Internet: [e-mail]

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

Date: 17 Oct 89 05:01:16 GMT
From: asuvax!stjhmc![e-mail]  (David Dodell)
Subject: KAM or KPC-4

In a message of <Oct 16 12:9>, [e-mail]  writes:

 >The KAM has two ports, and advertisements say it is HF+VHF capable.  Does
 >that
 >mean one of them will be only for HF while the other is for VHF?

This is correct.  One port is designed for HF operation, and the second port
for VHF.

 >I'd like to have some of the other features of KAM, but I want dual ports
 >that will both be concurrently operating on VHF.
 >
 >Does anyone have these radios and can explain what they REALLY do as
 >opposed
 >to what the "slick ads" and "glossy brochures" imply?

I have the KAM and would be glad to answer any specific questions you have via
mail.  From my understanding both the KAM and KPC4 are dual port TNCs, however
the KAM can only operate HF <-> VHF operation, while the KPC4 is designed for
VHF(UHF) <-> VHF (UHF) operation.

David wb7tpy@n7gll


--
   -------------------------------------------------------------------------
           uucp:  {decvax, ncar} !noao!asuvax!stjhmc!ddodell
    uucp:  {gatech, ames, rutgers} !ncar!noao!asuvax!stjhmc!ddodell
    Bitnet: ATW1H @ ASUACAD                    FidoNet=> 1:114/15
          Internet: [e-mail]

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

Date: 16 Oct 89 14:48:24 GMT
From: hpfcso!hpldola!hp-lsd!col![e-mail]  (Bdale Garbee)
Subject: Net/Rom Protocol Spec. Wanted

>> >By the way, please don't ask me for a copy.  I no longer have any
>> >code on my drives, having given up packet radio until such time
>> >as 1200 baud half-duplex is a distant memory.
>>
>> I'm waiting for the same thing before I get into packet radio for the
>> first time.  Throughput just isn't up to reasonable levels yet.  Keep on
>> working on it, guys, and I'll join you in a few years.
>
>I can't imagine it will take that long, unless you insist on staying only
>on the 144 Mhz band.  The higher bands have the space for less efficient
>(in terms of bits per square meter) modulation and transmission, so the
>faster bit rates will surely be seen there first.

While I understand that Dan has some immediate family time requirements, and
I'm willing to "let him off the hook" since he's already contributed a neat
hunk of code to "the cause"... but...

In general, I think this attitude STINKS.

Why should I get excited about building a high-speed network, so that when
throughput "is up to reasonable levels", you can just hop in and play for free?

This is a fundamental stumbling block towards developing higher speed network
facilities!  I'm going to keep working regardless, but I *need* your help to
get enough critical mass of folks to build (and maintain!) a high-speed
amateur data network.

"We have the technology"... what we don't have is a large enough group of
committed folks to make it really happen...

73 - Bdale, N3EUA

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

Date: 16 Oct 89 14:50:48 GMT
From: hpfcso!hpldola!hp-lsd!col![e-mail]  (Bdale Garbee)
Subject: TCP for CP/M???

>I've heard of the KA9Q TCP package written in C, and had heard it will
>run on PCDOS and similar machines, but recently I caught a mention
>that there was once a CP/M version of it... Is this still available?
>What was it written in?  Does anyone use it and have comments? email
>me, and I'll summarize. Tnx & 73s...

The original protocol development was done on Xerox 820's under CP/M (yes, it
has been a while!)... the code was written in Manx Aztec C for the Z80.  It
has not been touched for years, and I have no idea where you'd find a copy.
And even if you could, you wouldn't want it... it was a *very* rough initial
implementation.

Those who were at the ARRL CNC (5th?) in Orlando will remember my little
32016-based 4.2bsd box in the back of the room, slip'ing away to a pair of
820's...

73 - Bdale, N3EUA

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

Date: 13 Oct 89 19:31:29 GMT
From: hpfcso!hpldola!hp-lsd!col![e-mail]  (Bdale Garbee)
Subject: THE ADDRESS OF TAPR?

>Doeas anyone know the address (or fax number) of TAPR office ?

No FAX machine (yet)... here's the address:


TAPR
PO Box 12925
Tucson, AZ  85732
[phone]

73 - Bdale, TAPR Vice President

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

Date: 17 Oct 89 17:33:24 GMT
From: csibtfr!excelan!leadsv!esl!esl.ESL.COM![e-mail]  (Denis Lynch)
Subject: Using Tempo S-1 for Packet

I have a venerable Tempo S-1 (the one with the speaker/
mic connector) that I think would be happy being moved
into stationary operation as a dedicated packet radio.

Has anybody out there tried this? Is there anything I need to
know? The mic connection is a bit strange, do I need to do
anything besides put a capacitor between the TNC and the mic
input?

Thanks for your help, Denis Lynch, N2TI
[e-mail]

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

Date: 16 Oct 89 14:38:29 GMT
From: hpfcso!hpldola!hp-lsd!col![e-mail]  (Bdale Garbee)
Subject: VT100 emulation for KA9Q net code

>I've often thought
>about putting additional terminal emulation capabilities into the KA9Q
>package, but I can't figure out how to do so without greatly reducing the
>portability of the package. And, I'm sure that once I implemented one
>particular terminal type, I'd be deluged with requests to support every
>other one known to mankind...

And even more importantly, this is functionality that *belongs* outside of
NET!

Bdale

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

Date: 13 Oct 89 19:33:25 GMT
From: hpfcso!hpldola!hp-lsd!col![e-mail]  (Bdale Garbee)
Subject: VT100 emulation for KA9Q net code

>Is there an ANSI.SYS driver or something like that, or a code modification I
>could use to get net to work better with emulation?

Ed, if you load ANSI.SYS or any of the similar packages (NANSI, FANSI, etc)
from config.sys before running net, net will happily pass the escape sequences
through.  There are a couple of characters that are trapped to prevent chaos
on a raw Dos system, but I routinely run emacs over slip using the DoubleDOS
version of ansi.sys with no great difficulty.

Bdale

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

End of PACKET-RADIO Digest V89 Issue #216
*****************************************
20-Oct-89 15:12:07-MDT,10542;000000000000
Return-Path: <[e-mail]>
Date: Fri, 20 Oct 89 15:00:28 MDT
From: [e-mail]
Reply-To: [e-mail]
Subject: PACKET-RADIO Digest V89 #217
To: [e-mail]

PACKET-RADIO Digest         Fri, 20 Oct 89       Volume 89 : Issue 217

Today's Topics:
             Earthquake in SF!!!
        Net/Rom Protocol Spec. Wanted (3 msgs)
              TAPR 9600 Baud packetRADIO
             TCP/IP info packet?
              Using Tempo S-1 for Packet
----------------------------------------------------------------------

Date: 20 Oct 89 07:46:28 GMT
From: nsipo.arc.nasa.gov![e-mail]  (Milo S. Medin)
Subject: Earthquake in SF!!!

Actually, the Bay Area computer networks pretty much operated fine
during and after the Earthquake.  Both NSFNET backbone facility at Stanford
and the NSI facility at Ames Research Center didn't drop a bit.  Most
of the BARRNET system stayed up as well.  Including the T1 link
to UC Santa Cruz.  We were all quite surprised.

NASA would have not lost any networking if it wern't for a UPS failure later
in the evening.  Part of this is due to the increasing tendency to use
specialized routers and such for communications that have no rotating storage
and very few mechanical components.

While you couldn't dial anywhere via landlines immediately after the
quake, Email and general purpose IP network access was fine, and getting info
out via the Internet was easy.  Had we had an Amateur Radio message
traffic relay through the Internet working, we would have had extremely
high capacity messaging capability to the rest of the country.  Maybe next
time.

                        Thanks,
                           Milo

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

Date: 20 Oct 89 10:54:09 GMT
From: [e-mail]  (Brian Kantor)
Subject: Net/Rom Protocol Spec. Wanted

>> I'm waiting for the same thing before I get into packet radio for the
>> first time.  Throughput just isn't up to reasonable levels yet.  Keep on
>> working on it, guys, and I'll join you in a few years.

Go pound sand.  This is the kind of attitude that made America great?

No, it's the kind of non-productive attitude that made America what it is
today - the land that's second-rate in technical ability and first-rate
in lawsuits.  I think that people like this could best benefit the
public good by suicide.

Lead, follow, or get the hell out of the way.
    - Brian

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

Date: 20 Oct 89 17:42:49 GMT
From: shlump.nac.dec.com![e-mail]  (fred k1io)
Subject: Net/Rom Protocol Spec. Wanted

In article <[e-mail]>, [e-mail] (Brian Kantor) writes...
>>> I'm waiting for the same thing before I get into packet radio for the
>>> first time.  Throughput just isn't up to reasonable levels yet.  Keep on
>>> working on it, guys, and I'll join you in a few years.
>
>Go pound sand.  This is the kind of attitude that made America great?

Actually, I sympathize with the original author (Dan?).  If you actually
try to USE the packet networks in many areas, you'll quickly find that
quilting or worm-farming is more rewarding.

I stay moderately active, both here (playing protocol weenie) and on the
air (reading rbbss, etc.), but I could never get a true computer weenie
interested in packet radio if he saw what we now run.  Sure it's not
adequate to sit back and let George do it, but "mainstream" ham packet
is content to let the digipeaters and net/romms be "George".  It's swell
compared to '50s-style RTTY, but it's no comparison with modern wireline
hacker datacomms.

I take Dan's message as being a warning, not as a copout.
     fred

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

Date: 20 Oct 89 18:53:59 GMT
From: [e-mail]  (Dan Frank)
Subject: Net/Rom Protocol Spec. Wanted

In article <[e-mail]> [e-mail] (Bdale Garbee) writes:
>>> >By the way, please don't ask me for a copy.  I no longer have any
>>> >code on my drives, having given up packet radio until such time
>>> >as 1200 baud half-duplex is a distant memory.
>
>In general, I think this attitude STINKS.
>
>Why should I get excited about building a high-speed network, so that when
>throughput "is up to reasonable levels", you can just hop in and play for free?
>
>This is a fundamental stumbling block towards developing higher speed network
>facilities!  I'm going to keep working regardless, but I *need* your help to
>get enough critical mass of folks to build (and maintain!) a high-speed
>amateur data network.
>
>"We have the technology"... what we don't have is a large enough group of
>committed folks to make it really happen...

   I want to clarify my statement on this.  As Bdale mentioned, I have
some heavy demands on my time, between a new daughter and a new business
(I'm not sure which is worse!), but the main reason I am out of packet
is that it stopped being any fun.  I found myself babysitting not only
the local IP traffic but also the Wisconsin/Michigan NET/ROM network,
spending hours in trace mode every night watching TCP connections retry
again and again because the physical layer wasn't up to handling a
tenth of the traffic on the network.  I walked away from my computer
angry almost all the time.  It's only a hobby, and when it stops being
fun I'm going to stop doing it.

   Before I gave it up, I got together all the local "leading lights"
in packet (i.e. the TCP/IP users) and explained that I could no longer
fill in with software a network that needed new and better hardware.
I asked if people were willing to get some DSY modems and do some
experimenting, and maybe look at building a repeater or translator.
The answer every one of them gave was, "I am not willing to spend
$300 on a 56K modem when I can run packet with a $100 TNC."  I could
not find *one* person in this area willing to buy and build a DSY
modem so there would be a pair locally (I was going to build the
other, obviously).

   If and when someone around here decides that they want to do
something with the physical layer, and that they are willing to
invest more than a hundred bucks and ten minutes, I might get back
into packet.  I'm not saying, "I'll sit back and let folks build
the network for me."  I *am* saying, "I can't do it all alone.
Call me when *someone* is interested in building the network
*with* me."  Until then, I have a business and a family to build.

   73, Dan, W9NK

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

Date: Fri, 20 Oct 89 12:55:37 EDT
From: [e-mail]
Subject: TAPR 9600 Baud packetRADIO

First my apologies to hams that are not into packet for this posting. My
feed from "info-packet" has been irregular or nonexistent lately.

Can anyone with an "in" with TAPR (Phil // Brian?) give us the latest
scoop on the TAPR packetRADIO project? I realize that this is a topic
for presentation at the Colorado Conference, but I was hoping for some
advance info.

Rumor control has it that some of the units are now out in Beta test, and
while I filled out the little form volunteering for that effort, I never
received a reply. To get in a little plug... the whole state of North
Carolina is VERY interested in acting as a Beta Test site for that project
(and yes I am authorized to speak for the state :-)

I have seen the recent flyers from Kantronics advertising the 2 watt 9600
baud unit and also some blurbs from Paccom also hyping their product. The
big draw on the TAPR unit is its proposed turn-around time and its higher
power output of 25 watts. Does anyone have any idea whether these units
are going to be compatible with each other and to what degree?

While I realize that using a TNC as a switch is now considered to be a
rather primitive concept and that there are many better ways to go about
it (and some rather astounding products are "in the mill"), this TAPR
packetRADIO is EXACTLY what we are looking for in our stage of development
and I honestly feel that we represent the feelings of a lot of others that
are in the same situation.

Sooo... Any word on when this unit will be available, and at what cost, or
answers to any one of the other questions?

Thanks in advance.....

Mark Bitterlich
[e-mail]
wa3jpy@wb4uou

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

Date: 19 Oct 89 21:53:26 GMT
From: bunny![e-mail]  (Andrew Hudson)
Subject: TCP/IP info packet?

Some time ago a fellow by the name of Bdale posted
the availability of a number of RFC's on TCP/IP.
These were available on a PC floppy, I believe.
I was wondering if, after all this time, that
packet is still available. Any pointers
appreciated.

- Andrew Hudson
[e-mail]

--
"I remember, darkness doubled,
 I recall, lightning struck itself."

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

Date: 19 Oct 89 13:14:51 GMT
From: gem.mps.ohio-state.edu!wuarchive!texbell!merch!rwsys![e-mail]  (James Wyatt KA5VJL)
Subject: Using Tempo S-1 for Packet

In article <[e-mail]> [e-mail] (Denis Lynch) writes:
>I have a venerable Tempo S-1 (the one with the speaker/mic connector) that
>I think would be happy being moved into stationary operation as a dedicated
>packet radio.
>
>Has anybody out there tried this? Is there anything I need to know? The mic
>connection is a bit strange, do I need to do anything besides put a
>capacitor between the TNC and the mic input?

I have been wanting to do this as well, but where does one get the oddball
connector for the top of the thing and what is the pinout? I got it from
another ham who had it up in his attic. Also, can you feed power through
the top so I don't have to charge the batteries? It would be nice to use
it since my 2GAT is overkill for packet. One last one: Does anyone have
a copy of the manual they could send me? I would gladly pay postage!

Thanks - let's see if this message can make it out of my news setup 8{)

James T. Wyatt   KA5VJL - You woundn't WANT my opinions anyway.
 texbell.swbt.com!letni.lawnet.com!rwsys!{jim,root}     Work: 817-390-2864
{sys1.tandy.com!sneaky,merch.tandy.com}!/               Home: 214-579-0425

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

End of PACKET-RADIO Digest V89 Issue #217
*****************************************
22-Oct-89 20:23:14-MDT,10401;000000000000
Return-Path: <[e-mail]>
Date: Sun, 22 Oct 89 20:00:10 MDT
From: [e-mail]
Reply-To: [e-mail]
Subject: PACKET-RADIO Digest V89 #218
To: [e-mail]

PACKET-RADIO Digest         Sun, 22 Oct 89       Volume 89 : Issue 218

Today's Topics:
             More Net/Rom & ROSE comments
               TCP for CP/M???
               Tempo S1 connector pins
          Time for a new design for packet?
----------------------------------------------------------------------

Date: 19 Oct 89 18:08:37 GMT
From: att!tsdiag![e-mail]  (John Decatur KA2QHD)
Subject: More Net/Rom & ROSE comments

In article <[e-mail]>, [e-mail] (Phil Karn) writes:
>
> For perhaps the first time on this forum, I agree fully with Gordon Beattie.
>
> Phil

History in the making folks..... 8-)

de ka2qhd

--
US MAIL: John Decatur - CONCURRENT COMPUTER CORP.(Ex MASSCOMP,Interdata)
FAX: [phone]    2 Crescent Pl. Oceanport NJ 07757   PH 201-870-4093
UUCP: ucbvax!rutgers!petsd!tsdiag!johnd or [e-mail]  KA2QHD
IP: 44.64.0.40 ka2qhd.ampr.org PACKET RADIO: ka2qhd@nn2z TWX:710-7226502

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

Date: 20 Oct 89 18:20:31 GMT
From: gem.mps.ohio-state.edu!ctrsol!emory!stiatl!rsiatl![e-mail]  (John G. De Armond)
Subject: TCP for CP/M???

>>Well, dirt-cheap XT clones aren't portable.
>

I might suggest something else.  Take a look at the Ampro LittleBoards.
These little boards, which mount on the side of a disk drive, are self-
contained including serial ports and video adaptors.  They have a 286
version that will give you an AT in a box.

In other words, you can strip out the Z-80 cpu board, bolt in an Ampro
board, and have a modern system and use your existing periphials.  I have
built machines in this format and can say that it works fine.

I can understand your loyality to Z-80 machines.  I have a closet full of
them.  The problem is that the hardware has long since quit being the
driving factor.  Software development tools now drive hardware selection
decision.  I have looked at practically every C development system
available for Z-80's (native and cross), and have yet to find one that
comes anywhere near either Microsoft or Turbo C.  I would LOVE to find
a good C development environment for the Z-80.  I know the chip well, have
a nice hardware development environment and a lot of experience in both
hardware and software.  I find that I still have to limit myself to
Z-80 projects that I can do in assembler.

We have looked at porting portions of Phil's code to the Z-80 environment
for the purpose of putting a Telent client into a ROM for the TNC-2.  This
would allow keyboard users to take advantage of IP networks.  We've pretty
much decided that it just won't fit, given the quality of C compilers.

Why not spend a little money and get a system that supports modern tools.

John

--
John De Armond, WD4OQC                     | Manual? ... What manual ?!?
Radiation Systems, Inc.     Atlanta, GA    | This is Unix, My son, You
gatech!stiatl!rsiatl!jgd  **I am the NRA** | just GOTTA Know!!!

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

Date: Sun Oct 22 17:17:51 1989
From: [e-mail] (Douglas Quagliana)
Subject: Tempo S1 connector pins

TEMPO S1 SIX PIN CONNECTOR INFORMATION

   A long time ago, I used to have the manual and this is the original
source of this material. I have long since lost it (and am still looking
for a copy :) as well as any info on how to power the Tempo S1 with
any other power supply besides the batteries. Any info on the
batteries/alternative power supply or manual appreciated at this end!!

   I've been using my TEMPO S1 for over a year on PACKET.  Below is a
picture as best I can represent the TEMPO S1 top panel and the six
pin connector.  The earlier models did not have this six pin connector
(I have no idea of how to hook them up for PACKET, sorry). My model
also has an EAR jack on the left side above the PTT button, but I have
never used it though.  The male connectors for the six pin plug are
still available from HENRY RADIO.  I'm not sure on the price.
Get a small soldering iron for this connector!!!! They also
sell other accessories such as a convertor to go from the screw in
type jack for the rubber duckie to a PL-259 (or is it SO-239,
I'm not sure).  And a battery charger that goes to the cigarette
lighter of your car, etc.

   Parts are available from :
    Henry Radio
    2050 S. Bundy Dr.
    Los Angeles, CA 90025
    [phone]           TOLL FREE ORDER # [phone]

DISCLAIMER : I TAKE NO RESPONSIBILITY FOR ACCURACY OF THIS INFORMATION
         (the original source is an old Tempo S1 manual from HENRY)
         OR ANY DAMAGE THAT MIGHT HAPPEN AS A RESULT OF YOUR
         USE/MISUSE/INABILITY TO USE THIS INFORMATION. I AM
         *NOT* AN EMPLOYEE OF HENRY RADIO AND I HAVE NO CONNECTIONS
         WITH HENRY RADIO OTHER THAN THE FACT THAT I OWN A TEMPO S1!


----------------------------( cut here )---------------------------------

         TOP VIEW OF TEMPO S1

     3.5 mm ant jack -----|
                  |    /=\      <-------- Screw in for rubber
                  V   | O |               duckie
     ============================/    \====
     |                        ()   /--\    |
     |                       ANT  |    |   |   <-------- 6 pin connector
     |   FREQ. DIALS               \--/    |             (see below)
     |                                     |
     |                       0  =|= 5k     |    <------- 0/5k switch
     |                                     |
     |   VOLUME KNOB       SQUELCH KNOB    |
     |                                     |
     =======================================



BLOW UP OF SIX PIN CONNECTOR FOR TEMPO S1


                   ^
        BACK OF TEMPO S1---|

              XXXXX
<---             ---------------             X's represent approximate
           /                \            positions of notches on
T             /        (6)       \           connector.
O            /                    \
W           /                      \          Notches are CLOSER between
A          |  (5)             (1)   | X       3-4 and FARTHER between 1-3.
R          |                        | X       Fifth notch is above #6.
D          |                        | X
S          |                        | X
       X   |  (4)              (2)  |
F       X  \                        /
R        X  \                      /
E            \                    /
Q            X \        (3)       / X
           X ----------------- X
K               X X             X X
N
O
B               |-----TOWARDS SQUELCH KNOB
S               V     AND 5K SWITCH

<---


           PIN FUNCTIONS FOR TEMPO S1

           PIN#             FUNCTION
          ----------------------------------------------
            1                  PTT
            2                  SPEAKER AUDIO
            3                  GROUND
            4                  MIKE AUDIO
            5                  B+ FOR EXTERNAL MIKE
            6                  GROUND


   Hope this helps all those out there with Tempo S1's.  Feel free to
distribute this information as long as there are no changes made to
this document.
   Send any info, questions, additions, corrections, flames, etc. to :
[e-mail]

73's
--------------------------------------------------------------------------
| Doug Quagliana  KA2UPW  | Postal: POB 1882  |  Like a Micro Sat....    |
| DOMAIN : [e-mail]  | Saint Bonaventure |<* This Space For Rent! *>|
| Compu$erve: 70721,3374  | New York 14778    |                          |
--------------------------------------------------------------------------
.




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

Date: 20 Oct 89 16:43:01 GMT
From: eru!luth!sunic!mcsun!hp4nl!eutrc3![e-mail]  (Annard "Icon" Brouwer)
Subject: Time for a new design for packet?

Hello packeteers!

I can only agree with the question mentioned above, though I'm afraid that
in our country many people aren't interested in the functionality I (and
according to me others as well) are interested in. Remember that not
everybody has all these fancy machines with lots of memory and a big fat
harddisk :)), there still are people working with CPM and Commodore 64's etc.
But actually what I want is the Internet system at home, on my computer (in
my case a Macintosh) embedded in its functionality!
So in my case I want to go to the chooser, click on the packet icon and choose
(or type) the station I want to be connected with... Or even a fileserver
on my desktop. I think it can be done with TCP/IP, but then we should
transmit the data-frames directly on the air without the overhead of AX.25
and of course much higher baud-rates...
This is naturally not in accordance with the experimental character of our
hobby, but as long as it isn't there...
I also heard some people complaining about the "boring" character of an
implementation like this, but one can write occasional software to monitor
the network and make additions to your routing tables.
Well all this dreaming is very high-level of course and I would like to dig
in deeper, but I just started networking subjects for my studies so that will
have to wait a while :))
Please, any comments are welcome!!

Annard.

P.S. Phil, is it possible to use the MacTCP package in your internet package?


--
| Annard Brouwer                Bitnet (preferred) : rcgbbaab@heitue51
| Dreef 74                      UUCP               : [e-mail]
| NL-5504 LD  Veldhoven         packet-radio       : pe1koo@pi8mid
| The Netherlands               PSI (receive only) : psi%14901760604::rcgbbaab

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

End of PACKET-RADIO Digest V89 Issue #218
*****************************************
25-Oct-89 01:10:04-MDT,8445;000000000000
Return-Path: <[e-mail]>
Date: Wed, 25 Oct 89 01:00:33 MDT
From: [e-mail]
Reply-To: [e-mail]
Subject: PACKET-RADIO Digest V89 #219
To: [e-mail]

PACKET-RADIO Digest         Wed, 25 Oct 89       Volume 89 : Issue 219

Today's Topics:
      KA9Q 890421.1 XOBBS problem on Microport SysV/286
              need pbbs protocol
              Neophyte questions
            packet radio >1200 bps
  TAPR 9600 Baud packetRADIO & cellular radio power control (3 msgs)
                tnc2 mailbox?
----------------------------------------------------------------------

Date: 23 Oct 89 04:24:38 GMT
From: gem.mps.ohio-state.edu!lavaca.uh.edu!uhnix1!texbell!ark!lrark!argate![e-mail]  (Richard Duncan)
Subject: KA9Q 890421.1 XOBBS problem on Microport SysV/286

In article <[e-mail]>, [e-mail] (Bdale Garbee) writes:
> >This jives with mail I got from Dave Toth, who says that Microport's
> >message queues are broken. Rolfe Tessem, however, says that he has it
> >running on his Microport SysV/286 system, also at 2.4.
>
>
> Ain't "unsupported" unix in binary form fun?  :-)
>
> Bdale

Running into same problem with message queues under Xenix 286 system,
but same configurations on different boxes produces different results.
One system will run ONCE, but then have to reset and reload operating
system to get it to come up once exited.  Other will not function at
all.  Both develope problems in msgget calls within ax_mbx.c.

Anyway, now to figure out how to hook my bbs software into net...
:------------------------------------------------------------------:
: Richard Duncan  WD5B           Packet:  WD5B @ WD5B.AR.USA.NA    :
: Little Rock, AR                BBS:     501/568-6809 (2400/1200) :
: UUCP:    ...!bellcore!texbell!ark!lrark!argate!richard           :
:------------------------------------------------------------------:

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

Date: 22 Oct 89 23:38:59 GMT
From: gem.mps.ohio-state.edu!sunybcs!nsscb![e-mail]  (Andy Meyer)
Subject: need pbbs protocol

Greetings fellow experimenters!

I am in the process of writing a mailbox program so that I may send and
receive packet mail on an oddball computer I have at home.

Of course, I want to be able to have other systems poll my program for mail,
and vice-versa. Therefore, my system needs to look like any other pbbs.

Could someone either direct me to, or send me a document which describes the
interaction of 2 pbbses exchanging mail? (Or, does this even exist?)

Thanks,
Andy

    ==--      Andreas Meyer  N2FYE
  -====---    AT&T National Systems Support Center
  --==----    uucp: ..!rutgers!sunybcs!nsscb!ameyer
    ----      or: [e-mail]

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

Date: 25 Oct 89 02:27:23 GMT
From: [e-mail]  (Gary D Duzan)
Subject: Neophyte questions

   No, I'm not going to ask any really stupid questions. Instead, would
someone point me towards some source of data for up-to-date information on
computer communications via packet radio. I am especially interested in using
TCP/IP (yes, I have heard of KA9Q). Any help appreciated. Thanx.

                    Gary Duzan
                    Time  Lord
                    Third Regeneration




--
      _o_                                                            _o_
    [|o o|]        "Two hearts are better than one." -- Yes        [|o o|]
     |_O_|      "Don't listen to me; I never do." -- Doctor Who     |_O_|

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

Date: 24 Oct 89 21:04:40 GMT
From: oliveb!olivee![e-mail]  (Robert Swirsky)
Subject: packet radio >1200 bps

Hello.
I've been reading this newsgroup for a few weeks and have seen little
mention of the types of modulation used at speeds greater than 1200bps.

Is anyone using "standard" V.32 or PEP modems for 4800 or 9600 bps?
It would be nice to be able to use this equiplent because it is cheap and
readily available.

I'm not on packet yet & an wondering where the high speed activity is.
I've beed scanning the bands & hear lots of 1200 bps on 2 meters, and
a smattering of activity on 440 & *nothing* on 902-906. I don't
have any equipment to monitor 220. Is that where evryone is?


Robert A. Swirsky  AF2M
[e-mail]    olivetti!swirsky      oliveb!olivee!ubob!root

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

Date: 23 Oct 89 13:41:40 GMT
From: philmtl!philabs!briar.philips.com![e-mail]  (Robert Casey;6282;3.57;$0201)
Subject: TAPR 9600 Baud packetRADIO & cellular radio power control

While reading articles on cellular radio (the ones about how the cell site
controls the phone's output power) and the combination TNC and radio (if I
understood it right!), I had this idea:  Maybe the packetRADIOs can
automatically adjust each other's power to a level low enough to maintain
reliable communications and to avoid tying up the frequency in areas far away
from each radio in the QSO.  This could be done just after the connection is
made, the radios having measured each other's full power signal strength.  the
next transmissions could be a verification test, to see if the adjustments are
reasonable.  After that, then the real communicating could start.
  If all radios in the area and freq do this, maybe on average, more stations
  could use the channel.
Anyway, just an idea.
73 de WA2ISE

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

Date: 24 Oct 89 15:11:39 GMT
From: gem.mps.ohio-state.edu!ginosko!aplcen!stda.jhuapl.edu![e-mail]  (Marshall Jose)
Subject: TAPR 9600 Baud packetRADIO & cellular radio power control

In article <[e-mail]>
  [e-mail] (Robert Casey, WA2ISE) writes:
>                    ...I had this idea:  Maybe the packetRADIOs can
>automatically adjust each other's power to a level low enough to maintain
>reliable communications and to avoid tying up the frequency in areas far away
>from each radio in the QSO....

Robert,

That's an excellent idea, so hold that thought.  I think some means of
dynamically working out Po such that each side has a 10-15 dB SNR would
be wonderful.  You'll probably hear criticisms such as "Yes, but everybody
on frequency would have to be similarly equipped", or "SNR estimation
is difficult and would complicate the Layer 1 equipment".  Both are
probably true, but your idea still has just as much merit.  Perhaps
you could come up with a BER-to-SNR relation to use in such a scheme.
Marshall Jose  WA3VPZ
[e-mail]  ||  ...mimsy!aplcen!aplvax!mjj

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

Date: 25 Oct 89 03:48:52 GMT
From: tank!eecae!cps3xx![e-mail]  (Usenet file owner)
Subject: TAPR 9600 Baud packetRADIO & cellular radio power control

In article <66069@philabs> [e-mail] (Robert Casey) writes:
>understood it right!), I had this idea:  Maybe the packetRADIOs can
>automatically adjust each other's power to a level low enough to maintain
>reliable communications and to avoid tying up the frequency in areas far away
>from each radio in the QSO.  This could be done just after the connection is
>73 de WA2ISE

I think it's a fantastic idea.  Maybe it should be incorporated into the
"new" radios that will be coming out soon for 19.2 kbaud, 38.4 kbaud,
etc.  Of course, it's probably asking too much to ask most hams to
modify their existing equipment (unfortunately).

In the rare case that original ideas   Kenneth J. Hendrickson    N8DGN
are found here, I am responsible.      Owen W328, E. Lansing, MI 48825
Internet: [e-mail]   UUCP: ...!uunet!frith!hendrick

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

Date: 23 Oct 89 03:09:12 GMT
From: cs.utexas.edu!mailrus!jarvis.csri.toronto.edu!utgpu!watmath!ria!uwovax![e-mail]
Subject: tnc2 mailbox?

I hear alot about the mailbox feature being added to TNC2s with 32k ram.
Is the new software available somewhere for FTP?

de VE3PZR

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

End of PACKET-RADIO Digest V89 Issue #219
*****************************************
26-Oct-89 01:15:19-MDT,7240;000000000000
Return-Path: <[e-mail]>
Date: Thu, 26 Oct 89 01:01:16 MDT
From: [e-mail]
Reply-To: [e-mail]
Subject: PACKET-RADIO Digest V89 #220
To: [e-mail]

PACKET-RADIO Digest         Thu, 26 Oct 89       Volume 89 : Issue 220

Today's Topics:
               best packet box
            Net/Rom Protocol Spec. Wanted
            packet radio >1200 bps
  TAPR 9600 Baud packetRADIO & cellular radio power control (2 msgs)
----------------------------------------------------------------------

Date: 25 Oct 89 20:55:43 GMT
From: texbell!attctc!mjbtn![e-mail]  (Mark J. Bailey)
Subject: best packet box

Hello All,

I recently got myself a 2-meter mobile unit which I also intend to
bring indoors at night and want to run packet.

I was curious about what you thought was the BEST packet box (most
usable features), and the one you thought to be the BEST BUY (best $$$/
features).  I am familiar with the AEA PK-232 and Kantronics KAM,
but I would like to avoid overlooking other maybe lesser known gems.
Also, aside from most usable features, which one is the most packed
with features.

Your help would be greatly appreciated.

Thank you.

Mark.

--
Mark J. Bailey                                    "Ya'll com bak naw, ya hear!"
USMAIL: 511 Memorial Blvd., Murfreesboro, TN 37129 ___________________________
VOICE:  [phone]                            |         JobSoft
UUCP:   ...!{ames,mit-eddie}!attctc!mjbtn!mjb      | Design & Development Co.
DOMAIN: [e-mail]        CIS: 76314,160 |  Murfreesboro, TN  USA

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

Date: 24 Oct 89 18:31:28 GMT
From: eru!luth!sunic!mcsun!ukc!slxsys!qtnet!gewu2h![e-mail]  (Nick Lawes)
Subject: Net/Rom Protocol Spec. Wanted

From article <[e-mail]>, by [e-mail] (Dan Frank):
>
>    Before I gave it up, I got together all the local "leading lights"
> in packet (i.e. the TCP/IP users) and explained that I could no longer
> fill in with software a network that needed new and better hardware.
> I asked if people were willing to get some DSY modems and do some
> experimenting, and maybe look at building a repeater or translator.
> The answer every one of them gave was, "I am not willing to spend
> $300 on a 56K modem when I can run packet with a $100 TNC."  I could
> not find *one* person in this area willing to buy and build a DSY
> modem so there would be a pair locally (I was going to build the
> other, obviously).
>
>    If and when someone around here decides that they want to do
> something with the physical layer, and that they are willing to
> invest more than a hundred bucks and ten minutes, I might get back
> into packet.  I'm not saying, "I'll sit back and let folks build
> the network for me."  I *am* saying, "I can't do it all alone.
> Call me when *someone* is interested in building the network
> *with* me."  Until then, I have a business and a family to build.
>
>    73, Dan, W9NK

It's a shame that a hobby can get spoilt this way. I rapidly got fed up
with the congestion on the 'BBS channels' here and moved onto tcp/ip
which is pretty sparse in my area.

I thought that in the UK we were behind you guys in the packet area
and that all these high speed links were the norm. It would appear not.
There is a group of us here around London who are about to upgrade to at
least 9600 baud. The plan is to hit 56KB and higher in the near future,
and to place a high-speed backbone around London.

If you ever feel like moving to London, we'll help you out :-)

Seriously though, if you have had any thoughts for improvements that may
help build our network, I'd love to hear them. NET around here doesn't
look the same these days anyway.

    73s, Nick, G8ZHR
--
Nick Lawes, Systems Programmer, Quotron Technical Marketing |     Voice
Quotnet (UK) Ltd., 12 Norwich Street, London.  EC4a 1BP     | [phone]
uucp: ..!mcsun!ukc!idec!qtnet!nick | amprnet: 44.131.8.16   | bbs: g8zhr@gb3xp
--
Nick Lawes, Systems Programmer, Quotron Technical Marketing |     Voice
Quotnet (UK) Ltd., 12 Norwich Street, London.  EC4a 1BP     | [phone]
uucp: ..!mcsun!ukc!idec!qtnet!nick | amprnet: 44.131.8.16   | bbs: g8zhr@gb3xp

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

Date: 25 Oct 89 23:11:50 GMT
From: sol![e-mail]  (Phil R. Karn)
Subject: packet radio >1200 bps

The problem with almost every "standard" telephone modem is that
they're just not very suitable for radio operation. They're designed
for fullduplex telephone connections, where you have much more S/N
than bandwidth, and where you can spend 5 seconds to train and
equalize the path at the beginning of each "transmission". Packet
radio modems have to operate efficiently in burst mode (which tends
to rule out coherent demodulation, especially with large signal
constellations) and optimizing S/N performance is more important
than fitting into 3 KHz of spectrum (which also rules out the more
complex signal constellations that are quite popular in high speed
phone line modems.)

Phil

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

Date: 25 Oct 89 12:20:23 GMT
From: haven![e-mail]  (Louis A. Mamakos)
Subject: TAPR 9600 Baud packetRADIO & cellular radio power control

I don't think that this is a good idea.  If you lower your power, you will
increase the hidden-terminal problem.  The problem is that you really can't
compare amateur packet radio which has many stations concurrently using the
same channel in the same geographical area with cellular telephone where is
single station with is using the channel in a cell.  The whole point in
reducing the power of a cellular telephone's transmitter is to prevent
interference with adjacent cells and not with other stations within the
same cell.

I think the best approach is a full duplex repeater, which would reduce
the rate of collisions on the channel by eliminating the hidden terminal
problem.  Folks that put digipeaters up on huge towers with a very large
coverage area are just provoking the hidden terminal problem;  I suspect
that the community would be better served by a full duplex wide area
repeater or many more smaller coverage digipeaters.


louie WA3YMH

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

Date: 25 Oct 89 23:07:26 GMT
From: sol![e-mail]  (Phil R. Karn)
Subject: TAPR 9600 Baud packetRADIO & cellular radio power control

Automatic power control in packet radio is in fact an excellent
idea, one that has long been used by the DARPA packet radio project
(along with many other ideas that have largely been ignored by
hams).  Proper control of power, i.e., using only as much as is
really needed to reach your intended destination, can result in a
DRAMATIC increase in overall network throughput. There are proofs
and simulations which show this, but the result ought to be
intuitively obvious.

Phil

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

End of PACKET-RADIO Digest V89 Issue #220
*****************************************
27-Oct-89 01:13:18-MDT,10695;000000000000
Return-Path: <[e-mail]>
Date: Fri, 27 Oct 89 01:00:44 MDT
From: [e-mail]
Reply-To: [e-mail]
Subject: PACKET-RADIO Digest V89 #221
To: [e-mail]

PACKET-RADIO Digest         Fri, 27 Oct 89       Volume 89 : Issue 221

Today's Topics:
             Digicom64 cartridge
            Digital Symposium - 20-Jan-90
              Neophyte questions
    Re: TAPR 9600 Baud packetRADIO & cellular radio power control
  TAPR 9600 Baud packetRADIO & cellular radio power control (2 msgs)
         TheNet source...where can I get it?
         XOBBS problem in Microport and Xenix
----------------------------------------------------------------------

Date: 23 Oct 89 16:10:47 GMT
From: unisoft!hoptoad!peora!tsdiag!ka2qhd![e-mail]  (Barry)
Subject: Digicom64 cartridge

Now in the works is a cartridge version of Digicom64, the TNC emulator program
for the C64/128 (see my article in August '88, 73 Magazine for info).
The cartridge is autobooting and permits parameters to be stored to the
cartridge, eliminating the need for the disk drive, for those of you without
a drive.  This also makes it ideal for hilltop digipeating with a minimum of equipment.  Further info to follow as it becomes available. 73/Barry, W2UP
--
-------------------------------------------------------------------------------
Dr. Barry Kutner, W2UP  Yardly,Penn.     UUCP: rutgers!petsd!tsdiag!ka2qhd!w2up
-------------------------------------------------------------------------------

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

Date: 26 Oct 89 03:25:12 GMT
From: n8emr![e-mail]  (Gary Sanders)
Subject: Digital Symposium - 20-Jan-90

==============================================================
|               Relayed from packet radio via                |
| N8EMR's Ham BBS, 614-457-4227 (1200/2400/19.2 telebit,8N1) |
==============================================================


              CALL FOR PAPERS
       Fourth Annual Southwest Ohio Digital Symposium
              January 20, 1990

  Miami University - Middletown Campus - Middletown, Ohio

This is a preliminary announcement and call for papers for
the 4th Annual Southwest Ohio Digital Symposium.  At the
present time there is no set agenda nor time frame.
Preliminary ideas, generated from feedback from last year's
event include:

 1. A much-expanded session (probably a concurrent separate
    session) on how to get started in packet radio.  We were
    absolutely astounded at the interest in the beginner's
    aspects of packet, and were unprepared last year.

 2. Networking - the next steps.

 3. SYSOPS discussion group.

 4. MICROSAT and other topics of interest to AMSAT.

 5. Alternatives to TNCs for handling Node Functions.
    - G8BPQ Switch
    - TexNet Experience
    - ??? Next generation

 6. Super-fast Networking (ala-N3EUA's 1 mps @ 10 GHz)?

 7. New PBBS software?  (some surely will be available by
    January...)

 8. Duplex LANS????

 9. Experiences with the TAPR packetRADIO?

10. What's YOUR favorite subject?

The symposium is a cooperative effort hosted by the
Engineering Technology Department of Miami University, the
Middletown DIAL Twisters (Dial Radio Club), the Ohio Packet
Council, and the Cincinnati Buckeye Netters.

Please send ideas to  Hank Greeb, N8XX @ KC8TW,
              CIS 72277,706
              6580 Dry Ridge Road
              Cincinnati, OH 45252

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

Date: 26 Oct 89 19:20:59 GMT
From: hpl-opus!hpnmdla![e-mail]  (Glenn Elmore)
Subject: Neophyte questions

  Youmight consider the tcp-ip distribution list
[e-mail]
for such information.

Glenn Elmore
n6gn

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

Date: 26 Oct 89 23:05:49 GMT
From: hpl-opus!hpnmdla![e-mail]  (Glenn Elmore)
Subject: Re: TAPR 9600 Baud packetRADIO & cellular radio power control

   I think there is a fundamental issue here which is important.
The optimum power question is one of adequately getting information
to the other end while at the same time avoiding qrm/collisions
with other stations.

*Omnidirectional broadcast is the nemesis of these goals!*

  At the same time that it wastes power by sending it mostly in the
wrong directions it also qrms others (and removes their ability
to simultaneously use the resource). It does a poor job of getting
the transmit power, and the information, efficiently to the  destination
(inefficent use of hardware and spectrum resources).

  My opinion is that omni broadcast is a curse we won't soon escape
but we don't want to expend much of our spectrum resource on it. This
means we don't want to use it for high speed data. It also means
we don't want to use it over large geographical areas which have, or
potentially can have, a large number of users. Each additional CSMA
user effectively divides the resource up into smaller chunks for each
user. High level transmitters effectively deny the bulk of the resource
to users. As long as we don't increase the amount of spectrum wasted
in this manner, that is  as long as we don't use spectrum which could
have been used better, its not such an issue. 1200-9600 baud operation
at vhf probably can continue but let's not propagate this inefficient
use into areas which are our sole resource for doing things right and
efficiently.  Reducing power on an omni transmission helps but is
fundamentally a poor use of resources at best. To get high speed information
to a large number of users we *must* make efficient use of resources.

  We simply must go to point-point links to make optimum use of hardware
and spectrum. This means higher UHF and especially microwave.  It also
means we have to find routing protocols which efficiently get the
information to the destination without unnecessarily using network
resources.

  Not only do highly directional beams get more information rate per watt
to the user they also allow frequency re-use in a given geographical area.

73
Glenn "the higher the better" Elmore
N6GN

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

Date: 26 Oct 89 14:58:24 GMT
From: asuvax!stjhmc!f1.n234.z1.fidonet.org![e-mail]  (Jim Grubs)
Subject: TAPR 9600 Baud packetRADIO & cellular radio power control

 > From: [e-mail] (Marshall Jose)
 >
 > In article <[e-mail]>
 >   [e-mail] (Robert Casey, WA2ISE) writes:
 > >                    ...I had this idea:  Maybe the packetRADIOs can
 > >automatically adjust each other's power to a level low enough to maintain
 > >reliable communications and to avoid tying up the frequency in areas far
 > away
 > >from each radio in the QSO....
 >
 > Robert,
 >
 > That's an excellent idea, so hold that thought.  I think some means of
 > dynamically working out Po such that each side has a 10-15 dB SNR would
 > be wonderful.  You'll probably hear criticisms such as "Yes, but
 > everybody
 > on frequency would have to be similarly equipped", or "SNR estimation
 > is difficult and would complicate the Layer 1 equipment".  Both are
 > probably true, but your idea still has just as much merit.  Perhaps
 > you could come up with a BER-to-SNR relation to use in such a scheme.
 > Marshall Jose  WA3VPZ
 > [e-mail]  ||  ...mimsy!aplcen!aplvax!mjj

The "self-training" aspect proposed above is similar to the proposal in Don
Stoner's original PDRS petition to the FCC. At the time he had no idea how to
implement it.

73 de Jim Grubs, W8GRT


ow to
implement it.

73 de Jim Grubs, W8GRT

--
Uucp: ...{gatech,ames,rutgers}!ncar!noao!asuvax!stjhmc!234!1!Jim.Grubs
Internet: [e-mail]

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

Date: 26 Oct 89 21:47:30 GMT
From: att!cbnews![e-mail]  (Robert E. Stampfli)
Subject: TAPR 9600 Baud packetRADIO & cellular radio power control

In article <[e-mail]> [e-mail] (Phil R. Karn) writes:
>
>Automatic power control in packet radio is in fact an excellent
>idea, one that has long been used by the DARPA packet radio project
>(along with many other ideas that have largely been ignored by
>hams).  Proper control of power, i.e., using only as much as is
>really needed to reach your intended destination, can result in a
>DRAMATIC increase in overall network throughput. There are proofs
>and simulations which show this, but the result ought to be
>intuitively obvious.

Phil,
Although I agree that it appears "intuitively obvious", it would seem
to me that this would only exacerbate the hidden transmitter problem.
Why is this not a problem?

Rob Stampfli
att!cbnews!res (work)
osu-cis.cis.ohio-state.edu!n8emr!kd8wk!res (home)

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

Date: 26 Oct 89 18:54:00 GMT
From: m2c!jjmhome![e-mail]  (D. Pascoe KM3T)
Subject: TheNet source...where can I get it?

Does anyone out there know of a BBS carrying the source code for TheNet?  Or
does anyone have it on disk?  Please e-mail your replies if possible.

Thanks

--
        | Internet: [e-mail] or [e-mail]
Dave Pascoe | Smart Mailer: [e-mail]
  KM3T/1    | UUCP: {harvard}!cloud9!jjmhome!km3t
        | Packet Radio: km3t @ wb1dsw.nh.usa.na

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

Date: Thu, 26 Oct 89 9:41:59 PDT
From: Pete Carah <ghsvax!puffin![e-mail]>
Subject: XOBBS problem in Microport and Xenix

The problem with msgget in both XENIX (r) and Microport is much simpler
than most of us may think: the XO hook file appears to have been debugged
on a 32-bit machine (if it ever worked), and the author forgot to declare
ANY longs that are needed.  The msg key (first parameter) needs to be long,
and I remember a few other places (but not exactly where) where either
%l.. or (long) needed to be.  The other authors in "net" have generally
been careful of this.

I used:
long msgkey = *(long *)" BBS";
with msgkey, msgkey+1, msgkey+2, msgkey+3 for the keys for the 4 queues.

Also, I don't have W2XO's code, I used the hooks for an on-line database
to support a 100-mile running race (which worked pretty well on the event).

-- Pete (K6JRR)
[e-mail] (or {hacgate|ghsvax}!puffin!pete)

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

End of PACKET-RADIO Digest V89 Issue #221
*****************************************
27-Oct-89 05:18:42-MDT,7753;000000000000
Return-Path: <[e-mail]>
Date: Fri, 27 Oct 89 05:00:19 MDT
From: [e-mail]
Reply-To: [e-mail]
Subject: PACKET-RADIO Digest V89 #222
To: [e-mail]

PACKET-RADIO Digest         Fri, 27 Oct 89       Volume 89 : Issue 222

Today's Topics:
                KA9Q and Mail
            Net/Rom Protocol Spec. Wanted
    Re: TAPR 9600 Baud packetRADIO & cellular radio power control
      TAPR 9600 Baud packetRADIO & cellular radio power control
             TCP/IP info packet?
          Time for a new design for packet?
----------------------------------------------------------------------

Date: 25 Oct 89 08:17:38 GMT
From: hpfcso!hpldola!hp-lsd!col![e-mail]  (Bdale Garbee)
Subject: KA9Q and Mail

>Is the tcp/ip only designed for receiving, or is there a way for it to send
>mail to RLI style system for full bidirecitonal mail forwarding?

The mailbox stuff was a hack to make more folks happy about using the package,
since it allows interaction with AX.25 users more reasonably than not.

It does not provide a way to do outbound RLI-style forwarding.  You can do this
on a Unix system by running the W2XO PBBS code in tandem with NET, but that's
overkill if you're just looking to pass mail.

Bdale

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

Date: 25 Oct 89 08:14:17 GMT
From: hpfcso!hpldola!hp-lsd!col![e-mail]  (Bdale Garbee)
Subject: Net/Rom Protocol Spec. Wanted

>I'm not saying, "I'll sit back and let folks build
>the network for me."  I *am* saying, "I can't do it all alone.
>Call me when *someone* is interested in building the network
>*with* me."  Until then, I have a business and a family to build.

I understand the feeling.  This is an attitude I can live with, and it points
to a question that I don't think has been adequately addressed previously in
discussing our "dream network"...

Why do we want to build it?

Bdale

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

Date: 25 Oct 89 08:34:40 GMT
From: hpfcso!hpldola!hp-lsd!col![e-mail]  (Bdale Garbee)
Subject: Re: TAPR 9600 Baud packetRADIO & cellular radio power control

>Can anyone with an "in" with TAPR (Phil // Brian?) give us the latest
>scoop on the TAPR packetRADIO project?

I'll try.

>Rumor control has it that some of the units are now out in Beta test, and
>while I filled out the little form volunteering for that effort, I never
>received a reply.

No units are in beta test yet.  The design is still be bashed about by the
folks involved in the project.  Progress is being made, but the whole thing
has (as usual) taken longer than was hoped/expected.  I participated in an
effort to sort through the beta applications just after the conference here,
and my only comment is that there are a lot more applications than we intend
to have beta units for... noone has had a reply, because there's been nothing
to say.

I'd guess it'll be at least January before you hear anything positive or
negative.

>The big draw on the TAPR unit is its proposed turn-around time and its higher
>power output of 25 watts. Does anyone have any idea whether these units
>are going to be compatible with each other and to what degree?

The anticipation is that all of the direct-FSK units will be able to
interoperate.  This includes the original K9NG design still available in kit
form from TAPR, the G3RUH design licensed by Paccomm, the TPRS (Texnet) board's
9600 modem, and eventually the TAPR unit.  There are a bunch of things about
the TAPR unit (the output power, multiple frequencies, etc) that I think will
make the TAPR design attractive...

>Sooo... Any word on when this unit will be available, and at what cost, or
>answers to any one of the other questions?

There's not much more to be said right now.  Stay tuned, I'll try to provide
updates as information is available.

73 - Bdale, N3EUA, TAPR Vice President

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

Date: 27 Oct 89 02:39:26 GMT
From: cadre.dsl.pitt.edu!pitt!w2xo![e-mail]  (Jim Durham)
Subject: TAPR 9600 Baud packetRADIO & cellular radio power control

Louie, WA3YMH writes:
>
> I think the best approach is a full duplex repeater, which would reduce
> the rate of collisions on the channel by eliminating the hidden terminal
> problem.  Folks that put digipeaters up on huge towers with a very large
> coverage area are just provoking the hidden terminal problem;  I suspect
> that the community would be better served by a full duplex wide area
> repeater or many more smaller coverage digipeaters.

I say amen to this, brother. A system of local full-duplex repeaters
would inherently *double* the throughput, even without the gain in
collision avoidance because each packet appears only *once* on the
channel (input or output) instead of *twice* as it is sent and then
digipeated or net/rom'ed out again. The fact that everyone on the
repeater hears the same thing makes the collision avoidance algorithmns
work properly, as W3YMH pointed out, which is a further gain.

The sad part of all this is that , after just posting similar sentiments
to the tcpgroup, I got mail back from a fellow on the West Coast who
lamented that they had, in fact, had such a repeater going in that area
for a couple of years and *no* *one* *used* *it* ! Seems that it's a
great idea, but the average "plug and play" tnc user just doesn't
realize why it is a great idea, so they just continue to qrm the
input frequency by running simplex.

So, how does one get the message across? Repeaters would really be
the way to go, but just a few folks who didn't get with the program
would ruin it for the rest, probably without realizing it.

-73
Jim, W2XO    (w2xo![e-mail])  (W2XO @ W2XO)

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

Date: 25 Oct 89 08:28:17 GMT
From: hpfcso!hpldola!hp-lsd!col![e-mail]  (Bdale Garbee)
Subject: TCP/IP info packet?

>Some time ago a fellow by the name of Bdale posted
>the availability of a number of RFC's on TCP/IP.
>These were available on a PC floppy, I believe.
>I was wondering if, after all this time, that
>packet is still available. Any pointers
>appreciated.

Hi.  I'm still here, it's just only every week or two that I have a chance to
read and reply...

The package was a couple of disks available from TAPR, that Andy Freeborn
N0CCZ put together from stuff I gave him.  There are some recent things that
are interesting that aren't included, but for a fundamental understanding of
the TCP/IP protocol suite, and the pieces that are important to the base
functionality of Phil's NET package, it's still a good set of docs.

Here's contact info for TAPR:


TAPR
PO Box 12925
Tucson, AZ  85732
[phone]


73 - Bdale, N3EUA

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

Date: 25 Oct 89 08:20:56 GMT
From: hpfcso!hpldola!hp-lsd!col![e-mail]  (Bdale Garbee)
Subject: Time for a new design for packet?

>I think it's time for a new plan, based on computer-to-computer communication
>using radios designed from the  antenna down to do nothing but digial
>communication. I want to receive this newletter on my radio.

Go read the last few years worth of proceedings of the ARRL Digital Conferences
and you will find that this is not a new observation, and that in fact much
of what is happening now on the "bleeding edge" in packet radio is driven by
this realization.

Bdale, N3EUA

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

End of PACKET-RADIO Digest V89 Issue #222
*****************************************
28-Oct-89 09:13:45-MDT,8713;000000000000
Return-Path: <[e-mail]>
Date: Sat, 28 Oct 89 09:00:18 MDT
From: [e-mail]
Reply-To: [e-mail]
Subject: PACKET-RADIO Digest V89 #223
To: [e-mail]

PACKET-RADIO Digest         Sat, 28 Oct 89       Volume 89 : Issue 223

Today's Topics:
              KA9Q SW on unix - request
              KISS Protocol Info Request
              Neophyte questions
      TAPR 9600 Baud packetRADIO & cellular radio power control
 Why build the dream network? (was Re: Net/Rom Protocol Spec. Wanted)
----------------------------------------------------------------------

Date: 27 Oct 89 01:52:13 GMT
From: dtseng![e-mail]  (Robert P. Scott)
Subject: KA9Q SW on unix - request

Anyone out there with KA9Q's package running on a SYSV unix box willing
to e-mail me a copy?

How easy is/was it to use the package on a system which has other networking
packages (Interactive TCP/IP, NFS) already installed?

TNX
--
D T S  Engineering     |  Robert P. Scott
P. O. Box 277          |  ...!decvax!dtseng!rps -- ...!harvard!zinn!dtseng!rps
Hudson, NH  03051-0277 |
[phone]          |

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

Date: 27 Oct 89 11:37:00 CST
From: "christiansen" <[e-mail]>
Subject: KISS Protocol Info Request

Could some kind soul let me know where I might find a definition
of the KISS protocol, from the PC's point of view?  [I know that
I can browse through source code for existing programs, but I'm
leary about inferring ANYTHING about a protocol from ``code that
works'', without seeing it in a written spec!]

Thanks in advance.
--
Reed L. Christiansen  UW Polymerization Reaction Engineering Laboratory
[e-mail]  [phone]  N9GFG @ WD9ESU


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

Date: 27 Oct 89 17:24:11 GMT
From: [e-mail]  (Brian Kantor)
Subject: Neophyte questions

In article <[e-mail]> [e-mail] (Glenn Elmore) writes:
>
>  Youmight consider the tcp-ip distribution list
>[e-mail]
>for such information.
>
>Glenn Elmore
>n6gn

Please don't.  The tcp-group mailing list is for people who are actively
working on new developments in ham radio networking, particularly those
who are promoting the use of the TCP/IP suite of protocols.

It is NOT the place for user hand-holding.  Considering the small amount
of traffic and the large listening audience, it would seem to me that
this newsgroup (and it's associated Internet mailing list) is the best
place for such questions.
    - Brian

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

Date: 27 Oct 89 18:59:23 GMT
From: rochester!rit!cci632![e-mail]  (Just another hired gun (n2hkd))
Subject: TAPR 9600 Baud packetRADIO & cellular radio power control

In article <[e-mail]> [e-mail] (Kenneth J. Hendrickson) writes:
%In article <66069@philabs> [e-mail] (Robert Casey) writes:
%+understood it right!), I had this idea:  Maybe the packetRADIOs can
%+automatically adjust each other's power to a level low enough to maintain
%+reliable communications and to avoid tying up the frequency in areas far away
%+from each radio in the QSO.  This could be done just after the connection is
%+73 de WA2ISE
%
%I think it's a fantastic idea.  Maybe it should be incorporated into the
%"new" radios that will be coming out soon for 19.2 kbaud, 38.4 kbaud,
%etc.  Of course, it's probably asking too much to ask most hams to
%modify their existing equipment (unfortunately).
%
Beams, rotors and beams.Maybe beam headings should be part of the works.
Lat the software rotate the BEAM as well as adjust power. Why radiate
your QSO and create QRM in a direction that's not needed. If today's
software (packet) could handle the beam via a parrellel port (ie printer)
and a cheap rotor interface, the 01 qrm might be a lot less.
If somebody in buffalo is talking to Canada, I hear them in rochester,
this ties up the packet channel needlessly in the this area, or am
I missing something here. Just another HO.

--
I volunteered for the rights in America, and now I'm losing them, AAARGHH
email:   cb@cci632  or !rochester!kodak!n2hkd!curtis   Fight for your RIGHTS!
Curtis Braun, N2HKD, Computronics, PO Box 1002 Fairport NY, 14450

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

Date: 28 Oct 89 04:23:06 GMT
From: gem.mps.ohio-state.edu!wuarchive!texbell!splut![e-mail]  (Jay "you ignorant splut!" Maynard)
Subject: Why build the dream network? (was Re: Net/Rom Protocol Spec. Wanted)

In article <[e-mail]> [e-mail] (Bdale Garbee) writes:
>I understand the feeling.  This is an attitude I can live with, and it points
>to a question that I don't think has been adequately addressed previously in
>discussing our "dream network"...
>Why do we want to build it?

This strikes to the heart of everyone's differing expectations of ham
radio.

The techies want to build it because it's a neat hack.
The original packet implementations - slow and primitive as they were -
were still way ahead of their times: neat hacks. The TCP/IP stuff on ham
radio is a neat hack. 56 KBPS, and the upcoming megabaud efforts, are
neat hacks. To me, this has driven most of the packet development.

The congestion I see on 145.0x here is driven by a second group: the
ragchewers. They don't care if something is a neat hack. They want to
fire up their radio, and a couple of other pieces of gear, and yak. If
it isn't easy to use to the point of being transparent, they don't want
it.

The last group is the public service types. They want it to be reliable.
They don't want neat hacks until they've been beaten into submission and
bulletproofed.

The problem for the techies - who by far and away are the builders of
the network - is that they're grossly outnumbered. Dan's experience is a
perfect case in point: he's the only techie around there, and so nobody
else wanted to play with his neat hack.

No, I don't have much of a suggestion for improving the situation; that
delves deep into people's motivations, and any long-term reader of these
groups knows I'm not much at motivating people. :-)

--
Jay Maynard, EMT-P, K5ZC, PP-ASEL   | Never ascribe to malice that which can
[e-mail]       (eieio)| adequately be explained by stupidity.
{attctc,bellcore}!texbell!splut!jay +----------------------------------------
   Gandhi II: no more Mr. Passive Resistance...he's out to kick some butt!

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

Date: Thu, 26 Oct 89 21:50:10 EST
From: "Mich Tech Amateur Radio Club  W8YY" <[e-mail]>

WANTED!!! All Alumni of
Michigan Technological University Amateur Radio Club
W8YY  WA8CQR  AC8YY W9YX
Or Alumni of Mich Tech that are now Hams and Interested
in MTUARC.
Please send Name, Address, Call, and years at MTU. Other
Information is welcome. We hope to compile a list of all
past members of MTUARC for historic reasons.
MTUARC has been serving Mich Tech from 1932 to the present.
We are currently located on the 6th floor of Wadsworth Hall and
have about 20 members.

Send infomation to:
Michigan Tech Amateur Radio Club W8YY
West Wadsworth Hall
Houghton, MI 49931-1193

or via Packet:
N8JKQ @ WB8Q or W8YY @ WB8Q

or via Bitnet computer network:
[e-mail]

or via Phone:
James Wegner N8JKQ  [phone]


73's James Wegner N8JKQ
VP/Treasurer MTUARC

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

Date: Fri, 27 Oct 89 22:08:49 EST
From: "Mich Tech Amateur Radio Club  W8YY" <[e-mail]>

WANTED!!! All Alumni of
Michigan Technological University Amateur Radio Club
W8YY  WA8CQR  AC8YY W9YX
Or Alumni of Mich Tech that are now Hams and Interested
in MTUARC.
Please send Name, Address, Call, and years at MTU. Other
Information is welcome. We hope to compile a list of all
past members of MTUARC for historic reasons.
MTUARC has been serving Mich Tech from 1932 to the present.
We are currently located on the 6th floor of Wadsworth Hall and
have about 20 members.

Send infomation to:
Michigan Tech Amateur Radio Club W8YY
West Wadsworth Hall
Houghton, MI 49931-1193

or via Packet:
N8JKQ @ WB8Q or W8YY @ WB8Q

or via Bitnet computer network:
[e-mail]

or via Phone:
James Wegner N8JKQ  [phone]


73's James Wegner N8JKQ
VP/Treasurer MTUARC

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

End of PACKET-RADIO Digest V89 Issue #223
*****************************************
29-Oct-89 01:09:56-MDT,20956;000000000000
Return-Path: <[e-mail]>
Date: Sun, 29 Oct 89 01:00:14 MDT
From: [e-mail]
Reply-To: [e-mail]
Subject: PACKET-RADIO Digest V89 #224
To: [e-mail]

PACKET-RADIO Digest         Sun, 29 Oct 89       Volume 89 : Issue 224

Today's Topics:
             Gateway - 20-Oct-89
          New tcp/ip user in the Portland, Or. area
----------------------------------------------------------------------

Date: 29 Oct 89 02:30:50 GMT
From: n8emr![e-mail]  (Gary Sanders)
Subject: Gateway - 20-Oct-89

==============================================================
|               Relayed from packet radio via                |
| N8EMR's Ham BBS, 614-457-4227 (1200/2400/19.2 telebit,8N1) |
==============================================================


Gateway: The ARRL Packet Radio Newsletter - Volume 6 - Number 3
   The American Radio Relay League, 225 Main Street, Newington, CT 06111

 Edited by Stan Horzepa, WA1LOU   -    -   -   -   -  -   October 20, 1989

   LOWER-LAYER IMPROVEMENTS DOMINATE 8TH COMPUTER NETWORKING CONFERENCE

The ARRL Amateur Radio 8th Computer Networking Conference was held in
Colorado Springs, Colorado, on Saturday, October 7, with approximately 150
attendees.  In conjunction with the conference, the Rocky Mountain Packet
Radio Association (RMPRA) held a packetfest on Sunday.  The ARRL Digital
Committee met that same day.  If there was a theme to the conference it was
the need for improvements in the lower layers of the protocol stack.  New
or modified level 1 and 2 packet-radio protocols were discussed in several
papers, as were improvements to the radio systems in use.

A proposed broadcast protocol was presented by Gordon Beattie, N2DSY.  This
protocol is implemented in the BBC software package, which is part of the
Radio Amateur Telecommunications Society (RATS) ROSE system.  Improved
performance of the AX.25 link-layer protocol was proposed in papers by Lyle
Johnson, WA7GXD, Eric Gustafson, N7CL, and Detlef Schmidt, DK4EG.

On the radio front, the fast-approaching advent of high-speed packet-radio
hardware (see related story entitled "Awesome I/O Card in Beta Test")
brought forth much discussion of the need for coordinated network efforts,
culminating in a continental high- speed network.  To whet the appetites of
the packeteers present, Bdale Garbee, N3EUA, displayed the 10-GHz, 1-Mbit/s
packet-radio system developed with Glenn Elmore, N6GN.  HF wasn't neglected
either, as the HF packet-radio design quest announced in May, 1989 QST
begins to bear fruit (see related stories entitled "ARRL Digital Committee
Advances AX.25 V2.1, HF Project" and "Call for Participants in HF Diversity
Tests").

               AWESOME I/O CARD IN BETA TEST

At last year's Computer Networking Conference, Mike Chepponis, K3MC,
presented a design for the "Totally Awesome I/O card." (Mike lives in
California now... or couldn't you tell?) Since then, the Awesome I/O Card,
as it's known for short has been under development at Digital Radio
Systems, Inc (DRSI), in Clearwater, Florida.  DRSI founder Andy DeMartini,
KC2FF, brought copies of the "Product News Brief," dated October 7, to the
Conference.

The improved Awesome I/O Card consists of a NEC V40 CPU running at 8 MHz,
two 1-Mbit/s I/O ports with direct memory access (DMA), up to eight
19.2-kbit/s ports and as much as 512 kbytes of dynamic RAM and 128 kbytes
of EPROM.  The card plugs into an IBM PC/XT/AT or acts as a standalone
controller.

Software will include an EPROM version of TCP/IP.  Other packet-radio
networking providers are working on versions for the Awesome I/O card too.
For more information, contact DRSI at:

     DRSI
     2065 Range Rd
     Clearwater, FL 34625
     telephone [phone]

      ARRL DIGITAL COMMITTEE ADVANCES HF PROJECT, AX.25 V2.1

At its meeting on October 8, the ARRL Digital Committee discussed the
potential for vast improvement of HF packet radio.  They defined four
specific areas to improve: modem design, protocols, use of diversity
techniques, and network management.  Each of these areas will be addressed
with ARRL support as needed by issuance of grants to developers.  (See "The
Great 1989 HF Packet Design Quest" in May, 1989 QST.)

The proposed update of the AX.25 protocol to V2.1, reported in the October
21, 1988 issue of Gateway, was adopted by the Digital Committee.  The final
draft of the new protocol specification is being put together by Eric
Scace, K3NA, and Terry Fox, WB4JFI, and will be reviewed by the Committee
prior to publication.  The changes made to AX.25 should not affect
interoperability with existing V2.0 implementations.  The Committee would
like to thank all those who commented on the proposal for their
contributions to the final version.

        CALL FOR PARTICIPANTS IN HF DIVERSITY TESTS

One of the techniques that shows great promise for improved HF packet-radio
performance is diversity reception.  Used for years by military and
commercial stations, diversity is the technique of receiving the same
signal on two different antennas.  The antennas may be separated in space,
different in polarization or use different angles of arrival for the
received signal.  Steve Hall, WM6P, has been testing some of these
techniques and reported encouraging results at the 8th Computer Networking
Conference.  Steve has agreed to organize a group to work in this area to
find usable approaches for HF packet radio.  If you are interested in
assisting in this effort in any way, contact Steve via mail or packet radio
at:

     Steve Hall, WM6P @ N6BGW
     664 Bristol Av
     Simi Valley, CA 93065

(Special thanks to Jon Bloom, KE3Z, who provided the preceding reports from
the Conference.)

        CALL FOR PARTICIPANTS IN HF DIVERSITY TESTS

One of the techniques that shows great promise for improved HF packet-radio
performance is diversity reception.  Used for years by military and
commercial stations, diversity is the technique of receiving the same
signal on two different antennas.  The antennas may be separated in space,
different in polarization or use different angles of arrival for the
received signal.  Steve Hall, WM6P, has been testing some of these
techniques and reported encouraging results at the 8th Computer Networking
Conference.  Steve has agreed to organize a group to work in this area to
find usable approaches for HF packet radio.  If you are interested in
assisting in this effort in any way, contact Steve via mail or packet radio
at:

     Steve Hall, WM6P @ N6BGW
     664 Bristol Av
     Simi Valley, CA 93065

(Special thanks to Jon Bloom, KE3Z, who provided the preceding reports from
the Conference.)

               TCP/IP HF EXPERIMENT

Since last June, MITRE Corporation has been performing an ongoing set of
Near Vertical Incidence (NVI) HF sky-wave communication experiments to
determine the feasibility and utility of using the HF channel for TCP/IP
network operations.  These experiments were conducted using existing
packet-radio hardware and software, ie, off-the-shelf TNCs and radios and
no sophisticated HF modems.  The system software is the KA9Q Internet
Package.  The terminal hardware employed IBM AT computers, Kantronics KAM
TNCs and HF NVI antennas.

In addition to demonstrating the utility of the HF channel for TCP/IP
operation, a main objective of the experiment was to establish and assess
the performance of a pseudo-optimum set of NET and AX.25 parameters for HF
operation.  "Optimum" in this context means maximum throughput and channel
efficiency.  The results of this experiment would then be used to support
an analysis that predicts system (network) performance when more advanced
hardware and improved protocols are employed.  The experiment serves as a
convenient method for assessing HF network performance in a real world
channel and that may be used to support and validate simulation methods.

Approach to the Problem

To achieve the above goals, we first defined a worst case HF link scenario,
which happens to be an NVI link, ie, between 0 to 200 miles.  NVI links are
forced to utilize low frequencies because of the low MUF resulting from the
NVI geometry.  These links are plagued with severe multipath (more
pronounced at night) and high D-layer absorption during the day.  They also
suffer from high electrical storm burst noise in the summer.  The
philosophy here is "if it works on an NVI channel, it will work better on
long- haul channels."

Next, the fade and burst statistics of the channel were used to determine
the average usable baud rate and optimum packet length for a nonadaptive
system.  With a handle on the baud rate, optimum packet size and burst
error statistics of the channel, both network and link layer protocols may
be tailored for maximum efficiency.  A truly optimized system can only be
realized through simulation convergence with known network constraints.
However, there are some parameter adjustments that can be made to the
system that will put us in the ball park if a simple network architecture
is assumed.  For starters, Phil Karn, KA9Q, and Brian Lloyd, WB6RQN, have
shown in their paper "Link Level Protocols Revisited," that regardless of
link quality, maximum channel efficiency is realized when a stop-and-wait
ARQ protocol is used.  The current AX.25 TNC is easily configured for
stop-and-wait by simply setting the MAXFRAME parameter to 1.

In our experiment, the system was operated in unconnected or datagram mode.
This provided us with a measure of link performance in terms of network
layer parameter settings.  Also, by using the datagram mode, we were able
to avoid time-outs and disconnects resulting from AX.25 send queue
bottleneck, sometimes encountered when interfacing with high speed network
hosts.  We were also able to achieve greater throughput on good quality
links.  The stop-and-wait ARQ in this case was implemented at the network
level by simply setting the TCP WINDOW parameter to MSS (ie, a window size
of 1).

In their paper, Karn and Lloyd also advocate the use of a connectionless
ACK-ACK link level protocol to improve the efficiency of noisy channels
like HF.  Our analysis fully supports their conclusions.  However, the
ACK-ACK protocol is not easily implemented with the present hardware and
software and would not provide much more information on the network
performance potential than what could be derived analytically.  Therefore,
we did not attempt to implement the ACK-ACK protocol in this experiment.
It is, however, a worthy topic for further study.

The appropriate packet size for the NVI links may be estimated from the
link burst error statistics resulting from multipath effects.  My analysis
indicates that there is a high probability that selective fades will "hit"
packets at 12-second intervals on the average.  Keeping the packet length
about half of the hit interval significantly increases the probability of
successful delivery on a single try.  Thus, our reason for selecting a 228-
byte (6.08 second) duration packet for the experiment.

            TCP/IP HF EXPERIMENT - (Continued)

System Parameters

The following is a summary of the pseudo-optimum NET parameters derived
from the analysis and used in the HF experiment.

 Average Usable Baud Rate = 300 baud binary FSK 200 Hz shift
     (set by estimated multipath)
 Optimum Packet Size = 228 bytes (duration 6.08 seconds)
 MTU = 196 bytes
 MSS = 156 bytes
 WINDOW = 156 bytes (window size of one)
 AVERAGE RTT = 9 seconds (measured)
 AX.25 MAXFRAME = 1
 AX.25 TXD = 50 ms
 AX.25 P-PERSIST = (1-persistent)
 AX.25 SLOT TIME = 0

Expected Performance

The above parameters result in the following performance estimates for an
NVI HF link operating at 3.6 MHz with an NVI ERP of +26 dBW (ie, 100 watts
to a dipole mounted about 1/8 wavelength above average conducting ground).

 Average Received S/N = 65 db Hz => 38 dB SNR in 500-Hz data
  filter (mid-day, noise = QMN + 10 dB) Note: QMN = Quasi-Minimum
  Noise (see NELC Report 1712, 2 June 1970) (derived from IONCAP
  analysis)
 Probability of Packet Delivery
 For 1 try = .41
 For 2 tries = .74
 For 3 tries = .87
 Average link reliability = 70% (based on PING efficiency)
  (during usable periods)
 Max Possible Throughput = 17 bytes/sec/link (ideal channel,
  i.e., no fades, burst errors or contention)
 Average expected throughput = 4 to 6 bytes/sec

Measured Performance

Data was taken on an NVI link between Bedford and Norfolk, Massachusetts
(40 miles) several times daily over a total of 120 days.  The average
throughput under typical conditions was measured at 5 bytes/second peaking
to 9 bytes/sec under the best of conditions.  The corresponding link
reliability (the PING efficiency) ranged from 55 to 95%.  The average S/N
was 63 dB Hz (not counting electrical storms).  The measured performance is
in very close agreement with the above predictions, thus giving credence to
the analysis.

The lowest S/N never dropped below 53 dB Hz (27 dB SNR) (not counting
electrical storms).  SNR is not generally an issue for NVI links except for
periods of high D-layer absorption resulting from major solar flares, the
major culprit is multipath.  Increasing transmitter power won't help.  In
fact, it could exacerbate the situation.

Areas Requiring Further Work

There are three areas in need of enhancement and, if implemented, would
significantly improve HF link reliability and throughput.

The first is the link level protocol.  It appears that a significant
improvement in channel efficiency is realized through the use of an ACK-ACK
link layer protocol.  At the top of my "wish list" is to see a KISS mode
compatible link-level driver module written for the KA9Q package that would
provide an ACK-ACK protocol capability while maintaining backwards
compatibility with the existing AX.25 level 2 protocol.  An experiment
similar to this then could be set up that would assess improvements in a
real world environment.

The second concerns the network layer back-off algorithms.  The performance
data indicates a need for a "back-off" algorithm that is more suitably
tailored for the HF channel statistics and one which is capable of
differentiating between congestion and HF channel related burst errors.
This is not an easy task.  This algorithm needs to be more aggressive when
adapting to HF channel related noise and in such a way that it would not
compromise congestion control.

The third and, perhaps, the most effective enhancement would be the use of
a more robust modem.  The advanced modem would incorporate 8-level PSK
modulation, Forward Error Correction (FEC) and variable depth interleaving.
Such a modem would be capable of providing up to 2400-baud operation over
a typical 3-kHz HF radio channel.  Such modems do exist, however, they are
far too complex and expensive to be considered for Amateur Radio use at
this time.  Perhaps the DSP modem technology currently being explored by
other amateur packet-radio enthusiasts is the key to an affordable and
timely modem solution for the HF packet-radio community.

            TCP/IP HF EXPERIMENT - (Continued)

Near Term Utility of HF for TCP/IP

At a recent New England TCPers meeting, interest was expressed in using HF
radio for long-haul SMTP type TCP/IP traffic.  Now that the sun spot cycle
is on the climb, more and more long-haul interference-fee channels having
fade statistics that "may" be able to support up to 1200 bauds with
conventional binary FSK modems are becoming available.  These links remain
viable for a significant part of the day.  Although they experience slow
fades, the deep fade duration is relatively short-lived compared to life
time.  The long-haul links are also less prone to multipath contamination
than are the NVI links used in this experiment.  However, they are much
more vulnerable to the hidden terminal syndrome.  Whether or not 1200s baud
is supportable by these links is primarily governed by average round trip
time, which, in turn, affected the T/R delays of typical HF radios in the
path.  These delays are generally twice as long as those of VHF systems.
Furthermore, the HF modems contained in some of the existing TNCs, such as
the Kantronics KAM or AEA PK-232, have excellent predetection filtering
that is much better suited for HF channel operation than those common to
the standard 1200-baud port.  The equalization for a typical VHF radio is
significantly different than that required for HF.  Unlike the NVI links,
the long-haul multi-hop link budgets are such that they require a matched
filter to maximize the SNR.  For these reasons, I feel it is best to stay
with 300 bauds on HF.

The concept of a system that optimally exploits the long-haul path
characteristics for slow TCP/IP traffic handling is intriguing.  I feel
that with a judicious frequency management plan and the use of NET/ROM for
path diversity, it is possible to maintain network connectivity on a 24
hour/day basis.  A very interesting and productive experiment would be to
establish a 5-node HF TCP/IP NET/ROM network that would span the country
including nodes in Alaska and Hawaii.

If anyone has any ideas on this, please respond to the author, bob@w1imm-2
via rich@wa1equ.  Perhaps, we can form an HF working group of sorts.

by Bob Levreault, W1IMM from The New England TCPer


    MICROSATS PASS ENVIRONMENTAL TESTING; MUST WAIT FOR LAUNCH

All four of the AMSAT MicroSats (PACSAT, LUSAT, DOVE and WEBERSAT)
completed the necessary environmental tests, that is, thermal vacuum and
vibration tests, with flying colors.  This means the MicroSats are now
certified to fly aboard the Ariane IV launch vehicle.

Official word received from Intelsat and Arianespace representatives
indicates that the launch may be delayed at least four weeks from the
original date of November 10 to correct problems with the Ariane IV space
vehicle.  The AMSAT launch team will use this time to perform additional
system level and software testing on the satellites.

     from The ARRL Letter

               GATEWAY CONTRIBUTIONS

Submissions for publication in Gateway are welcome.  You may submit
material via the US mail to:

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

or electronically, via CompuServe to user ID 70645,247 or via Internet to
[e-mail].  Via telephone, your editor can be reached on
evenings and weekends at 203-879-1348 and he can switch a modem on line to
receive text at 300, 1200 or 2400 bit/s.  (Personal messages may be sent to
your Gateway editor via packet radio to: WA1LOU @ W1AW.)

The deadline for each issue of Gateway is the Saturday preceding the issue
date (which is typically a Friday).

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

Date: 27 Oct 89 21:14:53 GMT
From: guille![e-mail]  (Johan K. Reinalda)
Subject: New tcp/ip user in the Portland, Or. area

I have been playing around with the ax.25 stuff for a while now, and
would like to get into some more advanced stuff. I ftp'ed Phill Karn's
TCP/IP package from, I think loui.udel.edu, and looked at that. It is
a very nice package, and i have some questions about running tcp/ip on
top of a tnc.  First of all, I am located in a small college town
south of Portland, Oregon.  I have posted some messages on the local
packet bbs's asking about any other stations running tcp/ip, but to no
reply.  It would not be of any use to me to run it, if there aren't
any other paople running it, or at least if there is a gateway that i
could digipeat to, I think.  Does anybody in the Portland Oregon area
know of any tcp/ip activity and is there any coordination of IP
addresses ?

Second, I wonder if the version of tcp/ip i have is the most recent;
what is the best place to look for a recent version ? (ftp site; or
TAPR, tucson maybe ?).

Thanks a lot,
---
Johan "Big Jo" Reinalda,                          Internet :
'Grad' Electrical Engineering                       [e-mail]
Oregon State University                             [e-mail]
Corvallis, Or (USA)                               Amateur Packet Radio :
USPS: 420 NW 9                                      WG7J @ KA7VQD
      Corvallis, Or 97330                         AT&T:[phone]

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

End of PACKET-RADIO Digest V89 Issue #224
*****************************************