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

Text File | 1993-12-31 | 170.2 KB | 3,909 lines

1-Jun-89 02:50:31-MDT,2834;000000000000
Return-Path: <[e-mail]>
Date: Thu,  1 Jun 89 01:30:22 MDT
From: [e-mail]
Reply-To: [e-mail]
Subject: PACKET-RADIO Digest V89 #150
To: [e-mail]

PACKET-RADIO Digest         Thu,  1 Jun 89       Volume 89 : Issue 150

Today's Topics:
             A plea (Yea, what he said!)
            Wanted: PD PC Packet software
----------------------------------------------------------------------

Date: 30 May 89 17:53:32 GMT
From: tektronix!tekcrl!tekgvs![e-mail]  (Jan Steinman)
Subject: A plea (Yea, what he said!)

<<<[e-mail]>>>
<<[e-mail] (Phil Karn)>>
<[e-mail] (Jay "you ignorant splut!" Maynard)>

<As a matter of personal principle, I avoid all AT&T-based UNIX systems.  All
of the UNIX systems I use run Berkeley or Berkeley-derived code (e.g., SunOS,
Ultrix).>

<<Please confine your BSD bigotry to one source file, so that those of us who
have to make your code work in the real world won't have to rewrite the entire
package.>>

<Mr. Jay Maynard, please give me a break.  Try to figure out how to send  email
directly, it really isn't all that hard. >

Wow, I'm impressed, Mark!  You must be the last person in the world to not have
Jay in his kill file!

(enter soap-box mode)

Jay, don't try to do foolish things like port code to SysV that is admittedly,
unabashedly, purposfully Berkeleyoid, or at least stop ranting and raving about
something that is free.  You don't "have to make (Phil Karn's) code work in the
real world".  (Oh, sorry.  I didn't notice that gun pointed at your head.)  I
don't see wonderful System-Visms from your keyboard being donated for the
benefit of the community, so why don't you just shut up, you ignorant splut!

(end soap-box mode)

:::::: Jan Steinman - N7JDB                Electronic Systems Laboratory ::::::
:::::: [e-mail]       Box 500, MS 50-370 (w)503/627-5881 ::::::
:::::: [e-mail]     Beaverton, OR 97077 (h)503/657-7703 ::::::

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

Date: 30 May 89 16:54:36 GMT
From: bunny![e-mail]  (Andrew Hudson)
Subject: Wanted: PD PC Packet software

I would be greatful if anyone could provide me with a public
domain packet control software package. The equipment
is a Tandy 1000 PC compatible w/hard disk, a MFJ TNC, and a Yaesu FT-209
2M rig. I need this to bootstrap several packet stations in development.

I would also consider reasonably priced software to do the same thing.

- Andrew Hudson, KA2KHD
[e-mail]

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

End of PACKET-RADIO Digest V89 Issue #150
*****************************************
 2-Jun-89 02:41:58-MDT,2494;000000000000
Return-Path: <[e-mail]>
Date: Fri,  2 Jun 89 01:30:30 MDT
From: [e-mail]
Reply-To: [e-mail]
Subject: PACKET-RADIO Digest V89 #151
To: [e-mail]

PACKET-RADIO Digest         Fri,  2 Jun 89       Volume 89 : Issue 151

Today's Topics:
              A problem with Net
        looking for serial driver on Minix-ST
----------------------------------------------------------------------

Date: Thu, 01 Jun 89 07:30:27 EDT
From: Joseph Skoler <[e-mail]>
Subject: A problem with Net

A question to the net:

I have been experiencing the following problem:
On an AT clone (with a cheapo serial card) and an
MFJ-1278, while running NET (Latest version) under
Desqview, the program sometimes hangs.

By hangs I mean that control is still had over the
program - I can still issue commands to it - but
it doesn't seem to have connection to the computer.
For example, when I know there is activity on the freq.
the con and dcd lights go on but NET doesn't recognize
or interpret any signals.

At other times, I lose control over the program.  This
happens when multitasking with BM and Net.  I think 640K
should be enough to run both?

It seems to me two separate problems are at work here,
does anyone have any suggestions?

Thanks in advance,
Joe,
skohc@cunyvm
kc2yu @ kd6th
44.68.0.56

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

Date: 31 May 89 16:37:14 GMT
From: mcvax!unido!iraun1!iravcl![e-mail]
Subject: looking for serial driver on Minix-ST

Hi there netlanders !

I've got a little problem and hope for solution by news-readers...
I am running MINIX-ST 1.1 and like to include second terminal driver soft-
ware.

  Has anybody out there written a driver for serial i/o ?

  Is there any protocol (maybe tcp/ip) available for Minix-devices ?

  Did anybody already set up an AX.25 protocol for the packet radio
  communications ?

please respond to news - i'm not allowed to receive E-mail coming

over the normal nets (i hate those local policies...).

Another way for answering is postal mailing to the following address:

Fred Baumgarten
Kandelstrasse 27
D-7513 Stutensee-Buechig

Federal Republic of Germany

Thanks in advance, Fred

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

End of PACKET-RADIO Digest V89 Issue #151
*****************************************
 3-Jun-89 02:42:57-MDT,5287;000000000000
Return-Path: <[e-mail]>
Date: Sat,  3 Jun 89 01:31:19 MDT
From: [e-mail]
Reply-To: [e-mail]
Subject: PACKET-RADIO Digest V89 #152
To: [e-mail]

PACKET-RADIO Digest         Sat,  3 Jun 89       Volume 89 : Issue 152

Today's Topics:
         A plea (Yea, what he said!) (2 msgs)
             NET routing via SLIP
----------------------------------------------------------------------

Date: 1 Jun 89 17:30:19 GMT
From: emory!stiatl![e-mail]  (John DeArmond)
Subject: A plea (Yea, what he said!)

In article <[e-mail]> [e-mail] (Jay "you ignorant splut!" Maynard) writes:
>
>My tone may have been more inflammatory than necessary, but there's a

Generally when you call someone a bigot, it is taken as inflammatory.

>No, there's no gun pointed at my head, but, unless I do something about
>it, I have to assume that the NOS code - on which future enhancements to
>the KA9Q suite will be based - will leave me behind. I still want to be
>part of the packet revolution, and I see TCP/IP as the way to go, yet
>Phil's comments seemed to say that he was going to exclude me and anyone
>else running System V "as a matter of principle". He may have another
>option. I don't, short of spending $10000 or going back from Unix to
>MS-DOS.
>

Jay, perhaps you should consider the possibility that the "matter of principle"
Phil talks about would involve the fact that he works for AT&T and maybe
would want to avoid any problems regarding proprietary information?

Actually, I've disagreed with several things that have been done in net.  Some
of them have been debated on the mailing list, some via email and a bunch
more I simply keep quiet on, realizing that I'm gaining the benefit of
the free work of a lot of people.  After I realize this fact, I save my
criticism for those that deserve it.  After all, you really do have a
choice.  You can either use what you get or you can change it to fit your
needs or you can decide it does not fit your needs and simply ignore it.




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

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

Date: 1 Jun 89 12:25:13 GMT
From: texbell!splut![e-mail]  (Jay "you ignorant splut!" Maynard)
Subject: A plea (Yea, what he said!)

In article <[e-mail]> [e-mail] (Jan Steinman) writes:
>Jay, don't try to do foolish things like port code to SysV that is admittedly,
>unabashedly, purposfully Berkeleyoid, or at least stop ranting and raving about
>something that is free.  You don't "have to make (Phil Karn's) code work in the
>real world".  (Oh, sorry.  I didn't notice that gun pointed at your head.)  I
>don't see wonderful System-Visms from your keyboard being donated for the
>benefit of the community, so why don't you just shut up, you ignorant splut!

You must have missed the pty driver for System V/AT, then.

My tone may have been more inflammatory than necessary, but there's a
kernel (no put intended) of real request in there: if the code is going
to be BSD-ized, at least make the job of adaptation easier for those of
us who are going to be attempting it.

No, there's no gun pointed at my head, but, unless I do something about
it, I have to assume that the NOS code - on which future enhancements to
the KA9Q suite will be based - will leave me behind. I still want to be
part of the packet revolution, and I see TCP/IP as the way to go, yet
Phil's comments seemed to say that he was going to exclude me and anyone
else running System V "as a matter of principle". He may have another
option. I don't, short of spending $10000 or going back from Unix to
MS-DOS.

--
Jay Maynard, EMT-P, K5ZC, PP-ASEL   | Never ascribe to malice that which can
uucp:        uunet!nuchat!   (eieio)| adequately be explained by stupidity.
{killer,bellcore}!texbell!splut!jay +----------------------------------------
internet: [e-mail]    | "Less great!" "Tastes filling!"

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

Date: 31 May 89 13:50:36 GMT
From: ginosko!infinet!ulowell!tegra![e-mail]  (Johnathan Vail)
Subject: NET routing via SLIP

Is there any kind of NFS for the KA9Q SLIP?

I want to dedicate a machine to TCP/IP and it is not the machine I
normally use or want to use.  I would like some way to easily connect
the two.  Ideally ethernet but I can't justify the cost.

I have heard of a DOS device driver that will connect 2 PCs with
serial ports and mount the other's hard disks.  This "poor man's NFS"
may be what I want.

Any ideas or comments?

"Gravity pulls the trousers down
     Morality pulls the trousers up" -- Bedful of Metaphysicians
 _____
|     | Johnathan Vail | tegra![e-mail]
|Tegra| [phone] | N1DXG@145.110-,145.270-,444.2+,448.625-
 -----

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

End of PACKET-RADIO Digest V89 Issue #152
*****************************************
 3-Jun-89 23:38:26-MDT,14913;000000000000
Mail-From: KPETERSEN created at  3-Jun-89 23:10:41
Return-Path: <[e-mail]>
Date: Sat,  3 Jun 89 23:10:41 MDT
From: [e-mail]
Reply-To: [e-mail]
Subject: PACKET-RADIO Digest V89 #153
To: [e-mail]

PACKET-RADIO Digest         Sat,  3 Jun 89       Volume 89 : Issue 153

Today's Topics:
              Gateway 26-May-89
----------------------------------------------------------------------

Date: 3 Jun 89 14:18:37 GMT
From: n8emr![e-mail]  (Gary Sanders)
Subject: Gateway 26-May-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                         P 1 of 3

Stan Horzepa, WA1LOU, Editor - Volume 5, Number 18 - May 26, 1989

          MID-ATLANTIC SIX-METER BACKBONE ASSEMBLY BEGUN

During an informal meeting among the SYSOPs and node operators of Maryland,
New Jersey, Northern Virginia, Pennsylvania and the District of Columbia in
February 1989, a 6-meter frequency was selected for an experimental
backbone (a packet-radio network that transfers mail automatically with
access limited to PBBSs - Ed).  Subsequently, a number of RCA 100-watt
solid-state transceivers were obtained for $50 each and the hardware is now
being assembled to extend a backbone from Virginia through Maryland to New
Jersey. It is expected that few personal packet-radio stations will operate
on 6 meters because of the potential of TVI to channel 2, however, TVI
should not be a problem for the backbone because the nodes are located in
remote areas far from residential television receivers.

The backbone group is interested in learning about other 6-meter backbone
activity and experiences.  The group believes that 6 meters is perfect for
this application as they are trying to move all packet-radio activity
except for local user access off 2 meters.  Initially, the backbone will
operate at 1200 bauds while propagation data is gathered.  Hopefully, it
will operate at a higher speed in the future.  If you operate or plan to
operate 6-meter packet radio, please drop the group a note so they can be
better prepared for skip openings when the occur.

from Bob Bruninga, WB4APR @ W3IWI

               MICROSAT BAND PLAN EXPLAINED

It has come to the attention of AMSAT-NA officials that there is a small,
but vocal minority of radio amateurs who have questioned the MicroSat/
PACSAT and LUSAT frequency band plans.  As announced in articles in
AMSAT-NA Journal and 73 Magazine, the uplink frequencies for MicroSat will
be 145.900, 145.920, 145.940 and 145.960 MHz; for LUSAT, 145.840, 145.860,
145.880 and 145.900 MHz. The downlink frequencies for MicroSat and LUSAT
will be 437.050 and 437.150 MHz, respectively.  AMSAT-NA officials wish to
briefly explain the logic for choosing these frequencies for the
"store-and-forward" satellites.

MicroSat/LUSAT uplink frequencies are located within the portion of the
2-meter spectrum designated for "Amateur Satellite Service," which includes
145.800 to 146.000 MHz and 435.000 to 438.000 MHz.  Currently, these
frequencies are used by amateur satellites AO-10, AO-13, FO-12, UO-9, UO-11
and, to a limited degree, RS10/11, however, in many parts of the world,
145.800 to 146.000 MHz is heavily populated and virtually unprotected.  For
example, many amateurs point to the "chaotic" conditions which exist on 2
meters in Japan.  When the JARL and JAMSAT were designing FO-12, heavy
interference problems were considered very carefully.  When the designers
of the MicroSats considered the QRM problem, they also came to the
conclusion that Mode JD was the way to go.  From an equipment standpoint,
using Mode JD will permit many OSCAR-satellite users to use the same
equipment they have available for Mode B operations.  On the uplink,
packets can be sent with a few watts from a 2-meter FM transceiver.  Since
most amateurs own 2-meter FM transceivers and an HF rig, obtaining a 70-cm
converter is an easy way to build a basic MicroSat station.  Thus, the
designers of the MicroSats felt that Mode JD was a relatively inexpensive
way to get started on MicroSat operations.

As far as the actual choice of the frequencies for the uplinks to MicroSat
and LUSAT is concerned, you will notice that they are located on opposite
ends of the spectrum.  The decision by the designers to do this was based
mostly on considerations of orbital dynamics.  Because all of the MicroSats
will be "dropped off" from the Ariane rocket at the same time, it will take
many months before they "spread out" to the point that they all do not
appear in the sky at the same time over a ground station.  In order to
avoid interference between users of MicroSat and LUSAT, the frequencies for
the uplinks were widely spaced during the first several months.

As far as MicroSat users interfering with AO-10, AO-13 and other OSCAR
satellites is concerned, the best possible passes for the MicroSats will be
less than 17 minutes for an overhead pass.  This means that there will be a
potential of 45 minutes of QRM, but, as everyone who works packet radio
knows, packets are by nature very short bursts.  Anyone who has listened to
FO-12 will also be aware that 90% of its transmissions are very short.
Another important consideration is that the MicroSats will not digipeat;
they will only accept messages for storage and allow users to read mail
addressed to them (or read unconnected telemetry packets).  Not permitting
digipeating will help reduce any possibility of QRM caused by unattended
beacons.

The final concern is that once radio amateurs hear packets being sent on
the 2-meter satellite subband, terrestrial packeteers will start sending
their packets within the 145.800 to 146.000 MHz spectrum.  To the best
knowledge of AMSAT-NA officials, this has not happened with the current
OSCAR satellites and it is not expected to occur when the new MicroSats are
launched.  Because the equipment to send PSK packets to the MicroSats is
quite different from the AFSK packets sent terrestrially, it would appear
unlikely that such an "encroachment" would occur on the satellite sub-band.
In general, amateurs hold very strongly to gentlemen's agreements
concerning band plans.

It is hoped that this discussion about the MicroSat/LUSAT band plan can put
to rest any lingering questions about the issue.  In upcoming issues of QEX
and ASR, Bob McGwier, N4HY, will discuss this topic in great detail.  Until
then, if you have further concerns or comments, please send them to:

     Bob McGwier, N4HY
     15 Cherrybrook Ln
     East Windsor, NJ 08520

from AMSAT-NA



Gateway: The ARRL Packet Radio Newsletter                         P 2 of 3

Stan Horzepa, WA1LOU, Editor - Volume 5, Number 18 - May 26, 1989

          KA9Q TCP/IP SOFTWARE REVISION 890421.1 REVEALED

(In the previous issue of Gateway, it was reported that a new release of
the KA9Q TCP/IP software, revision 890421.1, for IBM PCs and compatible
computers was available at the TAPR booth at the Dayton HamVention.  The
following story by N3EUA describes this new release in detail and explains
how copies of the software may be obtained.)

This release constitutes an attempt to merge the best efforts of everyone
that has been working on the KA9Q package since the last official release
which was dated 871225.0.  For those who have been tracking the beta
releases, this package was built from 871225.33alpha.W9NK.4.1, with many
additions.  All users are encouraged to upgrade to this release as soon as
possible.

Developers should be aware that this package likely represents the last
official release of the KA9Q package until KA9Q finishes his internal
rewrite to include a multitasking kernel, now known as the "NOS" version of
NET.  All development effort for new applications should be directed
towards NOS.

Revision 890421.0 was distributed in a limited fashion on IBM PC floppies
at the Dayton Hamvention.  For PC users, there is no appreciable difference
between .0 and .1 other than the addition of modem dialing for slip, though
the documentation has been somewhat improved.

The following features are among those too numerous to mention that have
been added since the 871225.0 release.

o Official support for the Atari ST, NEC PC-98XX, HP Portable Plus and
various System V UNIX systems.

o Support for the FTP, Inc. packet driver specification on the IBM PC.

o Support for IP transport over NET/ROM networks and some NET/ROM
  user-level functionality.

o Prompting for RusernameS and RpasswordS in the FTP client.

o Finger application, similar to Berkeley Finger.

o AX.25 mailbox.

o Support for the W2XO PBBS when running under System V UNIX using System V
  IPC between NET and W2XO PBBS.

o Complete rewrite of the documentation.

o Conversion to the Borland Turbo-C 2.0 Professional Package for
  compiling/assembling/linking on the IBM PC.

o Support for the MIT slfp serial line framing protocol.

o Modem dialing for slip and slfp.

There are a number of ways to obtain copies of the software.

Via FTP on Internet:

The software may be found on tomcat.gsfc.nasa.gov in the anonymous ftp
directory called \public\tcp\net-8904.  This is a good source for the code
now.  If you are not on the "real" Internet, tomcat has a 2400 bit/s slip
port for dial-up users.

The software will also be available from wsmr-simtel20.army.mil shortly.
This will probably be the most stable Internet source.

The machine col.hp.com contains a copy of the software in the directory
~ftp/ka9q.  Access is quite reasonable from other sites on the HP Internet,
but very slow for folks outside HP.  This source is recommended only for HP
employees.

Via UUCP or Telephone BBS:

Howard Leadmon, WB3FFV, has the software available on his BBS, which also
supports UUCP.  The WB3FFV BBS telephone numbers are 301-335-0858 for
1200/2400-baud non-MNP modems, 301-335-1955 for 2400-baud MNP and
9600/19200-baud PEP modems.  The BBS uses data settings of 8 bits, no
parity, 1 stop bit.  It is accessible 24 hours per day except for routine
maintenance.

Via Mail:

Tucson Amateur Packet Radio (TAPR) is distributing copies of this release
on IBM-compatible 360-kbyte 5-1/4-inch diskettes.

from Bdale Garbee, N3EUA @ KA0WIE via CompuServe's HamNet


Stan Horzepa, WA1LOU, Editor - Volume 5, Number 18 - May 26, 1989

       SPACE SYMPOSIUM TO MARK 20TH ANNIVERSARY OF AMSAT-NA

This year is the twentieth anniversary of the Radio Amateur Satellite
Corporation (AMSAT-NA) and in celebration of this event, plans are underway
for the 1989 Space Symposium and Annual Meeting of AMSAT-NA to be hosted by
the Central Iowa Technical Society (CITS) in Des Moines on November 10-12.
The schedule for the weekend is for registration and informal dining on
Friday evening, registration, seminars, luncheon, banquet and annual
meeting on Saturday, and on Sunday, seminars and open board meeting.
Seminar topics include MicroSat/PACSAT, Phase IV, UoSAT D and E, satellite
fox hunting, command station development program and digital signal
processing.  For more information, send an SASE to:

     CITS - AMSAT 89
     c/o Ralph Wallio, W0RPK
     1250 Hwy G24
     Indianola, IA 50125

                STRAY BITS

This just in...  the Rocky Mountain Packet Radio Association (RMPRA) will
hold its 1989 Packetfest on Saturday, June 3 at 8:30 AM at the Honeywell
Test Instruments Division facility, 4800 East Dry Creek Rd, Littleton,
Colorado.  Honeywell security requires that all Packetfest attendees be
preregistered.  Details from Bill Flynn, AI0C, 286 S Nome St, Aurora, CO
80012-1212.

W0RLI PBBS Version 10.06 has been released.  Fixes include updating in BT,
better handling of WP updates, better control of CTS to help avoid port
hangs.  Also, batch files can now be run by the server.  Send bug reports
to VE3GYQ @ VE3GYQ.

BB, the AA4RE mailbox program, Version 2.5 has been released and, at this
time, is only available by downloading it (filename RBB25.ZIPS) from Data
Library 9 (DL9) of CompuServe's HamNet.

APLink Version 3.71 has been released and is available from CompuServe's
HamNet (Data Library 9, DL9).  [APLink is a software system written by
Victor Poor, W5SMM, that runs an AMTOR mailbox and a packet-radio BBS
(PBBS) concurrently using a common set of message files on an IBM XT, AT or
compatible computer under DOS 3.2 or higher.]

            CONNECTICUT HAMS INVITED TO CONNECT

Packet radio hams in the state of Connecticut are invited to join the
CONNECTicut Digital Radio Association (CONNECT for short), a new
organization whose objectives are as follows.

o To provide effective and efficient digital networks via Amateur Radio
  into, out of and throughout Connecticut via the participation of
  association members (CONN NET).

o To coordinate these networks with all surrounding digital and nondigital
  communications groups.

o To inform digital users of the availability and features of these
  networks via the Packet Education Network (PEN).

o To educate users in the proper use of the networks (PEN).

Anyone wishing to join CONNECT should contact Tom Hogarty, KC1J, via his
packet-radio mailbox on 145.01 or 145.07 MHz or via mail at 83 Harold Rd,
Farmington, CT 06032.

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

The deadline for each issue of Gateway is the Saturday preceding the issue
date (which is typically a Friday).

             REPRODUCTION OF GATEWAY MATERIAL

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


--
Gary W. Sanders (gws@n8emr or ...!osu-cis!n8emr!gws), 72277,1325
N8EMR @ W8CQK (ip addr) 44.70.0.1 [Ohio AMPR address coordinator]
HAM/SWL/SCANNER BBS (1200/2400/PEP) 614-457-4227

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

End of PACKET-RADIO Digest V89 Issue #153
*****************************************
 4-Jun-89 02:23:13-MDT,5231;000000000000
Return-Path: <[e-mail]>
Date: Sun,  4 Jun 89 01:30:52 MDT
From: [e-mail]
Reply-To: [e-mail]
Subject: PACKET-RADIO Digest V89 #154
To: [e-mail]

PACKET-RADIO Digest         Sun,  4 Jun 89       Volume 89 : Issue 154

Today's Topics:
             A plea (Yea, what he said!)
         Phil Karns vs Jay Steinman (2 msgs)
----------------------------------------------------------------------

Date: 3 Jun 89 20:55:29 GMT
From: ka9q.bellcore.com![e-mail]  (Phil Karn)
Subject: A plea (Yea, what he said!)

>Jay, perhaps you should consider the possibility that the "matter of principle"
>Phil talks about would involve the fact that he works for AT&T and maybe
>would want to avoid any problems regarding proprietary information?

John,

I haven't worked for AT&T since midnight on January 1, 1984. Since then I
have been employed by Bellcore, a subsidiary of the seven regional holding
companies. I hope that by now most people understand that these entities are
all completely independent of AT&T...

No, the "matter of personal principle" behind my avoidance of AT&T versions
of UNIX simply has to do with their highly "closed" nature, which makes it
very difficult for others to make significant modifications or additions to
the kernel.  Further, an extreme Not-Invented-Here syndrome (surpassed in
the industry only by IBM) has caused AT&T to ignore most of the additions
and enhancements contributed by Berkeley, with sockets and TCP/IP networking
leading the list.  Only recently has AT&T grudgingly admitted that some of
its users might actually want TCP/IP networking, so you can now buy (at
extra cost) TCP/IP packages for System V.  To me this is much like making
the clutch, transmission, wheels and tires of a new car "optional, extra
cost items".

I would be willing to reconsider using AT&T UNIX once they include TCP/IP
and all related networking facilities as standard, thoroughly supported
features for no additional cost.

Phil

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

Date: 3 Jun 89 00:34:59 GMT
From: jarvis.csri.toronto.edu!utgpu!attcan!nebulus![e-mail]  (Dennis S. Breckenridge)
Subject: Phil Karns vs Jay Steinman

In article <[e-mail]>, [e-mail] (Jay "you ignorant splut!" Maynard) writes:
> In article <[e-mail]> [e-mail] (Jan Steinman) writes:
> No, there's no gun pointed at my head, but, unless I do something about
> it, I have to assume that the NOS code - on which future enhancements to
> the KA9Q suite will be based - will leave me behind. I still want to be
> part of the packet revolution, and I see TCP/IP as the way to go, yet
> Phil's comments seemed to say that he was going to exclude me and anyone
> else running System V "as a matter of principle". He may have another
> option. I don't, short of spending $10000 or going back from Unix to
> MS-DOS.

Has anyone considered what it would take to port to Sys V rel 4.x?
I asked for it for that reason and was refused as well. I have to take
Jay's approach, are we, the Sys V users , ignored. Oh well so much for Unix
portability! I may as well run Plan-9 and be done with it.
 I guess Phil's concern is supporting this package, there would be a lot
of confusion. I find myself (a SysV kernel hack) interested in BSD internals
as well as some other operating systems. I try and WRITE portable code
not bitch at the "incompatibilities" of X vendor's release of *NIX
I may as well just buy a C64 and run the rest of the *utilities* from
my Kantronics.... Great stuff!

Mailbox what a novel concept.... maybe this will catch on someday...

--
==============================================================================
"A mind is a terrible thing to       MAIL:   Dennis S. Breckenridge
waste!"                                      206 Poyntz Ave
                         North York, Ontario M2N1J6
                         [phone]
UUCP: uunet!attcan!nebulus!dennis    ICBM:   79 28 05 W / 43 45 01 N
                         50 megatons should do!
==============================================================================

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

Date: 3 Jun 89 14:07:27 GMT
From: [e-mail]  (Brian Kantor)
Subject: Phil Karns vs Jay Steinman

So your complaint is that the new Karn TCP/IP package won't run on
your machine because it's specifically designed to run on some
other piece of hardware?  You complain even though you know it's
not just an upgrade of his old code but instead a new product,
complete with its own operating system?

Hmm.  Phil gives you the source for both of his TCP/IP packages.
Berkeley will give you the source for theirs.

There are essentially three choices here: 1) do it yourself, 2)
buy it from someone else, 3) go watch television where everything
is rosey and all problems are solved by pointing a gun at them.

I don't see that you have much valid cause for complaint.
    - Brian

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

End of PACKET-RADIO Digest V89 Issue #154
*****************************************
 5-Jun-89 01:53:06-MDT,3088;000000000000
Return-Path: <[e-mail]>
Date: Mon,  5 Jun 89 01:30:15 MDT
From: [e-mail]
Reply-To: [e-mail]
Subject: PACKET-RADIO Digest V89 #155
To: [e-mail]

PACKET-RADIO Digest         Mon,  5 Jun 89       Volume 89 : Issue 155

Today's Topics:
             A problem with Net (2 msgs)
----------------------------------------------------------------------

Date: 4 Jun 89 17:20:11 GMT
From: elbereth.rutgers.edu!ron.rutgers.edu![e-mail]  (Ron Natalie)
Subject: A problem with Net

Neither my TNC terminal program, nor KA9Q work at all with
DESQVIEW.  Both use their own drivers for the com ports, and
I suspect this doesn't get along with how DESQVIEW operates.

If you want a multitasking machine, run UNIX.

-Ron

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

Date: 4 Jun 89 15:17:58 GMT
From: texbell!uhnix1!moray!splut!linkit![e-mail]  (Herb Crosby)
Subject: A problem with Net

 js> From: [e-mail] (Joseph Skoler)
 js> Message-ID: <[e-mail]>
 js> I have been experiencing the following problem:
 js> On an AT clone (with a cheapo serial card) and an
 js> MFJ-1278, while running NET (Latest version) under
 js> Desqview, the program sometimes hangs.

OK, I am assuming 8904.1 release of KA9Q's Net and that you are running
an AX25 connect and not SLIP to the TNC.
 js>
 js> By hangs I mean that control is still had over the
 js> program - I can still issue commands to it - but
 js> it doesn't seem to have connection to the computer.
 js> For example, when I know there is activity on the freq.
 js> the con and dcd lights go on but NET doesn't recognize
 js> or interpret any signals.

Well this is caused by a FAST I/O transfer between TNC and COMPUTER
with the swap time too long between the windows.  You can correct
it in two ways that I know of... One) shorten the swap time to 1
forground and 1 background or Two) make all intrupts shared from
00 to 80 hex ie in the advance DV F1 window change the boxes for
intrupt to 80 and FF so only the upper intrupts are swapped out.
 js>
 js> At other times, I lose control over the program.  This
 js> happens when multitasking with BM and Net.  I think 640K
If you check the incomming mail you will find that most of the time
that the program hangs like that is from the incomming mail has finished
and it is time for NET to WRITE it into BM currently used mail file
and that the lock file is being hide from each program thus the lockup.
Make sure you are running BM v3.3.1 with the NET 890421.1 and not
some older version.
Herb WD5EFC @44.76.0.40  or @WA4EWV or @WB5BBW or via here OR direct
at [phone] modem 2400-300 8n1
--
Herb Crosby - via FidoNet node 1:106/7873
UUCP: ...!splut!linkit!herb
ARPA: [e-mail]
serviced via UFGATE 1.0

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

End of PACKET-RADIO Digest V89 Issue #155
*****************************************
 6-Jun-89 03:32:31-MDT,1513;000000000000
Return-Path: <[e-mail]>
Date: Tue,  6 Jun 89 01:30:21 MDT
From: [e-mail]
Reply-To: [e-mail]
Subject: PACKET-RADIO Digest V89 #156
To: [e-mail]

PACKET-RADIO Digest         Tue,  6 Jun 89       Volume 89 : Issue 156

Today's Topics:
            Help with TA9Q TCP/IP
----------------------------------------------------------------------

Date: Mon, 5 Jun 89 09:01:23 PDT
From: [e-mail]
Subject: Help with TA9Q TCP/IP

I have recently acquired the KA9Q TCP/IP package and have successfully
gotten it going with a KPC-2 TNC.  I now have two problems:

    1.  I don't have an IP address, and I don't know who the
    coordinator is for my area (San Francisco, CA bay area).

    2.  I need the freq and callsign(s) of some TCP/IP nodes in
    my area to talk to (my hosts.net contains nothing useful
    at the moment).  I've monitored the active packet freqs
    looking for an IP PID, but have never seen one.  I guess
    I will have to digipeat/netrom somewhere to connect to
    the ampr internet.

If anyone can help me with either of the above, I would appreciate
it.

Thanks,

Tony Fleig, KF6XH
DEC ENET:   THE780::FLEIG
USENET:     ucbvax!decwrl!dec-the780!fleig

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

End of PACKET-RADIO Digest V89 Issue #156
*****************************************
 7-Jun-89 02:18:06-MDT,12878;000000000000
Return-Path: <[e-mail]>
Date: Wed,  7 Jun 89 01:30:41 MDT
From: [e-mail]
Reply-To: [e-mail]
Subject: PACKET-RADIO Digest V89 #157
To: [e-mail]

PACKET-RADIO Digest         Wed,  7 Jun 89       Volume 89 : Issue 157

Today's Topics:
               9600 baud plus?
            KA9Q on System V Unix
              Phil Karns vs Jay Steinman
     Phil Karns vs Jay Steinman (you got the name wrong!)
              Sysop Reading Mail on BBS
----------------------------------------------------------------------

Date: 6 Jun 89 17:28:52 GMT
From: zephyr!tektronix!orca!ka7axd.WV.TEK.COM![e-mail]  (Michael T. Horne)
Subject: 9600 baud plus?

> Lets say that you have 3.2khz bandwidth.  Lets also say that you can get
> 100 hz resolution using DSP and/or moderate Q analog filters.  Lets also
> say that you use 2 frequencies for each bit you transmit (mark and space).
> Now, why could you not use 16 ( (3200/100) / 2) pairs and transmit 16 bits/
> baud?  Actually, since you will want to go fullduplex, originator gets 8
> pairs, and receiver gets 8 pairs, so you get 8 bits/baud
>
> That would mean that, instead of sending 300 bits/second at 300 baud, you
> could be sending 300 bytes (or 2400 bits) per second at 300 bauds.

Your idea is not that far off.  Parsing up a band-limited channel into
subchannels and modulating these channels at low baud rates, but using
multiple bits per baud, is one method for achieving reasonable throughput.
Since there is a tradeoff between how many sub-channels you can utilize
and your signaling rate within these sub-channels, your total (realizable)
channel capacity is mostly dependent upon how many bits per signaling
interval per channel you can encode/decode, and this is dependent upon the
quality of the communications channel.

In a communications scheme of this type, you have two attributes of signaling
you can exploit.  One is the amplitude of the signal in the sub-channel,
and the other is the phase of the signal.  M-ary signaling, as it is known, is
accomplished by assigning multiple bits per symbol, that is, having M possible
symbols that can be transmitted/received.  As a simple example, consider
encoding two bits per symbol in the following way:

    b1  b0       A   phase
    ---------+------------
     0   0     0.5       0
     0   1     0.5     +90
     1   0     1.0       0
     1   1     1.0     +90

In this example, every two bits (a dibit) are encoded in a single channel
by generating a sine wave with the attributes listed.  For example, to encode
the dibit {1,0}, the sinusoid would have an amplitude of 1 with a +90 degree
phase shift, or:

    f(omega, b1, b0) = (0.5 + 0.5*b1) sin(omega + (b0 * 90))

This is only a simple example; encoding more bits requires unique combinations
of amplitude and phase for each bit pattern possible.  However, limitations
in the communications channel and in the detection process may limit how
many bits you can encode in a given sub-channel.  There are many other methods
for encoding data that are more spectrally efficient or have lower bit-error
rates for a given input signal strength;  find a good book on data communication
systems if you would like more information.

As I stated above, one of the limiting factors in your throughput is your
communications channel.  For amateur use, the limiting factor is usually
the transmitter/receiver, or in the case of HF, the transmission medium.
Most of today's VHF/UHF radios butcher the audio spectrum in both the
receive and transmit sections, since their original intent is to pass the
human voice, not data.  Because of this, if you use one of the methods above,
you will need to run a `training sequence' between two systems wishing to
communicate, since the radios may have completely different passband
characteristics.  The two communicating modems need to evaluate each other's
characteristics so that some signaling reference is available.  For a multicast
system like most of our current packet systems are seeing, this is difficult
at best.  For HF, the radios can still be a problem, but an even bigger problem
is the fact that HF links introduce amplitude and phase distortions, as
well as multipath effects, and all of these are a function of frequency, making
decoding a challenge to any system using this method.  In this case, you would
probably only encode information in the amplitudes of the signals, and use
pilot carrier(s) as a reference.

Your choice of going to full/half duplex depends on your data flow requirements.
If your data generally flows in one direction at a time, it may be better to
go half duplex, swapping directions as needed, since this will give you the
best overall throughput *in a given direction*.  If your data flows both
directions in nearly equal quantities at random intervals, full duplex is
generally the better way to go.

All in all, your suggestion is basically sound.  As you can see, there are a
lot of `gotchas' in trying to make it work with standard amateur VHF/UHF
equipment.  A better solution might be to use some of the higher amateur
bands and use more traditional modulation schemes since 1) we have the
spectrum and the bandwidth (at least we do right now:), and 2) it's much
easier to build from scratch (and hence do it right) than to hack every 2M
radio to get a system to work.  The Heatherington 56kbaud modem is a first
step in the right direction.

Mike

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

Date: Tue, 6 Jun 89 11:57:03 EDT
From: [e-mail] (Bob Hoffman)
Subject: KA9Q on System V Unix

Over the last week or two I have been reading the many complaints about
the KA9Q port for System V.  First, I would like to offer an apology
for not having caught some errors in the 890421 pre-release code.
Several pieces of Unix support code that I sent to Bdale in February
didn't make it into the 890421.0 release.  I am in the process of
tracking down all of the discrepancies and will forward the changes
to Bdale this week.

When putting together a NET port, I test it on the following systems:
a Sun-3 with SunOS 4.0.1, an AT&T 7300 with Unix 3.5, and an AT&T 3B2/310
with System V release 3.0.  I understand the sizeof(int) vs sizeof(char *)
problems that the Microport (or, more precisely, the 80x86) users are
having.  I do not run Unix on an Intel architecture, so I have to rely
on those who do to send in their machine-specific code.  My goal is
that any System V user should be able to run NET unmodified, save for
editing the Makefile and config.h.   I promise to include all Intel-
specific code that is submitted to me.

Regarding NOS on Unix, there have been several people expressing
interest in working on the port.  Phil has done a nice job making
the clients and servers adhere to a lightweight task model.  I feel
that it would be counter-productive to port NOS to Unix as a large
monolithic process.  Rather, I would like to see these lightweight
processes become real Unix processes.

Since NOS uses the Berkeley socket mechanism, it seems to me that the
best solution is to implement a socket library for System V based on
the underlying interprocess communication (IPC) facilities.  SysVr2 has
three types of IPC:  shared memory, message passing, and semaphores.
SysVr3 includes these and adds a streams facility.  At least one person
I know is in the process of writing a streams-based socket library.
This may be adaptable to the older IPC as well.  NOS would then be
broken up into a daemon that handles the serial ports and TCP/IP/AX.25
protocols and the individual clients and servers would have new main()
routines written around them.

Regarding KA9Q on BSD systems, I'm afraid I've ignored those folks.
For a long time, nobody said anything about running KA9Q on BSD Unix,
so I just didn't do anything.  Phil's solution to putting a Berkeley
system on the packet network is by far the easiest:  run an ethernet
between the Berkeley system and a dedicated PC, and let the PC switch
packets between the ethernet and the packet radio network.  For those
who wish to run KA9Q on a BSD system directly, I will try to bring the
BSD support up to date for the .2 release.

While I agree with Phil that developers should switch to NOS, I believe
that it would be bad PR to abandon 890421.x with serious bugs.

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

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

Date: 6 Jun 89 02:41:00 GMT
From: ux1.cso.uiuc.edu![e-mail]
Subject: Phil Karns vs Jay Steinman

I suppose this all should be on alt.unix.wars but I do have to at least say a
word about the issue of software portability.

Suppose you have a sheet full of dots in a fixed matrix that represent the
features you might see in a computer system.  You make up sheets of paper
for each system, punching out holes when that system has that feature.
Laying the sheet over the dots shows you the available features.

Now if you want to make sure your program is portable over systems X, Y,
and Z, you overlay all three sheets and see what features are left.  Use
only those features, and your program is portable over those systems.

The problem with making a program TOO PORTABLE is that you have so many
sheets of paper blocking so many features that by the time you evaluate
the various systems, you have very few features available.  I like the
idea of portability, but it must be tempered to some degree.  Without
that, systems designers are taking a free ride at the expensive of those
of us developing portable applications.

It also happens to be that UNIX System V version 3.* lacks so many of the
features that academic developers are accustomed to.  Of course BSD lacks
the features of SysV as well.  The common ground between these two systems
is still yet way too small.  So one normally chooses the system they are
most familiar with until it becomes worthwhile to abandon it for a new and
better one.  I recently tried a SysV machine and WAS LOST.  Things just
did not even work.  SysV was as different as BSD Unix and IBM's VM/CMS,
to me that is, and I know both systems fairly well (especially VM/CMS).

For the time being *I* too choose BSD Unix, and await to see if SysV ver 4
will be good enough to switch over (but my expectations are low).  I want
source code, too, enough to rebuild the WHOLE THING.

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

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

Date: 5 Jun 89 17:26:56 GMT
From: tektronix!tekcrl!tekgvs![e-mail]  (Jan Steinman)
Subject: Phil Karns vs Jay Steinman (you got the name wrong!)

Hey, folks, please, PLEEEEZZZE check your attributions!  I am *Jan* (not Jay)
Steinman, and I am not *vs* Phil *Karn* (not Karns), in fact, I support his
position, which I thought was clear from my rebuttal of Jay "you ignorant
splut!" *Maynard* (not Steinman), who was *vs* Phil *Karn* (not Karns).

If you don't know enough about the issue to even get the names of the
participants right, go back and re-read carefully!

:::::: Jan Steinman - N7JDB                Electronic Systems Laboratory ::::::
:::::: [e-mail]       Box 500, MS 50-370 (w)503/627-5881 ::::::
:::::: [e-mail]     Beaverton, OR 97077 (h)503/657-7703 ::::::

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

Date: Tue, 6 Jun 89 09:06:40 -0500
From: Ed Brill  BACS <[e-mail]>
Subject: Sysop Reading Mail on BBS

This question is actually a result of my taking over a modem based BBS, but
I think it applies to packet radio as well.

For a bulletin board that is sponsored by something other than an individual
(i.e. club, group, school), is it a) legal and/or b) ethical and/or c) the
sysop's responsibility  to read every mail message on the system?

There was a lawsuit recently filed in Indiana against the sysop of a modem
BBS because he recovered a killed message on the system and allowed others
to read it and it evidently contained some not-so-nice info.  Anyway, this has
led to some discussion here at Indiana U.  I hope my question is clear enough...what does the
net think???

Thanks and 73,
Ed Brill KA9TAW
[e-mail] (or silver.bacs or jade.bacs or aqua.bacs)
[e-mail]
PC-Link Central BBS: [phone]
145.05  KA9TAW@K9IU

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

End of PACKET-RADIO Digest V89 Issue #157
*****************************************
 8-Jun-89 02:35:56-MDT,6991;000000000000
Return-Path: <[e-mail]>
Date: Thu,  8 Jun 89 01:30:22 MDT
From: [e-mail]
Reply-To: [e-mail]
Subject: PACKET-RADIO Digest V89 #158
To: [e-mail]

PACKET-RADIO Digest         Thu,  8 Jun 89       Volume 89 : Issue 158

Today's Topics:
              A problem with Net
                 CP/M TCP/IP
              NET trace problem
           TheNetRom & software innovation
    Xenix, Merit, KA9Q, 80286, getting them all to work together?
----------------------------------------------------------------------

Date: 5 Jun 89 18:32:03 GMT
From: portal!atari![e-mail]  (Jim Tittsler)
Subject: A problem with Net

In article <[e-mail]>, [e-mail] (Ron Natalie) writes:
> Neither my TNC terminal program, nor KA9Q work at all with
> DESQVIEW.  Both use their own drivers for the com ports, and
> I suspect this doesn't get along with how DESQVIEW operates.

A couple of months back I switched from using DoubleDOS to DESQview to run
the KA9Q NET software and have not had any problems... so it does work (in
at least some cases).

I am using DESQview version 2.24.  The "Optimize Communications" switch
under the "P"erformance selection of the Advanced Setup menu is set to "Y".
(I've used both NET 881225.33 and 890421.1 in this configuration.)

73, Jim AI8A/6    AI8A @ WB6ASR    {portal, daisy, ames}!atari!jwt

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

Date: 26 May 89 20:04:23 GMT
From: hpfcdc!hpldola!hp-lsd!col![e-mail]  (Bdale Garbee)
Subject: CP/M TCP/IP

>Is there a version of Net avaialble that will run under CP/M?

No.  The original development was done on a Xerox 820 (that should date the
project a bit!) under CP/M, but the code hasn't been run in that kind of
environment for a couple of years, and a couple hundred K of space...  :-)

Several folks, including PE1CHL, have taken stabs at porting a subset back to
CP/M, all have decided there were other fish to fry, I believe.

It's probably possible to create a degenerate version that just allows Telnet
and maybe FTP clients.  If you want to go for it, the best bets would be to
get a copy of the Aztec C compiler for CP/M (others may work, but Aztec is
likely to be easy since we use Aztec under DOS as well), and start cutting
things out.  If you can make it work, send me diffs and I'll include it in
a future release if possible.

73 - Bdale, N3EUA

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

Date: 4 Jun 89 18:47:28 GMT
From: portal!cup.portal.com![e-mail]  (R A Lingelbach)
Subject: NET trace problem

When I try "trace to <filename>" after issuing "trace ax0 111", on the console
I get run-on unformatted lines with no headers and with periods for non-ASCII
characters; the file <filename>, however, gets headers only!  When I turn on
Hex dump with "trace ax0 211", and continue tracing to a file, I get a similar
situation with hex and ASCII to the console and just headers in the file. Is
this the way it's supposed to work?

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

Date: 24 May 89 22:55:00 GMT
From: hpfcdc!hpldola!hp-lsd!col![e-mail]  (Bdale Garbee)
Subject: TheNetRom & software innovation

>How come my AT running Unix slows down whenever I fire up the TCP/IP
>package? If I get any activity on the channel, the response time for
>other tasks goes through the roof. Microport's serial handler is
>notoriously buggy, but it's not all that slow; I don't get such a
>noticeable slowdown when running uucp to another machine.

>My AT is too busy. It slows down noticeably when asked to run the
>NET package. That seems to me to be empirical evidence. I see no way that
>forcing it to do even more work can make it less busy.

Because I run NET under sysV on an HP9000/550 (an obsolete but ironclad unix
box) that has separate I/O processors, I had never noticed this.  It turns out
that the way the current sysV drivers are set up in NET to handle the serial
ports is about as stupid as you can get, and NET will eat as much CPU as is
available while eating packets.  This is an implementation defect, not a valid
argument against the offered conceptual model.

A couple of folks have offered fixes, after I get back from next week's
vacation I'll see about integrating one as part of the .2 patches.

>I don't have a machine I can dedicate to packet; that's part of why I'm
>running Unix.

No problem.  My unix machine services a modem, several slip links, two TNC's
running KISS, and four local terminals with no great headache... processing
and I/O horsepower is about equivelent of a fast 286 clone...

>Out here in the real world, where people use packet to communicate, they
>don't give a fuzzy rat's posterior about software experimentation; they
>just want to send packets back and forth.

Some of us understand this.  The goal isn't to make everyone a packet
experimenter (though I don't personally think that would be bad :-), but
instead to experiment so that we can provide the larger user base better
ways to "send packets back and forth".  The fragile nature of BBS forwarding
links running across NET/ROM paths here in CO is interesting to watch in
side-by-side comparison with mail forwarding using SMTP/TCP/IP over the same
paths... passing mail direct to Los Alamos from Colorado Springs through a
long string of single-port NR nodes using NET really works, because of the
stability of TCP under adverse link conditions, where the local PBBS sysops
get frustrated because they "can't keep a link going long enough to pass
traffic".  Real, empirical evidence that we're moving in the right
direction.

73 - Bdale, N3EUA

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

Date: 24 May 89 23:11:54 GMT
From: hpfcdc!hpldola!hp-lsd!col![e-mail]  (Bdale Garbee)
Subject: Xenix, Merit, KA9Q, 80286, getting them all to work together?

>All of the routines compile using the makefile designed for Unix with the
>appropriate patches, however I get an error with a few unresolved externals
>in the final link.  These include procedures from slfp.c, pc.c, and maybe
>a few other modules in the package.  It appears that the makefile doesn't
>include these at all as they use non-unix structures etc?  I am not really
>sure.

You need to do the following to get from sources to working bits on Unix or
lookalike systems:

    edit the file config.h, this specifies what drivers you want, some
    of which won't make sense for your configuration.

    run 'make depend' to update the depend.out file for the weirdies
    in include files on your system.

    run 'make' to build net.debug and a stripped net

73 - Bdale, N3EUA

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

End of PACKET-RADIO Digest V89 Issue #158
*****************************************
 9-Jun-89 03:21:28-MDT,15894;000000000000
Return-Path: <[e-mail]>
Date: Fri,  9 Jun 89 03:00:14 MDT
From: [e-mail]
Reply-To: [e-mail]
Subject: PACKET-RADIO Digest V89 #159
To: [e-mail]

PACKET-RADIO Digest         Fri,  9 Jun 89       Volume 89 : Issue 159

Today's Topics:
              A problem with Net
         relayed for DF2AU: NET/ROM, NORD><LINK, TAPR
          Release 3.x of the Clarkson packet driver
----------------------------------------------------------------------

Date: 6 Jun 89 13:15:11 GMT
From: mitel!sce!cognos!dgbt![e-mail]  (Barry Mclarnon)
Subject: A problem with Net

From article <[e-mail]>, by [e-mail] (Ron Natalie):
> Neither my TNC terminal program, nor KA9Q work at all with
> DESQVIEW.  Both use their own drivers for the com ports, and
> I suspect this doesn't get along with how DESQVIEW operates.

Huh?  KA9Q works just fine under DESQview.  So do all of the comms programs
I've tried.  There are may well be exceptions amongst packet-specific
terminal programs, but I know YAPP works under DV.  And there are a great
many people running BBS programs under DV, again with no problems.  I'm
running a couple of BBS ports (WA7MBL), plus the latest pre-NOS KA9Q bits
handling two additional ports, all under DV.  This is a mix of programs
with separately-loaded and built-in com port drivers, and it all works.
DESQview ain't UNIX, but it does a pretty impressive job of making
MeSsy-DOS tolerable.

Barry

--
Barry McLarnon    Communications Research Center    Ottawa, ON   Canada
UUCP: ...utzoo!bnr-vpa!bnr-rsc!dgbt!barry   INTERNET:  [e-mail]
Compu$erve: 71470,3651     Packet radio:  VE3JF @ VE3JF

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

Date: Thu, 08 Jun 89 10:49:14 MEZ
From: [e-mail]
Subject: relayed for DF2AU: NET/ROM, NORD><LINK, TAPR

The latest articles on the S2000 NORD><LINK debate ask for some
clarification. Our intention was to stay out of this discussion because
it is mostly done emotional and not rational and because we do not like
the libel and slander thrown around by S2000. So here is the (hopefully
last) statement:



Topic: 73 magazine, the NET/ROM-Nordlink question
-------------------------------------------------

This article is a good example of biased and unfair journalism. Because
73 magazine never answered to previous letters we have to answer public.

WB2KQI, the author, called me twice on the fone and although I asked
him for a written copy of his questions and promised to answer by
rapifax within 24 hours he insisted on a voice interview. During that
interview I got the impression that he already had made up his mind and
was just asking the same questions again and again because he didn't
like the answer. He also promised to send me a copy of the article - it
never arrived. Seems as if his memory is a bit damaged. He forgot the
main statements I made and gives some misquotations.

We do not want to discuss cloning here, that's common practice (but
done somewhat different from the way WB2KQI tells).


Some of the things he forgot to tell:

- the first crossband digipeater/node was made by NORD><LINK from TNC1s
by connecting them thru the RS232 ports. We used a TNC source supplied
to us by WA8DED and sent back the results (as source and documentation)
to WA8DED. At that time there was some discussion with WA8DED and W6IXU
on how to build a backbone. But only the crossband digi came out of that.
If you look at the sources of that digi/node and of TheNet you will find
similiar structures and variable names. This was long before NET/ROM
appeared on the scene.

- TheNet was made using a different compiler version and a different
optimizer then NET/ROM. The optimizer shrinks the code by some 30%. So
the process "disassemble-deoptimize-decompile" could not work.  How
deoptimize if you don't know the way original optimization was done,
how decompile if you don't have the original compiler? Have you ever
heard about a decompiler that adds comments to the source?

- TheNet contains a lot more features and less bugs than NET/ROM.

- The report from WA6IGY is wrong in some parts (type of auto variables,
optimization, etc).

- Level 1 and Level 2 of TheNet are made by minor changes to
TheFirmware which is compatible to WA8DEDs firmware but is much faster
and has less bugs and more features (another clone which WA8DED doesn't
care about).

- We _bought_ NET/ROM and we _payed_ for it |
If our intention had been just to steel NET/ROM we would have
published the call encrytion routines and the location of default
parameters. That would have enabled all owners of NET/ROM to change
their callsign (if needed to do so).

- After a short look at the sources any programer will tell you that it
would have been extremely simple to hide any similiarities to NET/ROM -
if we had wanted to do that. On the contrary: we put a lot of work into
TheNet to make it as close to NET/ROM as possible.


Misquotations:

- The "high nosed attitude of WA8DED" was not his refusal to release
the sources (we never asked him for that) but the way S2000 answered to
bug reports and the way they handled updates. Bug reports were answered
"it was intended to be that way" (even the wrong handling of FRMR) and
the next version of NET/ROM came out with exactly theese bugs fixed the
way we had proposed it. Updates were handled "there is no warranty, you
have to buy it again" (with new bugs in it). We wonder why no one in
the states took S2000 to the Better Bussiness Bureau.

- We never told anybody that TheNet is an independent development. We
always stated that it is a clone of NET/ROM.


A closing remark: the author is asking for self policing. That's my
credo too. So stay away from companies that spell HAM as Huge Amount of
Money and try to ripoff your bucks by selling buggy EPROMs without any
warranty, stay away from companies that call your boss to make false
accusations regarding your hobby, stay away from companies that try to
divide the amateur community by locking out some stations.


Topic: Statement by TAPR, stop of NNC development by NORD><LINK
---------------------------------------------------------------

The idea to put TheNet on the NNC came from TAPR last year. After some
internal discussions we stopped our EWTNC development and agreed.
Immediately after this the TAPR internal discussions started again.
Obviously some directors of TAPR wanted the NNC to be filled with live,
others preferred to let it die instead of using TheNet. DF2AU and
DL1LBN went to Tucson and discussed the matter with some TAPR members
and directors. Later on a written statement was sent to TAPR telling
the history of TheNet. TAPR agreed. A formal written contract was made
stating that the NNC was given to NORD><LINK on a permanent loan and
giving NORD><LINK the right to make copies of the hardware for non
commercial use.  The NNC arrived (and we payed some 100$ on duties on
it). The documentation that came with it was rather poor and some
letters to TAPR asking for more were never answered.

Now TAPR changed it's minds and recalled the NNC. Didn't they read
their own contract?  We will not discuss with them. If it wasn't for
the money and the time already spent on that project we would laugh
about that (and file it as "things learned in the past").

So what will happen now? We will continue the 68070 based EWTNC and
start another 80188 based TNC board for the IBM slot.  And the NNC will
be stone dead as it was before. Sorry for those that already bought a
board.


73, Georg, DF2AU @ DK0MAV, on behalf of the NORD><LINK programers

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

Date: 8 Jun 89 18:18:47 GMT
From: sun.soe.clarkson.edu![e-mail]  (Russ Nelson)
Subject: Release 3.x of the Clarkson packet driver

In article <[e-mail]> [e-mail] (Dave Rocks) writes:

    I need a packet driver for 3C523mc adapter for NCSA TELNET and
    NOVELL.

You and about a billion other people.   Anyway, release 3.x of the
Clarkson packet driver collection is now available.  The READ.ME file
appears below.

Availability

The Clarkson collection of packet drivers is available by FTP, by
archive-server, and by modem.

FTP:

sun.soe.clarkson.edu:/pub/ka9q/drivers.arc
grape.ecs.clarkson.edu:/e/tcpip/drivers.arc
flash.bellcore.com:/pub/ka9q/drivers.arc
louie.udel.edu:/pub/ka9q/drivers.arc

(On these last two, look in /pub first -- I had to ask the sysadmins to
move the drivers to /pub/ka9q, and they may not have gotten around to it.)

Archive-server:

Send mail to [e-mail] and put the following
command as the body of your message:
    send ka9q drivers01

Repeat for drivers02, drivers03, and drivers04.  Combine the four parts
and unarchive it.

Modem:

Call the Clarkson Heath User's Group's BBS: [phone], 8N1,
1200/2400 Baud, 24 hours.  Change to file area 24 and download drivers.arc.

Opus:

260/360 in the Nodelist.  Drivers.arc is file requestable.




        Release 3.0 of the Clarkson packet drivers

If you are a user, all you need do is locate the correct packet driver for your
interface, and read DRIVERS.DOC.


Enclosed you will find

3C501.ASM     Device dependent 3COM 3C501 code.
3C501.COM     Executable for a packet driver for the 3COM 3C501.
3C503.ASM     Device dependent 3COM 3C503 code.
3C503.COM     Executable for a packet driver for the 3COM 3C503.
3C523.ASM     Device dependent 3COM 3C523 code.
3C523.COM     Executable for a packet driver for the 3COM 3C523.
DEFS.ASM      Definitions and macros.
DRIVERS.DOC   User documentation.
GENERIC.ASM   Device dependent generic code (a skeleton only).
HEAD.ASM      Resident device independent generic code.
MAKEFILE      Makefile.  Uses tasm and tlink, but MS may work.
NI5010.ASM    Device dependent Interlan NI5010 code.
NI5010.COM    Executable for a packet driver for the Interlan NI5010.
NI5210.ASM    Device dependent MICOM-Interlan NI5210 code.
NI5210.COM    Executable for a packet driver for the MICOM-Interlan NI5210.
PACKETQA.TXT  Questions from R. Nelson and Answers from [e-mail]
PACKET_D.108  Packet driver spec version 1.08
READ.ME       This file.
README.503    Bob Clements' README file for the 3c503.
SLIP8250.ASM  Device dependent SLIP driver using IBM-PC 8250.
SLIP8250.COM  Executable for a SLIP packet driver for the IBM-PC 8250.
TAIL.ASM      Non-resident device independent generic code.
WD8003E.ASM   Device dependent Western Digital WD-8003e code.
WD8003E.COM   Executable for a packet driver for the Western Digital WD-8003e.

I have been in a quandry for some time about the credit that I should take
for these packet drivers.  I created the infrastructure for the packet
drivers, but all of the device dependent portions were written by other
people.  So I feel uncomfortable about taking all the credit.  Probably
the best term to describe what I do is "Editor and publisher", because I
perform a function similar to that served in the literary world.  So, I
sign myself,

    Russell Nelson, Editor of the Clarkson packet drivers.
    [e-mail], [e-mail]

Changes from version 2.0 to 3.0 of the drivers:

NOTE: Only the SLIP8250, NI5210, and 3c523 drivers have been tested.  All
     others are believed to work.

GNU General Public License adopted.  The restriction on commercial usage
     prevented some companies from distributing the packet drivers.  This
     is entirely my idea, so send any comments to [e-mail].
3c523 driver added, thanks to Dan Lanciani ([e-mail]).
Gregg Stefanik ([e-mail]) is working on a 3c505 driver.  Don't
     bug him about it unless you're willing to be a alpha tester.
User documentation added (DRIVERS.DOC).
Brad Clements (no relation to Bob Clements) fixed the NI5210 driver so that
     it will work with a MTU of 1500.
The NI5210 now checks for shorts and opens before it starts up, thanks to
     Brad.
All memory-mapped packet drivers now check the packet length in send_pkt to
     ensure that too-long packets get trapped.  All packet drivers will
     work with MTUs of 1500 (plus 14 bytes of Ethernet header).
Deborah Swanberg noticed that attach_type was returning NO_CLASS
     when it meant to return NO_TYPE.
She also noted that packet drivers weren't returning unique handles.  This
     is only a problem with Phil Karn's code, as his code directs *every*
     packet driver to the same receiver routine.  With non-unique handles,
     it was impossible to tell which packet driver was upcalling the
     receiver.  Unique handles are now generated, based on the starting
     segment of the driver.  The latest version of Karn's code uses different
     receiver routines, so the code to implement this will eventually go away.
Tail.asm now prints the Ethernet address of the interface (if it is an Ethernet
     class device)
Micom has sold Interlan, and Racal has bought it, so perhaps the NI5210 is
     now the Racal-Interlan NI5210?
If anyone is interested in using the Zenith Z-100 with a SLIP packet driver, please
     send me (Russell Nelson) mail.  I have it partially written, but will
     probably never use it myself.
WD8003E and 3c503 sped up slightly -- stole movemem from NI5210.


Changes from version 3 to 2.0 of the drivers:

Version numbering now changed.  If the skeleton changes, the major version is
     incremented and all the minor versions are reset to zero.

Support for version 1.08 of the packet driver spec included.
Bob Clements' 3c503 driver added.  See README.503.
Some comments improved.
BAD_COMMAND checking code fixed.
cld instructions added to ensure that DF=0.
NI5210 sped up slightly -- look at movemem in ni5210.asm for an especially
     fast routine to move memory around.


Changes from version 2 to 3 of the drivers:

SLIP8250 can now be one of three classes: SLIP, AX.25, and KISS.
Tail.asm now checks for a packet driver already at the given interrupt.
Tail.asm now echoes its arguments in hex and decimal.
Tail.asm will close stdout so that a file handle won't be used up in
     case the user redirects stdout to NUL.
Head.asm now supports driver termination.
Termin.com added to terminate a driver.
Head.asm now does a stack swap to avoid pushing too many things when
     interrupting MS-LOSS.


Changes from version 1 to 2 of the drivers:

!!  Arguments are now in decimal by default  !!  Use a 0x prefix for hex.

DEFS.ASM created.
The loadport macro improved.
SLIP8250 driver added, thanks for a C version from Phil Karn.
     I've tried to put some 16550 support in, but I don't have one to
     test it with.  The documentation insists the TBRE goes low when
     the transmit buffer is not empty, while it makes sense for it to stay
     high while the buffer is not full.  I suspect the documentation is
     wrong.
NI5010 driver added, thanks for a C version from Bill Doster.
WD8003 driver added, by Bob Clements.
Loadport macro added to WD8003 driver by Russell Nelson.
Numeric arguments may now be specified in octal, decimal or hex, using the
     C notation.
Numeric arguments can now use up to 32 bits.
Source files reformatted.

--
--russ (nelson@clutx [.bitnet | .clarkson.edu])
I'm a right-to-lifer -- everyone has a right to earn a living sufficient to
feed himself and his family.

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

End of PACKET-RADIO Digest V89 Issue #159
*****************************************
11-Jun-89 18:28:55-MDT,9662;000000000000
Return-Path: <[e-mail]>
Date: Sun, 11 Jun 89 18:00:31 MDT
From: [e-mail]
Reply-To: [e-mail]
Subject: PACKET-RADIO Digest V89 #160
To: [e-mail]

PACKET-RADIO Digest         Sun, 11 Jun 89       Volume 89 : Issue 160

Today's Topics:
            Help with TA9Q TCP/IP
              News From OSCAR-11 09Jun89
              News From OSCAR-9  06Jun89
           Re: A plea (Yea, what he said!)
----------------------------------------------------------------------

Date: 9 Jun 89 13:14:40 GMT
From: mitel!sce!cognos!dgbt![e-mail]  (Barry Mclarnon)
Subject: Help with TA9Q TCP/IP

From article <[e-mail]>, by [e-mail]:
>     1.  I don't have an IP address, and I don't know who the
>         coordinator is for my area (San Francisco, CA bay area).
>
According to the list I have, the coordinator for your area is Andy
Cromarty, N6JLJ.

Maybe I should post the whole list of address coordinators to this
newsgroup?  This info seems to be more of a deep, dark secret than it
should be.

Barry VE3JF

--
Barry McLarnon    Communications Research Center    Ottawa, ON   Canada
UUCP: ...utzoo!bnr-vpa!bnr-rsc!dgbt!barry   INTERNET:  [e-mail]
Compu$erve: 71470,3651     Packet radio:  VE3JF @ VE3JF

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

Date: 11 Jun 89 04:53:39 GMT
From: att!tsdiag!ka2qhd![e-mail]  (John Magliacane Wall Township NJ)
Subject: News From OSCAR-11 09Jun89

**UOSAT 2 COMPUTER STATUS INFORMATION**

FAD1 OPERATING SYSTEM V2.0
TODAY'S DATE IS 11 /6 /89
UNIVERSAL TIME IS 2 :31 :26  DAY 1
AUTO MODE IS SELECTED
SPIN PERIOD IS - 154
Z  MAG FIRINGS = 0
+ SPIN FIRINGS = 27
- SPIN FIRINGS = 0
RAM WASH POINTER AT 1DF4
WOD COMMENCED 11 /6 /89 AT 0 :0 :10
WITH CHANNELS 2 ,61 ,
LAST CMD RECEIVED WAS 112 TO 1 WITH DATA 1

 !!!NEWSFLASH!!!
Geschenk voor de beschrijving van uw
station 3/6 in Helchteren, 11/6 Koksijde
of QSL direkt
ON1KHB, Thier des Crichios,
2 B-4600 CHENEE BELGUIM



ATTITUDE CONTROL INITIATED, MODE 1

DATA COLLECTION IN PROGRESS
DIGITALKER ACTIVE



****         UoSAT-OSCAR-11     BULLETIN - 188      9th June  1989   ****

              UoSAT MISSION CONTROL CENTRE
    University of Surrey, Guildford, Surrey, GU2 5XH, England

** Forth Diary Binary Packet Format - WOD **

A new binary dump format is now operating in the Diary cycle. The general
format of the packet is shown below:-

Sync 1 - 50H
Sync 2 - 41H
Frame Count MSW
Frame Count LSW

Data
Data
Data
Data            64 bytes of data
Data
etc.

Checksum MSW
Checksum LSW    16 bit binary addition of all bytes excluding Syncs.

As described last week this format is used for an engineering frame, and can
also be used for Whole Orbit Data dumps. In the WOD mode each 64 bytes of data
is part of a memory dump, with the address of each packet being given by the
frame count. Each telemetry sample comprises 3 BCD digits which are packed as
follows:-

|    Byte 1    |    Byte 2   |   Byte 3   |
 S1MSD          S1LSD   S2MSD        S2LSD

where MSN and LSN are the most and least significant digits of samples S1 and
S2. This pattern repeats for the whole memory, and cycles through the channels
in the dump. The number and type of channels in the dump can be found from the
engineering frame.

As a trial this format will be transmitted on Tuesdays, initially with Channel
53. The data will be transmitted between the DCE titles and Telemetry and will
replace the conventional WOD dump.

* UO-9 elements from RGO *

Epoch : 89156.07708184
Inclin: 97.5565
RAAN  : 209.4585
Eccn  : 0.0004073
ArgPer: 155.7516
MeanAn: 204.3998
MeanMo: 15.58793637
Decay : 0.00071304
RevNo : 42718

**  AO-13 SCHEDULE **

Date    : 14Jun89 until 16Aug89 ! 16Aug89 until 16Nov89
Attitude:           180/0       !           210/0
Mode-B  :     MA   0 to MA 110  !     MA   3 to MA 160
Mode-JL :     MA 110 to MA 145  !     MA 160 to MA 200
Mode-B  :     MA 145 to MA 255  !     MA 200 to MA 240
OFF     :             %         !     MA 240 to MA   3
Mode-S  :     MA 150 to MA 160  !     MA 210 to MA 222

Also, for a trial period the OMNI-directional 70cm antenna will be connected
to the Mode-B RCVR from MA 20 to MA 40. These changes have been introduced to
enable stations who have access around perigee to experiment with perigee
operation.  Mode S unchanged. 14May89: BLON/BLAT 212.0/+2.4 with a drift rate
of 0.016/-0.061 deg/day, respectively.

Transponders will be in operation during the whole orbit from June 14 until
Aug 16 due to excellent sunangle and power budget. No perigee operation
between August and November due to perigee solar eclipses!

** UO-11 WOD **

Day  Channels
---  --------
Sun  2,61
Mon  1,2,3,61
Tue  53
Wed  19
Thu  1,2,3,61
Fri  0,10,20,30
Sat  10,11,19,29

** Reports **

Thanks for the reports:-

Angus Newman

** $BID **

Please use BID $UOSAT.188B for PR BBS use.

Info supplied by UoS, ANS, RGO, VK5AFR


--
 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: 11 Jun 89 17:43:26 GMT
From: att!tsdiag!ka2qhd![e-mail]  (John Magliacane Wall Township NJ)
Subject: News From OSCAR-9  06Jun89

***UOSAT 1 COMPUTER STATUS INFORMATION***

COMMAND DIARY V1.2 IN OPERATION
UNIVERSAL TIME IS 14:01:48
DATE 11/06/89
AUTO MODE IS SELECTED
MEMORY WASH POINTER AT 03C7H
LAST CMD SENT BY COMPUTER WAS 29H TO 0
LAST CMD RECD BY COMPUTER WAS 7DH TO 0 WITH DATA 21H

CURRENT WOD COMMENCED AT 00:00:00
DATE 11/06/89
SURVEY INCLUDES CHANS 01,03,13,







****    UOSAT-OSCAR-9 Bulletin-262a   6th June 1989    ****

UoSAT Spacecraft Control Centre,
          University of Surrey, England, GU2 5XH

** UoSAT-OSCAR-9 **

The latest UoSAT-OSCAR-9 element set from RGO is :-

EPOC 89156.59034956
INCL 97.5565
RAAN 209.4585
ECCN 0.0004073
ARGP 155.7516
MA   204.3998
MM   15.58793637
DECY .00071304
REVN 42718

** UoSAT-D News **

Harold Price, NK6K has been performing some performance tests on the UoSAT-D
PCE, the Microsat CPU, and other machines. The results are summarised below.

Using a dhryston C benchmark from Sept. '86 DDJ p.88, here are some
performance numbers (using a 6MHz AT as the index).    The same compiler and
options were used (/AS /Ze /Zp /Ot /Gs ).  /Gs (no stack checking) was used
because the S/C stack check is different than the dos version.  Normally /G1
(80186 instruction set) would be used for S/C programs.

The RIC is the PC card we're using for the simulator and for SW development.

Device       CPU       Clock       dhrystons/sec     index

Toshiba 3200 80286     12 MHz      3762              2.03
AT Clone     80286      8 MHz      2145              1.16
IBM AT       80286      6 MHz      1850              1.00
UoSAT PCE    80C186    7.3728 MHz  1398 +            0.75
RIC          80186     7.3728 MHz  1391 +            0.75
AMSAT proto  V40       7.372 MHz   861               0.47
AMSAT flight V40       4.608 MHz   538*              0.29*
IBM PC       8088      4.77 MHz    1531              0.29

+ The timer resolution of 10ms gives an uncertainty of +/-14 counts,
  these numbers are equivalent.

* calculated based on clock speed difference from wirewrap.

The RIC, Microsat Prototype, and UoSAT tests were done under the kernal, so
clock and scheduler overhead are included.  Zero wait states were used.


Please use Bulletin ID UOSAT.261A if put on a packet radio BBS.


--
 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: 7 Jun 89 00:44:48 GMT
From: hpfcdc!hpldola!hp-lsd!col![e-mail]  (Bdale Garbee)
Subject: Re: A plea (Yea, what he said!)

>My tone may have been more inflammatory than necessary, but there's a
>kernel (no put intended) of real request in there: if the code is going
>to be BSD-ized, at least make the job of adaptation easier for those of
>us who are going to be attempting it.

There are actually quite a few of us "insiders" that consider adequate support
of sysV Unix a must.  Don't worry, you won't be left out.

Despite my strong personal pro-BSD bigotry (not ashamed of it at all!), I
happen to run NET full time on an HP9000/550, under HP-UX 5.21... which is
effectively sysVr2, with no hope of improvement since it's an obsoleted machine
now.  Oh to be running currently supported Iron with UX 6.5 that includes all
the BSD wonders... [sigh]

There is a very strong distinction, which may have gotten lost in the telling,
between Phil's inclusion of BSD-style sockets as the interface mechanism
between the network and application hunks of code, and the need to run the
code on BSD flavors of Unix.

If you think about it, there's no good reason to want to run the code under
BSD Unix.  There is a compelling reason to run the code under "missed-em 5"...

73 - Bdale, N3EUA

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

End of PACKET-RADIO Digest V89 Issue #160
*****************************************
14-Jun-89 10:08:11-MDT,8914;000000000000
Return-Path: <[e-mail]>
Date: Wed, 14 Jun 89 10:00:30 MDT
From: [e-mail]
Reply-To: [e-mail]
Subject: PACKET-RADIO Digest V89 #161
To: [e-mail]

PACKET-RADIO Digest         Wed, 14 Jun 89       Volume 89 : Issue 161

Today's Topics:
              KA9Q NOS on UNIX System V
           Split screen term prog? (2 msgs)
               Station problems
----------------------------------------------------------------------

Date: 13 Jun 89 19:57:13 GMT
From: mcvax!kth!sunic!sics.se![e-mail]  (Anders Klemets)
Subject: KA9Q NOS on UNIX System V

This message is to announce the availability of a NOS porting kit for both
the System V and the BSD UNIX operating systems.

I have seen people express the opinion that the best way to run
TCP/IP on packet radio from a BSD UNIX system is to have the KA9Q program
running on a dedicated PC. I find it hard to agree on that.
First, the new KA9Q NOS program does not use any more processor time than
most other programs. Secondly, the KA9Q program is more than just an IP
switch, you may want to run pure AX.25 or NET/ROM as well.
It is better to run the KA9Q program directly on the UNIX machine, at
least as long as it is completely isolated from the TCP/IP code in the
machines operating system.
If you want to be able to act as a gateway between the packet radio network
and your local network, you could use a driver for the NIT interface that I
have written.
It works on 4.3 BSD compatible machines that have support for the
Network Interface Tap. There is one drawback however, the NIT driver
has to monitor all packets on the ethernet, so the load on the machine
will increase, to say the least. Using a PC for this particular purpose
would be more efficient, but probably not as cheap as freeware...

It is much more difficult to make NET and particularly the new program, NOS,
run efficiently on a System V machine. Phil Karn should not be blamed
for this, if it is anybodys fault, it definitely is the fault of the
System V designers.
Having a PC as a separate networking processor would probably be a good
idea here. But then of course, you need some way to communicate between
the System V machine and the PC...

I have NOS running here on a machine with System V release 3.2 and an
80386 CPU. And when I say running, I mean it. It is not supposed wait longer
than 10 ms or so. NOS on a PC or a BSD UNIX machine sits idle when it
has nothing to do, while this one keeps spinning.
NOS is, or at least it can be, interrupt driven. If all ttys are
STREAMS drivers you can arrange to get an interrupt whenever new data
has arrived on the read queue. This works fine on a BSD machine but
not on System V. Instead one has to resort to a commuter loop
that repeatedly tried to read the ttys, just like how it is done in NET.
But there is no need to despair, I have been told that this problem
will be solved in System V release 4.

NOS needs some kind of timer interrupt at regular intervals, several
times per second. This is easily done on BSD machines with the ualarm()
call. System V designers however, apparently never imagined that people
would like to use timers with a granularity of less than a second.
I am solving the problem by having a separate process that handles the
timing by making dummy calls to poll(). It is possible to specify that
the poll() call should timeout after a certain number of milliseconds.
Earlier versions of System V may not even have the poll() function,
but there should be other ways of solving this problem on those machines.

There are not only performance problems to overcome on System V however.
The worst problem is that you are not allowed to move the stack
pointer below the heap. At least not on the 80386 machine I am using.
The multitasker in NOS relies on that every NOS process (or thread) has
its own stack in the data segment of the UNIX process. On some machines,
for instance MS/DOS machines and the SUN-3 with SunOS 4.0, this works
just fine. Apparently SunOS 4.0 (mostly 4.3 BSD) never checks whether
the stack pointer is within legal limits or not. On a SUN-4 (a Sparc
RISC-processor machine) also running SunOS 4.0, the same program would crash.
The 80386 System V machine, on the other hand, would simply refuse to
make the stack pointer point to the data segment.
Unfortunately this kind of behaviour makes NOS somewhat difficult to port.

The way I have worked around the problem is to use parts of the machines
stack segment as stacks for the NOS processes. Obviously this is risky
business. The operating system does not know that those parts of the
stack segment are in use and may page out that part of the memory when
it needs to. When the stack pointer is eventually moved to that area
I guess the machine might not want to page it back since is not supposed
to tamper with anything that is above the stack pointer in memory.
I have not experienced any problems so far, though, but I do not guarantee
that it will work reliably in the long run!
I would be interested to hear from anybody who knows of a better way of
solving this problem.

The source for the NOS porting kit is available with anonymous ftp on the
Internet from sics.se (192.16.123.90).
The filename is:         archive/packet/ka9q/nos/nosunix.tar
The archive contains the files for both BSD and System V, including the
NIT driver that I mentioned previously (for 4.3 BSD or equivalent only).

There is no warranty whatsoever. Good luck!

    Anders SM0RGV

--
E-mail: [e-mail]         Packet radio:   [e-mail]
Phone:  [phone] (W), ([phone] (H))

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

Date: 14 Jun 89 00:58:48 GMT
From: usc!hamal.usc.edu![e-mail]  (Dick Mead)
Subject: Split screen term prog?

    I have had a number of local packet radio users running Macs
    if there is a terminal program that allows split screen mode
    to separate the send and receive data. I know of no such program
    for the Mac, but have seen packet specific programs for IBM clones
    that do this. Does anyone know of any Mac program, terminal or
    packet, that does the same?

    Dick WB6NGC  <[e-mail]>

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

Date: 14 Jun 89 15:00:24 GMT
From: apple.com![e-mail]  (Brian Bechtel)
Subject: Split screen term prog?

In article <[e-mail]> [e-mail] (Dick Mead) writes:
>         I have had a number of local packet radio users running Macs
>         if there is a terminal program that allows split screen mode
>         to separate the send and receive data.

The latest edition of "Tune In The World with Ham Radio" contains the name
and address of a person who sells such a beast.  Sorry, I don't have my
copy at work, so I don't know the address directly.

--Brian Bechtel, N6RMR   [e-mail]     "My opinion, not Apple's"

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

Date: 12 Jun 89 19:09:38 GMT
From: philmtl!philabs!briar.philips.com![e-mail]  (Robert Casey;6282;3.57;$0201)
Subject: Station problems

I've had a packet station set up for about a year now, and up to a month ago,
I've been able to connect and operate reasonably two PBBSs on .07
But lately, things got worse.  I can still connect, but I have a hard time
getting reception of long packets.  (short ones are easier, of course).
Strangely enough, when I'm not connected, but just monitoring the channel, I
seem to have an easier time recieving packets.  (I thought: maybe my reciever
gets bad just after transmitting, but I tried various tests of this and it
seems ok).  <doesn't make sense>
Only thing that I can think of is that for the past year untill a month ago,
this area had a shortage of rainfall, and this last month it rained a lot.
Could the extra water in the tree leaves (lots of trees around my QTH) be
absorbing the RF (this is 2 meters) and spoiling reception?  (lots of trees
between my QTH and PBBS, about 5 miles of 'em).  I noticed that the higher
channels on VHF TV have also gotten weak.  Or high humidity in the air?  I
didn't think this would affect 2meters.  My antenna and coax are all inside
the house, (in attic), so rain can't get at them.  Maybe a wet roof is
attenuating things?  But, as far as I can tell, my transmitted signal is not
impaired.
Now with these weaker signals, TNC RFI is a bigger problem.  Maybe an analog
fiber-optic link between the radio and TNC-computer would help.  Anyone done
something like this?  expensive?  Or just try to tighten up the TNC more?

Thanks in advance
please e-mail

73 de WA2ISE

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

End of PACKET-RADIO Digest V89 Issue #161
*****************************************
18-Jun-89 20:23:53-MDT,14544;000000000000
Return-Path: <[e-mail]>
Date: Sun, 18 Jun 89 20:00:13 MDT
From: [e-mail]
Reply-To: [e-mail]
Subject: PACKET-RADIO Digest V89 #162
To: [e-mail]

PACKET-RADIO Digest         Sun, 18 Jun 89       Volume 89 : Issue 162

Today's Topics:
              BBS'ing with packet radio
            Looking for Software for Amiga
              NET trace problem
        TheNet and KA9Q TCP/IP Info. (2 msgs)
            The Story of Digipeter Rabbit
        UNIX -> ham radio -> unix connections
----------------------------------------------------------------------

Date: 18 Jun 89 03:05:08 GMT
From: bungia!orbit!pnet51![e-mail]  (Shawn Stanley)
Subject: BBS'ing with packet radio

Hi!

I'm a bit new to this area, and especially new to this topic.  (In fact, I'm
currently studying for my novice classification.)

The reason I became interested in packet radio is that a friend mentioned it
to me and thought it would be a good way to "open up" my BBS to a whole new
world.

Has anyone had BBS experience with packet radio, either as a user or a sysop?
What's it like, and what's generally used for equipment?

UUCP: {uunet!rosevax, amdahl!bungia, chinet, killer}!orbit!pnet51!shawn
INET: [e-mail]

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

Date: 17 Jun 89 18:04:43 GMT
From: mcvax!kth!sunic!chalmers!tekno.chalmers.se![e-mail]
Subject: Looking for Software for Amiga

[I'm posting this for a friend. Since I'm not into ham-radio, I have no
idea of what it is all about.]

Hi,

I'm looking for packet radio software for the Amiga-series computers,
escpecially a software implementation of the TNC-functions. I would
be very grateful for any pointers concerning this. Thanks in advance!

             Magnus Backstrom

[ Please respond by e-mail, since I don't read this newsgroup regularly.
  If there is any response I'll summarize to the net. Thanks for your
  time! /Tobbe E-mail to: [e-mail] ]

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

Date: 13 Jun 89 19:15:31 GMT
From: hpfcdc!hpldola!hp-lsd!col![e-mail]  (Bdale Garbee)
Subject: NET trace problem

>Is this the way it's supposed to work?

This is a known bug in the .1 release.  I anticipate it will be fixed for .2,
date of release as yet unknown.

73 - Bdale, N3EUA

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

Date: 14 Jun 89 13:58:06 GMT
From: mcvax!ukc!stl!stc!praxis!hilbert![e-mail]  (Michael Chace)
Subject: TheNet and KA9Q TCP/IP Info.

Hello All,

Would anyone on the net know of machines from which I can FTP details on
TheNet and the KA9Q TCP/IP S/W for the PC.  I'm specifically looking for
operating manual type documentation both for the hardware required and for
the software itself.

Many 73,

Mike.




Contact :    AX25  :  G6DHU @ G6DHU or G6DHU @ GB7IMB.
         Net   :  [e-mail]

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

Date: 16 Jun 89 13:43:42 GMT
From: elbereth.rutgers.edu!hardees.rutgers.edu![e-mail]  (Ron Natalie)
Subject: TheNet and KA9Q TCP/IP Info.

There is a lot of amateur radio stuff on LOUIE.UDEL.EDU.
You can also find the latest KA9Q stuff on FLASH.BELLCORE.COM.

TheNet is not an IBM-PC package.  It is code that gets compiled
to run in TNC2 ROM's.  This is generally recognized as an outright
decompilation of a commercial product (NETROM) and you should
probably steer clear of it.  If you are interested in the NETROM
node protocol, the KA9Q code includes an implementation as part
of the package that was independently written.  It's probably
of more use to you.

-Ron

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

Date: 17 Jun 89 17:15:37 GMT
From: att!tsdiag!ka2qhd![e-mail]  (John Magliacane Wall Township NJ)
Subject: The Story of Digipeter Rabbit

           The Story of Digipeter Rabbit -- A No-Code Fable

              Written by Frank Terranella, N2IGO

   Once upon a time, in a far-away kingdom of Radio, there was a peaceful
valley called Hamville, inhabited by a group of rabbits. Hamville was
orginally settled by the Whiskey family, and the patriarch of that family was
an old hare called Charlie Whiskey.

   Charlie Whiskey was a farmer by trade. He came to the beautiful valley of
Hamville when it was all open meadows. He saw the potential for farming the
vacant land, and over time he developed a thriving carrot plantation.
Charlie Whiskey's carrot plantation was the envy of all the inhabitants of
the kingdom of Radio. He succeeded year after year in producing a bumper crop
of carrots. All the other residents of the kingdom came to Charlie for advice
on planting carrots. Charlie would always tell them, "The secret's in
developing a good ear". No, Charlie didn't have superior hearing, but he had
developed a very special skill. You see, Charlie picked his carrots with his
ears.

   In fact, Charlie had worked hard at perfecting this skill and was able to
harvest at better than 20 carrots per minute. All of Charlie's family learned
to pick carrots with their ears. Soon they were all picking at better than 20
carrots per minute. Charlie was so proud of his special skill that he insisted
that everyone who came to work in Hamville first show that he could pick
carrots with his ears. Charlie would not give new settlers any land unless
they could demonstrate to his foreman, Victor Echo, that they could pick at
least 5 carrots per minute with their ears. When they could pick at 13 carrots
per minute, Charlie gave them more land to work. When they were able to pick
carrots by ear at the rate of 20 carrots per minute, Charlie made them full
citizens of Hamville.

   This process of learning to pick carrots with your ears went on for some
time. In other parts of the kingdom of Radio, other rabbits began to pick
carrots by ear, however, there were some noisy ducks, known as the Quackers,
who lived in the community of Good Buddy. They used their mouths to pick their
crops instead of their ears. They had much larger mouths than the rabbits and
saw no need to use their ears. The rabbits all looked down on the Quackers.
"We must always require ear harvesting skills for entry into Hamville", they
said. "That way we will keep out those noisy Quackers." So everyone who came
to Hamville had to learn how to pick carrots by ear if they wanted to stay.
Charlie Whiskey was adamant about that. "If you don't want to learn the skill
of ear harvesting, then go work in Good Buddy with the Quackers", he would
say.

   And so the years passed, and new methods of farming were developed. These
new methods were easier to learn than ear harvesting, especially for the
animals who didn't have the big ears that the rabbits had. What's more, the
new methods were just as efficient as ear harvesting. As time went by, fewer
and fewer of the young animals were willing to learn the skill of ear
harvesting. The population of Hamville began to dwindle. All the residents of
Hamville were getting on in years. To make matters worse, there were new
neighbors nearby who coveted the beautiful open farmland of Hamville. They
wanted to come in and use it for commercial uses like shopping centers.
And worst of all, the pollution from the Quackers, the other rabbits, and the
Mice (known in Hamville as the QRM group) was having an adverse effect on
farming in Hamville. The future looked bleak indeed.

   Then, one day, a stranger called Digipeter Rabbit came to Hamville. He was
an educated rabbit who studied at the School for Scientific Business (SSB).
He had majored in Farm Mechanics and knew all of the latest scientific
agriculture methods. But for all his education and know-how, there was one
thing that Digipeter could not do. He could not master the skill of picking
carrots with his ears, and since he already knew how to pick carrots more
efficently with new scientific methods, he was not interested in learning.

   Charlie Whiskey was outraged. "What do you mean you won't learn to pick
carrots with your ears? Why, we in Hamville have been picking carrots that
way for 75 years. It's a tradition here. It shows that we're special and that
we're better than the Quackers. If you don't have the desire to develop a good
ear, then we don't want you here in Hamville."

   But Digipeter was adamant. He saw no reason to learn an obsolete skill just
to stay in Hamville and he refused to even try. Charlie Whiskey took the
matter to the Ancient Royal Rabbit League, which he founded. The ARRL decreed
that everyone in Hamville must learn to pick carrots with their ears or be
banished. And so Digipeter Rabbit left Hamville and founded his own village
called Techietown.

   Soon, all the young animals in the land of Radio were flocking to
Techietown, but Digipeter had his own entrance requirement. A good ear and a
good memory were not enough for him. No one could stay in Techietown unless
they could demonstrate technical knowledge, understanding and ability, and the
desire to contribute to the advancement of Techietown.

   Digipeter encouraged all the residents of Techietown to experiment in the
cultivation of new unexplored lands, never before farmed. Digipeter showed
them how to overcome pollution problems. He showed them how to use the land
they had more efficently. Digipeter even perfected a method of farming which
allowed a number of rabbits to farm the land at the same time. And while the
residents of Hamville were picking 30 carrots per minute on a good day, in
Techietown harvests of 300 carrots per minute were possible. Using Digipeter's
methods and those developed by the other bright, young residents, Techietown
soon became the most prosperous village in the kingdom of Radio. This did not
escape the notice of the Field Carrot Council, which governed the kingdom of
radio. To reward the residents of the kingdom, the Field Carrot Council gave
Techietown more and more land to work, until its borders touched those of
Hamville.

   Meanwhile, Hamville was still plodding along as it always had, oblivious to
the revolution in farming occurring around it. The old hares still picked
carrots by ear. The Ancient Royal Rabbit League complained bitterly to the
Field Carrot Council about all the new land it was giving to Techietown, but
the population of Hamville continued to drop. When the Field Carrot Council
gave 2 acres of Hamville property to Techietown, the residents of Hamville
began, for the first time, to be genuinely concerned about their plight. Some
even dared to ask the Ancient Royal Rabbit League to change its mind about the
need to learn to pick carrots by ear to live in Hamville. "We need new blood
here to fight off the Field Carrot Council", they said. Charlie Whiskey, now
in his nineties, was furious. "We have to maintain our standards. We don't need
those smart young bunnies, we need rabbits skilled in our time-honored
harvesting techniques. We need rabbits who are dedicated enough to the
principles of Hamville to want to learn our methods. If a rabbit really wants
to live here, he'll learn our ways. If he doesn't, we don't want him. You
don't want those Quackers to move here, do you?"

   But by now the residents of Hamville had seen the writing on the wall.
Although they genuinely enjoyed picking carrots with their ears, they realized
that there were now other ways which yielded just as many carrots. And though
they would probably continue to pick carrots by ear as they always had, they
could no longer shun those bright young rabbits who chose a more modern
method. A group of rabbits, led by an elder statesman rabbit named Elmer, who
had once served in the government of the kingdom of Radio, asked the Ancient
Royal Rabbit League to change its policy. The League agreed and issued a
decree that henceforth ear harvesting skills would not be required to become a
resident of Hamville.

   When Digipeter heard of the decree, he sent envoys to Hamville with all the
latest scientific discoveries, which he shared freely with the residents. The
residents of Hamville seized upon the new knowledge and soon Hamville became
revitalized. Its population began to increase as young rabbits were attracted
to its bountiful open farmland. The Field Carrot Council, impressed by the
renaissance in Hamville, did not take away any more land, but actually gave
some new territory to Hamville. Everyone was amazed at the new vibrancy of
Hamville.

   Charlie Whiskey, though sad that his beloved harvesting method was no
longer in vogue, saw that his people were prospering and was glad. And to show
that there were no hard feelings, Charlie Whiskey sent Digipeter Rabbit a
packet of 73 carrots which he had picked himself -- with his ears.

   The residents of Hamville rejoiced and declared a festival to celebrate
their new prosperity, and over the front door of the Hamville Festival they
put a banner, which read: "A bunny's worth is measured not by the skill of his
ears, but by what lies between them." The residents of Hamville had learned an
important lesson.

   The End.


--
 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: 15 Jun 89 22:45:54 GMT
From: ucla-an!hermix![e-mail]  (Lance Ellinghouse)
Subject: UNIX -> ham radio -> unix connections

Again I am asking for any information you can give me. Sofar I have
not gotten ONE response.

Someone out there has to be doing this!!

I have a SCO Xenix box at home and work. I want to tie them together
via radio. I would like to get at least 2400 Baud out of it.
It does not have to be packet (direct two-way connect is ok, but it
HAS to be bi-directional at ALL times).

Has anyone done this? Can someone help me? ANy ideas on who I should
contact?  What would it cost? Etc.

Thanks,

--
Lance Ellinghouse
Mark V Systems, Ltd.
UUCP: ...!hermix!lance
ARPA: ucla-an!hermix![e-mail]

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

End of PACKET-RADIO Digest V89 Issue #162
*****************************************
20-Jun-89 20:15:34-MDT,8220;000000000000
Return-Path: <[e-mail]>
Date: Tue, 20 Jun 89 20:00:23 MDT
From: [e-mail]
Reply-To: [e-mail]
Subject: PACKET-RADIO Digest V89 #163
To: [e-mail]

PACKET-RADIO Digest         Tue, 20 Jun 89       Volume 89 : Issue 163

Today's Topics:
         DOC about TCP/IP and TheNet (2 msgs)
             PACKET-RADIO Digest V89 #161
            The Story of Digipeter Rabbit
              West German Mailbox Info.
----------------------------------------------------------------------

Date: Mon, 19 Jun 89 14:59:50 MEZ
From: [e-mail]
Subject: DOC about TCP/IP and TheNet

On

>Date: 16 Jun 89 13:43:42 GMT
>From: elbereth.rutgers.edu!hardees.rutgers.edu![e-mail]  (Ron Natalie)

writes

>Subject: TheNet and KA9Q TCP/IP Info.
>
>There is a lot of amateur radio stuff on LOUIE.UDEL.EDU.
>You can also find the latest KA9Q stuff on FLASH.BELLCORE.COM.

That's right. A lot of interesting things are available there.

>TheNet is not an IBM-PC package.  It is code that gets compiled
>to run in TNC2 ROM's.

This is right and wrong. TheNet is designed to run on TNC2s, but there
are versions running on IBM-PCs and ATARI STs too. Both utilize
the KISS mode of ( any ) TNC. Most of TheNet modules have been developed
on PCs / STs utilizing KISS mode because there was no download function
on a TNC available.

>This is generally recognized as an outright
>decompilation of a commercial product (NETROM) and you should
>probably steer clear of it.

This is simply wrong. Such flames are mostly derived from
third hand rumours which are based one pure commercial propaganda.
If you're interested to read some first hand information take a look
at PR-Digest #159 of 9th june 89. If you missed it let me know.
I'll forward this info to anyone who's interesed in it.

There are several servers with doc and source of TheNet, including
the bridge function CONVERS. Take a look at SIMTEL20 archives. In Europe
there are those TRICKLE servers available saving TheNet files for you.
Look at TRICKLE @ TREARN.BITNET in <MISC.PACKET>TN*. Any other
Trickle will work too ( IMIPOLI, DKTC11, AWIWUW11, DB0FUB11 etc ),
cause your request is automagicaly forwarded
to the corresponding archive.

Detlef
.

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

Date: 20 Jun 89 22:24:15 GMT
From: jupiter![e-mail]  (Phil R. Karn)
Subject: DOC about TCP/IP and TheNet

Bdale: This [TheNet] is generally recognized as an outright
Bdale: decompilation of a commercial product (NETROM) and you should
Bdale: probably steer clear of it.

Detlef: This is simply wrong. Such flames are mostly derived from
Detlef: third hand rumours which are based one pure commercial propaganda.
Detlef: If you're interested to read some first hand information take a look
Detlef: at PR-Digest #159 of 9th june 89. If you missed it let me know.
Detlef: I'll forward this info to anyone who's interesed in it.

I have remained mostly quiet in the NET/ROM vs TheNet battle, but I
cannot let Detlef's assertion go by unchallenged.

Bdale and I are both members of the TAPR board of directors. At our
February meeting, we were shown listings of both NET/ROM and TheNet
source code.

It was immediately obvious to all who examined them that the two
versions could not possibly be independent efforts. The only significant
differences between the two were:

1. The addition of German comments to the TheNet source.
2. The consistent reversal of function argument ordering (i.e., if NET/ROM
called f(a,b,c) TheNet would call f(c,b,a).
3. Different choices for variable and function names.
4. Minor variations in C expression coding and formatting. These variations
were functionally equivalent; i.e., they generated the same object code.

All of these observations were completely consistent with the assertion
by Software 2000 that TheNet was generated by a "decompilation" effort
that started with NET/ROM's object code.  Such an effort is a clear
violation of US copyright laws, which protect "derivative" works as well
as the original.

Concerned about this situation, the TAPR Board sent a letter to
NORD><LINK asking for a response to the charges that had been made
against them. NORD<>LINK responded by essentially conceding to the
accusations, but refusing to admit that there was anything wrong with
their actions.

I personally believe that amateur packet radio is best served by
software (including full source code) that is freely available to every
interested amateur, both for on-air use and for personal study and
experimentation. I have acted on this belief by starting the KA9Q
Internet Protocol Package and encouraging others to contribute to it.
I believe my approach has been very successful.

But others may decide to produce their amateur radio software on a
commercial basis only. Even though I may regret such decisions
personally, I fully respect the authors' rights to make them. There is
plenty of room in amateur radio for both commercial and non-commercial
software packages.

If NORD><LINK had written its own software, from scratch, so as to be
functionally compatible with NET/ROM (i.e., by meeting the protocol
specs documented in the NET/ROM manual, and by interoperability testing
with NET/ROM implementations) then its effort would have been perfectly
legitimate. Such projects are quite common in the computer industry.
Examples include the non-IBM BIOS ROMs found in "clone" PCs, and the
NET/ROM-compatible code contributed to my TCP/IP package by Dan Frank,
W9NK (with the blessing of Software 2000, I might add). But TheNet does
not fall into this category; it is clearly derived from Software 2000's
original work.

The non-commercial people should respect the proprietary nature of the
commercial packages. In turn, the commercial folks should continue to
respect the right of others to INDEPENDENTLY produce packages that are
functionally similar to their own, as Software 2000 has with W9NK's
NET/ROM code.  (Thank God we have no "look and feel" lawsuits in amateur
radio.)

Phil Karn, KA9Q

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

Date: Tue, 20 Jun 89 08:33:46 -0400 (EDT)
From: Norm Brososky <[e-mail]>
Subject: PACKET-RADIO Digest V89 #161

Yes there is a program for split screen for the Macintosh,it's called
Macket and I have been using it for over a year and have had no problems.
You can get more info by writing to :
    S.Fine Software
    P.O. Box 6037
    State College,PA
       16801
 73 de WB3EUT
    Norm

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

Date: 19 Jun 89 16:15:04 GMT
From: cs.utexas.edu!oakhill!dover![e-mail]  (Strawberry Jammer)
Subject: The Story of Digipeter Rabbit

And I *STILL* think that belongs on the pages of QST, CQ etc.!

Please submit it to one of them it really is good!
(Or give me permission to by E-mail and I will do the foot work!)

--
       *Mike Waters    AA4MW/7  [e-mail] *
And on the seventh day, He exited from append mode.

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

Date: 20 Jun 89 09:07:50 GMT
From: mcvax!ukc!stl!stc!praxis!hilbert![e-mail]  (Michael Chace)
Subject: West German Mailbox Info.

Dear All,

Does anyone on the net have information on mailboxes in West Germany.
I am paticularly interested in contacting friends in Iserlohn, a town
to the south-west of Dortmund. I would appreciate details of callsigns
for mailboxes/nodes in :-
              Iserlohn/Altena
              Duesseldorf
              Dortmund
              Hagen/Schwerte

I've posted in English since there maybe others outside DL who could help.
I am fluent in German, so write in Deutsch if it's easier !!

73 & 55,

Mike
****

AX25       -  G6DHU @ G6DHU or G6DHU @ GB7IMB
JANET etc  -  [e-mail]

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

End of PACKET-RADIO Digest V89 Issue #163
*****************************************
22-Jun-89 20:21:00-MDT,19960;000000000000
Return-Path: <[e-mail]>
Date: Thu, 22 Jun 89 20:00:18 MDT
From: [e-mail]
Reply-To: [e-mail]
Subject: PACKET-RADIO Digest V89 #164
To: [e-mail]

PACKET-RADIO Digest         Thu, 22 Jun 89       Volume 89 : Issue 164

Today's Topics:
           Re: DOC about TCP/IP and TheNet (4 msgs)
        to clone or not to clone / hen or egg?
                 unsubscribe
----------------------------------------------------------------------

Date: 22 Jun 89 07:19:29 GMT
From: mcvax![e-mail]  (Frank Rahmani)
Subject: Re: DOC about TCP/IP and TheNet

> commercial packages. In turn, the commercial folks should continue to
> respect the right of others to INDEPENDENTLY produce packages that are
> functionally similar to their own, as Software 2000 has with W9NK's
> NET/ROM code.  (Thank God we have no "look and feel" lawsuits in amateur
> radio.)
> Phil Karn, KA9Q
Dear Phil,
although I agree to what you say in this passage 100% and very much respect
your efforts, I have one remark to make.
The non-commercial people write their fine software for everybody, that
means also for the commercial people. And they use it in their commercial
packages (like Apple using lots of FSF software). We found big hunks of
literally copied public domain software in expensive commercial packages (by
reverse engineering).  So who is really pirating on whom?? Isn't per definition
public domain software deemed to be victimized by the commercial companies?
So if somebody is sued for unallowed copying of commercial software,
shouldn't there be any investigation of how much of the copied software is
based on public domain software? Can the glueing together of public domain
software by a little original code into a commercial package be called a
protectable artistic effort? How many really different ways are there to
write a certain software implementation? Some time ago  I read that all
those companies sueing others for break of look and feel protection (like
Apple e.g.) were sued on their part by a company who held the rights for

bitmapped displays. Somehow they must have arranged as it it rather quiet
now about this business.
Sorry for taking up your time, just some loose thoughts going round and
round my brain...
[e-mail]
--
It is better never to have been born. But who among us has such luck?
Maintainer's Motto:
    If we can't fix it, it ain't broke.
These opinions are solely mine and in no way reflect those of my employer.

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

Date: 22 Jun 89 20:51:34 GMT
From: emory!stiatl![e-mail]  (John DeArmond)
Subject: Re: DOC about TCP/IP and TheNet

In article <[e-mail]> [e-mail] (Frank Rahmani) writes:
>> commercial packages. In turn, the commercial folks should continue to
>> respect the right of others to INDEPENDENTLY produce packages that are
>> functionally similar to their own, as Software 2000 has with W9NK's
>> NET/ROM code.  (Thank God we have no "look and feel" lawsuits in amateur
>> radio.)
>> Phil Karn, KA9Q
>
>Dear Phil,
>although I agree to what you say in this passage 100% and very much respect
>your efforts, I have one remark to make.
>The non-commercial people write their fine software for everybody, that
>means also for the commercial people. And they use it in their commercial
>packages (like Apple using lots of FSF software). We found big hunks of
>literally copied public domain software in expensive commercial packages (by
>reverse engineering).  So who is really pirating on whom?? Isn't per definition
>public domain software deemed to be victimized by the commercial companies?


Well, I'm diametrically opposed to the position taken by TAPR and Phil.
I think TAPR has lost a lot of credibility in this move.  More disturbing to
me than the TAPR action however, is the above comments by Frank which reflect
a total ignorance of the copyright laws and the meaning of public domain.

Frank, when someone releases a work to the public domain, he relinquishes all
ownership and control.  There is NO restriction on reuse or copying.  I can
take public domain software and:

Exerpt portions for my own use
Exerpt portions for commercial gain.
Copy the work in its entirity
Copy the work in its entirity and sell it for commercial gain.
And by some legal opinions, put my own copyright on it and restrict your
   use.

The above is what you can do legally.  Ethically, I attribute any public
domain code I use to the original author if known.

The statement "copyright 1989 Joe Cool, All rights reserved, Released to the
public domain."  seen in many PD packages is an oxymoron and has no legal
meaning.  It is one or the other but not both.  My copyright attorney's
opinion is that the public domain clause will rule because the courts
usually resolve such conflicts toward the benefit of the public - of course,
assuming someone was so stupid as to sue.

Much less clear is the status of such packages as Phil's net program which
exhibit all the attributes of public domain software but retain copyright
protection.  I've discussed this situation with my lawyer at length because
it affects my ability to exerpt  useful algorithms without undue concern.
My lawyer cites the Duck principle of law - "if it waddles like a duck,
quacks like a duck, swims like a duck, you can call it a cow but it's still
a duck".

As to your characterizing anyone who exerpts public domain software for
profit as "piracy", it appears that your deep seated resentment of people
who make profits is showing.  It is no more improper or unethical for me to
incorporate public domain code into my product than it is for you to take
information gleaned from published papers and resell it as a consultant's
work product.  Knowledge belongs to anyone who puts forth the effort to
acquire it, some extremely narrowly classified areas reserved by intellectual
property law.  Strictly as a professional courtesy, I normally notify
a PD  author that I'm using some of "his" code.


Now back to the issue of TAPR and Nord><Link.  I find it fascinating that
people will piously pontificate against the reverse engineering job done
by Nord><Link while they themselves are using a PC clone.  If you are not
using genuine Big Blue PC hardware, you are using a blantantly reverse-
engineered product.  Absolutely no difference than the Nord><Link work.
Let's remember a few facts:

*   As far as I've seen, Ron Rakes has never claimed Nord><Link stole or
    even had access to the source for NET/ROM.

*   The source published by Nord><link is C source, not assembler which
    would be expected from a decompillation effort.  If anyone has an
    algorithm for decompiling an optimized binary back to C source, I'd like
    to know about it.  We've seen "evidence" from a variety of sources
    that the Nord><Link and NET/ROM sources are the same.  Each opinion
    I've read has carefully avoided any discussion of HOW the 2 sources
    arrived at the state they are reputed to be.  I smell a fish.

*   Rakes has thus far failed to take any public action to protect himself
    against this alleged "piracy".  He has instead chosen the public
    forum to make his allegations.  A forum where rumor and innuendo rule.

    If his very venomous allegations have a molecule of substance, why has
    he thus far not even sought an injunction against further distribution?
    No, it could not be enforced but the outcome of a legal proceeding would
    be respected by many hams.  I suspect that few of his allegations would
    withstand the scrutiny of law.


hat has really happened here is that Rakes took a publicly (*not "public
domain") developed protocol running on a publicly developed hardware platform
incorporated into a publicly developed and supported network and sold a
commercial product that exploited these works.  Ok so far.  Remember that
releases prior to 1.0 were distributed publicly without cost so the good 'ole
free ham community could help him refine and debug the product.  Still
sort of OK.  Then he released the commercial version complete with
encrypted callsigns, high prices, almost full price for call sign changes and
rip-off bug fix release charges.  The market responded with Nord><Link, a
product of some people who were apparently pissed off enough to do a fine job
of reverse engineering.  And then to pour gasoline on the fire, after
Nord><link hit the streets, Rakes suddenly comes out with a low cost (or
free, I don't remember) "upgrade" that contained intentional incompatibilities
with both the old NET/ROM and Nord><Link.  And all the while yelling
bloody murder in public and sitting on his hands legally.

I remember well when Nord><link arrived where I was living.  The dull blue
glow on the horizon was hundreds of EPROM erasers firing off to purge
NET/ROM from the face of the earth and replace it with Nord><Link.  95%
of the people converting over had already spent the money on NET/ROM
so it was not a case of people trying to be cheap.  Rather it was a
reaction to one of the more offensive commercial software policies this
side of Lotus.

And now TAPR unilaterally decides to discontinue distribution of NORD><LINK?
I am deeply disappointed.

John

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

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

Date: 22 Jun 89 23:53:01 GMT
From: jupiter![e-mail]  (Phil R. Karn)
Subject: Re: DOC about TCP/IP and TheNet

Frank,

I fully agree with you in your dislike of commercial vendors basing
their products on code originally placed in the public domain. That's
why I copyright my own code instead of placing it in the public domain.
I have no problem with people using my stuff for noncommercial purposes,
but if they want to make money off it, I want to hear from them.

An alternative is the FSF/GNU "copyleft", which is a copyright that
grants use and distribution rights of the software only if the recipient
agrees to allow it (and any enhancements) to be freely recopied. This
effectively eliminates the ability of someone to make money off the
software.

Phil

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

Date: 23 Jun 89 00:24:13 GMT
From: jupiter![e-mail]  (Phil R. Karn)
Subject: Re: DOC about TCP/IP and TheNet

>Frank, when someone releases a work to the public domain, he relinquishes all
>ownership and control.  There is NO restriction on reuse or copying.  I can
>take public domain software and...

Quite true. That's why I copyright my own works (e.g., most parts of
NET.EXE) even though I have no intention of making money off hams. (And
after the NET/ROM-vs-TheNet controversy, I'm damn glad I didn't even
THINK of trying to do so.) However, the ready availability of my code
does NOT lessen the protection my copyright gives against commercial
misuse of my software. Copyrights are quite different from trade
secrets, where you actually have to make an effort to keep something
secret in order to keep legal protection. The whole purpose of a
copyright is to protect an author's interest in a work even though it
has been widely disseminated to the public.

>Now back to the issue of TAPR and Nord><Link.  I find it fascinating that
>people will piously pontificate against the reverse engineering job done
>by Nord><Link while they themselves are using a PC clone.  If you are not
>using genuine Big Blue PC hardware, you are using a blantantly reverse-
>engineered product.  Absolutely no difference than the Nord><Link work.

Absolutely incorrect. There is a *MAJOR* difference between the legal
process of reverse engineering and cloning (as typified by the IBM PC)
and the illegal process of direct code copying. The BIOS ROMs in PC
clones were made by programmers who had never even seen the original IBM
code. They wrote their own code from scratch to meet a set of written
functional specifications. The code is not identical at any level
(source or object) to IBM's original code. (There were some early PC
clones that did indeed use directly copied IBM BIOS ROMs. IBM jumped on
them quite hard, and the result was the carefully established cloning
procedures that now exist.)

>Let's remember a few facts:
>
>*   As far as I've seen, Ron Rakes has never claimed Nord><Link stole or
>    even had access to the source for NET/ROM.

No, he has not claimed this. He *has* claimed that NORD><LINK produced their
source code by reverse-compiling (not just disassembling) the object code
in a NET/ROM EPROM. Since the copyright law covers the translation of
copyrighted works, and "translation" includes compilation and decompilation
of computer programs, this is clearly a copyright infringement.

>*   The source published by Nord><link is C source, not assembler which
>    would be expected from a decompillation effort.  If anyone has an
>    algorithm for decompiling an optimized binary back to C source, I'd like
>    to know about it.  We've seen "evidence" from a variety of sources
>    that the Nord><Link and NET/ROM sources are the same.  Each opinion
>    I've read has carefully avoided any discussion of HOW the 2 sources
>    arrived at the state they are reputed to be.  I smell a fish.

Decompilation is a tedious process, but it is by no means impossible.
Remember the Internet Worm of last November? There now exist something
like a half dozen separate versions of the worm's source code, and all
were produced by tedious manual decompilation of the worm's object code.

When I first heard the piracy accusations against NORD><LINK, I
expressed considerable skepticism that a group of programmers skilled
enough to reverse compile a non-trivial Z-80 object code program would
spend their time on such a tedious and non-creative operation rather
than write a functionally equivalent (and probably better) program from
scratch. Nevertheless, my own examination of the source code for both
versions has convinced me that Ron's accusations are correct: TheNet was
indeed produced by reverse compilation of the NET/ROM object code. I
simply could not come to any other conclusion.

>
>*   Rakes has thus far failed to take any public action to protect himself
>    against this alleged "piracy".  He has instead chosen the public
>    forum to make his allegations.  A forum where rumor and innuendo rule.
>
>    If his very venomous allegations have a molecule of substance, why has
>    he thus far not even sought an injunction against further distribution?
>    No, it could not be enforced but the outcome of a legal proceeding would
>    be respected by many hams.  I suspect that few of his allegations would
>    withstand the scrutiny of law.

For a very simple reason: the income Ron has made from NET/ROM could not
possibly be enough to pay for a copyright infringement suit where the
defendants are in a foreign country.  Ron has decided instead to take
his case to the court of public opinion, and I respect his right to do
so.

Phil

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

Date: Thu, 22 Jun 89 12:10:14 MEZ
From: [e-mail]
Subject: to clone or not to clone / hen or egg?

On

>Date: 20 Jun 89 22:24:15 GMT
>From: jupiter![e-mail]  (Phil R. Karn)

writes:

>Subject: DOC about TCP/IP and TheNet

>.................

>Bdale and I are both members of the TAPR board of directors. At our
>February meeting, we were shown listings of both NET/ROM and TheNet
>source code.
>
>It was immediately obvious to all who examined them that the two
>versions could not possibly be independent efforts. The only significant
>differences between the two were: ......

Mhh. CONVERS mode is no significant difference ?

I don't know of any statement of any NORD><LINK member claiming
TheNet is an independent development. See PR-Digest #159:

: [ df2au writes:]
:- the first crossband digipeater/node was made by NORD><LINK from TNC1s
:by connecting them thru the RS232 ports. We used a TNC source supplied
:to us by WA8DED and sent back the results (as source and documentation)
:to WA8DED. At that time there was some discussion with WA8DED and W6IXU
:on how to build a backbone. But only the crossband digi came out of that.
:If you look at the sources of that digi/node and of TheNet you will find
:similiar structures and variable names. This was long before NET/ROM
:appeared on the scene.
:
:- TheNet was made using a different compiler version and a different
:optimizer then NET/ROM. The optimizer shrinks the code by some 30%. So
:the process "disassemble-deoptimize-decompile" could not work.  How
:deoptimize if you don't know the way original optimization was done,
:how decompile if you don't have the original compiler? Have you ever
:heard about a decompiler that adds comments to the source?
:
:- TheNet contains a lot more features and less bugs than NET/ROM.
:
:- The report from WA6IGY is wrong in some parts (type of auto variables,
:optimization, etc).
:
:- Level 1 and Level 2 of TheNet are made by minor changes to
:TheFirmware which is compatible to WA8DEDs firmware but is much faster
:and has less bugs and more features (another clone which WA8DED doesn't
:care about).
:
:- After a short look at the sources any programer will tell you that it
:would have been extremely simple to hide any similiarities to NET/ROM -
:if we had wanted to do that. On the contrary: we put a lot of work into
:TheNet to make it as close to NET/ROM as possible.
:
:- We never told anybody that TheNet is an independent development. We
:always stated that it is a clone of NET/ROM.
: ..........

:73, Georg, DF2AU @ DK0MAV, on behalf of the NORD><LINK programers

> [ ka9q: ]
>
>All of these observations were completely consistent with the assertion
>by Software 2000 that TheNet was generated by a "decompilation" effort
>that started with NET/ROM's object code.

Maybe somewhat consistent, but wrong anyway.
( this is the commercial propaganda. The propaganda term in my previous
posting doesn't relate to TAPR's observations)

I have to make one thing clear:

I was not personally envolved in programming of NORD><LINK's software,
neither TheNet nor TheFirmware. So don't blame me for serving infos
that some guys don't like ( like S2000 did before ).

But I know it took DC4OX and DF2AU
an enormous amount of time to write the software. They developed
and realized the concept of connecting TNCs back-to-back to act as
an interlink node controller. They sent the relating software
to california ( see above ). I developed and published a protocoll
version allowing  hop-to-hop ACKs within AX.25.
And all this happend long before NET/ROM was available.

So should we blame S2000 to have stolen NORD><LINK's ideas and
sell it to the HAM community ?

If you like clones or not: it's your choice. If you don't like them
stay clear of PCs not labeled with a blue button. Unfortunatly
you can't use the TNC2 in this case, even not together with NET/ROM.
Because it's CPU Z80 looks like a clone of the good old 8080,
compatible bit for bit, and a superset of 8080's functions...

73s Detlef
.

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

Date: Wed, 21 Jun 89 14:27 CST
From: <[e-mail]>
Subject: unsubscribe

for ac4691a@drake unsubscribe * (netwide

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

End of PACKET-RADIO Digest V89 Issue #164
*****************************************
23-Jun-89 20:51:57-MDT,14612;000000000000
Return-Path: <[e-mail]>
Date: Fri, 23 Jun 89 20:00:17 MDT
From: [e-mail]
Reply-To: [e-mail]
Subject: PACKET-RADIO Digest V89 #165
To: [e-mail]

PACKET-RADIO Digest         Fri, 23 Jun 89       Volume 89 : Issue 165

Today's Topics:
          AA4RE and Phone Modem Interfacing
             DOC about TCP/IP and TheNet
           Re: DOC about TCP/IP and TheNet (3 msgs)
       TheNet controversy (was Re: DOC about TCP/IP and TheNet)
----------------------------------------------------------------------

Date: Fri, 23 Jun 89 13:13 CDT
From: <[e-mail]>
Subject: AA4RE and Phone Modem Interfacing

Greetings everyone.

Was wondering if anyone out there in Packet-BBS land had successfully
interfaced the AA4RE BB software to a phone modem (on COM1 or COM2)?
I am using a DRSI PC*PA for my TNC port(s) and would like to experiment
with putting a modem on COM1 or COM2.

I have COM1 open and have an internal modem operating on COM3.  (I have
an external 1200 baud AA/AD modem that I would run off of COM1 for the
phone port access.)

Any comments/help/suggestions welcomed.

Also, on another note, if you are using the G8BPQ PC_Node software then
I would appreciate hearing from you also.

Best 73's...

     John K Kreymer
     N5LKM @ W5AC  (Texas A&M University - Packet)
     JKK3283 @ TAMVENUS  (Bitnet)

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

Date: 23 Jun 89 18:13:00 GMT
From: ux1.cso.uiuc.edu![e-mail]
Subject: DOC about TCP/IP and TheNet

> And by some legal opinions, put my own copyright on it and restrict your
>    use.

Whose opinion?  Something in public domain stays there.  You can change
one LETTER, and copyright THAT, but the original is still in the public
domain; I can change a DIFFERENT letter and have a DIFFERENT copyright
on a DIFFERENT WORK.

> The statement "copyright 1989 Joe Cool, All rights reserved, Released to the
> public domain."  seen in many PD packages is an oxymoron and has no legal
> meaning.  It is one or the other but not both.  My copyright attorney's

The meaning CAN be interpreted as the author having rescinded his rights.
The keyword is "Released".

> Much less clear is the status of such packages as Phil's net program which
> exhibit all the attributes of public domain software but retain copyright
> protection.  I've discussed this situation with my lawyer at length because
> it affects my ability to exerpt  useful algorithms without undue concern.
> My lawyer cites the Duck principle of law - "if it waddles like a duck,
> quacks like a duck, swims like a duck, you can call it a cow but it's still
> a duck".

Seems pretty clear to me.  Phil retains the rights, but grants specific
privileges to all or certain person (depending on the wording, I'm not
reading it right now).

I don't see any problem excerpting algorithms or code.  Ask Phil for the
permission.  He's a nice guy, I'm sure he'd not object.

> Now back to the issue of TAPR and Nord><Link.  I find it fascinating that
> people will piously pontificate against the reverse engineering job done
> by Nord><Link while they themselves are using a PC clone.  If you are not

...and now we are back to "look and feel" again.

> using genuine Big Blue PC hardware, you are using a blantantly reverse-
> engineered product.  Absolutely no difference than the Nord><Link work.
> Let's remember a few facts:

> *   The source published by Nord><link is C source, not assembler which
>     would be expected from a decompillation effort.  If anyone has an

It's pretty easy to figure out the C code from the binary.  MANY independent
decompilations of the Morris Virus took place on the same day last November.

> *   Rakes has thus far failed to take any public action to protect himself
>     against this alleged "piracy".  He has instead chosen the public
>     forum to make his allegations.  A forum where rumor and innuendo rule.
>
>     If his very venomous allegations have a molecule of substance, why has
>     he thus far not even sought an injunction against further distribution?
>     No, it could not be enforced but the outcome of a legal proceeding would
>     be respected by many hams.  I suspect that few of his allegations would
>     withstand the scrutiny of law.

Carrying out a civil law suit across international boundaries is EXTREMELY
EXPENSIVE.  It would probably cost several TIMES the combined net worth of
both parties.


> And now TAPR unilaterally decides to discontinue distribution of NORD><LINK?
> I am deeply disappointed.

I applaud the decision.

Now let's get on with designing new and better things.

--phil (the other one) ka9wgn--

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

Date: 23 Jun 89 07:09:18 GMT
From: ka9q.bellcore.com![e-mail]  (Phil Karn)
Subject: Re: DOC about TCP/IP and TheNet

>And now TAPR unilaterally decides to discontinue distribution of NORD><LINK?
>I am deeply disappointed.

I don't understand this remark. TAPR has had no connection with NORD><LINK
except for our unfortunate (in retrospect) decision to loan them an old
TAPR NNC (Network Node Controller) board for their development efforts.
It was only because of this that we even became involved in the controversy,
as Software 2000 felt we were aiding piracy by this loan. Our recent decision
was limited to the specific issue of whether we should request NORD><LINK
to return the NNC we had loaned them.

To my knowledge, TAPR has never had any role in the distribution of any
NORD><LINK software.

>John DeArmond          **I am the NRA**

Phil Karn               **L'etat est moi** :-)

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

Date: 23 Jun 89 16:15:14 GMT
From: shlump.dec.com![e-mail]  (Fred Goldstein k1io)
Subject: Re: DOC about TCP/IP and TheNet

All of this discussion about the alleged copyright violation by
>NordLink< seems to be taking place under the rubric of US law.
However, NordLink is in Germany, not the US.  It is quite possible
that "decompilation" of a ROM does not constitute a copyright
violation, there.

In any case, I find Raikes overall behavior to be sufficiently
reprehensible to render the question moot, for my own purposes.
His treatment of the JPL (?) ham club members was egregious.
Hell, the protocol is egregious!  When NET/ROM first came out,
he distributed the technical documentation only under non-disclosure,
so we couldn't even discuss the protocol here (on the wireline
nets) until after it was widely in service.  And it contributes
to making appliance operators out of packeteers, at just the wrong place
(the network layer) to bound things so tightly into a ROM.

NordLink can't fix the protocol, but at least they can fix the worst
misfeatures and bugs in Raikes' implementation.  Since the protocol spec
is apparently not rigorously architected, it's quite possible that
the NET/ROM protocol, like (for example) rlogin, is really "defined by
the implementation" and thus reverse-engineering is the only way to get
it right.  Or at least, if it's legal in Germany, the best way.

I know essentially nothing about German law....
     fred k1io

[full disclaimer:  Opinions are mine alone; sharing requires
permission.]

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

Date: 23 Jun 89 17:02:41 GMT
From: fernwood!c3![e-mail]  (Glenn Tenney)
Subject: Re: DOC about TCP/IP and TheNet

In article <[e-mail]> [e-mail] (Phil R. Karn) writes:
> ...
>
>No, he has not claimed this. He *has* claimed that NORD><LINK produced their
>source code by reverse-compiling (not just disassembling) the object code
>in a NET/ROM EPROM. Since the copyright law covers the translation of
>copyrighted works, and "translation" includes compilation and decompilation
>of computer programs, this is clearly a copyright infringement.
>
> ...

Phil, there are some misconceptions in this statement.  You state this as if it
were gospel, but it is NOT.  The case law is unclear at best if converting a program
from, say Basic, to C is a translation.  Going from object code to C, is far from
legally or ethically a translation.  Although the semiconductor chip act doesn't
cover software, that is one example of explicitly legal reverse engineering (ie. copying).

Look at it this way:  Comparing the original object code to the new C code, is it
obvious to the average person that more than 50% is different?  I can believe that
there are many similarities, but that is not enough to warrant claims of outright piracy.
I've acted as an expert witness (never needed to get to trial though) many years ago
about a BIOS that was copied.  In that case, it was a bit easier since assembler is
so much closer to object.

A couple of other points:  (1) How do you know that the source code you looked at
(months after nordlink hit the fan) is actually the source code was in existence
when the reverse engineering was done?  It would be very possible (likely?) for someone
claiming piracy to spend weeks tweaking their code to match the alleged pirate's code.
Yes, the object generated might even be the same, but by careful work one could
make the source code look like a copy.  (2) Is there really a registered, valid copyright
of NetRom?  What is the registration number and date?  (3) I feel that if S2000 is not
willing to at least take some legal action (it doesn't take lots of money, sometimes
less than $100 will accomplish enough), then they are by definition allowing their
copyright to lapse into the public domain.  If no action is taken, then they have
declared netrom to be public domain -- and nordlink is golden.

This whole thing bothers me deeply.  From ALL sides!!!  It really does sound like
S2000 was trying to be too commercial (greedy?) and they didn't like the community's
response so they're crying.

Glenn AA6ER

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

Date: 23 Jun 89 21:44:07 GMT
From: emory!stiatl![e-mail]  (John DeArmond)
Subject: TheNet controversy (was Re: DOC about TCP/IP and TheNet)

In article <[e-mail]> [e-mail] (Phil Karn) writes:
>>And now TAPR unilaterally decides to discontinue distribution of NORD><LINK?
>>I am deeply disappointed.
>
>I don't understand this remark. TAPR has had no connection with NORD><LINK
>except for our unfortunate (in retrospect) decision to loan them an old
>TAPR NNC (Network Node Controller) board for their development efforts.
>It was only because of this that we even became involved in the controversy,
>as Software 2000 felt we were aiding piracy by this loan. Our recent decision
>was limited to the specific issue of whether we should request NORD><LINK
>to return the NNC we had loaned them.

My comment above was in reference to a note that came over the BBS network
a few months back that stated that TAPR was a source for TheNet code.  I no
longer have the traffic so I cannot supply any further detail.  If that
statement was incorrect, then I withdraw my comment.  I instead redirect it
toward the NNC unit.  I am still deeply disappointed.

As an outside observer, I see TAPR giving very unfair preference to Rakes
and company based on personal relationships between Rakes and some of the
board members.  I see the nord><link people being branded as guilty by
virtue of an absence of response.  Fair?  Hardly..  I see "evidence"
provided by an "independent" expert being taken at face value.  From reading
his report, I can hardly call him unbiased.  We have no indication that
the code he evaluated was even production code and not "ringer" code
prepared for the purpose of discrediting Nord><Link.

I'm not saying Rakes and company did this.  But based on the extremely
hateful and spiteful statements Ron made, I'd be as prepared to believe
this possibility as I would to believe the Nord><Link guys explicitly
copied his code.

Since TAPR (and now we) are sitting in judgement, it is our obligation to
treat both sides fairly.  If we are to take Rakes' word at face value,
we must also take Nord><Link's word.  Detlif has stated that they
used a different compiler and a homemade optimizer on their code.  In the
absence of proof to the contrary, I must accept that statement.  He follows
up with some pretty convincing evidence regarding work done BEFORE NET/ROM.
Again, in the absence of proof, I accept that statement.

Nord><Link has, after all, presented pretty strong support for their side -
the source code and the tools used to build the executable.  I'd expect
Rakes to make his source available for public scrutiny especially since
he claims the Nord><Link code is identical.  Then I'd expect a verification
to be made that the source released actually builds a binary identical
to an independently acquired NET/ROM.

At the same time, I'd expect the Nord><Link guys to release background work
such as early prototypes, code fragments, logic diagrams and so on to show
that the work is something other than a mechanical decompile (which I still
seriously doubt to be practical on optimized code).  Detlif, care to respond
here?

I'd expect the 2 to look remarkably alike.  There are only so many ways to
do things on the Z80.  And I'd expect Nord><Link to work from a disassembly
of the NET/ROM.  After all, how else could one determine all the subtleties
of the protocol - even the undocumented features.

My last concern is that TAPR has delivered yet another blow to the NNC.
Nord><Link had the most potential of making the NNC practical and useful.
Considering the money and time invested in the device, I'd expect
support to be given to any effort.  (BTW, Detlif, I know a couple of guys
here that have an NNC who might loan it out.  Contact me if you are
interested.)

john

>
>To my knowledge, TAPR has never had any role in the distribution of any
>NORD><LINK software.
>
>>John DeArmond         **I am the NRA**
>
>Phil Karn              **L'etat est moi** :-)


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

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

End of PACKET-RADIO Digest V89 Issue #165
*****************************************
26-Jun-89 10:28:22-MDT,9690;000000000000
Return-Path: <[e-mail]>
Date: Mon, 26 Jun 89 10:00:24 MDT
From: [e-mail]
Reply-To: [e-mail]
Subject: PACKET-RADIO Digest V89 #166
To: [e-mail]

PACKET-RADIO Digest         Mon, 26 Jun 89       Volume 89 : Issue 166

Today's Topics:
          misinfo re TAPR-NET/ROM-NORD><LINK
           Re: DOC about TCP/IP and TheNet
       TheNet controversy (was Re: DOC about TCP/IP and TheNet)
        to clone or not to clone / hen or egg?
----------------------------------------------------------------------

Date: Mon, 26 Jun 89 04:39:40 GMT
From: [e-mail] (David B. Toth)
Subject: misinfo re TAPR-NET/ROM-NORD><LINK

In response to John De Armond, WD4OQC:
John: you are making wild and irresponsible statements.
Ron Raikes and S2000 have no inside track with the TAPR BoD.
In fact, we stated repeatedly that we were not a court of law
and did not feel that it was our place to make a decision on
this issue. In fact, we felt that it was for the community to decide
based on clear facts, and not hysterical ravings by EITHER side.
We sent NORD><LINK a copy of the WA6IGY analysis. We stated that the
North American ham community had concerns re this issue and invited
a reply. They sent a reply. It did not speak to the questions that we
had raised. Therefore, we asked for the return of the NNC, and have
offered to cover their expenses.

Now, the NNC was closed as a project in late 1987 (by me) since the
people who had promised to write software hadn't (remember the caveat
that you should only get one if you planned to write code). In addition
we found that software tools were either expensive or non-existent.

So we asked for the NNC back because it was a matter of principle, since
they had avoided our questions. This does not imply a decision on the
part of the board as to who is right, and how right they are.

And just to help your disappointment, we never did say that we carried
the NORD><LINK software.

David B. Toth, M.D.
VE3GYQ
Secretary, TAPR Inc.



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

Date: 25 Jun 89 14:15:06 GMT
From: sun-barr!texsun!texbell!splut![e-mail]  (Jay "you ignorant splut!" Maynard)
Subject: Re: DOC about TCP/IP and TheNet

In article <[e-mail]> [e-mail] (Fred Goldstein  k1io) writes:
>In any case, I find Raikes overall behavior to be sufficiently
>reprehensible to render the question moot, for my own purposes.
>His treatment of the JPL (?) ham club members was egregious.

>gasp< Fred and I actually agree on something.
Personally, I will never buy a product from Software 2000 because of
their treatment of TheNet users, especially the JPL Radio Club, W6VIO.
(My spy out there says they _still_ haven't recovered from the bad press
they got with the JPL administration.)

--
Jay Maynard, EMT-P, K5ZC, PP-ASEL   | Never ascribe to malice that which can
uucp:        uunet!nuchat!   (eieio)| adequately be explained by stupidity.
{killer,bellcore}!texbell!splut!jay +----------------------------------------
internet: [e-mail]    | Just say NO to misc.headlines.unitex.

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

Date: 26 Jun 89 08:04:25 GMT
From: ka9q.bellcore.com![e-mail]  (Phil Karn)
Subject: TheNet controversy (was Re: DOC about TCP/IP and TheNet)

>As an outside observer, I see TAPR giving very unfair preference to Rakes
>and company based on personal relationships between Rakes and some of the
>board members.  I see the nord><link people being branded as guilty by
>virtue of an absence of response.  Fair?  Hardly..  I see "evidence"
>provided by an "independent" expert being taken at face value.  From reading
>his report, I can hardly call him unbiased.  We have no indication that
>the code he evaluated was even production code and not "ringer" code
>prepared for the purpose of discrediting Nord><Link.

As a TAPR board member, I am completely unaware of any such personal
relationships. Ron came to us and presented his case. We stated that we
wanted to hear both sides of the story, so we sent NORD><LINK a letter and a
copy of the WA6IGY study. We stated in the letter that we would like a
formal response which we would make public.  Only after their response came
and was read by every director did TAPR announce that NORD><LINK's response
had not satisfied the Board's concerns, and that TAPR would ask for the
return of the NNC it had loaned NORD><LINK. We made it clear to Ron from
the beginning that this was the maximum extent of the "relief" he could
expect from us; we are not a court of law, and we cannot act as one.

Throughout this whole sorry episode, TAPR has tried very hard to maintain an
unbiased position. We have in fact had to resist many attempts by some of
Ron's more outspoken supporters to get drawn even further into the
controversy, and we have sustained many attacks for this. I guess since
we're getting it from both sides equally, we must be doing things about
right.

>I'd expect
>Rakes to make his source available for public scrutiny especially since
>he claims the Nord><Link code is identical.  Then I'd expect a verification
>to be made that the source released actually builds a binary identical
>to an independently acquired NET/ROM.

Those who have compared the versions have done exactly this -- verified that
the NET/ROM source code provided by WA8DED compiles into object code
matching that found in a legitimate NET/ROM EPROM.

>My last concern is that TAPR has delivered yet another blow to the NNC.

The NNC was already, for all intents and purposes, dead well before
NORD><LINK asked to borrow one. The design is completely inadequate for
serious packet switching use, despite the relatively high cost. (In my
opinion, TNC-2s are also completely inadequate for serious packet switching.
But they are considerably cheaper than NNCs.)  The PS-186 from SANDPAC is
the machine you really want (if you want a dedicated hardware engine in the
first place, that is) and I think it will assume the role originally
intended for the NNC.  N3EUA is already porting the KA9Q TCP/IP package
(including W9NK's independently developed NET/ROM code) to it.  In the
meantime, lots of us are using stripped PCs as IP (and NET/ROM) packet
switches, and they work great.

As for the TheNet-vs-NET/ROM controversy, this topic has totally consumed
the HAMNET forum on Compuserve for at least the past six months. I do not
want to see it happen here as well. Before commenting on this topic, I
strongly suggest that everyone go read the volumnous record of comparisons
and articles that have already been written.

Phil

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

Date: 23 Jun 89 21:14:59 GMT
From: jupiter![e-mail]  (Phil R. Karn)
Subject: to clone or not to clone / hen or egg?

>>It was immediately obvious to all who examined them that the two
>>versions could not possibly be independent efforts. The only significant
>>differences between the two were: ......
>
>Mhh. CONVERS mode is no significant difference ?

No, it isn't. Because I went through page after page of source code
listings, concentrating on the internal protocol layers that constitute
most of the software. Function after function, statement after statement
were identical except for the choice of symbol names.

DF2AU: We never told anybody that TheNet is an independent development. We
DF2AU: always stated that it is a clone of NET/ROM.

Since English is not your native language, you may not be aware that the
word "clone" as currently used in the US computer industry has a
colloquial meaning that is somewhat different from that given in most
dictionaries. The formal definition of "clone" implies "identical", as
would be produced by the direct copying of an original.

However, the word "clone" as used in the US computer industry implies a
product that, FROM THE OUTSIDE IS FUNCTIONALLY EQUIVALENT to another
company's product, NOT IDENTICAL ON THE INSIDE. As long as the "clone"
was produced from scratch by a completely independent development
project toward a set of functional specifications, it is legal. This is
how the BIOS ROMs in "clones" of IBM PCs are produced.  The developers
of PC clones did NOT disassemble an IBM ROM, modify it slightly and
reassemble it, because that violates US copyright law. (Several
developers did indeed do just this in the early days, and IBM came down
on them very hard until the present legal cloning procedures were
established.)

In other words, you can still have a legal clone if it was produced by
an independent development. TheNet, as you now admit, was not developed
independently from NET/ROM; therefore it violates the copyright held
by NET/ROM's authors.

>But I know it took DC4OX and DF2AU
>an enormous amount of time to write the software.

This was quite apparent to me. Almost every line in the TheNet source
was commented in German, in stark contrast to NET/ROM's sources which
were almost completely comment-free. But this does not take away from
the fact that the code being commented was produced by a reverse-
compilation process in violation of NET/ROM's copyright. What I still
can't figure out is why a bunch of guys would be willing to spend that
much effort on a non-original work instead of writing their own code
from scratch.

Phil

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

End of PACKET-RADIO Digest V89 Issue #166
*****************************************
29-Jun-89 05:08:53-MDT,17984;000000000000
Return-Path: <[e-mail]>
Date: Thu, 29 Jun 89 05:00:25 MDT
From: [e-mail]
Reply-To: [e-mail]
Subject: PACKET-RADIO Digest V89 #167
To: [e-mail]

PACKET-RADIO Digest         Thu, 29 Jun 89       Volume 89 : Issue 167

Today's Topics:
                 Alaskan PBBS
          misinfo re TAPR-NET/ROM-NORD><LINK
          misinfo TAPR-NET/ROM - NORD><LINK
              TNC RFI problem reduction
----------------------------------------------------------------------

Date: 28 Jun 89 02:14:17 GMT
From: [e-mail]
Subject: Alaskan PBBS

We will be going to Alaska in July and August to conduct some ionospheric
heating experiments (see QST July 1989).  We would greatly appreciate it if
someone can provide a list of the packet bulletin board actively running in
Anchorage, Fairbanks, and any surrounding areas.  Please e-mail to me at:-

         afz1@psuvm

Tnx in advance and 73.


Ahmad, N3FLX

-------
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
<<                                                                     >>
<<  Ahmad F. M. Zain                             Bitnet : afz1@psuvm   >>
<<  316 Communications and Space Science Lab     Packet : N3FLX@WA7SSO >>
<<  Pennsylvania State University                         9M2DX@9M2BBS >>
<<  University Park, PA 16802.             "Time is Life"              >>
<<                                                                     >>
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

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

Date: 29 Jun 89 08:00:59 GMT
From: emory!stiatl![e-mail]  (John DeArmond)
Subject: misinfo re TAPR-NET/ROM-NORD><LINK

I'm going to address Dave's (aka Dr. Death) and Phil's comments in one
posting, as they pertain to the same subject.


In article <[e-mail]> (David B. Toth) writes:
>In response to John De Armond, WD4OQC:
>John: you are making wild and irresponsible statements.
>Ron Raikes and S2000 have no inside track with the TAPR BoD.
>In fact, we stated repeatedly that we were not a court of law

Boy the verbage streching over a year or so don't support that
statement.

>and did not feel that it was our place to make a decision on
>this issue. In fact, we felt that it was for the community to decide
>based on clear facts, and not hysterical ravings by EITHER side.

The community HAS spoken by virtue of the almost complete replacement of
NET/ROM with TheNet firmware.  How much stronger can the community
speak?

>We sent NORD><LINK a copy of the WA6IGY analysis. We stated that the
>North American ham community had concerns re this issue and invited
>a reply.

My reply to that would have been a) you could hardly claim to speak for
the North American ham community and b) the fact that you had a priori
judged Raikes' consultants' report to be true on its face illustrates
extreme bias.  I would not have replied directly to your allegations because
as framed, I could not give a "correct" answer.

They sent a reply. It did not speak to the questions that we
>had raised. Therefore, we asked for the return of the NNC, and have
>offered to cover their expenses.

I don't thinks expenses were the issue.  The loan of the NNC was in
and of itself no big deal.  Many of us could have done that.  Pulling
it in the above context IS a big deal in my book.  TAPR should have
stayed totally out of this debate.

>
>Now, the NNC was closed as a project in late 1987 (by me) since the
>people who had promised to write software hadn't (remember the caveat
>that you should only get one if you planned to write code). In addition
>we found that software tools were either expensive or non-existent.

Let's put some facts on the table here dave, since you claim credit for
killing the NNC.  I had possesion of one of the development units here
in Atlanta for quite some time so I'm fairly intimate with the project.

The NNC was basicly a clone of the Micro Mint (circuit celler) SBC-180.
(not sure of the model #).  It contained copied Micro Mint Bios ROMS
and ZCPR as the OS - again, I believe from the MM board.  The release notes
left a serious doubt in our minds as to the legitimacy of the copied roms.
(shades of this discussion, no?)  The major difference between the MM board
and NNC is the addition of an SCSI controller.

So we received a clone board with a cloned bios and a cloned OS (charitable
choice of words here.)  Which meant that as far as a reproducable unit
went, we had bare boards.  We could not rely on ANY rom or OS services.
We'd have had to start from scratch.  A major hurdle but not fatal.
We pressed on, buying SLR's ASM-180 and Ecosoft C for development tools.
(NOT, by the way, excessivly expensive).

The next big revelation was that there was to be no software coordinator
at TAPR.  The plan was for groups to go off into corners and write massive
ammounts of code, mostly duplicated low level routines, and TAPR would
bless the most successful.  Well, I got a kick out of writing my first
couple of BIOSs but thrill was gone by the time the NNC came along.  I
had little interest in wasting time duplicating the efforts of others.
But still not fatal.

So we start looking at applications.  Phil had started pushing TCP/IP.
We were looking at something simpler, something that would probably have
evolved along the lines of NET/ROM.  There was just one little problem.
Does anybody remember the mythical multi-I/O board promised by TAPR for
the NNC?  The board that was to contain 4 modems and let us talk to
the outside world?  Sure you do.  You probably also remember promised
hard drive controller.  Funny thing, these were never delivered.
We were supposed to write software for hardware that did not exist.

What we ended up with was a funky little clone CP/M box with little I/O
a bootleg BIOS and no ham application other than a terminal emulator.
Oh yeah, and a big dent in the pocketbook.  At least I was lucky to only
be out the price of some tools and not the hardware.

So Dave, don't sit up there and point down on the software people as an
excuse for ending the NNC work.  TAPR simply dropped the ball on this
one, pure and simple.  The Georgia contingent may or may not have written
any useful code but we sure had a bunch of eager and capable people trying.

>
>So we asked for the NNC back because it was a matter of principle, since
>they had avoided our questions. This does not imply a decision on the
>part of the board as to who is right, and how right they are.
>

Funny how yanking a supposidly useless piece of hardware is presented
as not a decision as to who is right and who is wrong.  Interesting
concept.



> (Me)..
>As an outside observer, I see TAPR giving very unfair preference to Rakes
>and company based on personal relationships between Rakes and some of the
>board members.  I see the nord><link people being branded as guilty by
>virtue of an absence of response.  Fair?  Hardly..  I see "evidence"
>provided by an "independent" expert being taken at face value.  From reading
>his report, I can hardly call him unbiased.  We have no indication that
>the code he evaluated was even production code and not "ringer" code
>prepared for the purpose of discrediting Nord><Link.

And Phil sez....

>As a TAPR board member, I am completely unaware of any such personal
>relationships.

> (ME)
>I'd expect
>Rakes to make his source available for public scrutiny especially since
>he claims the Nord><Link code is identical.  Then I'd expect a verification
>to be made that the source released actually builds a binary identical
>to an independently acquired NET/ROM.

Phil Sez...

>Those who have compared the versions have done exactly this -- verified that
>the NET/ROM source code provided by WA8DED compiles into object code
>matching that found in a legitimate NET/ROM EPROM.

I guess I must have a bit of Missouri blood in me because I want Raikes to
"show me".  If indeed the code is identical, Raikes has absolutely
nothing to fear as there is nothing to disclose.  Then the rest of us can
take the code, compile it and compare it to NET/ROMS on the shelf to verify
authenticity and only then compare it to the Nord><Link stuff.  The ONLY
reason I can think of for Raikes to not release his code is that
he is hiding something.  (That may not be an 100% fair statement but
it's as fair as TAPR's response to Nord><Link's "lack of response").

Even if the code is 99% alike, I have no problem as long as no one
stole source from Raikes.   I don't believe Raikes ever claimed that.
I (and apparently a lot of others including the courts in the few applicable
cases) consider reverse engineering to be a legitimate development activity.
Assembler, maybe not.  But C is another story.  I maintain that strict
decompilation of an optimized binary is not practical.  Those that cite
the Internet worm as a counterexample should remember that the worm
had not been stripped and contained much runtime library code.  Both
make decompilation much easier.

I COULD anticipate someone sitting down with a compiler and didling original
code until the compiler emitted nearly identical binaries.  I'd then expect
both sets of sources to be alike.  I doubt that anyone could claim infring-
ment on that basis.  Certainly not worth the massive abuse aimed at
Nord><Link.  That they may have done such a thing may stretch credibility
for some of us who have computing centers in our homes but it is not at all
unreasonable for someone of limited resources and a purely hobby level
interest to have done so.

(ME)...
>My last concern is that TAPR has delivered yet another blow to the NNC.

And Phil sez...
>
>The NNC was already, for all intents and purposes, dead well before
>NORD><LINK asked to borrow one. The design is completely inadequate for
>serious packet switching use, despite the relatively high cost. (In my
>opinion, TNC-2s are also completely inadequate for serious packet switching.
>But they are considerably cheaper than NNCs.)

This attitude bothers me.  The NNC with Nord><Link code on it would fill
many networking needs for the majority of the ham groups who can neither
afford the cost of higher speed nor find space for the equipment.  The
NNC, perhaps with a little crystal goosing, could very adequately handle
multiport switching at 9600 baud or below.  I presume the Nord><Link
guys would have been supplying the mythical modem boards as part of the
development effort.

Besides the potential for being cheap, the NNC would fit many places
a PC and faster RF hardware would not.  I know of many sites available
to us here where a nicely packaged NNC and RF gear on 2 meters or 440 could
be unobstrusivly placed.  A rackfull of gear like our high speed switch
occupies would be out of the question.  I could much easily fit a few
2 meter or 440 yagis which look like the rest of the antennas on the
tower.  It would be quite another thing to justify a microwave dish or a
long boom yagi to the site manager.  And consider that most of us who don't
have a research lab or 2-way shop at our disposal have test equipment
that is perfectly adequate up to about 500 mhz.  I could never justify
the money necessary to buy microwave test equipment even at hamfest
prices (at least the ones I've seen.)


The PS-186 from SANDPAC is
>the machine you really want (if you want a dedicated hardware engine in the
>first place, that is) and I think it will assume the role originally
>intended for the NNC.  N3EUA is already porting the KA9Q TCP/IP package
>(including W9NK's independently developed NET/ROM code) to it.  In the
>meantime, lots of us are using stripped PCs as IP (and NET/ROM) packet
>switches, and they work great.
>

Well remember which group started and pushed the concept of PCs on
mountaintops. (if you guessed GRAPES, you'd be right on the money)  I
remember when I was severely chastized on the net for suggesting a
PC with a hard drive on a mountaintop (they work just fine, probably
tougher than the PC).  I remember when the concept of a PC as a
switch was dismissed as a "toy" idea.  I remember how long it took to
get KE4ZV's digipeater code incorporated into a release of net and how much
time it took to backfit each release.

So yes, we know a bit about PCs as switches.  We also know that a 4 port
switch occupies a full height 19" rack, the space for which is unavailable
at most sites.  The NNC combo would do a nice job for these sites.

I know that a lot of work is going into your code, the PS-186, Bdales
ehternet over microwave and such.  I'm very interested in experimenting
with all these goodies but what I bolt to the top of a mountain is a
whole 'nuther matter.  I must have something that is reliable, reproducable,
replaceable, affordable, and preferably, already built.  The time I
spend driving up to mountaintops to fix flakey hardware is time away from
the fun.


>As for the TheNet-vs-NET/ROM controversy, this topic has totally consumed
>the HAMNET forum on Compuserve for at least the past six months. I do not
>want to see it happen here as well. Before commenting on this topic, I
>strongly suggest that everyone go read the volumnous record of comparisons
>and articles that have already been written.
>
>Phil
>

Well, I got tired of feeding CompuServ about a year ago so I've not
seen the discussion though I can anticipate most threads.  I feel that
the issue of Nord><Link and particularly the issue of TAPR's actions
toward them are too important to dismiss.  We may eat up bandwidth
and we may only change a few peoples' minds but the effort is worth it.
I mean no personal malice toward anybody on this net but sometimes
feelings get hurt.  To that problem, I can only say I'm sorry.  These
issues are a personal culmination of several years worth of exasperation
that have finally come to a head.

Lastly, I appoligize for the length of this posting but there were many
issues to address.  I guess it's lucky I'm doing this at 3:00 am and getting
tired :-)

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

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

Date: Wed, 28 Jun 89 09:33:59 MEZ
From: [e-mail]
Subject: misinfo TAPR-NET/ROM - NORD><LINK

>From: [e-mail] (David B. Toth)
>Subject: misinfo re TAPR-NET/ROM-NORD><LINK
>
>........
>And just to help your disappointment, we never did say that we carried
>the NORD><LINK software.
>
>David B. Toth, M.D.
>VE3GYQ
>Secretary, TAPR Inc.
>

>Date: 26 Jun 89 08:04:25 GMT
>From: ka9q.bellcore.com|[e-mail]  (Phil Karn)
>Subject: TheNet controversy (was Re: DOC about TCP/IP and TheNet)
>
>..........
>The NNC was already, for all intents and purposes, dead well before
>NORD><LINK asked to borrow one. The design is completely inadequate for
>serious packet switching use, despite the relatively high cost. (In my
>opinion, TNC-2s are also completely inadequate for serious packet switching.
>But they are considerably cheaper than NNCs.)  The PS-186 from SANDPAC is
>.....

Just to avoid confusion:

I don't know of any NORD><LINK official ever asking for loaning a NNC
because of the reasons mentioned above.
I started the development of an 68070 ( = 68000 + MMU + DMA-controller +
Timers + etc  ) based TNC / NNC about a year ago. The development was
continued by DC4OX  and prototype board is up and running. So there was
really no need to ask for TAPR's NNCs.
But NORD><LINK was and still is interested in cooperation with other
groups. So a TAPR member asked DF2AU at a visit in USA to port TheNet
to the NNC. I saw some TAPR letters concerning this agreement and
I'll ask Georg for a written statement about that and
will forward it for your information.

Detlef
.

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

Date: 27 Jun 89 13:20:24 GMT
From: philmtl!philabs!briar.philips.com![e-mail]  (Robert Casey;6282;3.57;$0201)
Subject: TNC RFI problem reduction

Here's another thing to try when you're trying to get your 2 meter radio to
not hear TNC RFI.  I separated the radio and TNC by about 10 feet, using about
20 feet of cable that has 3 shielded twisted pairs.  I also used separate
power supplies to run the radio and the TNC.  All this helped a lot, but I found
that putting a toroid ferrite bead coil in the speaker line at the TNC made it
better.  I also used toroid core inductors in the 3 wire RS232 line to keep
that wire from being an antenna (tried that before trying the long cable
between the radio and TNC, didn't help the radio much but reduced TVI from the
TNC).
The cable that I used is marked "Inmac Clear Signal" which I had some of
laying around.  It's intended for some sort of computer use, but it works just
fine for analog audio (mic and speaker lines).  3 twisted pairs with a foil
shield over each pair.  Grounded one wire of each pair.  Any shielded wire
should do.
My radio is crystal controlled, with one packet freq, so its being far away
from the computer is not any inconvience.
BTW, my antenna is about 20 feet away from the radio, and something like 30
feet away from the TNC and computer.  Don't forget to consider that in your
station.
Hope this helps,
73 de WA2ISE

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

End of PACKET-RADIO Digest V89 Issue #167
*****************************************