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

Text File | 1993-12-31 | 203.3 KB | 5,012 lines

2-Jan-89 01:49:29-MST,1114;000000000000
Return-Path: <[e-mail]>
Date: Mon,  2 Jan 89 01:30:33 MST
From: [e-mail]
Reply-To: [e-mail]
Subject: PACKET-RADIO Digest V88 #1
To: [e-mail]

PACKET-RADIO Digest         Mon,  2 Jan 89       Volume 89 : Issue   1

Today's Topics:
                  Atari KISS
----------------------------------------------------------------------

Date: 29 Dec 88 21:25:14 GMT
From: ssc-vax!uvicctr![e-mail]  (Doug Collinge)
Subject: Atari KISS

I have been told that many people use Atari STs for packet.  Is there a
bare modem board and software such as is available for C64?
Doug.

--
        Doug Collinge
        School of Music, University of Victoria,
        PO Box 1700, Victoria, B.C., Canada,  V8W 2Y2
        [e-mail]
        decvax!uw-beaver!uvicctr!collinge
        ubc-vision!uvicctr!collinge
        __... ...__  _.. .  ..._ . __... __. _. .._  ..._._

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

End of PACKET-RADIO Digest
******************************
 3-Jan-89 01:43:25-MST,5576;000000000000
Return-Path: <[e-mail]>
Date: Tue,  3 Jan 89 01:30:58 MST
From: [e-mail]
Reply-To: [e-mail]
Subject: PACKET-RADIO Digest V88 #2
To: [e-mail]

PACKET-RADIO Digest         Tue,  3 Jan 89       Volume 89 : Issue   2

Today's Topics:
              Ciphers and stuff (2 msgs)
            Monoco 10+ Font for Red Ryder
               PK-232 problems
----------------------------------------------------------------------

Date: 1 Jan 89 01:22:00 GMT
From: asuvax!stjhmc!f1.n234.z1.fidonet.org![e-mail]  (Jim Grubs)
Subject: Ciphers and stuff

From: [e-mail] (Geert Jan de Groot)
Date: 19 Dec 88 21:22:08 GMT
Organization: Philips Research Geldrop
Message-ID: <[e-mail]>
Newsgroups: rec.ham-radio.packet

In article <[e-mail]> [e-mail] (Geert Jan de Groot) writes:

>In article <[e-mail]> [e-mail] (Mike Waters) writes:
>>
>> ... authentication of
>>a remote user on any link is tough, radio is harder and the restrictions
>>about no encryption etc. on ham radio make it even tougher.
>>
>>About the only thing that comes to mind as simple, universal, and legal
>>is a form of "one time pad". That is station A sends station B list of some
>>kind
>>by other means (normal mail should work for our purposes) which contains
>>say dates and random numbers for each date. When station A connects
>>it sends the appropriate code number for the day and station B verifies it.

>In Holland, we have had such problems some time ago. People tried to log in
>with the call of the BBS, became remote sysop and removed essential files
>(like mail index files). After 2 hits in one month, we decided that remote
>sysop is *DANGEROUS* and should no longer be used.

Wasn't it Phil Karn who made the point a year or two ago that even although
encryption of message content was illegal, encryption of connect ID
verification was not????


--
St. Joseph's Hospital/Medical Center - Usenet <=> FidoNet Gateway
Uucp: ...{gatech,ames,rutgers}!ncar!noao!asuvax!stjhmc!234!1!Jim.Grubs
Internet: [e-mail]

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

Date: 3 Jan 89 00:01:34 GMT
From: ka9q.bellcore.com![e-mail]  (Phil Karn)
Subject: Ciphers and stuff

Yes, it was I who proposed the use of encryption techniques for
authenticating a message as opposed to hiding its contents. As far as I can
tell, this is perfectly legal.

See my paper in the 6th ARRL Computer Networking Conference proceedings for
details.  For those without copies, I have placed the ms/nroff source to
this paper on flash.bellcore.com (128.96.32.20). Using anonymous FTP, the
file name is /pub/arrl/authent.ms.

Phil

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

Date: 2 Jan 89 01:27:29 GMT
From: killer!texbell!bigtex!milano!lad-shrike![e-mail]  (R M Kriss)
Subject: Monoco 10+ Font for Red Ryder

If you use a Macintosh and Red Ryder 10.3 for Packet Radio,
try this you will like it!

My preference for the default font for Red Ryder is Monaco because it does
not activate the horizontal scroll bar. The problem is most of us only have
Monaco 9 and its eye strain at best. I downloaded Monaco 10 and it is
larger and still does not activate the horizontal scroll bar. The only
problem with Monaco 10 is its hard to tell letter O from the number 0. This
almost drove me crazy when I got a packet message from WO0N (wo0n). On my
Mac+ his all caps call looked like WOON.

The fix was a simple ResEdit trick to add a right to left slant or slash
bar to the zero. If you have ResEdit, do it you will like it. Like all
other ResEdit tricks, do the mod on a copy. Just open the font Suitcase
with ResEdit, mouse on FONT and mouse on the ID. You will then get the font
editor. Scroll until you find the zero, then use the pencil tool to add
dots to cross the zero. After editing, close the ResEdit boxes and when
asked to save changes, do it. After modifying the font, change the name to
Monaco 10+. If you forget to change the name, its hard to spot the
non-virgin. You will need to install Monaco 10+ with the Font/DA Mover. Do
not use Suitcase as it will conflict with the Mac System required Monaco
font. The 10+ will disappear when installed.

If you are reluctant to do the ResEdit trick or cannot find #10, send me a
disk and an SASE for the hacked font. For those on ARPANET, I can Email it
to you.

It works great!

Dick Kriss
Packet Radio    KD5VU @ KB5PM
ARPANET         [e-mail]




:w

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

Date: 2 Jan 89 01:05:59 GMT
From: lindy![e-mail]  (Kevin J. Burnett)
Subject: PK-232 problems

I'm having some problems with my PK-232, namely that the damn thing doesn't
work.  When I turn it on, the 4 leftmost status lights flash (MULT, SEND,
STA, CON), and then nothing happens.  I can't get the thing to respond
to any commands at all.  The "Tune" graph seems to be working, as if I
connect a radio to the box I get the usual pattern, but I just can't
get any response out of it at all.

Does anyone have any suggestions about something in particular that I
should check?

Thanks.
--
Kevin Burnett, KC6AOA/KT                AMPR.ORG: 44.4.0.231

"I have a problem.
 I am a cannibal."   -  Understatement of the century.

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

End of PACKET-RADIO Digest
******************************
 4-Jan-89 01:43:38-MST,3102;000000000000
Return-Path: <[e-mail]>
Date: Wed,  4 Jan 89 01:31:12 MST
From: [e-mail]
Reply-To: [e-mail]
Subject: PACKET-RADIO Digest V88 #3
To: [e-mail]

PACKET-RADIO Digest         Wed,  4 Jan 89       Volume 89 : Issue   3

Today's Topics:
                  Atari KISS
            Monoco 10+ Font for Red Ryder
----------------------------------------------------------------------

Date: Tue, 3 Jan 89 09:48:17 MST
From: apcihq!apcislc![e-mail] (John D. Hays)
Subject: Atari KISS

I used an Atari ST for packet for quite some time.  I used a regular
TNC (with KISS) for communication.

I believe the KA9Q bits are available for TCP/IP on the ATARI.  (I
was working on a port myself --- until I got tired of having to write
everything I wanted for the Atari and broke down and traded on a
PC-CLONE.)  The most flexible way to go would be to get a TNC with
KISS and the "Howie" code.  That way you can run TCP/IP if you want
to leave the system runinng ... or switch to "Howie" code and let
the TNC act as a storage buffer when the machine is off.

I don't understand this desire to just attach a modem.  The price
difference is so small ... and you have to dedicate the machine to
packet. (Of course mine is pretty well dedicated anyway ... but the
flexibility is there.)

BTW ... I loved my ST when I had it ... It was one of the best values
for the dollar on the market.  It also was a very quite on RF, which
cannot be said for my clone.

John D. Hays, Consultant, Regional Systems Engineering   | My
Apollo Computer Inc. - Salt Lake City, Utah - USA        | Opinions
Packet Radio: [e-mail] [44.40.1.3]            | Are
ARPA: [e-mail] COMPU$ERVE: 72725,424  GEnie: HAYS | My
UUCP: utah-cs!caeco!apcislc!hays W0RLI/NET: KD7UW@WB7TRX | Own

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

Date: 2 Jan 89 20:03:53 GMT
From: pacbell!well![e-mail]  (Bob Murphy)
Subject: Monoco 10+ Font for Red Ryder

The trick of hacking the Monaco font on the Macintosh is quite handy.  As
a programmer, I frequently have trouble distinguishing the letter O from
zero, or the capital I from the miniscule l.  However, hacking Monaco 9
is rather tricky since it's been included in some of the recent versions
of the ROM, so changing the version in your System file has no effect.
What I've wound up doing is using the fact that Font/DA Mover will install
fonts in applications if you hold down the option key when you hit its
open button; it will then let you see *all* files, not just suitcases and
the System file.  So, I have hacked versions of Monaco 9 and Monaco 12,
and installed them in the Lightspeed C and MPW Shell programs.  There's
no reason you couldn't do this to Red Ryder 10.3.  It doesn't make your
hacked font available to all programs, alas, but it's good enough for what
I do.

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

End of PACKET-RADIO Digest
******************************
 6-Jan-89 01:51:11-MST,13057;000000000000
Return-Path: <[e-mail]>
Date: Fri,  6 Jan 89 01:30:22 MST
From: [e-mail]
Reply-To: [e-mail]
Subject: PACKET-RADIO Digest V88 #4
To: [e-mail]

PACKET-RADIO Digest         Fri,  6 Jan 89       Volume 89 : Issue   4

Today's Topics:
        BITNET and Usenet access to Simtel20 archives
              mail gateway(s) ?
           TheNet 1.0 user manual available
----------------------------------------------------------------------

Date: Fri, 6 Jan 1989  00:54 MST
From: Keith Petersen <[e-mail]>
Subject: BITNET and Usenet access to Simtel20 archives

Here is info on the server at RPICICGE.  Notice the various options
and limitations depending on the operating system of your host.

Usenet users should use a path to the nearest backbone site that is
also on the Arpanet.  Example: ucbvax!vm.ecs.rpi.edu!listserv
Another example: uunet!vm.ecs.rpi.edu!listserv

--
Keith Petersen
Maintainer of the CP/M & MSDOS archives at wsmr-simtel20.army.mil [26.0.0.74]
DDN: [e-mail]
Uucp: {ames,decwrl,harvard,rutgers,ucbvax,uunet}!wsmr-simtel20.army.mil!w8sdz

---forwarded message---
From:   "John S. Fisher"  <[e-mail]>
To:  [e-mail]
Subject: More up-to-date info on the server at RPICICGE.BITNET

The following is a more up-to-date collection of information about
using the server at RPICICGE.BITNET (aka VM.ECS.RPI.EDU).  Two notes
first, though: For non-Bitnet users connectivity continues to be a
problem.  The server uses the From: header in mail messages to derive
the return path, and it does this without the aid of a domain name
server.  Hosts not in the SRI hosts tables are typically unreachable.
Also, there have been some performance problems with the gateway
between Arpanet and Nysernet (where VM.ECS.RPI.EDU is to be found).
The ability of the server to satisfy file requests has been hampered.

       --------------
RPICICGE File Server Documentation and Usage Notes

The RPICICGE File Server gives users on Bitnet hosts nearly up-to-date
access to the collossal public domain software collection stored on
WSMR-SIMTEL20.ARMY.MIL.  The server runs on an IBM VM/SP system and is
built on top of popular mail/file server, Revised LISTSERV.  However,
since the server handles files directly from WSMR-SIMTEL20.ARMY.MIL,
the normal VM/SP and LISTSERV concepts do not apply.

     WSMR-SIMTEL20.ARMY.MIL is a DEC Tops-20 system, and file naming
therefore follow Tops-20 conventions.  For this server, file names
always conform , to the following layout:

     diskname:<directoryname.subdirectoryname>filename.extension

The diskname identifies the physical disk device where the file is
stored.  The software archives are all kept on the disk named PD.
The directoryname identifies in which archive the file is stored.
The server provides access to the following archives:

     CPM     -- Info-CPM software archives.
     MSDOS   -- Info-IBMPC software archives.
     SIGM    -- SIG/M software archives.
     PC-BLUE -- PC-Blue software archives.
     MISC    -- Miscellaneous software archives.

The subdirectorynames partitions the archive into categories, and the
categories vary from archive to archive.  The filename is generally
some descriptive name for the file; the extentionname indicates its
type.  For example,

     PD1:<MSDOS.STARTER>UUDECODE.BAS

is a BASIC source program that does uudecoding.  It is located in the
STARTER (for starter-kit) subdirectory of the MSDOS archive.  When
requesting files from the server you must specify the file's fully
qualified name using the Tops-20 notation.

(Note:  The design of the server does not allow for getting files
at the top level directory, e.g. PD2:<CPM>CPM.CRCLST is not available.
However, since the files at the top level are generally directory
listings, the need for them is superceded by the /PDDIR command.)

Requests are sent to [e-mail] either as RFC822-style
mail, or as interactive messages.  Two commands are supported by the
server.  The /PDDIR command requests a directory of available files,
and the /PDDIR command requests a specific file.

*********************
The /PDDIR command. *
*********************
The /PDDIR command is used to list the names of files that match some
pattern.  The command has several forms.  They are:

    /PDDIR
    /PDDIR  PD1:<directory>
    /PDDIR  PD1:<directory.subdirectory>filename.ext  age

The first form lists the names of all the archives known to the server.
At present these are CPM, SIGM, PC-BLUE, MSDOS, and MISC.  The second
form lists the names of all the subdirectories in a particular archive.
(The directory name must be one of the known archives: CPM, SIGM, etc.)
The third form lists the names of files in the archive.  The age
parameter limits how old a file in the archive may be and still be
considered.  If omitted, the default is 30, meaning 30 days old.
The directory name must be one of CPM, SIGM, PC-BLUE, MSDOS, or MISC.
The subdirectory, filename, and ext may include asterisks ('*') as
"wild-card" characters.  The following are examples.

    /PDDIR PD1:<MSDOS>  --Lists all subdirectories in the MSDOS archive.
    /PDDIR PD2:<SIGM.*>*.*   --Lists files added in the last 30 days.
    /PDDIR PD1:<MISC.VAXVMS>*.* 9999 --Lists VAX/VMS related files.
    /PDDIR PD2:<CPM>UUDECODE*.* 9999 --Lists uudecode software for CP/M.

*********************
The /PDDIR command. *
*********************
The /PDGET command is used to request specific files.  No pattern-
matching is allowed.  The syntax for this command is as follows:

    /PDGET  format  simtel.filename   ( encoding

The format specifies how the file is to be transmitted.  Allowed
values are NETDATA, PUNCH, and MAIL.

    NETDATA  -- suitable for transfer to Bitnet hosts that can accept
        files in IBM Netdata format.
    PUNCH    -- suitable for transfer to Bitnet hosts that can accept
        files but cannot decode the Netdata format.  Files
        are sent as 80-byte card-images.
    MAIL     -- suitable for transfer to hosts that can accept only
        mail or are accessible to Bitnet only through gateways.
        Large files sent via mail are split into several
        smaller files that the recipient must reassemble.

If the format is omitted, NETDATA is assumed for Bitnet hosts and MAIL
for all others.

The encoding specifies any special translation for the file data:

    ASIS     -- suitable for hosts that can receive binary data.  The
        file is sent exactly as it is stored on the server:
        binary images of the file data.  ASIS may be used
        only with format NETDATA.
    UUENCODE -- suitable for hosts that cannot receive binary data.
        The file is sent uuencoded.
    TRANSLATE -- suitable for any host, but only when the file actually
        represents readable text.  The file is translated to
        EBCDIC.  (If you are on an ASCII machine, then your
        system should automatically translate to ASCII when
        the file arrives.) TRANSLATE applied to a binary file
        will yield trash.

If no encoding is specified, then ASIS is assumed for NETDATA, and
UUENCODE for the others.

*** Note:  Users on non-IBM hosts should remember that with the
       NETDATA/ASIS server defaults, binary data is put on an
       EBCDIC network (viz. Bitnet).  The normal action of most
       non-IBM networking software is to do EBCDIC/ASCII trans-
       lation on incoming data.  This will render most files
       from the server useless.  Non-IBM users should either
       use one of the other encoding options or receive the
       a file without translation.  (Jnet has this capability.)

In each of the following examples the user wants the UUDECODE.HEX and
the UNARC16.ARK file to download to a CP/M micro.

(1)  The user is on an IBM host directly connected to Bitnet:
      /PDGET  NETDATA  PD2:<CPM.STARTER-KIT>UUDECODE.HEX (TRANSLATE
      /PDGET  NETDATA  PD2:<CPM.ARC-LBR>UNARC16.ARK

(2)  The user is on a non-IBM host directly connected to Bitnet and can
     receive Netdata files, but not binary:
      /PDGET  NETDATA  PD2:<CPM.STARTER-KIT>UUDECODE.HEX (TRANSLATE
      /PDGET  NETDATA  PD2:<CPM.ARC-LBR>UNARC16.ARK  (UUE

(3)  The user is on some host somewhere:
      /PDGET  MAIL  PD2:<CPM.STARTER-KIT>UUDECODE.HEX (TRANSLATE
      /PDGET  MAIL  PD2:<CPM.ARC-LBR>UNARC16.ARK  (UUE

*********************
Additional remarks: *
*********************
(1)  If the server is unable to satisfy a request for a file from
     Simtel20 in three days, the request is rejected.

(2)  The server limits /PDGET and /PDDIR request by number and by size.
     The limits are adjusted periodically to regulate network load.

(3)  The server refreshes its directory listings of files at Simtel20
     about every two days.  Therefore, there is a window during which
     requests for recently deleted files are accepted by the server
     and requests for recently added files are rejected.

(4)  The server is EXPERIMENTAL.  It is supported on an as-time-is-
     available, best-efforts basis.

(5)  The primary mission of the server is to support the Info-CPM
     community on Bitnet.  General availability will continue as
     long as that mission is not compromised, and as long as disk
     space, system load, and network load are not a problem.

(6)  Problems regarding the service should be sent directly to
     FISHER@RPICICGE, and not to anyone at Simtel20 or its associated
     interest groups.

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

Date: 4 Jan 89 17:42:41 GMT
From: hpda!hpcupt1![e-mail]  (Andrew Valencia(Seattle))
Subject: mail gateway(s) ?

/ hpcupt1:rec.ham-radio.packet / [e-mail] (Mark Silbernagel) /  5:18 pm  Jan  3, 1989 /

>       Question? Is there an established link for mail between the
>       various nets (reachable via UUCP, ARPA, Bitnet, etc) and a
>       packet mailbox such as ELN node N7HHU or ALW node WA7EAQ ?

    Yup, I set one up.  You have to get mail to a UUCP site, though,
so bang-pathing is the most convenient.  Just mail to:

    ...!hplabs!hpda!baltor!wb6rru!<packet-bbs>!<call>

    Although the gateway will actually translate all of the various
addressing forms in common use, I've found it much easier to just tell
people to use this form.  "baltor" and "wb6rru" are the same machine, but
queueing to "wb6rru" puts the mail into the UUCP spool directory where
the packet mailer can then filch it.

    Mail in the other direction is less convenient, as all W0RLI-based
mailers seem inclined to truncate all addresses to a "call @ call" format.
To send mail in this direction, mail to "uucp @ wb6rru", and include a line
like:

To: hpda!<mail address>

    in the body of the message.  The mailer will then rewrite the
message and send it on its way.

            73s... Andy WB6RRU

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

Date: Thu, 05 Jan 89 10:44:39 MEZ
From: [e-mail]
Subject: TheNet 1.0 user manual available

            NORD><LINK
   The northern Germany packet-radio development group

Ever again some requests for info about the TheNet usage dropped in here.
So it took some expense to answer to all the questions.

But here are some good news:

There is an english version of TheNet user manual available right now.
It was translated from the german version which is available for nearly
one year right now.

I'll forward the file to Don ( K4NGC ) in one of the next days.
So everyone could download the manual from his BBS and redistribute it.

Furthermore I intent to bring it to SIMTEL20 somehow but I'm in trouble
to access SIMTEL since sometime. My access is denied and I'm only
informed to access my nearest server in Germany. Havn't found out yet
how the german server could forward my files to SIMTEL or what files
are available at SIMTEL.

So if you're interested in the doc and havn't found it yet please keep
in patience, it will be available pretty soon.

p.s.: we're still interested in a C-compiler that runs on IBM-PCs
(clones) and produces 6809-code. Anyone any idea ?
Should not be too expensive!


73s de Detlef ( DK4EG @ DK0MAV )

Detlef J.Schmidt
C0033003 at dbstu1.bitnet
 [e-mail]
 [e-mail]")
 [e-mail]
 CUNYVM.CUNY.EDU![e-mail]
etc...
.

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

End of PACKET-RADIO Digest
******************************
 7-Jan-89 01:52:33-MST,5390;000000000000
Return-Path: <[e-mail]>
Date: Sat,  7 Jan 89 01:30:58 MST
From: [e-mail]
Reply-To: [e-mail]
Subject: PACKET-RADIO Digest V89 #5
To: [e-mail]

PACKET-RADIO Digest         Sat,  7 Jan 89       Volume 89 : Issue   5

Today's Topics:
              Ciphers and stuff (2 msgs)
        Trailblazer Wormholes; What happened?
----------------------------------------------------------------------

Date: 4 Jan 89 19:38:00 GMT
From: asuvax!stjhmc!f1.n234.z1.fidonet.org![e-mail]  (Jim Grubs)
Subject: Ciphers and stuff

 > From: [e-mail] (Phil Karn)
 > Date: 3 Jan 89 00:01:34 GMT
 > Organization: Home for Burned-out Hackers
 > Message-ID: <[e-mail]>
 > Newsgroups: rec.ham-radio.packet
 >
 > Yes, it was I who proposed the use of encryption techniques for
 > authenticating a message as opposed to hiding its contents. As far as I
 > can
 > tell, this is perfectly legal.


Yes, and if memory serves, the FCC even encourages encrypted authenticaation
for things like repeater control links.


--
St. Joseph's Hospital/Medical Center - Usenet <=> FidoNet Gateway
Uucp: ...{gatech,ames,rutgers}!ncar!noao!asuvax!stjhmc!234!1!Jim.Grubs
Internet: [e-mail]

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

Date: 4 Jan 89 21:06:58 GMT
From: mcvax!hp4nl!philmds!nlgvax![e-mail]  (Geert Jan de Groot)
Subject: Ciphers and stuff

In article <[e-mail]> [e-mail] (Jim Grubs) writes:
>In article <[e-mail]> [e-mail] (Geert Jan de Groot) writes:
>
>>In article <[e-mail]> [e-mail] (Mike Waters) writes:
>>>
>>> ... authentication of
>>>a remote user on any link is tough, radio is harder and the restrictions
>>>about no encryption etc. on ham radio make it even tougher.
>>>
>>>About the only thing that comes to mind as simple, universal, and legal
>>>is a form of "one time pad". That is station A sends station B list of some
>>>kind
>>>by other means (normal mail should work for our purposes) which contains
>>>say dates and random numbers for each date. When station A connects
>>>it sends the appropriate code number for the day and station B verifies it.
>
>>In Holland, we have had such problems some time ago. People tried to log in
>>with the call of the BBS, became remote sysop and removed essential files
>>(like mail index files). After 2 hits in one month, we decided that remote
>>sysop is *DANGEROUS* and should no longer be used.
>
>Wasn't it Phil Karn who made the point a year or two ago that even although
>encryption of message content was illegal, encryption of connect ID
>verification was not????

And Phil writes..

>Yes, it was I who proposed the use of encryption techniques for
>authenticating a message as opposed to hiding its contents. As far as I can
>tell, this is perfectly legal.

The Dutch regulations do explicitly disallow encrypted information.
That is why my method uses random patterns (i.e. noise, no information)
as basis. This is questionable, but I have not received questions about
that (yet?) and I *know* they have monitored me (when I spoke somebody
at a monitor station, he knew me by call..).

Back to the main point. Yes, I have read Phil's paper about authentication.
I should have given credit to Phil and apoplogise for not have done so.

However, Phil's method is based on TCP/IP, and unfortunately, current
BBS software is based on AX.25 only, not TCP/IP. That is why Phil's
method is not usable here, and I had to find another method. Also,
my method can be used with the same basic equipment which is used to
access a BBS, and does not need special TNC software. Unfortunate
people with only AX.25 level 2 equipment (i.e. digicom or plain TNC)
can use it. That is what makes it different with Phil's approach.

Unfortunately, an average PR station is not able to work with TCP/IP
yet. That is why we have to stick to the old AX.25 level 2 techniques.
I would like to know about software which can be accessed both with
plain AX.25 and TCP/IP (say SMTP/NNTP/POP?). It would be great if it
is compatible with the RLI protocol, because this can form a migration
path upwards to general usage of TCP/IP. Comments?

73
Geert Jan PE1HZG
.

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

Date: 6 Jan 89 19:55:09 GMT
From: bbn.com![e-mail]  (Bob Clements)
Subject: Trailblazer Wormholes; What happened?

A while ago someone posted a message suggesting that the packet
network could benefit from people using trailblazers or other
fast dialup links to move blocks of messages around the
country.  I have since lost the message -- sorry.  I don't
remember any followups.  Did anything come of this?

I have a TB+ on my home machine (Boston area), but no
cheap/freebie phone service to support a regular schedule of
packet mail.  If someone wanted to call me, though, I might be
interested in helping out. (Assuming we can come up with
the right software package -- maybe SLIP and KA9Q with some
sort of W0RLI/SMTP gateway.)

73,
Bob, K1BC
[e-mail]

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

End of PACKET-RADIO Digest
******************************
 8-Jan-89 01:54:17-MST,5168;000000000000
Return-Path: <[e-mail]>
Date: Sun,  8 Jan 89 01:30:43 MST
From: [e-mail]
Reply-To: [e-mail]
Subject: PACKET-RADIO Digest V89 #6
To: [e-mail]

PACKET-RADIO Digest         Sun,  8 Jan 89       Volume 89 : Issue   6

Today's Topics:
                  Atari KISS
              KISS in TAPR 1.1.6
        Looking for 'anwering machine' software for PC
          Need Apple II+ software for PK-232
              Postings...please, go on!
                TheBox
----------------------------------------------------------------------

Date: 4 Jan 89 19:26:00 GMT
From: aim.dec.com![e-mail]  (fred, k1io@FN42jk, [phone])
Subject: Atari KISS

Doug Collinge asks about using the Atari ST for packet, and a bare
modem board such as is available for the C64.

Not exactly.  The ST does not have hardware support for HDLC built in,
and it would not really be feasible to do fake HDLC in its serial line
chip (68910).  Since most packet activity uses HDLC (not really a good
idea, but not germaine to this discussion...), the ST needs hardware
help.  A TNC is thus needed.  (Unlike PCs, though, the standard ST
hardware does support non-HDLC sync comms, so a byte-oriented sync
protocol could be run on it.)

The KA9Q TCP/IP package also has been ported to the ST, using a KISS
TNC.  Version 871225.33 is now available for anonymous ftp from
TOMCAT.GSFC.NASA.GOV (that may be temporary) as NET33_ST.ARC.
    fred k1io

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

Date: 6 Jan 89 11:09:02 GMT
From: mcvax!enea!kth!osiris!sics.se![e-mail]  (Anders Klemets)
Subject: KISS in TAPR 1.1.6

There is a person here in Stockholm who is complaining about that he
cannot leave KISS mode using the TAPR 1.1.6 EPROM.
Issuing "param ax0 255" to NET doesn't work.

I have been asking him why on earth anybody would leave KISS, except
by pure accident, but he doesn't pay attention...

Is there anybody who knows how it can be done?

73's Anders SM0RGV
[e-mail]

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

Date: 4 Jan 89 15:57:36 GMT
From: nic.MR.NET!gonzo.eta.com![e-mail]  (Chris Elmquist)
Subject: Looking for 'anwering machine' software for PC

Is there a piece of code out there that implements a simple answering
machine type of BBS on a PC with connected TNC-2 ?  I don't need a
full blown PBBS, just something that will take a text (or maybe even
binary file) that some connectee drops off and write it to disk.

I could write it myself...but I've gotta believe it's been done
already!

Also, where does one go for documentation on 'HOST' and 'KISS' modes
of TNC-2 type boxes?  I have a PK-87, and there is nothing mentioned
other than how to enable those modes, in the included user guide.

TNX and 73 de Chris  N0JCF

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

Date: 4 Jan 89 17:10:05 GMT
From: rochester!kodak!ektools![e-mail]  (Andrew A. Kinsman)
Subject: Need Apple II+ software for PK-232

    I've got an Apple II+ system that keeps on ticking, and
    would like to use it on packet to control a PK-232.  Does
    anybody have shareware available for this computer?

\___                 ___|___
Andy\__   --------------|--------------
Kinsman\_____
5441 Holtz Rd\_____                             NOFUEL on the Hill
Palmyra, N.Y. 14522\___
----->N2HZK/AG<--------\_______________  still /AG  arg!
rutgers!rochester!kodak!ektools!kinsman\______________________
Eastman Kodak Co., Rochester, N.Y. "Little Yellow Box Factory"\

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

Date: 6 Jan 89 17:52:54 GMT
From: portal!cup.portal.com![e-mail]
Subject: Postings...please, go on!

    I appreciate your postings a great deal!  Thanx for keeping up with
all the changing name and sources.  I look forward to your continuing
contributions.
                73,    de KB6FVA

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

Date: 4 Jan 89 09:57:14 GMT
From: van-bc![e-mail]  (Samuel Lam)
Subject: TheBox

Could anyone who has successfully installed a copy of TheBox
recently give us a hand here?

My club was tring to install TheBox on our Turbo XT tonight, and
after we edited the appropriate configuration files and started the
program up, it just went into a loop trying to "re-synchronize", and
then eventually gave up and printed an "hostmode crashed" message
on the screen and exited.

Not being German readers ourself, and therefore not being able to
read the comments in the configuration files, we must have missed
something obvious.  Could anyone tell us what that is?

We do have the English version of the documentation, but there
isn't a step by step installation guide in there.  Is there one
in the German version?

Thanks in advance for any help.

...Sam
--
Samuel Lam     {alberta,watmath,uw-beaver,cs.ubc.ca}!ubc-cs!van-bc!skl

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

End of PACKET-RADIO Digest
******************************
 9-Jan-89 01:43:08-MST,1737;000000000000
Return-Path: <[e-mail]>
Date: Mon,  9 Jan 89 01:30:32 MST
From: [e-mail]
Reply-To: [e-mail]
Subject: PACKET-RADIO Digest V89 #7
To: [e-mail]

PACKET-RADIO Digest         Mon,  9 Jan 89       Volume 89 : Issue   7

Today's Topics:
             FT-23R use for packet radio
             MS-DOS software for MFJ-1278
----------------------------------------------------------------------

Date: Sunday, 8 January 1989  08:01-MST
From: [e-mail]
Subject: FT-23R use for packet radio

A quick question.  Can anyone tell me how they found the FT-23R in
relation to packet radio?

thanks

Patrick Millar

York University
Toronto

Bitnet: AK200065@YUGEMINI

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

Date: 9 Jan 89 00:25:26 GMT
From: wa3wbu![e-mail]  (John Gayman)
Subject: MS-DOS software for MFJ-1278

   Not long ago someone posted some information about a software
package which was available for the MFJ-1278. I beleive it was available
free for a mailer. A freind just obtained a 1278 and is a complete
novice to packet et al. Such a program would be a big help to him in
the beginning. If anyone saved the file containing the call and/or
address, could you please Email me.  Thanks!


                    73, John


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

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

End of PACKET-RADIO Digest
******************************
10-Jan-89 01:45:57-MST,7247;000000000000
Return-Path: <[e-mail]>
Date: Tue, 10 Jan 89 01:31:20 MST
From: [e-mail]
Reply-To: [e-mail]
Subject: PACKET-RADIO Digest V89 #8
To: [e-mail]

PACKET-RADIO Digest         Tue, 10 Jan 89       Volume 89 : Issue   8

Today's Topics:
              Ciphers and stuff
         Connectivity program, does it exist?
            Installing NORD><LINKs TheBox
        Looking for 'anwering machine' software for PC
----------------------------------------------------------------------

Date: 9 Jan 89 19:06:56 GMT
From: [e-mail]  (news)
Subject: Ciphers and stuff

>The Dutch regulations do explicitly disallow encrypted information.

So do the US regulations.  However I interpret this as allowing the
transmission of encrypted information as long as the plaintext of the same
information is also transmitted. Nothing is hidden. This is how my
authentication scheme works.

>That is why my method uses random patterns (i.e. noise, no information)
>as basis.

Strictly speaking, there is no way you can tell the difference between truly
random data that contains no information, and seemingly "random" data that
is in fact encrypted, useful information. To tell the difference you have to
be able to decrypt the data, either by having the key or by cracking the
encryption scheme. This is a fairly fundamental principle of cryptography.

Having said that, you should be prepared to answer the government inspector
when he challenges you to *PROVE* that the squelch tails on your repeater
are not bursts of encrypted data... :-)

>However, Phil's method is based on TCP/IP...

Actually, the general method I described is applicable to any datagram
oriented protocol, not just TCP/IP. In fact, I believe you pretty much
*have* to use a robust datagram-oriented protocol (at some level) in order
for an authentication scheme to be completely secure against "playback"
attacks.  Unfortunately, the LAPB sublayer in AX.25 just doesn't qualify as
"robust".

You can still gain a modicum of security by a session-based challenge/
response scheme I've implemented for UNIX.  This will work with plain
vanilla AX.25. Send the user the time-of-day when he connects, and challenge
him to encrypt and return it. The constantly-changing challenge prevents
someone else from re-using the response. This scheme has come in handy a few
times when I wanted to log into my Sun without typing my UNIX password all
over two meters. I'm thinking of building this scheme into Telnet as a
negotiated option.

However, this scheme is still vulnerable to someone "taking over" the
connection after you've authenticated it.  Of course, since you are active
you are more likely to detect this, but depending on what he does it might
be too late...

Phil

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

Date: 9 Jan 89 17:57:26 GMT
From: rochester!kodak!ektools![e-mail]  (Andrew A. Kinsman)
Subject: Connectivity program, does it exist?

    Does anybody have a package of software which monitors the headerlines
and builds a connectivity tree for stations within range of my packet station?
A program like this would provide interesting information on routing,and the
times when particular routes are available.  Surely it must already exist?
-AAK
\___                 ___|___
Andy\__   --------------|--------------
Kinsman\_____
5441 Holtz Rd\_____                             NOFUEL on the Hill
Palmyra, N.Y. 14522\___
----->N2HZK/AG<--------\__________________
rutgers!rochester!kodak!ektools!kinsman\______________________
Eastman Kodak Co., Rochester, N.Y. "Little Yellow Box Factory"\

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

Date: Mon, 09 Jan 89 10:11:58 MEZ
From: [e-mail]
Subject: Installing NORD><LINKs TheBox

On
>Date: 4 Jan 89 09:57:14 GMT
>From: van-bc][e-mail]  (Samuel Lam)
writes

...
>My club was tring to install TheBox on our Turbo XT tonight, and
>after we edited the appropriate configuration files and started the
>program up, it just went into a loop trying to "re-synchronize", and
>then eventually gave up and printed an "hostmode crashed" message
>on the screen and exited.
.....
>Samuel Lam   {alberta,watmath,uw-beaver,cs.ubc.ca}!ubc-cs!van-bc!skl

( sorry, couldn't find that path backward here from BITNET, so I post
my response)

Are you shure you've got the right HOSTMODE firmware installed?
To take full advantage of all TheBox features you should install the
expanded HOSTMODE firmware ( by DC4OX of NORD><LINK )  in your TNC2.
This should be included on the BBS distribution floppy named TF4 for the
4channel version, TF8 for the firmware for an 8-channel PBBS version
and up to 16 channels.
TheFirmware was written for TNC2s a la TAPR, so it wouldn't work in
a (e.g.) TNC220 or other TNCs of different hardware configuration.

Do you get any response from your TNC? Just check it too.

Good luck !

If that still failes you might ask the author of TheBox Reinhard (DF3AV)
here at [e-mail]. He's sometimes around here and I'm
shure he will answer to your problem ( if there is an e-mail path back
to you ).

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

73s de Detlef ( DK4EG )

#include <disclaimer.std>

 NORD><LINK
 Detlef J. Schmidt                [phone]
 DK4EG @ DK0MAV


C0033003 at dbstu1.bitnet
 [e-mail]
 [e-mail]")
 [e-mail]
 CUNYVM.CUNY.EDU![e-mail]
etc...
.

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

Date: 9 Jan 89 14:29:56 GMT
From: encore!necis![e-mail]  (Rich Bono)
Subject: Looking for 'anwering machine' software for PC

In article <[e-mail]>, [e-mail] (Chris Elmquist) writes:
> Is there a piece of code out there that implements a simple answering
> machine type of BBS on a PC with connected TNC-2 ?  I don't need a
> full blown PBBS, just something that will take a text (or maybe even
> binary file) that some connectee drops off and write it to disk.
>

    DOSGATE is a generic interface between the PC and the TNC...
It will start any (or come into a running program) when a user connects.
I have inlcuded a SIMPLE non-forwarding mail system as just one example.

    The DOSGATE distribution was posted here on rec.ham-radio.packet
not too long ago...

    Has ANYONE got a DOSGATE system up yet?  I have heard of one,
but it is being used between a telephone-modem and a PC to allow one
to check in at work from home....  Any other Packet implemenations?


                Rich

--
 /**************************************************************************\
 * Rich Bono (NM1D)    If I could only 'C' forever!!    [e-mail] *
 * [phone]         NEC Information Systems       NM1D @ WB1DSW-1     *
 \**************************************************************************/

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

End of PACKET-RADIO Digest
******************************
11-Jan-89 01:49:07-MST,9238;000000000000
Return-Path: <[e-mail]>
Date: Wed, 11 Jan 89 01:30:50 MST
From: [e-mail]
Reply-To: [e-mail]
Subject: PACKET-RADIO Digest V89 #9
To: [e-mail]

PACKET-RADIO Digest         Wed, 11 Jan 89       Volume 89 : Issue   9

Today's Topics:
              Ciphers and stuff (3 msgs)
              Multiplayer games?
            Packet <-> UUCP Gateway Info 2
         Wanted: EEMS boards for 4XNET PBBSes
----------------------------------------------------------------------

Date: 10 Jan 89 05:06:10 GMT
From: emcard!stiatl![e-mail]  (John DeArmond)
Subject: Ciphers and stuff

Phil:

This is only obliquely related to your authentication scheme but
I've been wanting to ask this question of an expert for quit some
time.

What is the cryptographic effect of compressing a data stream, say
with "compress" before encrypting it.  It would appear at first
glance to make the ecryption more secure because of the increased
entropy of the "cleartext" stream.  Is this first glance accurate?

73 john

--
John De Armond, WD4OQC                     | "I can't drive 85!"
Sales Technologies, Inc.    Atlanta, GA    | Sammy Hagar driving
...!gatech!stiatl!john                     | thru Atlanta!

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

Date: 10 Jan 89 19:57:27 GMT
From: ka9q.bellcore.com![e-mail]  (Phil Karn)
Subject: Ciphers and stuff

Ever since Shannon, compression before encryption has been known to be a
Good Thing.  It does indeed make it considerably harder to do a
ciphertext-only cryptanalysis, since the increased entropy of the plaintext
makes it harder to know when you've hit on the right key. It also reduces
the amount of information you have to encrypt, a considerable advantage when
running DES in software!

Having said that, I should point out that most compression programs place
well-known "magic numbers" in front of the compressed output, and this
constitutes a partially-known "plaintext" for the cryptanalyst. However, if
your cipher is resistant to known-plaintext attacks (like DES apparently is)
this isn't much of a real problem. Also, if your block size is 8 bytes (as
in DES) and the magic number is, say, 2 bytes, there will be a lot of
"garbage" plaintext blocks that all have the correct magic number in the
first two bytes -- 2^48 - 1 of them.  One way to remove even this small
vulnerability is to precede your plaintext with a block or two of random
data that is stripped off by the receiver after decryption but before
decompression. (This assumes you are using cipher block chaining, of
course).

Phil

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

Date: 10 Jan 89 19:04:07 GMT
From: m2c!ulowell!tegra![e-mail]  (Johnathan Vail)
Subject: Ciphers and stuff

I must be missing something.  Maybe someone could enlighten me and
perhaps others.

What is the purpose of encryption or validation in *amateur* packet?

Who is "attacking"?  I guess I have heard of people cracking the PL on
repeaters (real tough) and playing "touch tone charlie" to figure out
things.  It seems to me that there are easier ways to do evil on the
airwaves than cracking a packet link.

I feel this is a hobby and shouldn't need any special safeguards.
Amateur Radio is a lot more of a hacker utopia than the real world and
I don't feel comfortable  adding more paranoia to it.

"History is made at night.  Character is what you are in the dark!"
  - Dr. Lizardo, "Buckaroo Banzai"
 _____
|     | Johnathan Vail  | tegra![e-mail]
|Tegra| [phone]  | N1DXG @ 145.110-, 444.2+, 448.625-
 -----

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

Date: 10 Jan 89 23:38:21 GMT
From: ubvax!igor![e-mail]  (David S. Bakin)
Subject: Multiplayer games?

Has anybody worked on multiplayer games using packet techniques?  I'm thinking
of high-speed real time simulation games utilizing the broadcast nature of
radio to take the place of a highly-connected wired network -- a situation
where using modems & phones won't work.  Interesting problems (besides the
game itself, of course) would be the fact that game participants might not
be able to hear all participants, so the network would be highly connected
but not fully connected;  the bandwidth problem;  missed updates;  effective
use of local computing;  and protocols for joining and leaving a game in
progress; and doing the above without a central repeater (which would
differentiate this work from the Aloha network, for example).

Please send me any information on existing, or in-progress, or planned
work, or even if you're just interested.

Thanks  -- Dave   AA6EH

----------------------------------------------------------
Dave Bakin                                  [phone]
c/o Rational; 3320 Scott Blvd.; Santa Clara, CA 95054-3197
Internet:  [e-mail]      Uucp:  ...!uunet!igor!dsb
                ...!{elxsi|sun}!aeras!igor!dsb
----------------------------------------------------------
Dave Bakin                                  [phone]
c/o Rational; 3320 Scott Blvd.; Santa Clara, CA 95054-3197
Internet:  [e-mail]      Uucp:  ...!uunet!igor!dsb

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

Date: 10 Jan 89 17:04:47 GMT
From: hpda!hpcupt1![e-mail]  (Andrew Valencia(Seattle))
Subject: Packet <-> UUCP Gateway Info 2

Here's an update on the packet <-> UUCP gateway, and answers to questions
which have been asked more than once:

1. Is it automatic?
    No, all traffic in both directions is queued until I manually
approve it.  I have a utility which scans for questionable words in
the messages (its database was built once drunken night, but that's
another story...) to help me identify any problems.  So far, all traffic
has been fine.

2. Does it understand hierarchical addressing?
    Yes.  In fact, if the BBS destination could be expressed
in hierarchical notation it helps me, as otherwise many hams use
their callsigns as UUCP node names, too.  Then I have to manually break
the tie between possible destinations--so far it has always been in
favor of the packet route.

3. What's it running on?  Can I get it?
    It runs under either Microport UNIX or SCO XENIX.  It's really
a normal packet BBS, with additional functionality in the mail header
decoding code.  It's also multi-user/multi-connect, but current packet
repeater configurations in Santa Clara Valley make it pretty unrewarding
to try and run even a few channels at a time.
    I provide source to interested hams.  I maintain copyright so that
various terms can be enforced, but I don't think these terms will bother
any ham who wants to run a board.  If they do, then I'm willing to talk!

******
Now for the update:

    A bunch of mail came through after I re-announced its availability
lately.  Most of this went on its way fine.  Last night I was trying to bring
up HDB UUCP and accidentally blew away seven mail messages in the UUCP to
packet direction (actually, rmail truncated their body, threw out the return
address, THEN reported the problem to me.  Bleh.  This was Microport's
rmail; SCO's software in general and mailer in particular are far superior).

    Otherwise (ha! ha!) the system is working fine.  For the packet to
UUCP direction, please try to express your destination in terms of a place
that an Internet site can reach.  I had some mail for for an obscure
.COM destination which none of my systems had heard about.  If worst comes
to worst, express the path explicitly all the way through.

            Thanks and 73s...
            Andy WB6RRU
            [e-mail]

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

Date: 10 Jan 89 13:43:58 GMT
From: [e-mail] (Ofer Lapid (4X6OJ))
Subject: Wanted: EEMS boards for 4XNET PBBSes

Hello friends,

We are having a rough time trying to buy some EEMS boards in order to
upgrade our XT based PBBSes to newer software versions. (As you must
know, newer versions are never smaller then earlier ones).

We tried the AST RamPage + but it didn't work so well with our clones
and it forgot it's setup after an hour. The AST dealer had took the
and said he would never get these again (after trying to fix them three
times over).

There is no other dealer in here who sells real EEMS or real LIM 4.0 and
we must have the real one in order to use the multitasking feature of
DesqView 2.0 .

Please, if you know of a dealer who sells such a board (with dip-switch
setting - not FlashRom) for the XT, without memory chips, at a
reasonable cost. Please let me know. Our whole process of upgrading the
network is stopped because of these boards.

Many 73s and thank you for reading, Ofer 4X6OJ.
--
Ofer Lapid 4X6OJ                             AX.25: 4X6OJ@4X4HF
P.O.Box 623                                  IP: [44.138.40.04]
Kiriat Bialik 27000,Israel.                  Pho:  972-4-721257
E-Mail: Now: [e-mail]  Usually: [e-mail]

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

End of PACKET-RADIO Digest
******************************
12-Jan-89 01:55:49-MST,4630;000000000000
Return-Path: <[e-mail]>
Date: Thu, 12 Jan 89 01:31:14 MST
From: [e-mail]
Reply-To: [e-mail]
Subject: PACKET-RADIO Digest V89 #10
To: [e-mail]

PACKET-RADIO Digest         Thu, 12 Jan 89       Volume 89 : Issue  10

Today's Topics:
              Ciphers and stuff (2 msgs)
         Connectivity program, does it exist?
----------------------------------------------------------------------

Date: 11 Jan 89 16:47:01 GMT
From: agate!pasteur!cad.Berkeley.EDU![e-mail]  (EDIF Committee)
Subject: Ciphers and stuff

In article <[e-mail]> [e-mail] (Johnathan Vail) writes:

>What is the purpose of encryption or validation in *amateur* packet?

I guess I started it all by proposing a solution to a problem posted
by the operator of an international packet link (in Israel I think).
I own up to ignorance (lazyness?) in that I did not know about Phil's
paper when I proposed my solution.

The problem was that someone would log on as a regular mail forwarder
and send bogus messages or delete messages. The requirement is for
authentication (are you who you say you are?) rather than encryption
which makes it (a) reasonable and (b) probably legal for ham radio.

Phil's scheme seems to be the appropriate one to use, although the sensitive
nature of international amateur communications could still be a problem.
It is easy to forget that many countries consider a ham to be a spy until
proven otherwise and even then they are doubtful. I suspect that any scheme
of authentication will be subject to the same paranoia.

I recall though that some time ago the FCC (U.S. again) published a "position
paper" or some such to the effect that if certain rules were followed then
a "code" (e.g. Manchester) would not be considered a "cypher". Codes are
clearly legal while cyphers are not.

Perhaps some formal scheme of either filing authentication keys with the
appropriate authorities or having the keys available in a log at both
ends would be the solution even for international communications.

A challenge/response involving the current time as Phil suggested in another
post here would seem to "fill the bill" very well. I find it hard to see
how even the most paranoid of governments could object to encrypting the time
of day with a cypher that they (the government) posess.

Mike Waters    AA4MW/7                  *
Motorola CAD Group                      *    Witty remark goes *HERE*
Mesa, AZ   ...!sun!sunburn!dover!waters *
      OR   [e-mail]     *

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

Date: 11 Jan 89 21:15:52 GMT
From: jupiter![e-mail]  (Phil R. Karn)
Subject: Ciphers and stuff

>What is the purpose of encryption or validation in *amateur* packet?

Unfortunately, there is a need for this sort of thing, particularly for
packet switches and network servers that operate under remote control. I
don't want people to be able to delete files and reconfigure systems without
my permission.

With the proper use of authentication, it would also be possible to
eliminate the FCC requirement for a separate control frequency to a remotely
controlled repeater.  The repeater could be configured to require a
timestamped and authenticated "keep alive" message on the regular input from
the control operator every N minutes to stay on the air; jamming the input
would simply cause it to shut down.

Phil

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

Date: 11 Jan 89 16:56:26 GMT
From: pasteur!cad.Berkeley.EDU![e-mail]  (EDIF Committee)
Subject: Connectivity program, does it exist?

In article <[e-mail]> [e-mail] (Andrew A. Kinsman) writes:
>
>       Does anybody have a package of software which monitors the headerlines
>and builds a connectivity tree for stations within range of my packet station?

I wonder if the USENET software such as pathalias would do the trick?
It has almost all of the hooks for path cost, times available etc..
The only problem I can think of is that the connection information would
have to be in the same format as used by the UUCP mapping project.
The source is in C and is public domain.

Mike Waters    AA4MW/7                  *
Motorola CAD Group                      *    Witty remark goes *HERE*
Mesa, AZ   ...!sun!sunburn!dover!waters *
      OR   [e-mail]     *

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

End of PACKET-RADIO Digest
******************************
13-Jan-89 01:47:46-MST,17580;000000000000
Return-Path: <[e-mail]>
Date: Fri, 13 Jan 89 01:30:21 MST
From: [e-mail]
Reply-To: [e-mail]
Subject: PACKET-RADIO Digest V89 #11
To: [e-mail]

PACKET-RADIO Digest         Fri, 13 Jan 89       Volume 89 : Issue  11

Today's Topics:
              Ciphers and stuff (4 msgs)
            FT-727 Packet Interface Wanted
       HOSSTRADERS HAM RADIO FLEAMARKET RETURNS TO DEERFIELD !!
            Kenwood TH-205AT and AEA PK-88
              Multiplayer games?
              Multiplayer games? (LONG)
             Need NODR><LINK user manual
----------------------------------------------------------------------

Date: 12 Jan 89 00:40:28 GMT
From: emcard!stiatl![e-mail]  (John DeArmond)
Subject: Ciphers and stuff

In article <[e-mail]> [e-mail] (Johnathan Vail) writes:
>
>I must be missing something.  Maybe someone could enlighten me and
>perhaps others.
>
>What is the purpose of encryption or validation in *amateur* packet?
>
>Who is "attacking"?  I guess I have heard of people cracking the PL on
>repeaters (real tough) and playing "touch tone charlie" to figure out
>things.  It seems to me that there are easier ways to do evil on the
>airwaves than cracking a packet link.
>
>I feel this is a hobby and shouldn't need any special safeguards.
>Amateur Radio is a lot more of a hacker utopia than the real world and
>I don't feel comfortable  adding more paranoia to it.
>
>"History is made at night.  Character is what you are in the dark!"
>  - Dr. Lizardo, "Buckaroo Banzai"
> _____
>|     | Johnathan Vail  | tegra![e-mail]
>|Tegra| [phone]  | N1DXG @ 145.110-, 444.2+, 448.625-
> -----



John,
I agree with your last parargraph 100%, at least in theory.  The real
world intrudes, as ususal, and changes things.  Let's look at 2
examples I'm personally involved in.  I work for a software development
company and have a consulting business on the side.  My packet station
at home sits on my Novell network.  A large portion of the server is
dedicated to packet radio storage.   Now, Novell has a nice security
system but if I want to log in and work on the system remotely, I have
to have supervisor priviledge.  Thus, my login would be available to
anybody monitoring the channel.  Phil's DES validation whereby the
data packet and it's encrypted analog or some subset thereof is
transmitted over the air solves my problem.  I set up a special account
That I would use only over the air and give it supervisor priviledges.
Then, even though you would see my login and password, you could not
forge it because you would not know my private encryption key.

Similiarly, we are at the office here considering hanging a packet
node off our unix system.  Needless to say, this would not ever be
considered without some kind of secure login.  Actually, for this
application, I'd hardcode permitted paths into the IP code as an
added security provision.

In either case, users have unpassworded logins.  I do not believe ham
radio should be used for "secret" communications, whether they be
encrypted data or coded messages on voice.

Please understand that I do not expect to have any overt attacks on
my systems by hams.  I believe that packet radio enthusiasts are
of better character than that (and experience to date has proven the
theory).  The problem is that even accidents can be fatal when dealing
with confidental data.  All someone would have to do is get my file
containing my client list and I'd be in hot water.  I understand full well
that no security system is 100% secure with any outside links but I
feel that there is adequate security in Phil's scheme.

john



--
John De Armond, WD4OQC                     | "I can't drive 85!"
Sales Technologies, Inc.    Atlanta, GA    | Sammy Hagar driving
...!gatech!stiatl!john                     | thru Atlanta!

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

Date: 12 Jan 89 13:54:47 GMT
From: texbell!sugar!splut![e-mail]  (Jay "you ignorant splut!" Maynard)
Subject: Ciphers and stuff

In article <[e-mail]> [e-mail] (Johnathan Vail) writes:
>What is the purpose of encryption or validation in *amateur* packet?

Weeeeellllllllll...for starters, there's this section in Part 97 that
specifies that control links shall be secured so as to prevent
unauthorized use...

Then there's such things as satellites. How would you feel if someone
took advantage of an unsecured command link to send AO-13 into an orbit
that would make it burn up within days?

>I feel this is a hobby and shouldn't need any special safeguards.
>Amateur Radio is a lot more of a hacker utopia than the real world and
>I don't feel comfortable  adding more paranoia to it.

Lemme guess. You are a Richard Stallman follower. (For the uninformed,
Stallman believes that there should be no security on computer systems;
after all, information belongs to the people! Pfaugh.)
Amateur radio is a service as well as a hobby. Those who wish to provide
central facilities to help this service should be able to protect
themselves from the malicious who want nothing more than to wreak havoc.

--
Jay Maynard, EMT-P, K5ZC, PP-ASEL   | Never ascribe to malice that which can
uucp:        uunet!nuchat!   (eieio)| adequately be explained by stupidity.
    hoptoad!academ!uhnix1!splut!jay +----------------------------------------
{killer,bellcore}!texbell!          | "Sexism is ugly." - Cheryl Stewart

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

Date: 12 Jan 89 22:41:17 GMT
From: elbereth.rutgers.edu!ron.rutgers.edu![e-mail]  (Ron Natalie)
Subject: Ciphers and stuff

> Then there's such things as satellites. How would you feel if someone
> took advantage of an unsecured command link to send AO-13 into an orbit
> that would make it burn up within days?

Yep, and the FCC encourages encryption of satellite telecommand links.

_Ron

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

Date: 9 Jan 89 08:05:41 GMT
From: ka9q.bellcore.com![e-mail]  (Phil Karn)
Subject: Ciphers and stuff

>The Dutch regulations do explicitly disallow encrypted information.

So do the US regulations.  However I interpret this as allowing the
transmission of encrypted information as long as the plaintext of the same
information is also transmitted. Nothing is hidden. This is how my
authentication scheme works.

>That is why my method uses random patterns (i.e. noise, no information)
>as basis.

Strictly speaking, there is no way you can tell the difference between truly
random data that contains no information, and seemingly "random" data that
is in fact encrypted, useful information. To tell the difference you have to
be able to decrypt the data, either by having the key or by cracking the
encryption scheme. This is a fairly fundamental principle of cryptography.

Having said that, you should be prepared to answer the government inspector
when he challenges you to *PROVE* that the squelch tails on your repeater
are not bursts of encrypted data... :-)

>However, Phil's method is based on TCP/IP...

Actually, the general method I described is applicable to any datagram
oriented protocol, not just TCP/IP. In fact, I believe you pretty much
*have* to use a robust datagram-oriented protocol (at some level) in order
for an authentication scheme to be completely secure against "playback"
attacks.  Unfortunately, the LAPB sublayer in AX.25 just doesn't qualify as
"robust".

You can still gain a modicum of security by a session-based challenge/
response scheme I've implemented for UNIX.  This will work with plain
vanilla AX.25. Send the user the time-of-day when he connects, and challenge
him to encrypt and return it. The constantly-changing challenge prevents
someone else from re-using the response. This scheme has come in handy a few
times when I wanted to log into my Sun without typing my UNIX password all
over two meters. I'm thinking of building this scheme into Telnet as a
negotiated option.

However, this scheme is still vulnerable to someone "taking over" the
connection after you've authenticated it.  Of course, since you are active
you are more likely to detect this, but depending on what he does it might
be too late...

Phil

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

Date: 12 Jan 89 05:24:23 GMT
From: att!lznv!lzsc![e-mail]  (M.GOSNELL)
Subject: FT-727 Packet Interface Wanted

I just purchased a Yaesu FT-727 and want to use it for packet when I'm not
using it as an HT.  If you've interfaced this radio (or the FT-209, which
has the same interface) to a TNC, I'd appreciate a note on how to do it.

73's and thanks in advance.
  Marsh Gosnell  AD2H  att!lzma!mkg

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

Date: 10 Jan 89 14:05:13 GMT
From: mirror!rayssd!raybed2![e-mail]  (EUGENE BALINSKI)
Subject: HOSSTRADERS HAM RADIO FLEAMARKET RETURNS TO DEERFIELD !!

    The HOSSTRADERS Ham Radio and Electronics flea market is RETURNING
to the DEERFIELD Fairgrounds, Deerfield, NH. New Date is JUNE 3, 1989.
    Start planning now to attend the largest Ham Radio flea market
in New England. Remember, the BEST deals always go down the night before!
                                  73
                                WA1UXA

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

Date: 12 Jan 89 10:08:00 CST
From: "reed" <[e-mail]>
Subject: Kenwood TH-205AT and AEA PK-88

I'm interested in hearing from anyone who has interfaced a TNC to
the Kenwood TH-205AT HT.  In particular, interfacing the PTT line to
the microphone input.  Please reply by direct mail, if possible.

Thanks and 73,
Reed Christiansen, N9GFG.

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

Date: 12 Jan 89 15:01:05 GMT
From: mirror!necntc!necis![e-mail]  (Rich Bono)
Subject: Multiplayer games?

In article <[e-mail]>, [e-mail] (David S. Bakin) writes:
> Has anybody worked on multiplayer games using packet techniques?  I'm thinking

    [deleted some stuff]


 I thought a *REAL* interesting game for packet would be one that could
evolve as different "players" entered and left the game (connected/disconnected)

Maybe it could be some kind of ongoing adventure/fantasy.... or a science-
fiction type of event...  It sounds like it could be interesting...  My
imagination runs wild thinking of how this could go on for weeks/months...

I have been playing with some multi-connect stuff... just to allow many users
to chat with one-another.... This would be better than a bunch of un-proto
packets flying around with all the collisions...

 The one problem... I think this would be a facinating event for packet
radio... Too many think that packet is *only* good for EMAIL and PBBS stuff..
But I am NOT a game player or a game designer...  Just A guy who admires
interesting algorithms and soloutions to tough problems..

  Any ideas....?

                Rich, NM1D




--
 /**************************************************************************\
 * Rich Bono (NM1D)    If I could only 'C' forever!!    [e-mail] *
 * [phone]         NEC Information Systems       NM1D @ WB1DSW-1     *
 \**************************************************************************/

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

Date: 13 Jan 89 01:24:45 GMT
From: ubvax!igor![e-mail]  (David S. Bakin)
Subject: Multiplayer games? (LONG)

In article <[e-mail]>, rbono@necis (Rich Bono) writes:
>In article <[e-mail]>, [e-mail] (David S. Bakin) writes:
>> Has anybody worked on multiplayer games using packet techniques?  I'm thinking
>       [deleted some stuff]
>
> I thought a *REAL* interesting game for packet would be one that could
>evolve as different "players" entered and left the game (connected/disconnected)

Yes yes, that was also my idea!  A single game "instance" could live
indefinitely, as players joined and left.  As long as there was connectivity
of some order between all the players (again, total connectivity not
necessary).  (Or maybe the game "instance" could survive partitioning and then
reconnecting.  I suppose it would depend on the game.)

For example, on the old CDC Plato computer-based educational system there was
a multi-player "flight simulator" where everyone could join a team and take
off and land a fighter from the team's airfield.  Then, once in the air, you
could fly around and find out who else was flying around and engage them in
dogfights (if opponents) or training (if on the same team).  You left when
you felt like it (or when you were shot down, or when you had to give the
terminal up :-)).  Scores were cumulative over some length of time.

>  Any ideas....?
>
>                               Rich, NM1D

I liked your suggestion about an adventure game.  It would be neat to go
roaming around in a "dungeon" or "cave" or whatever and not know whether
the monsters you bumped up against were "androids" run by the computer
or "animated" by real players.  In a battle you could have a lot of fun
because the "monster" would be fighting/hiding/etc under control of another
person, not just a random number generator.

Another idea would be an adventure game where instead of each person out
for himself, players were organized in teams and some or all of the puzzles
would require team effort to solve.  Not just because of difficulty, but
because more than one thing would have to happen at once and in cooperation
in order to make progress.  I think that the whole arena of team games could
be explored if the base technology existed that would make teams practical.
I mean right now, everyone in some building of some networked company could
get together after work and play some game, sitting in front of the PC
in their cubicle, but who does it?  Ham radio would provide a great way to
run this sort of game.

I have received 2 other responses by e-mail.  One ham indicated he has played
normal 1-player games over packet.  Another ham indicated he has setup a
multi-player game of unspecified variety, but individual players connect to
the central node (which does all the processing) either directly or by
digipeating or via network nodes.  I guess the kind of game I was thinking of
would involve more distributed processing and communication protocols.  The
distributed processing would be so that the power of each player's PC could be
used to full advantage.  The communication protocols would be so that the
ability of the radio medium to support broadcast messages could be used to the
fullest extent, even though not all players could hear all other players.
(Interesting note:  Both of these responses were not from the U.S.of A.  Names
withheld because it was E-mail and I wasn't sure if they wanted everyone to
know.  (Or were they just saving net bandwidth, and here I'm squandering
it freely??))

Again, the multi-player fighter war would be a good example of the power
of the technique.  In the first place, whatever fancy graphics and other
user interface you desired could be done -- because it could all be
generated locally using the computer on the player's desk and none of it
would be transmitted from a central node.  Instead, only position updates
and status updates (missle fired, player joining, etc.) would be broadcast
and each computer would do its own simulation of the airspace and objects
therein.  (With some sort of occasional checkpointing to keep in sync.)
The communication problem has certainly been studying in the computer
science milieu, an existing solution could be used/adapted.

I should admit right now that I'm not currently active in packet.  (In fact,
to be honest, I'm not currently active except for an 2m HT in the glove
compartment.)  But developing this sort of thing could be my motivation for
becoming active on packet.  And there's a lapsed ham here where I work who
would "reenlist" if something of this sort got cooking.  To this end, if I get
enough E-mailed interest I'd be happy to set up a mailing list so that we
could make something a reality.

-- Dave  AA6EH

----------------------------------------------------------
Dave Bakin                                  [phone]
c/o Rational; 3320 Scott Blvd.; Santa Clara, CA 95054-3197
Internet:  [e-mail]      Uucp:  ...!uunet!igor!dsb

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

Date: 12 Jan 89 17:45:14 GMT
From: rochester!kodak!ektools![e-mail]  (Andrew A. Kinsman)
Subject: Need NODR><LINK user manual

    Does anybody have a copy of the NODR><LINK Thenet USER
    MANUAL AND OPERATIONS MANUAL.  It is available on a BBS
    service at 703-680-5970, file section #18, "Net.Doc".
    Anybody in Virginia like to assist?  A local packet group
    is looking for this manual.  Thanks.  73, -AAK

\___                 ___|___
Andy\__   --------------|--------------
Kinsman\_____
5441 Holtz Rd\_____                             NOFUEL on the Hill
Palmyra, N.Y. 14522\___
----->N2HZK/AG<--------\__________________ still!
rutgers!rochester!kodak!ektools!kinsman\______________________
Eastman Kodak Co., Rochester, N.Y. "Little Yellow Box Factory"\

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

End of PACKET-RADIO Digest
******************************
14-Jan-89 01:56:50-MST,10383;000000000000
Return-Path: <[e-mail]>
Date: Sat, 14 Jan 89 01:30:58 MST
From: [e-mail]
Reply-To: [e-mail]
Subject: PACKET-RADIO Digest V89 #12
To: [e-mail]

PACKET-RADIO Digest         Sat, 14 Jan 89       Volume 89 : Issue  12

Today's Topics:
               Amateur Radio's future?
              Ciphers and stuff
         Ham licensing mailing list is ready
              Multiplayer games?
       Richard Stallman ?? (was Re: Ciphers and stuff) (2 msgs)
----------------------------------------------------------------------

Date: 11 Jan 89 17:59:48 GMT
From: hpda!hpcuhb!hpcilzb!hpcea!hpnmdla![e-mail]  (Glenn Elmore)
Subject: Amateur Radio's future?

    I see in the  January 9 issue of EE times that a New Jersey  compnay
is coming out with a spread spectrum communications system.  The article
talks about how great it is, being less  susceptible to qrm etc etc.  It
goes on to  suggest  how  this  may be used to  eliminate  miles of wire
otherwise  necessary  to  control  home  electronics.  But  what  really
bothers  me is the  frequencies  selected  for  this 1W  output  device;
902-928 MHz, 2.4 to 2.4835 GHz and 5.725 to 5.85 GHZ!

   Can anyone  imagine  using  these  amateur  bands for  anything  even
resembling  communications  with every home having a 1W spread  spectrum
source in it?  The article  claims this system is just  capitalizing  on
reccent rulings of the FCC.

   If losing 40% of 220 MHz  bothers  you, how do you feel about  losing
ALL off 900 MHz a hunk of 2.3 GHz (AO13  mode S is at 2403) and the bulk
of 5.6 GHZ (the calling frequency is 5760 MHz!)?

   I think it is time for the amateur  community  to start  claiming its
spectrum.  I think that  something  which might help save us is some low
cost digital  hardware for packet  switching, even  digipeating, at high
rates to finally get a real  amateur  network.  We need  something  with
some of the same  attributes as a TNC, that is high  quantity,  low cost
plug-in and use, which really makes an impact on amateur radio.

   Providing a *real*  digital  network  with high  enough data rates to
interest  the younger  computer  hackers into  amateur  radio as well as
providing  a real  emergency  network  might  be able to help  save  the
amateur service.

   A few of us in the amateur  tcp/ip  (packet)  community  are  working
toward  offerings in this area.  I believe that the  technology  is here
for  building  such a network.  I don't want to limit it by calling it a
computer  network either.  If appropriate  data throughput is available,
it  should  be a  small  matter  to  hook  up  a  microphone  to your
digitizer,  enter the  distant  station's  call sign and have your  audio
transmitted over the network, routed  automatically with no intervention
necessary  and  'reassembled'   into  audio  at  the  distant  station's
digitizer/undigitizer.  This kind of  functionality  is not a pipe dream
either, 2-10Mbaud transceivers which can provide the necessary data rate
over  significant  distances can be built for less than the cost of a 2M
FM  transceiver.  I have a pair already  funtioning on 24 GHZ built from
radar gun modules which cost under $50 per module.  The antenna is a 16"
$9 lamp  reflector  from a German  lighting  store.  We have  500 MHz of
spectrum  alloted to us at 10 GHz which is probably an excellent  choice
for this kind of high speed network.

   I'm afraid that if we aren't looking  towards  imlementing  something
more  than  what we have  presently,  what we do  have  will  disappear.


Glenn Elmore -N6GN-

N6GN @ N6IIU-1
[e-mail]
[e-mail]

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

Date: 12 Jan 89 23:13:00 GMT
From: uxg.cso.uiuc.edu![e-mail]
Subject: Ciphers and stuff

> >What is the purpose of encryption or validation in *amateur* packet?
>
> Unfortunately, there is a need for this sort of thing, particularly for
> packet switches and network servers that operate under remote control. I
> don't want people to be able to delete files and reconfigure systems without
> my permission.

The ultimate purpose is to make sure your repeater or other remote station
is operating in compliance with FCC rules.  Someone else could gain control
and make the machine do things that are illegal.

--phil ka9wgn--

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

Date: 12 Jan 89 23:00:00 GMT
From: uxg.cso.uiuc.edu![e-mail]
Subject: Ham licensing mailing list is ready

I have created a new MAILING LIST on which discussion of Amateur Radio
licensing matters and closely related issue may be held.  This mailing
list is open to anyone.  You do NOT have to be a licensed ham radio
operator.  LIDS are unwelcome.

This mailing list is served by Eric Thomas' LISTSERV server.


HOW TO SUBSCRIBE:

Send E-mail with one line of text (and NO signature) containing:

    SUB HAMLICEN firstname lastname callsign

substituting the appropriate info.  You can use lower or mixed case.
Send that mail to one of these addresses:

    [e-mail]
    uiucuxc!vmd!listserv
    [e-mail]

If this fails, send me E-mail (to: [e-mail] or
uiucuxc!uxg!phil) and ask me to add you to the list.  Often, return
addresses get mangled on the way here and may not be useable once
that happens.  The server will send you mail acknowledging that you
are added to the mailing list.  If you fail to get this within six
days (allowing 3 each way) contact me at [e-mail] to
have you added manually.  Please supply your full domain host name
or one very near to you if at all possible.


HOW TO SUBMIT ARTICLE:

E-mail your article to one of the following addresses:

    [e-mail]
    uiucuxc!vmd!hamlicen
    [e-mail]


Once the mailing list gets underway, I will tell how to get back issues.

--phil ka9wgn--

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

Date: 13 Jan 89 16:56:52 GMT
From: pasteur!cad.Berkeley.EDU![e-mail]  (EDIF Committee)
Subject: Multiplayer games?

In article <[e-mail]> [e-mail] (David S. Bakin) writes:
>In article <[e-mail]>, rbono@necis (Rich Bono) writes:
>>In article <[e-mail]>, [e-mail] (David S. Bakin) writes:
>>> Has anybody worked on multiplayer games using packet techniques?  I'm thinking
>>      [deleted some stuff]
>>
>For example, on the old CDC Plato computer-based educational system there was
>a multi-player "flight simulator" where everyone could join a team and take
>off and land a fighter from the team's airfield.  Then, once in the air, you

The Microsoft/SubLogic Flight Simulator V 3.0 includes this capability, and
I for one would LOVE to try it out! The FS3 sells for approx. $30 for the
IBM/PC clones, don't know if the other versions are out yet.

The method used is similar to the one you described, a position/attitude/
velocity update is exchanged between the two machines on a regular basis.
The documentation implies that the frequency of update varies with the
link speed. They recommend 1200+ baud, but the main effect of 300 baud
is to have a very slow setup when starting (4-5 min.).

I have the setup at home not linked to my packet setup (yet), but this could
be accomplished easily. I have a Microcom AX/9624C telephone modem
(effective data rates of 19.2Kbaud), and that could be used on 2M.

Anyone in Southern AZ want to try this? I have 22el o2M so I can get simplex
into most of the state.

73 Mike

Mike Waters    AA4MW/7                  *
Motorola CAD Group                      *    Witty remark goes *HERE*
Mesa, AZ   ...!sun!sunburn!dover!waters *
      OR   [e-mail]     *

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

Date: 13 Jan 89 16:43:36 GMT
From: pasteur!cad.Berkeley.EDU![e-mail]  (EDIF Committee)
Subject: Richard Stallman ?? (was Re: Ciphers and stuff)

In article <[e-mail]> [e-mail] (Jay "you ignorant splut!" Maynard) writes:

>Lemme guess. You are a Richard Stallman follower. (For the uninformed,
>Stallman believes that there should be no security on computer systems;
>after all, information belongs to the people! Pfaugh.)

Never heard of him before, but I will believe he is serious if he will
send me a list of five or more of HIS cridit card numbers together with
signed permission to post them for the world. I wouldn't make illegal
charges to them, but ...    Power to the people!
Mike Waters    AA4MW/7                  *
Motorola CAD Group                      *    Witty remark goes *HERE*
Mesa, AZ   ...!sun!sunburn!dover!waters *
      OR   [e-mail]     *

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

Date: 13 Jan 89 23:52:14 GMT
From: [e-mail]  (David A Rasmussen)
Subject: Richard Stallman ?? (was Re: Ciphers and stuff)

From article <[e-mail]>, by [e-mail] (EDIF Committee):
# In article <[e-mail]> [e-mail] (Jay "you ignorant splut!" Maynard) writes:
#
#>Lemme guess. You are a Richard Stallman follower. (For the uninformed,
#>Stallman believes that there should be no security on computer systems;
#>after all, information belongs to the people! Pfaugh.)
#
# Never heard of him before, but I will believe he is serious if he will
# send me a list of five or more of HIS cridit card numbers together with
                    ^^^^^^
# signed permission to post them for the world. I wouldn't make illegal
# charges to them, but ...    Power to the people!

Maybe rms could refer you to a dictionary too, or haven't you paid your
license fee to use the proper english language yet? ;-)


--
Dave Rasmussen c/o Computing Services Division @ U of WI - Milwaukee
Internet: [e-mail]  Uucp: uwvax!uwmcsd1!uwmcsd4!dave {o,o}
Any opinions expressed are my own.  Now, for a limited time, they can be yours
too, for the incredible price of only $19.95.

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

End of PACKET-RADIO Digest
******************************
15-Jan-89 02:02:32-MST,5269;000000000000
Return-Path: <[e-mail]>
Date: Sun, 15 Jan 89 01:31:13 MST
From: [e-mail]
Reply-To: [e-mail]
Subject: PACKET-RADIO Digest V89 #13
To: [e-mail]

PACKET-RADIO Digest         Sun, 15 Jan 89       Volume 89 : Issue  13

Today's Topics:
              Ciphers and stuff
           Maybe we should move the debate
----------------------------------------------------------------------

Date: 12 Jan 89 20:12:44 GMT
From: hpfcdc!hpldola!hp-lsd!hp-col![e-mail]  (Bdale Garbee)
Subject: Ciphers and stuff

>I must be missing something.  Maybe someone could enlighten me ...

I'll try.

>What is the purpose of encryption or validation in *amateur* packet?

Authentification that a sending (often control) station is really who he/she
says they are.

>Who is "attacking"?  ...  It seems to me that there are easier ways to do
>evil on the airwaves than cracking a packet link.

Sure.  But if it's easy, where's the challenge?  There is a personality group
where the challenge of creating the havoc is the thing...

>I feel this is a hobby and shouldn't need any special safeguards.
>Amateur Radio is a lot more of a hacker utopia than the real world and
>I don't feel comfortable  adding more paranoia to it.

About the worst you can do jamming a repeater is make it hard for someone else
to use while you're jamming it.  Sophisticated repeater controllers with
touchtone inputs begin to provide the subversive community with a greater
challenge, but still, the maximum damage that can be done is slight.

With packet, mountaintop packet switches are already envisioned that will have
substantial sophistication.  There will be a need for control operators to be
able to tweak things, like static route table entries.  An untrained operator
tweaking with these same parameters could bring a network to a standstill, in
the case of some of us with nasty winter weather, perhaps even until the spring
thaw... that's a risk we'd rather avoid.

An even more practical example of the need for authentification of packet
links will come with the next generation of amateur satellites.  All that I
am aware of will use packet for command and telemetry, meaning that if you can
spoof the packet link, you can royally torch the bird.  We cannot tolerate
that, there's too much effort and money involved.

I'd like to think that all hams are "White Hats", but even if you really
believe that, the fact that a large percentage of repeater jamming incidents
involve non-hams should make you realize that the problem isn't necessarily
bad hams...

73 - Bdale, N3EUA

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

Date: 13 Jan 89 21:22:29 GMT
From: adelie!atexnet!cvman![e-mail]  (Gary Delong)
Subject: Maybe we should move the debate

In article <[e-mail]>, [e-mail] writes:
>
> Maybe we should move the debate about proposed license class changes (and
> whether or not the code requirement should be included with them) over to
> a separate automatic mailing list and not on REC.HAM-RADIO newsgroup and
> INFO-HAMS mailing list.  There are a lot of people who either don't care
> about the issue or just don't want to be part of it.
>
> I am willing to run a separate mailing list if enough people would like
> to participate.  It would be open to all regardless of the position they
> take, if any.  Let me know if you would like it to be an open list or a
> moderated one.  I can't say that I would have the time to moderate it,
> though.
>
> E-mail to:  [e-mail]  for this topic.
> --phil ka9wgn--

To date I have seen a couple of follow-ups to the above, one indicated
that that is part of ham-radio, another indicated that packet had a
a new group created for it to move that traffic out of general ham-radio
discussions.

I would tend to agree with the idea that the ongoing discussions in
rec.ham-radio on a no-code/yes-code license and of other proposals for
changing the Amateur Radio Licence structure are of such volume that
those discussions might be moved into a dedicated group for those who
are interested to present their viewpoints without filling up rec.ham-radio.

CALL FOR DISCUSSION:

In line with accepted net practices, I would like to call for discussion
the formation of:

       rec.ham-radio.licensing

Discussion might also indicate other possable names and/or guidelines
for such a group.

Althought this is posted to both rec.ham-radio and news.groups, the proper
place for this discussion is (I understand) news.groups.

For readers of the INFO-HAMS mailing list, I will also monitor that for
any discussion which you are unable to post to news.groups and summarize
and re-post that summery to news.groups prior to any call for votes.

--
  _____
 /  \    /   Gary A. Delong, N1BIP          [e-mail]
 |   \  /    COMPUTERVISION Division        {sun|linus}!cvbnet!gdelong
 \____\/     Prime Computer, Inc.           [phone] x 261

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

End of PACKET-RADIO Digest
******************************
16-Jan-89 01:55:07-MST,4291;000000000000
Return-Path: <[e-mail]>
Date: Mon, 16 Jan 89 01:30:32 MST
From: [e-mail]
Reply-To: [e-mail]
Subject: PACKET-RADIO Digest V89 #14
To: [e-mail]

PACKET-RADIO Digest         Mon, 16 Jan 89       Volume 89 : Issue  14

Today's Topics:
                 HDTV
              Multiplayer games? (LONG)
               Packet on 29.050
----------------------------------------------------------------------

Date: 10 Jan 89 02:38:00 GMT
From: asuvax!stjhmc!f1.n234.z1.fidonet.org![e-mail]  (Jim Grubs)
Subject: HDTV

I watched NBC-TV News' report on High Definition TV as shown at the
Electronics show at Las Vegas. The newsmen, industry spokesmen, AND
congressmen interviewed unanimously agreed that the US government were going
to have to take any and all possible measures to 'jump start' US industry to
overtake the Japanese lead in this field. Translation? All VHF/UHF/SHF ham
bands that aren't full from edge to edge are GONE and perhaps those that are
full, too. Hey, you guys who say you'd rather see ham radio die as is than
switch to no-code are about to get your wish.

73, Jim Grubs, W8GRT


--
St. Joseph's Hospital/Medical Center - Usenet <=> FidoNet Gateway
Uucp: ...{gatech,ames,rutgers}!ncar!noao!asuvax!stjhmc!234!1!Jim.Grubs
Internet: [e-mail]

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

Date: 14 Jan 89 18:45:37 GMT
From: ece-csc!ncrcae!ncrlnk!ncrwic!ksuvax1!deimos!harris.cis.ksu.edu![e-mail]  (Myron A. Calhoun)
Subject: Multiplayer games? (LONG)

>> Has anybody worked on multiplayer games using packet techniques?

We have an "interactive competetive simulation" (the word "game" is
verboten here) called "hunt" running on several machines here at KSU.
It is essentially an adventure game (one roams around in caverns, halls,
rooms, etc.) where one shoots at everything that goes bump in the night.
And those "things" are OTHER players who are also shooting at you.  At
my ripe old age I don't have sufficient survival reflexes, but one of
my sons did very (too) well against me.  And those who "play" (I mean
"compete") regularly shoot FAST!

I don't know how it might work via packet, but it would be interesting
to try.
--W0PBV
Dr. Myron A. Calhoun, W0PBV, [phone] (work), 539-4448 (home).
INTERNET: [e-mail]
BITNET:   [e-mail] -or- [e-mail]
UUCP: ..!rutgers!ksuvax1!mac -or- ..!{pyramid,ucsd}!ncr-sd!ncrwic!ksuvax1!mac

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

Date: 16 Jan 89 01:36:09 GMT
From: netsys!bigbox![e-mail]  (J. E. Cook)
Subject: Packet on 29.050

>Path:  N4QQ
>Date:  07 Dec 88 08:01:46 Z
>From:  K3AKK@N4QQ
>To:    ALL@MDCBBS
>Subject: Higer power at NATCAP node

The NATCAP node (one of the DCA /K3AF nodes) is now running 400 watts to a
3 element beam looking west.  The node is on 29.050 running 1200 baud.  It
                          ^^^^^^
is designed to connect with AZSE and the 145.01 network in the Southwestern
U.S.  Additional 29.050 nodes will be coming on line in Seattle and southern
California.  There is occasional QRM from AM voice stations that could cause
circuit delays.  There are at least five hours a day of good circuits into
Arizona.  Comments and observations would be helpful.  Access NATCAP K3AF-7
through the DCA nodes.    Dick - K3AKK @ N4QQ    sysop DCA nodes
 --------------------------------------------------------

    The above was taken off a PBBS (VE4CY) by a U.S. Ham on 29.050 using
F1B, an ARRL O.O wrote the amateur, saying  "Sorry OM, you can't run packet on
29.050"  The poor guy ask me (ME!) to check my new (to me) copy of part 97, as
it does read like a law book, I'am seeking the help of others before I answer
him..  I think the ARRL O.O is correct..  Packet in (F1B) 28.000-28.3000. I
know that this sounds like " I have this friend....." BUT I DO! :-)

73 -- Jim N8JBO
(my first er, second posting  I don't own a FLAMEPROOF suit..)

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

End of PACKET-RADIO Digest
******************************
17-Jan-89 01:53:11-MST,8508;000000000000
Return-Path: <[e-mail]>
Date: Tue, 17 Jan 89 01:30:32 MST
From: [e-mail]
Reply-To: [e-mail]
Subject: PACKET-RADIO Digest V89 #15
To: [e-mail]

PACKET-RADIO Digest         Tue, 17 Jan 89       Volume 89 : Issue  15

Today's Topics:
      connectivity tree from header intercepts (2 msgs)
                  Mail List
       Richard Stallman ?? (was Re: Ciphers and stuff)
----------------------------------------------------------------------

Date: 16 Jan 89 16:21:32 GMT
From: rochester!kodak!ektools![e-mail]  (Andrew A. Kinsman)
Subject: connectivity tree from header intercepts

In a related article Mike Waters writes:
>
>In article <[e-mail]> [e-mail] (Andrew A. Kinsman) writes:
>>
>>      Does anybody have a package of software which monitors the headerlines
>>and builds a connectivity tree for stations within range of my packet station?

>I wonder if the USENET software such as pathalias would do the trick?
>It has almost all of the hooks for path cost, times available etc..
>The only problem I can think of is that the connection information would
>have to be in the same format as used by the UUCP mapping project.
>The source is in C and is public domain.

My thoughts exactly.  We have a program which analyses these uucp maps to determine
the fastest path from Kodak to a distant node.  I thought about using the same software
that pathalias uses then employ our utility "npath" to come up with the shortest
packet path.  It wasn't too difficult to determine that the shortest wasn't often
available, with ham shack schedules being irregular.  I've since turned towards a program
which will gather packet headers and add the information to a data base which can be
searched for new and shorter paths.  This program will only determine paths outward from
my station, and will regularly prune the tree of silent keys, and off air stations.
The end result is about 20k structure, and 4k code(so far).  When placed on line it should
be able to produce several paths to a station of my choice.  One problem is that now I need
two packet stations!  One to gather data, and one to use for packet.  I guess the prime
time for gathering interesting headers is at night and during contests.

\___                 ___|___
Andy\__   --------------|--------------
Kinsman\_____
5441 Holtz Rd\_____                             NOFUEL on the Hill
Palmyra, N.Y. 14522\___
----->N2HZK/AG<--------\__________________
rutgers!rochester!kodak!ektools!kinsman\______________________
Eastman Kodak Co., Rochester, N.Y. "Little Yellow Box Factory"\

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

Date: 17 Jan 89 02:58:23 GMT
From: jupiter![e-mail]  (Phil R. Karn)
Subject: connectivity tree from header intercepts

>>>     Does anybody have a package of software which monitors the headerlines
>>>and builds a connectivity tree for stations within range of my packet station?

Check out ARPA RFC-981, "An Experimental Multiple-Path Routing Algorithm",
by Dave Mills, W3HCF. Here is the first paragraph (!) of the abstract:

Abstract

   This document introduces wiretap algorithms, which are a class of
   routing algorithms that compute quasi-optimum routes for stations
   sharing a broadcast channel, but with some stations hidden from
   others. The wiretapper observes the paths (source routes) used by
   other stations sending traffic on the channel and, using a heuristic
   set of factors and weights, constructs speculative paths for its own
   traffic.  A prototype algorithm, called here the Wiretap Algorithm,
   has been designed for the AX.25 packet-radio channel.  Its design is
   similar in many respects to the shortest-path-first (spf) algorithm
   used in the ARPANET and elsewhere, and is in fact a variation in the
   class of algorithms, including the Viterbi Algorithm, that construct
   optimum paths on a graph according to a distance computed as a
   weighted sum of factors assigned to the nodes and edges.

--Phil

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

Date: 17 Jan 89 03:33:33 GMT
From: bpa![e-mail]  (Bob Esposito)
Subject: Mail List

    Please delete me fro the mailing list.

    Tnx.....

--
Bob Esposito           uucp: [e-mail], {rutgers|bellcore}!bpa!espo
Bell of Pennsylvania   inet: [e-mail]
Philadelphia, PA.      phone: [phone]  packet: N3CTA @ N3CTA 44.80.0.93
===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===

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

Date: 16 Jan 89 18:28:09 GMT
From: m2c!ulowell!tegra![e-mail]  (Johnathan Vail)
Subject: Richard Stallman ?? (was Re: Ciphers and stuff)

I think things are going too far here:

~~   In article <[e-mail]> [e-mail] (Jay "you ignorant splut!" Maynard) writes:
~~
~~   >Lemme guess. You are a Richard Stallman follower. (For the uninformed,
~~   >Stallman believes that there should be no security on computer systems;
~~   >after all, information belongs to the people! Pfaugh.)
~~
~~   Never heard of him before, but I will believe he is serious if he will
~~   send me a list of five or more of HIS cridit card numbers together with
~~   signed permission to post them for the world. I wouldn't make illegal
~~   charges to them, but ...    Power to the people!
~~   Mike Waters    AA4MW/7                  *

I started all this by asking:

> >What is the purpose of encryption or validation in *amateur* packet?

My posting was not intented to be a flame.  I was hoping there was a
technical reason where encrypted verification was necessary.  Some,
like Phil Karn have come up with a reasonable way to do this with
minimal impact and overhead.  It is sad that it is necessary at all.

Yes, my beliefs fall more with Richard Stallman on many things than
with those on the other side like Mitch Kapor and Bill Gates.  I think
Jay has either misunderstand the GNU philosophy or has deliberately
distorted the truth.  Although it seems carefully worded, he has
apparently equated myself, RMS, and "the malicious who want nothing
more than to wreak havoc".  I feel all three are separate.  I think
the quote of RMS, "information belongs to the people" is an unfair
distortion of "software *should* be free" (my own distortion :-).
Note that the word free is used as is the word freedom, and not to
imply without cost.

Richard Stallman, for those that already don't know, is the founder of
the Free Software Foundation.  Their first "product" is the GNU Emacs.
Richard Stallman is credited with writing the original Emacs but was
unable to give it away since MIT owned and sold the rights.  So, he
rewrote it, extending the concept so that he could distribute it
freely.  Taking this further, the FSF is writing their own version of
Unix, to be dirstibuted for free including source code.  Their
optimizing C compiler is released.  Although there are bugs (what new
compiler doesn't have them?) my company is switching over to using
that for our products.  It is far superior to the commercial product
that we bought the rights to and have been maintaining ourselves
anyway.

I feel that this concept is very valuable and achieves his goals of
advancing the art without the stagnating restrictions that traditional
software licenses impose.  Many large companies feel this way to and
demonstrate it by contributing to the FSF.  The NeXT computer also
comes with FSF software.

For more information about what RMS believes I would refer the
interested and curious to the "GNU Manifesto".  It is included in the
GNU Emacs Manual.

There are many places where security is needed and justified.  There
are others where it shouldn't be necessary, like Amateur radio.
Unfortunately there is evil in the world, apparently even in amateur
radio.

!>I feel this is a hobby and shouldn't need any special safeguards. !
!>I don't feel comfortable  adding more paranoia to it.             !

"....say you're thinking about a plate of shrimp...
..and someone says to you `plate,' or `shrimp'......"
 _____
|     | Johnathan Vail  | tegra![e-mail]
|Tegra| [phone]  | N1DXG @ 145.110-, 444.2+, 448.625-
 -----

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

End of PACKET-RADIO Digest
******************************
18-Jan-89 01:57:18-MST,12937;000000000000
Return-Path: <[e-mail]>
Date: Wed, 18 Jan 89 01:30:54 MST
From: [e-mail]
Reply-To: [e-mail]
Subject: PACKET-RADIO Digest V89 #16
To: [e-mail]

PACKET-RADIO Digest         Wed, 18 Jan 89       Volume 89 : Issue  16

Today's Topics:
                <None>
          How does one make double-sided PC boards?
          looking for local mail gateway(s)
              Multiplayer games
               Need manual: GLB TNC-2A
       Richard Stallman ?? (was Re: Ciphers and stuff)
        security (was Re: Ciphers and stuff) (3 msgs)
----------------------------------------------------------------------

Date: 16 Jan 89 10:25:26 GMT
From: attcan!utgpu!watmath!julian!uwovax![e-mail]
Subject: <None>

We here in London, Ontario are thinking of putting up a dual-band digi.
We would like for someone on 2meters to be able to cross-connect onto
440 mhz.  Has anyone have any comments regarding the NORDLINK rom.  I have
burned in a ROM, but felt it wasn't as user friendly as the KA-Nodes.

If someone had 2 TNC-2s, what would be the best solution for connecting
them together for x-band digi.  How reliable is the software?  Does it ever
need power off/on resetting?

What is the Rose Switch software?

de VE3PZR.

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

Date: 17 Jan 89 17:40:33 GMT
From: att!whuts!homxb!hotps!ka2qhd![e-mail]  ( Westfield NJ)
Subject: How does one make double-sided PC boards?

Can someone give me some suggestions on how to make my own double-sided PC
boards?  I only need to make a few boards for myself for various projects.
Therefore, it isn't worth investing in elaborate commerical equipment.  Nor
does it pay me to have it done by a commercial outfit.

I have make my own single-sided PC boards using photoetching techniques at
home.  But so far I can't seem to get the two sides of double-sided board to
line up.  Ever try to drill a board where the IC socket holes don't line up
exactly? :-)

Strangely, I have not be able to find any useful information in any ham mags.
Yet the same magazines often publish double-side board patterns in their
construction articles.  Even the ARRL Handbook is moot on this topic.

Any help that is application to we homebrewers to don't happen to work for a
company where we could make boards on off-hours will be most welcome.

AdvTHANKSance  for the help.
--
Bob Billson, KC2WZ                                   Packet: KC2WZ @ NN2Z
SnailMail: 837 Summit Avenue, Westfield, NJ 07090     Phone: [phone]
UUCP: ucbvax!rutgers!petsd!tsdiag!ka2qhd!kc2wz
          "I want to be a quantum mechanic when I grow up!"

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

Date: 18 Jan 89 04:41:54 GMT
From: bbn.com![e-mail]  (Martin Grossman)
Subject: looking for local mail gateway(s)

I've compleated a email message from Cambridge, MA (UUCP) to
Boston, MA (packet BBS) via wb6rru located out west.  It got
to hplabs in 10 minutes and then took 5 days to go thru 10 or 11 nodes.

I'm looking for any local (new england) gateway between UUCP and packet.

Please send any info to both
    [e-mail]
        and
    ka1ppg@n1bgg

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

Date: 17 Jan 89 21:55:05 GMT
From: ubvax!igor![e-mail]  (David S. Bakin)
Subject: Multiplayer games

Jason E-mailed this to me directly with a request I post it (because he can't
for some reason):

From: uunet!mcvax!ukc.ac.uk!jat
Sender: uunet!mcvax!ukc.ac.uk!jat

In article <[e-mail]> [e-mail] (David S. Bakin) writes:
>Has anybody worked on multiplayer games using packet techniques?  I'm thinking
>[stuff deleted]

Hi Dave,
    I wasn't sure whether you were only interested in stateside stuff,
but i thought i would throw in my two-peneth. In answer to your request
for information, I have recently setup a multi-player game here in England.
Its QTH is Bletchingley, Surrey. (just South of London). The system runs on
a pc-compatible and uses a pk-88 tnc in host mode. As far as networking is
concerned, well several of the players connect either by digipeating or
by using network nodes.

    Yours,          Jason Tanner G1SHX

--
ARPA : [e-mail]      USENET: [e-mail]
JANET: [e-mail]                   useBANGnet: ...mcvax!ukc!gos!jat
Mail : Jason Tanner, 169 Ingrave Road, Brentwood, Essex, CM13 2AA.

----------------------------------------------------------
Dave Bakin                                  [phone]
c/o Rational; 3320 Scott Blvd.; Santa Clara, CA 95054-3197
Internet:  [e-mail]      Uucp:  ...!uunet!igor!dsb

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

Date: 17 Jan 89 21:53:22 GMT
From: ulysses!nsscb![e-mail]  (Andy Meyer)
Subject: Need manual: GLB TNC-2A

Does someone have a manual for a TNC-2A from GLB Electronics?
I got my TNC by horse-trading, and the fellow didn't have the manual.
It works well, but I suspect I'm missing some of the operational nuances.
I'd be willing to pay copying costs.

Thanks in advance,
Andy

    ==--      Andreas Meyer, N2FYE
  -====---    AT&T National Systems Support Center
  --==----    South Plainfield, NJ
    ----      uucp: ..!rutgers!psuvax1!nsscb!ameyer

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

Date: 17 Jan 89 13:46:12 GMT
From: killer!texbell!splut![e-mail]  (Jay "you ignorant splut!" Maynard)
Subject: Richard Stallman ?? (was Re: Ciphers and stuff)

In article <[e-mail]> [e-mail] (Johnathan Vail) writes:
>I think things are going too far here:
>~~   In article <[e-mail]> [e-mail] (Jay "you ignorant splut!" Maynard) writes:
>~~   >Lemme guess. You are a Richard Stallman follower. (For the uninformed,
>~~   >Stallman believes that there should be no security on computer systems;
>~~   >after all, information belongs to the people! Pfaugh.)
>I started all this by asking:
>> >What is the purpose of encryption or validation in *amateur* packet?
>My posting was not intented to be a flame.  I was hoping there was a
>technical reason where encrypted verification was necessary.

Actually, not so much a technical reason as much as a legal/control
reason.

>It is sad that it is necessary at all.

I would agree, but your distaste should properly be directed at those
who would disrupt operations of BBSs, relays, ... than those who react
to the destroyers by trying to protect themselves.

>Yes, my beliefs fall more with Richard Stallman on many things than
>with those on the other side like Mitch Kapor and Bill Gates.  I think
>Jay has either misunderstand the GNU philosophy or has deliberately
>distorted the truth.  Although it seems carefully worded, he has
>apparently equated myself, RMS, and "the malicious who want nothing
>more than to wreak havoc".  I feel all three are separate.  I think
>the quote of RMS, "information belongs to the people" is an unfair
>distortion of "software *should* be free" (my own distortion :-).
>Note that the word free is used as is the word freedom, and not to
>imply without cost.

I have read the GNU Manifesto carefully. Maybe I'm biased, as one who
makes a comfortable living supporting software, but his idea (that
software should be freely given away, and only charges made for
supporting it) seems to be completely unworkable.
His "information should be free" philosophy is, however, documented fact
- see the last chapter in _Hackers_. Otherwise, why is he absolutely
refusing to put any form of security in the GNU operating system, and
refusing to countenance anyone else adding any? That alone will be
enough to guarantee that it's never adopted in places where the
integrity of data matters...like just about every DP shop in existence.

I'm not equating you and RMS and the destroyers; what I am saying is
that your and RMS's attitudes towards security leaves yourselves wide
open for the destroyers. Your idealized "hacker's paradise" doesn't
include them, but the real world does.

>For more information about what RMS believes I would refer the
>interested and curious to the "GNU Manifesto".  It is included in the
>GNU Emacs Manual.

It is interesting reading. Kinda like the _Communist Manifesto_.

>There are many places where security is needed and justified.

Like anything that has any connection with the real world.

>There are others where it shouldn't be necessary, like Amateur radio.

Unfortunately, ham radio exists in the real world.

>Unfortunately there is evil in the world, apparently even in amateur
>radio.

Unfortunately, you are correct. Therefore, we're stuck with it.

--
Jay Maynard, EMT-P, K5ZC, PP-ASEL   | Never ascribe to malice that which can
uucp:        uunet!nuchat!   (eieio)| adequately be explained by stupidity.
    hoptoad!academ!uhnix1!splut!jay +----------------------------------------
{killer,bellcore}!texbell!          | "Sexism is ugly." - Cheryl Stewart

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

Date: 16 Jan 89 23:08:12 GMT
From: cadnetix.COM!cadnetix![e-mail]  (Rusty)
Subject: security (was Re: Ciphers and stuff)

In article <[e-mail]> [e-mail] (Bdale Garbee) writes:
...
>>What is the purpose of encryption or validation in *amateur* packet?
>
>Authentification that a sending (often control) station is really who he/she
>says they are.
<lots of good information, deleted for space reasons>

A possible solution to the problem of someone 'taking over' the link
once you have 'proved' yourself would be to send the authentication
sequence in ANY packet which will initiate a "dangerous" activity.
"Theoretically", since the NSA algorithm is "secure", the massive
number of samples you transmit will not compromise your system.
Theoretically.

Some kind of pseudo-randomly changing key might help improve the
security since you really don't want too massive a sample base for
the cracker to use.



-----
Rusty Carruth  UUCP:{uunet,boulder}!cadnetix!rusty  DOMAIN: [e-mail]
Cadnetix Corp. [phone]x681 \  5775 Flatiron Pkwy. \ Boulder, Co 80301
Radio: N7IKQ    'home': P.O.B. 461 \  Lafayette, CO 80026

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

Date: 17 Jan 89 20:35:07 GMT
From: jupiter![e-mail]  (Phil R. Karn)
Subject: security (was Re: Ciphers and stuff)

>A possible solution to the problem of someone 'taking over' the link
>once you have 'proved' yourself would be to send the authentication
>sequence in ANY packet which will initiate a "dangerous" activity.

This is the other scheme I proposed in my paper. Each and every IP datagram
is individually authenticated by encrypting the TCP or UDP header and the
data with DES in the "cipher block chaining" mode. Then you transmit the
original, UNencrypted packet with the very last block (8 bytes) of
ciphertext stuck in an IP option. The receiver performs the same computation
and compares the last block of its ciphertext against the value in the IP
option. If they don't match, the packet is rejected.

This scheme detects both the generation of bogus datagrams or the alteration
of legitimate ones. The only thing it won't detect is the "playback" of an
earlier, legitimate datagram, but since the Internet transport level
protocols like TCP are already designed to defend themselves against
"long-delayed duplicates", this isn't a problem.

Phil

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

Date: 17 Jan 89 17:09:36 GMT
From: hpda!hpcupt1![e-mail]  (Andrew Valencia(Seattle))
Subject: security (was Re: Ciphers and stuff)

/ hpcupt1:rec.ham-radio.packet / [e-mail] (Rusty) /  3:08 pm  Jan 16, 1989 /
>A possible solution to the problem of someone 'taking over' the link
>once you have 'proved' yourself would be to send the authentication
>sequence in ANY packet which will initiate a "dangerous" activity.

    Don't know how the computer will know which ones those are, in the
general case.  Why not just encrypt the checksum and include it in the packet?
That would make it hard to change *any* of the packet without it being
detected.  Calculating changes to the text which will do what you want
while leaving the CRC-16 checksum unchanged in real time is probably hard
enought to discourage even fairly inspired crashers.  And if the encrypted
checksum was actually a recalculated checksum from a different polynomial
CRC, it could be downright tricky.  I'm sure the NSA could do it, but they'd
probably just take you out back and shoot you if it came down to it.

                    Andy

disclaimer:  these are only my opinions

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

End of PACKET-RADIO Digest
******************************
19-Jan-89 01:55:25-MST,3741;000000000000
Return-Path: <[e-mail]>
Date: Thu, 19 Jan 89 01:30:40 MST
From: [e-mail]
Reply-To: [e-mail]
Subject: PACKET-RADIO Digest V89 #17
To: [e-mail]

PACKET-RADIO Digest         Thu, 19 Jan 89       Volume 89 : Issue  17

Today's Topics:
              Multiplayer games? (LONG)
----------------------------------------------------------------------

Date: 18 Jan 89 14:38:04 GMT
From: encore!necis![e-mail]  (Rich Bono)
Subject: Multiplayer games? (LONG)

In article <[e-mail]>, [e-mail] (David S. Bakin) writes:
> In article <[e-mail]>, rbono@necis (Rich Bono) writes:
> >In article <[e-mail]>, [e-mail] (David S. Bakin) writes:
> >> Has anybody worked on multiplayer games using packet techniques?  I'm thinking
> >     [deleted some stuff]
> >
> > I thought a *REAL* interesting game for packet would be one that could
> >evolve as different "players" entered and left the game (connected/disconnected)
>
> Yes yes, that was also my idea!  A single game "instance" could live
> indefinitely, as players joined and left.  As long as there was connectivity
> of some order between all the players (again, total connectivity not
> necessary).  (Or maybe the game "instance" could survive partitioning and then
> reconnecting.  I suppose it would depend on the game.)
>
>

    [much stuff deleted]

> I should admit right now that I'm not currently active in packet.  (In fact,
> to be honest, I'm not currently active except for an 2m HT in the glove
> compartment.)  But developing this sort of thing could be my motivation for
> becoming active on packet.  And there's a lapsed ham here where I work who
> would "reenlist" if something of this sort got cooking.  To this end, if I get
> enough E-mailed interest I'd be happy to set up a mailing list so that we
> could make something a reality.
>

This would be an interesting idea... I do (via my DOSGATE project) have some
games available for play via packet... (mostly the INFOCOM series)... and
they do see many hours of play via packet...  I also have.. but have not
tested it yet.. the new MS-flight simulator which allows one to "fly with a
friend via a modem"... I don't know if the throughput would be handled via
packet with the associated delays, etc...  This could be simply tested...

  BUT, a real, MULTIplayer game, via packet, with users coming and going,
would have to be a special packet implemenation (in one sense)... that can
handle the TNC's multi streams (Kantronix can support 26 simultaneous
connects).. with users coming and going...

  The closest I have come to this (not trying to build a monster) is
a "conferenceing system", that very simply allows multiple users to
connect to my system and talk in a roundtable fashion.. it does handle
the connects and disconnects and informs everyone of who is coming and
going... not a game.. but the TNC handling stuff is there...

  We now just need a GAME PROGRAMMER to come up with the idea and implement
it!  Packet is a great technology that can be used for MUCH more than
JUST EMAIL!!!!


    I like this idea! (Still)....


                Rich, NM1D

--
 /**************************************************************************\
 * Rich Bono (NM1D)    If I could only 'C' forever!!    [e-mail] *
 * [phone]         NEC Information Systems       NM1D @ WB1DSW-1     *
 \**************************************************************************/

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

End of PACKET-RADIO Digest
******************************
20-Jan-89 01:52:00-MST,10643;000000000000
Return-Path: <[e-mail]>
Date: Fri, 20 Jan 89 01:30:23 MST
From: [e-mail]
Reply-To: [e-mail]
Subject: PACKET-RADIO Digest V89 #18
To: [e-mail]

PACKET-RADIO Digest         Fri, 20 Jan 89       Volume 89 : Issue  18

Today's Topics:
              Battery operated printers?
           Maybe we should move the debate
              Multiplayer games
             RRU Gateway software
         security (was Re: Ciphers and stuff)
----------------------------------------------------------------------

Date: 18 Jan 89 02:01:58 GMT
From: sm.unisys.com!csun!csuf3b![e-mail]  (James Paul)
Subject: Battery operated printers?

I've been looking for an _inexpensive_ battery operated printer for use
with my laptop (tandy 200) mobile emergency packet station. Purple
Computing used to have one, as I read about in a 73 magazine article,
but they have been discontinued.

Does anyone know of a good place to get a small battery operated printer
that would be inexpensive and good for my purpose? The print quality
doesn't matter, and thermal printing would be fine, too.

-James L. Paul, N6SIW

--------------------------------------------------------------------------
James L. Paul            ucbvax!ucdavis!csusac |
CIS: 72767,3436                lll-lcc!csustan | !csufres!jamespa
GEnie: J.Paul               hplabs!hp-sdd!sdsu |

DISCLAIMER: I said it. If I'm wrong, well, oops.
--------------------------------------------------------------------------

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

Date: 18 Jan 89 16:04:28 GMT
From: mirror!rayssd!raybed2!cvbnet2![e-mail]  (Gary Delong)
Subject: Maybe we should move the debate

In article <[e-mail]>, [e-mail] writes:
>
> Maybe we should move the debate about proposed license class changes (and
> whether or not the code requirement should be included with them) over to
> a separate automatic mailing list and not on REC.HAM-RADIO newsgroup and
> INFO-HAMS mailing list.  There are a lot of people who either don't care
> about the issue or just don't want to be part of it.
>
> I am willing to run a separate mailing list if enough people would like
> to participate.  It would be open to all regardless of the position they
> take, if any.  Let me know if you would like it to be an open list or a
> moderated one.  I can't say that I would have the time to moderate it,
> though.
>
> E-mail to:  [e-mail]  for this topic.
> --phil ka9wgn--

To date I have seen a couple of follow-ups to the above, some have indicated
that it is part of ham-radio, another indicated that packet had a
a new group created for it to move that traffic out of general ham-radio
discussions.  There is also a move to create a mailing list for this
topic, but their have been objections to that.

I would tend to agree with the idea that the ongoing discussions in
rec.ham-radio on a no-code/yes-code license and of other proposals for
changing the Amateur Radio Licence structure are of such volume that
those discussions might be moved into a dedicated group for those who
are interested to present their viewpoints without filling up rec.ham-radio.

CALL FOR DISCUSSION:

In line with accepted net practices, I would like to call for discussion
the formation of:

       rec.ham-radio.licensing

Discussion might also indicate other possable names and/or guidelines
for such a group.

Althought this is posted to both rec.ham-radio and news.groups, the proper
place for this discussion is (I understand) news.groups.

For readers of the INFO-HAMS mailing list, I will also monitor that for
any discussion which you are unable to post to news.groups and summarize
and re-post that summery to news.groups prior to any call for votes.

[Note: This is a re-post, the first posting was from a leaf node
       with poor conectivity and it didn't seem to make it to most
       sites so I am re-posting.  Apologies to those who've seen it.]

--
  _____
 /  \    /   Gary A. Delong, N1BIP          [e-mail]
 |   \  /    COMPUTERVISION Division        {sun|linus}!cvbnet!gdelong
 \____\/     Prime Computer, Inc.           [phone] x 261

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

Date: Thu, 19 Jan 89 22:05:50 -0500
From: -David C. Kovar <daedalus![e-mail]>
Subject: Multiplayer games

>>> I thought a *REAL* interesting game for packet would be one that could
>>>evolve as different "players" entered and left the game (connected/disconnected)
>> Yes yes, that was also my idea!  A single game "instance" could live
>> indefinitely, as players joined and left.  As long as there was connectivity
>> of some order between all the players (again, total connectivity not
>> necessary).  (Or maybe the game "instance" could survive partitioning and then
>> reconnecting.  I suppose it would depend on the game.)

>  BUT, a real, MULTIplayer game, via packet, with users coming and going,
>would have to be a special packet implemenation (in one sense)... that can
>handle the TNC's multi streams (Kantronix can support 26 simultaneous
>connects).. with users coming and going...
>
>  The closest I have come to this (not trying to build a monster) is
>a "conferenceing system", that very simply allows multiple users to
>connect to my system and talk in a roundtable fashion.. it does handle
>the connects and disconnects and informs everyone of who is coming and
>going... not a game.. but the TNC handling stuff is there...
>
>  We now just need a GAME PROGRAMMER to come up with the idea and implement
>it!  Packet is a great technology that can be used for MUCH more than
>JUST EMAIL!!!!

  Let me start off by saying that I am a sometimes game programmer (currently
a Harvard consultant) with a definite interest in packet but no money to
break into it.

  The major problem with a ongoing, multiplayer, networked game is keeping
everyone up to date on the current state and initializing the game state
of new players. If you're considering a dungeon type of game, you have to
think about describing the entire world to any new player and insuring
that updates get to everyone on a timely basis. On a reliable 10MB
Ethernet this isn't too much of a problem. I'm not sure what packet is
like so I can't make any comparisons. One possible solution, if you're
playing such a game, is to distribute the database via another channel
and distribute updates to it at some interval. Timing is a real pain.
Do you want to go with a central game server machine or a game state that
lives on all machines and can be updated from anywhere? Fun stuff.

  I'd love to get involved in such a project. Maybe it'll even convince
me to buy all the gear, pass a few exams, and get active in packet. Worse
things could happen.

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

Date: 18 Jan 89 18:54:30 GMT
From: hpda!hpcupt1![e-mail]  (Andrew Valencia(Seattle))
Subject: RRU Gateway software

  A number of people asked about getting my software.  Here are the terms
under which I provide my software.  If you want my software and these terms
are acceptable, I have included my address at the bottom.  Please mail me
a self-addressed, stamped floppy mailer with two high-density floppy disks.
I will burn my software in cpio format onto the disks and mail them back.
If you don't send me a mailer, or disks, or postage (somebody once just sent
some dollar bills instead!) then you have to wait for me to "get around" to
hunting down some mailers, and a pen, and stamps  (You'll probably wait
forever :->).
===========================

  All files Copyright 1988 by Andrew Valencia

    It is my honest desire that everyone get access to quality software.
But in order to protect myself and others, I must maintain my copyright
of the WB6RRU Multi-user BBS software.  The terms set out below are, I
hope, reasonable.  If there is something in them which seems objectionable,
please contact me--my hope was to be reasonable without having the
unhappy consequences of writing software without copyright protection.

    All sections of the U.S. copyright law are in force.  But all is not
lost!  The following clauses spell out the special cases:

1. If you are not a licensed Amateur Radio Operator, you may not use
    this software in whole or part.

2. For FCC-licensed Amateur Radio Operators, the following are allowed:
    a. You may run this software on your own equipment for non-profit purposes.
    b. You may modify this software for your own personal station.
    c. With the permission of Andrew Valencia, you may give this software to
    another Amateur Radio Operator.
    (1) You may give the original copy as received from Andrew Valencia.
    (2) You may give your modified copy only if you also provide
        the original copy as received from Andrew Valencia.
    d. You may request the latest version of the software from Andrew Valencia
    at any time.  This will be provided free of charge, but you will be
    expected to provide disks, postage, and mailer.

3. All other uses are disallowed without further contractual agreement
    with Andrew Valencia.

    Sincerely,
    Andrew ("Andy") Valencia
    WB6RRU
    [phone]       Home
    [phone]       Work

===========================

    My mailing address:

        Andy Valencia
        125 Connemara #140
        Sunnyvale, CA  94087

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

Date: 20 Jan 89 05:46:24 GMT
From: ka9q.bellcore.com![e-mail]  (Phil Karn)
Subject: security (was Re: Ciphers and stuff)

> Why not just encrypt the checksum and include it in the packet?

This is a very weak scheme, for two reasons:

1. There are only 65,536 different values that a 16-bit CRC field can take.
It would not take long, on an active high speed channel, for someone to
build up a usable "dictionary" of plaintext and encrypted CRC values for
use in his own bogus packets.

2. The CRC algorithm is linear, and well known. It is just not that hard to
modify a packet in such a way that the CRC is left unchanged. If there are
unused fields within the packet (e.g., the URG field in TCP), then it's
even easier to do this while saying something meaningful (and malevolent)
in the data portion of the packet.

Phil

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

End of PACKET-RADIO Digest
******************************
21-Jan-89 01:45:12-MST,5708;000000000000
Return-Path: <[e-mail]>
Date: Sat, 21 Jan 89 01:30:36 MST
From: [e-mail]
Reply-To: [e-mail]
Subject: PACKET-RADIO Digest V89 #19
To: [e-mail]

PACKET-RADIO Digest         Sat, 21 Jan 89       Volume 89 : Issue  19

Today's Topics:
              Battery operated printers?
              Multiplayer games
             NORD><LINK software releases
             RRU Gateway software
         security (was Re: Ciphers and stuff)
----------------------------------------------------------------------

Date: 20 Jan 89 13:49:37 GMT
From: pitt![e-mail]  (Bob Hoffman)
Subject: Battery operated printers?

The only battery-operated printer I've seen is the Diconix ink-jet.  Tom
Clark had one at the ARRL packet conference in LA two years ago.  It was
pretty slick -- the batteries were inside the platen and it was very
quiet.

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

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

Date: 20 Jan 89 17:14:44 GMT
From: hpda!hpcupt1![e-mail]  (Andrew Valencia(Seattle))
Subject: Multiplayer games

/ hpcupt1:rec.ham-radio.packet / [e-mail] (-David C. Kovar) /  7:05 pm  Jan 19, 1989 /
>  The major problem with a ongoing, multiplayer, networked game is keeping
>everyone up to date on the current state and initializing the game state
>of new players.

    One easy way is to generate the dungeon fractally, distributing just
the seed for the current dungeon on startup.  You may still want to pre-
distribute the bitmaps for the various objects, sounds and so forth, but at
least you can play in "fresh" dungeons with very little cost.

                    Andy

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

Date: Thu, 19 Jan 89 09:31:21 MEZ
From: [e-mail]
Subject: NORD><LINK software releases

Hi folks,

several requests arrive here now an then asking for the newest
releases of NORD><LINK software. To answer to these questions
and because some of my direct responses bounced here is a short
summary of the latest release versions.


   item         source  release#     author

1. TheBox               1.5.c        DF3AV
   Multiconnect, multilangual PBBS  for IBM PCs / clones
   running *DOS 3.*, utilizing hostmode firmware in a TNC
   serving up to 4 TNCs

2. TheNet          C    1.1          DC4OX, DF2AU
   network node running on TNC2 / clones
   no urgend need to change compared to 1.0

3. TheNet          C    1.0          DF2AU
   network node running on TNC220, to be released soon

4. TheNet CONVERS  C    1.0          DL8ZAW
   network node running on TNC2 / clones
   conversational mode in a dedicated TNC

5. TheFirmware          2.1c         DC4OX
   Firmware for TNC2 / clones, Hostmode, some repaired bugs
   up to 18 channels

6. TNC1soft             0.07/1.0     DC4OX
   Firmware for TNC1 / clones, Hostmode, some repaired bugs
   including MiniMon

7. TurboPR         P    2.6          DL1BHO
   Terminal programm for IBM PCs / clones
   running *DOS 3.*, utilizing hostmode firmware in a TNC.
   multichannel filefransfer, autorouting, auto logbook
   auto identification for TheBox & TheNet SYSOPs

           C  C source
           P  PASCAL source


All software is available from NORD><LINK at no charge for noncommercial
amateur usage. You only have to care for  EPROMS / floppies, postage,
and handling expense.
But you might feel free to include donations at your choice.


73s Detlef ( DK4EG @ DK0MAV )            NORD><LINK

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

#include <disclaimer.std>


 Detlef J. Schmidt
 Braunschweig F.R.G.

C0033003 at dbstu1.bitnet
 [e-mail]
 [e-mail]")
 [e-mail]
 CUNYVM.CUNY.EDU![e-mail]
etc...
.

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

Date: 19 Jan 89 17:14:14 GMT
From: hpda!hpcupt1![e-mail]  (Andrew Valencia(Seattle))
Subject: RRU Gateway software

    Brian Kantor, in classic form, has notified me that my wording is
rather USA-centric.  Sorry.  Any non-US hams are more than welcome to my
software, and I'll adjust the wording appropriately.

            73s... Andy WB6RRU

    "If I'd wanted to think like a lawyer, I would have BEEN a lawyer"

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

Date: 20 Jan 89 19:21:56 GMT
From: hpda!hpcupt1![e-mail]  (Andrew Valencia(Seattle))
Subject: security (was Re: Ciphers and stuff)

/ hpcupt1:rec.ham-radio.packet / [e-mail] (Phil Karn) /  9:46 pm  Jan 19, 1989 /
>> Why not just encrypt the checksum and include it in the packet?
>This is a very weak scheme, for two reasons:
> <two good reasons follow...>

    Yes, seems right.  How about the second part of my suggestion?
CRC-32 would make the dictionary quite large.  Or make up a CRC-64 (or is
there one already in existence?) And what if this CRC were also included
only encrypted in the packet?  Also, randomly pick its position within
the encrypted block, and include bits in the block telling where to get it
from.  Do these start to get at the heart of how to identify the packet, or
am I just hacking at an already-hashed Bad Idea?

            73s... Andy

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

End of PACKET-RADIO Digest
******************************
22-Jan-89 01:46:29-MST,1532;000000000000
Return-Path: <[e-mail]>
Date: Sun, 22 Jan 89 01:30:48 MST
From: [e-mail]
Reply-To: [e-mail]
Subject: PACKET-RADIO Digest V89 #20
To: [e-mail]

PACKET-RADIO Digest         Sun, 22 Jan 89       Volume 89 : Issue  20

Today's Topics:
               Packet on 29.050
----------------------------------------------------------------------

Date: 21 Jan 89 15:40:06 GMT
From: att!whuts!homxb!hotps!ka2qhd!@ucbvax.Berkeley.EDU  (John D Ocean NJ)
Subject: Packet on 29.050

Netters... Regarding 29.050 1200 baud packet... Thought I read about 1200 ok
on "above 29mhz" (ofcourse bandplan considerations)? I am a frequenter of the
300 baud stuff on 28102 ish... I've been hearing 1200 baud activity on 28201
and was wondering is it was really ok there??? (I understand that how wide ur
signal becomes is the real factor, but I dont have a spect, analyzer handy at
the moment 8-) so... ) If anyones SURE 1200 is ok on 28201, Im sure im not the
only one looking to hear it. Locally on phone I keep hearing "gee, I dunno..".
Best 73 de johnd/ka2qhd

--
FAX: [phone] * PACKET: ka2qhd@nn2z * KA2QHD/NN2Z USENET NEWS GATEWAY *
UUCP: ucbvax!rutgers!petsd!pedsga!johnd            KA2QHD-1 145.05,144.97 *
Voice: 201-870-4093   Quote: GUNS DONT KILL PEOPLE, NJ CAR INSURANCE DOES!

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

End of PACKET-RADIO Digest
******************************
23-Jan-89 01:44:53-MST,3765;000000000000
Return-Path: <[e-mail]>
Date: Mon, 23 Jan 89 01:32:27 MST
From: [e-mail]
Reply-To: [e-mail]
Subject: PACKET-RADIO Digest V89 #21
To: [e-mail]

PACKET-RADIO Digest         Mon, 23 Jan 89       Volume 89 : Issue  21

Today's Topics:
              Battery operated printers?
              Ciphers and stuff
             NORD><LINK software releases
              WANTED: KA9Q UNIX patches
----------------------------------------------------------------------

Date: 21 Jan 89 21:41:00 GMT
From: asuvax!stjhmc!f1.n234.z1.fidonet.org![e-mail]  (Jim Grubs)
Subject: Battery operated printers?

 > From: [e-mail] (James Paul)
 > Date: 18 Jan 89 02:01:58 GMT
 > Organization: California State Univ., Fresno
 > Message-ID: <[e-mail]>
 > Newsgroups: rec.ham-radio.packet
 >
 > I've been looking for an _inexpensive_ battery operated printer for use
 > with my laptop (tandy 200) mobile emergency packet station. Purple

RS used to put out one for use with the Tandy 100. They also had a half width
color printer for the original Coco. I think it worked off batteries, too, but
I'm not positive.

73, Jim Grubs, W8GRT


--
St. Joseph's Hospital/Medical Center - Usenet <=> FidoNet Gateway
Uucp: ...{gatech,ames,rutgers}!ncar!noao!asuvax!stjhmc!234!1!Jim.Grubs
Internet: [e-mail]

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

Date: 22 Jan 89 01:44:53 GMT
From: att!ihlpf![e-mail]  (Unruh)
Subject: Ciphers and stuff

I believe you will find that the control operator of a satellite is allowed
to essentially "encrypt" command signals.  I am not sure what the exact wording
is, but it looks like the FCC took the potential damage that could be
done by someone playing with the bird into account.
John Unruh, NY9R

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

Date: 22 Jan 89 21:17:13 GMT
From: haven!trantor.umd.edu![e-mail]  (Louis A. Mamakos)
Subject: NORD><LINK software releases

In article <[e-mail]> [e-mail] writes:
>
> Detlef J. Schmidt
> Braunschweig F.R.G.
>
>C0033003 at dbstu1.bitnet
> [e-mail]


> [e-mail]")

I hate to throw a wet blanket on things, but please do not use UMD2.UMD.EDU
as a BITNET/Internet mail gateway.  Though you might think that it performs
this function, its use is indended for University of Maryland campus use
only.  We will feel free to drop any unauthorized traffic on the floor as
we see fit.

If you want to use a gateway that works, use the supported and funded ones,
like the one at CUNYVM.UMD.EDU.

> [e-mail]
> CUNYVM.CUNY.EDU![e-mail]




Louis A. Mamakos  WA3YMH    Internet: [e-mail]
University of Maryland, Computer Science Center - Systems Programming

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

Date: 23 Jan 89 02:32:48 GMT
From: osu-cis!killer!crlabs![e-mail]  (Chris Wiener)
Subject: WANTED: KA9Q UNIX patches

I'm having trouble getting SLIP working using the KA9Q package.  As I remember,
there was a bug in the 122587.1 version which made SLIP not work under UNIX.

Would someone please email me the patch to get SLIP working.  I have no access
to the internet.

                            Chris Wiener N2CR

--
Christopher Wiener N2CR
CR Labs, Cliffside Park, NJ
DOMAIN: [e-mail]    UCCP: ..!killer!crlabs!cwiener

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

End of PACKET-RADIO Digest
******************************
24-Jan-89 01:49:47-MST,8072;000000000000
Return-Path: <[e-mail]>
Date: Tue, 24 Jan 89 01:30:34 MST
From: [e-mail]
Reply-To: [e-mail]
Subject: PACKET-RADIO Digest V89 #22
To: [e-mail]

PACKET-RADIO Digest         Tue, 24 Jan 89       Volume 89 : Issue  22

Today's Topics:
              Battery operated printers?
        FCC Decision to reallocate 220-222 MHz
      How does one make double-sided PC boards? (2 msgs)
              Multiplayer games
               Packet on 29.050
----------------------------------------------------------------------

Date: Mon, 23 Jan 89 09:00:00 CST
From: Rick Troth <[e-mail]>
Subject: Battery operated printers?

    Hewlett-Packard makes some rugged little Think Jet printers that
run on batteries.  The trouble is ... they expect to talk to an HP-IL
interface like the option for your HP 41-C.  HP does a great job on
things like interface hardware,  but they really hurt when it comes to
compatibility.

                                   - 73 - N5CEI

"We become the sum of everything               Rick Troth <[e-mail]>
 we bring before our eyes." - Joe English          RICE ICSA VM Systems Support

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

Date: 23 Jan 89 18:53:00 EST
From: [e-mail]
Subject: FCC Decision to reallocate 220-222 MHz

    I'm doing some research concerning FCC General Docket No. 87-14
which reallocates the 220-222 MHz band to land mobile service.
I would like to have as much information as possible concerning the issues
involved which I will develop into a position paper.  Being new
to the technology, I'm only aware of limited material which documents
this decision.

As a doctoral student at the George Washington University (which is located
in Washington D.C. very close to the FCC) I would like to develop a paper
describing the current trends of the FCC under Fowler/Patrick in their
spectrum allocation methods.  I'm also a computer enthusiast who wants
to get into to packet radio and is disturbed by the FCC trend to tax,
charge, and limit computer networking when it is not done by a large
business for profit.

PLEASE forward annotations of any articles, materials etc... that could
enlighten me.  I understand the ARRL has been active in this area and I would
also like to get in touch with someone affiliated with their efforts.
Thanks for your help....

            Bill Yurcik

            "[e-mail]"
            [phone]

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

Date: 21 Jan 89 19:05:41 GMT
From: ssc-vax!uvicctr![e-mail]  (Doug Collinge)
Subject: How does one make double-sided PC boards?

In article <[e-mail]> [e-mail] ( Westfield NJ) writes:
>Can someone give me some suggestions on how to make my own double-sided PC
>boards?  Ever try to drill a board where the IC socket holes don't line up
>exactly? :-)

Simple trick:  drill holes before trying to register the sides.
--
        Doug Collinge
        School of Music, University of Victoria,
        PO Box 1700, Victoria, B.C., Canada,  V8W 2Y2
        [e-mail]
        decvax!uw-beaver!uvicctr!collinge
        ubc-vision!uvicctr!collinge
        __... ...__  _.. .  ..._ . __... __. _. .._  ..._._

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

Date: 24 Jan 89 00:03:55 GMT
From: oliveb!pyramid!ncc!adec23![e-mail]  (Mark Salyzyn)
Subject: How does one make double-sided PC boards?

In article <[e-mail]>, [e-mail] (Doug Collinge) writes:
> In article <[e-mail]> [e-mail] ( Westfield NJ) writes:
> >Can someone give me some suggestions on how to make my own double-sided PC
> Simple trick:  drill holes before trying to register the sides.
Even Simpler trick, align the negatives (back to back), tape them together on
three sides (NO Don't bend the tape, there is bound to be an overlap you can
tape flat). Place the PC baord into this pocket. Use two pieces of glass
and sandwich the PC board between them. Turn on light on one side for N minutes,
flip glass/PC/negative sandwich over and run under light for an additional N
minutes.

I know, you'd figure a simpler (but more reliable) method would take less
to verbalise :-}

Ta da 73's de VE6MGS (wanted VE6UU2, but they didn't allow numbers for last
three call letter, just tap it out in morse code to see what it sounds like ...)

-- Mark Salyzyn

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

Date: 23 Jan 89 14:53:59 GMT
From: encore!necis![e-mail]  (Rich Bono)
Subject: Multiplayer games

In article <[e-mail]>, [e-mail] (-David C. Kovar) writes:
> >>> I thought a *REAL* interesting game for packet would be one that could
> >>>evolve as different "players" entered and left the game (connected/disconnected)
>

    [ much deleted ]

> everyone up to date on the current state and initializing the game state
> of new players. If you're considering a dungeon type of game, you have to
> think about describing the entire world to any new player and insuring
> that updates get to everyone on a timely basis. On a reliable 10MB
> Ethernet this isn't too much of a problem. I'm not sure what packet is
> like so I can't make any comparisons. One possible solution, if you're
> playing such a game, is to distribute the database via another channel
> and distribute updates to it at some interval. Timing is a real pain.
> Do you want to go with a central game server machine or a game state that
> lives on all machines and can be updated from anywhere? Fun stuff.
>

    I would think the proper way (for packet) would be for the "game"
machine to keep the instance data for each user... This would mean many
files to be updated... but keep the traffic load on the network down to
a minimum.... Similar to a PBBS, where it keeps data on each user.  If a
user was not to "play" the game for a long period of time, his files would
be deleted, and he would have to start-up again...

    Someone else said some things that led me to beleive that they
were thinking of a graphics based game... That is always interesting, BUT
(I believe that) software for the "general" packet community should be
PLAIN ASCII TEXT.  The reason for this is because there is such a WIDE
range of end-user equipment out there... From model 100's, timex sinclairs,
to Macintoshes and IBM-AT's...  I have seen many end-users "terminals" not
know what to do with a Line-Feed!!... Most Comodore terminal emulation prints
a backslash as the british pound symbol...  Unless you wanted to limit the
use of the game to those with certain hardware, and to those using a special
software package on their end.

                Rich, NM1D

--
 /**************************************************************************\
 * Rich Bono (NM1D)    If I could only 'C' forever!!    [e-mail] *
 * [phone]         NEC Information Systems       NM1D @ WB1DSW-1     *
 \**************************************************************************/

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

Date: 23 Jan 89 04:04:03 GMT
From: att!whuts!homxb!hotps!ka2qhd![e-mail]  (Barry)
Subject: Packet on 29.050

Perhaps I missed the beginning of the discussion, but... a recent issue of
Gateway stated that packet is only legal on 10 meters in the CW segment
(28.0-28.3) at maximum of 300 baud. NOT at 1200 baud at 29 MHz. Don't have
the rules to quote, but maybe will be addressed in more detail in an upcoming
QST or Gateway.
--
-------------------------------------------------------------------------------
Dr. Barry Kutner, W2UP  Yardly,Penn.     UUCP: rutgers!petsd!tsdiag!ka2qhd!w2up
-------------------------------------------------------------------------------

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

End of PACKET-RADIO Digest
******************************
25-Jan-89 02:03:22-MST,7665;000000000000
Return-Path: <[e-mail]>
Date: Wed, 25 Jan 89 01:30:37 MST
From: [e-mail]
Reply-To: [e-mail]
Subject: PACKET-RADIO Digest V89 #23
To: [e-mail]

PACKET-RADIO Digest         Wed, 25 Jan 89       Volume 89 : Issue  23

Today's Topics:
              Battery operated printers?
                 Digicom news
           Kantronics battery back-up clock
               Packet on 29.050
               Packet on 29 MHz
            quo vadis ax.25 lvl2 committee
----------------------------------------------------------------------

Date: Tue, 24 Jan 89 10:30:14 est
From: <[e-mail]>
Subject: Battery operated printers?

CEO summary:
I have a DICONIX 150 (made by Kodak) which is EPSON/IBM compatible
and runs on 4 "C" cells (nicad or alkaline). It uses HP Thinkjet
cartridges and hasn't given me any trouble. They're advertised in
BYTE and all the PC magazines. They print on regular 8.5x11 sheets or
pin-feed fanfold (the print does look a little better if you use the
special ink-jet paper, though). It does graphics & everything.
Sorry, don't know the price as I got this one on a trade.
73 de Pete, KA1AXY
[e-mail]

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

Date: 24 Jan 89 17:13:03 GMT
From: att!whuts!homxb!hotps!ka2qhd![e-mail]  (Barry)
Subject: Digicom news

To: ALL DIGICOM USERS

To answer an often asked question about new versions of Digicom, please read
the following packet message which was forwarded to me by KJ4IT.


[42836] B   BID: 12190CDB0CZ
Path: N4QQ!W3IWI!SK0WE!SK0TM!SK5BB!SM6JZZ!SK6SA!LA1G!LA9FY!LA5G!LA8GE!LA6HX
Path: HB9AC!DB0CZ
Date: 21 Jan 89 18:57:50 Z
From: DF3MH@DB0CZ
To: DIGICO@EU
Subject: DC64/128-VERSIONS


de DF3MH @ DB0CZ

                 DIGICOM-VERSIONS
                 ================

Since numerous rumours are being spread that new DIGICOM-versions are avai-
lable, we comment as follows:

     As before, version 2.00 is the current version. All other version num-
     bers are the results of modifications made by 'hobby software experts'.
     These versions cannot, of course, be supplied by us. Version 2.00 is
     still the only version being supplied by us.

We kindly ask you to refrain from inquiring as to the availability of updated
versions. At the moment it cannot be predicted as to when new versions will
appear. There will be certainly nothing available from us before autumn 1989
or even 1990, although contemplations are already being made as to how a new
version should look. We thank you for your understanding.

Au, Jan 12th, 1989                     for the DIGICOM-TEAM  DF3MH / DB0CZ
                          (translated by DL5MBW)


I am in possession of 2 of the "unofficial" updates. One, called V2.03 has
several parameters with expanded range. Also, there is a new password feature
which allows remote access even if the REMOTE is OFF.  V3.00 is BBS oriented
with numbered messages, and can serve as a personal maildrop.

I am happy to answer technical questions about Digicom via Packet. PLEASE do
not ask (nor expect a reply to) any questions about orders, prices, etc. via
Packet. This is what the USPS is for (SASE please). Please do not send blank
disks or mailers any longer. My mailman has been folding them to fit in the
mailbox! Send a SASE for info on how to receive the updates, if you are
interested.

73 de W2UP @ KB3UD
Barry Kutner
614-B Palmer Lane
Yardley, PA 19067

.
w
q
s
--
-------------------------------------------------------------------------------
Dr. Barry Kutner, W2UP  Yardly,Penn.     UUCP: rutgers!petsd!tsdiag!ka2qhd!w2up
-------------------------------------------------------------------------------

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

Date: 23 Jan 89 15:03:45 GMT
From: oliveb!pyramid!prls!philabs!briar.philips.com![e-mail]  (Robert Casey;6282;3.57;$0201)
Subject: Kantronics battery back-up clock

Just wondering if anyone on the net has any experience with the accuracy of
the Kantronics battery back-up with clock module.  I got one for my KPC2, and
found that it was off 5 minutes after a week (as compared against wwv).  Sent
it back for another one, and the new one is better, but it looks like it is
off 2 min a week.  I would have expected better accuracy, as digital watches
commonly stay 1/4 min or better a week.  (I set the time to wwv by doing DA
and let the TNC run for a week, turn the power off and the on to load the
time from the module, and then ask the time with DA and compare it tp wwv).
73 de WA2ISE

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

Date: 24 Jan 89 23:36:18 GMT
From: tektronix!tekecs![e-mail]  (Michael T. Horne)
Subject: Packet on 29.050

I seem to remember an FCC rule stating 1200 baud packet is legal at 28 MHz
and above.  Could someone confirm this?

Michael T. Horne - KA7AXD    Interactive Technologies Division, Tektronix, Inc.
[e-mail]                                          [phone]

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

Date: 24 Jan 89 03:34:24 GMT
From: att!whuts!homxb!hotps!ka2qhd![e-mail]  (John Magliacane Wall Township NJ)
Subject: Packet on 29 MHz

I haven't done any research on the subject of operating AFSK packet radio on
a wideband FM carrier on 29 MHz, but it seems that is just MIGHT be okay.

The rules do indicate that, except for some CW-only segments, wideband FM
(5 KHz deviation) is allowed on 29 MHz and above. Since 1200 baud AFSK packet
operation IS allowed on 2 meter FM, where the same wideband FM bandwidth
restrictions apply, I feel that 29 MHz and 50 MHz might both be legal vehicles
for packet radio operation.

It's best to check the books just to be sure, but I think my logic makes sense!

73, John  KD2BD
--
 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: Tue, 24 Jan 89 09:51:08 MEZ
From: [e-mail]
Subject: quo vadis ax.25 lvl2 committee

Hi folks,

would some kind soul enlighten me please what's the actual status of the
AX.25 LVL2 committee's work ?
Last rumours I've noticed are of june '87 where something about
p-persistance, packet lenght, and round trip timing is mentioned.

Any new proposals out yet ? Any drafts ?
What's the address of the committee ? preferably an e-mail address

tnx 4 any response

p.s.: sometimes e-mails of vnet originators drop in here on my site.
      I'm sorry, can't reply via bitnet. vnet nodes are unknown on
      BITNET, you have to specify explicitly the return path and you
      have to open the gateway from vnet side for me.


73s Detlef ( DK4EG @ DK0MAV )            NORD><LINK

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

#include <disclaimer.std>


 Detlef J. Schmidt
 Braunschweig F.R.G.

C0033003 at dbstu1.bitnet
 [e-mail]
 [e-mail]")
 [e-mail]
 CUNYVM.CUNY.EDU![e-mail]
etc...
.

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

End of PACKET-RADIO Digest
******************************
26-Jan-89 01:53:27-MST,5269;000000000000
Return-Path: <[e-mail]>
Date: Thu, 26 Jan 89 01:30:43 MST
From: [e-mail]
Reply-To: [e-mail]
Subject: PACKET-RADIO Digest V89 #24
To: [e-mail]

PACKET-RADIO Digest         Thu, 26 Jan 89       Volume 89 : Issue  24

Today's Topics:
               AEA PK-88 Bug???
               KAM on busy channel?????
           Pre-processor program for IONCAP
            WA8DED code available?
----------------------------------------------------------------------

Date: 25 Jan 89 22:32:39 GMT
From: att!mtuxo![e-mail]  (xt147-K.REDDEN)
Subject: AEA PK-88 Bug???

I have an AEA PK-88 TNC that I have been using for two months with the
KA9Q TCP/IP package without any problems. Last week the TNC crashed in
KISS mode, and had to be powered off to clear it. Since then, the TNC
works fine in normal AX-25 mode, and can also go in and out of host (KISS)
mode and still work ok when in AX-25 mode.

If however, the TCP net program is ever run while in host mode, the PK-88
immediately crashes and must be powered off to recover. AEA said it
sound like a bad CPU and had me send it pack for warranty repair.

Today I saw mail from Dan Frank (W9NK) talking about a KISS bug on the PK-88,
that he said is not being fixed by AEA. Does anyone know what this bug
is an whether it is related to my problem??


Kevin Redden, wb2zlf
[phone]

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

Date: 21 Jan 89 03:02:12 GMT
From: att!alberta!dvinci![e-mail]  (Peter Hardie )
Subject: KAM on busy channel?????

Is anyone else out there having problems with the KAM on a busy channel,
particularly on HF (say 14.107 for example!)?
I have found that the KAM is extremely slow in handling retries on a busy
channel. It appears that if it transmits a packet and there is no response
then it times out as expected and retries again .... BUT if the channel is
busy at the time it would have retransmitted the packet it then restarts
the entire timeout period again, rather than finding the next clear spot.
This appears to be what is happening as I have done some timing tests on
the KAM with the PTT disconnected but the audio connected to the rig listening
to 14.107. With retry at 7 and frack at 2 seconds it can take up to 5 minutes!
for the thing to finally retry-out on a connect command.
I've talked to a sysop in California who has given up using the KAM because
of this problem. Anyone else had any experiences like this?
The problem is not affected by audio levels into the KAM and I also phoned
kantronics and either I didn't explain it properly or the guy that I talked
to didn;t think it was a problem.

73 de Pete VE5VA
uucp: ???
bitnet:  hardie@sask

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

Date: 25 Jan 89 17:31:11 GMT
From: mcdchg![e-mail]  (Nur Serinken)
Subject: Pre-processor program for IONCAP

Communications Research Centre has developed a pre-processor package
for the HF Ionospheric Communications Analysis and Prediction
program (IONCAP for IBM-pc). The data entry program is called
Ionhelp and runs on IBM-pc type computers.

Ionhelp generates output data in the format required by Ioncap
program. The built-in context sensitive help information,
pre-programmed selection menus simplifies data preparation. The data
validation for the data entered reduces operator errors.

The Ionhelp program and user's manual is available to the
interested organizations free of charge. To obtain a copy, send an
official letter requesting Ionhelp with a  formatted floppy to my
address. This package does not include Ioncap program.

Department of Communications makes no warranties as to the contents
of the Ionhelp manual, Ionhelp software package and specifically
disclaims any implied warranties of merchantability or fitness for
any particular purpose.  Also further reserves the right to make
changes to the specifications of the program and the contents of
the manual without obligation to notify any person or organization
of such changes.

Department of Communications makes no warranties on the results of
the Ioncap program and has no relationship to the originators and
suppliers of Ioncap package. Ioncap program and the user's manual
is property of the United States Government.

January 24, 1989

Dr. Nur Serinken
DIP
Communications Research Centre
P.O. Box 11490 Stn 'H',
Ottawa Ontario, K2H 8S2,
Canada
--
Nur  Serinken   The Communications Research Centre
[phone]          3701 Carling Avenue Ottawa, Ontario Canada
INTERNET: [e-mail]
UUCP: ...decvax!uunet!ai.toronto.edu!utgpu!bnr-vpa!bnr-rsc!dgbt!nur

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

Date: 21 Jan 89 02:55:29 GMT
From: att!alberta!dvinci![e-mail]  (Peter Hardie )
Subject: WA8DED code available?

A friend here would like to obtain the source code for the WA8DED EPROM
mod for the TNC1. Is it available and if so how can he get it?
Thanks.
73 de Pete ve5va
bitnet:  hardie@sask

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

End of PACKET-RADIO Digest
******************************
27-Jan-89 11:15:45-MST,6032;000000000000
Return-Path: <[e-mail]>
Date: Fri, 27 Jan 89 01:30:55 MST
From: [e-mail]
Reply-To: [e-mail]
Subject: PACKET-RADIO Digest V89 #25
To: [e-mail]

PACKET-RADIO Digest         Fri, 27 Jan 89       Volume 89 : Issue  25

Today's Topics:
              Battery operated printers?
         Italian AMPR-net Addresses (2 msgs)
        Packet station mods (cure for flickering leds)
----------------------------------------------------------------------

Date: 25 Jan 89 17:31:47 GMT
From: hpfcdc!hpldola!hp-lsd!hp-col![e-mail]  (Bdale Garbee)
Subject: Battery operated printers?

>The trouble is ... they expect to talk to an HP-IL
>interface like the option for your HP 41-C.

Ouch.  The Thinkjet is available in non-battery form for a variety of
interfaces, including HP-IB, HP-IL, RS-232, and Centronics.  There *is* a
version with batteries that supports Centronics, which is exactly what you want
for a laptop, in most cases.

My 1988 catalog shows that the part number is HP2225P, list price of $495,
with a cable available with part number 922197 for $49 list... though any
Centronics cable should work.

disclaimer:  I work for a different part of HP.  I've never used this
         particular model of Thinkjet, but have read pleased reviews from
         a number of folks outside the company.  All the other standard
         stuff...

73 - Bdale, N3EUA

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

Date: Thu, 26 Jan 89 11:11 SET
From: Bruno Peticone <[e-mail]>
Subject: Italian AMPR-net Addresses

Hi,

    does anybody know wath is the AMPR-net address space assigned to
    Italy and if does or doesn't exit an international coordinator
    for ham TCP/IP activities?

                  Thank you, Bruno  IK5FTK

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

Date: 26 Jan 89 15:29:23 GMT
From: [e-mail]  (Brian Kantor)
Subject: Italian AMPR-net Addresses

In article <[e-mail]> [e-mail]
(Bruno Peticone) writes:
>    does anybody know wath is the AMPR-net address space assigned to
>    Italy and if does or doesn't exit an international coordinator
>    for ham TCP/IP activities?
>                              Thank you, Bruno  IK5FTK

The ham IP address coordinator and some of the hosts in Italy are:

# 44.134        Italy           I2KFX
#
#               44.134.xxx.xxx - Italy
#               ----------------------
#               Pino Zollo I2KFX,
#               Milano; <HB9ZZ@RZETH5> (temporary)
#                    I2KFX @ I2JJR-1 RBBS (W0RLI)

# 44.134.001.xxx * I1
44.134.001.001    IW1ALW
44.134.001.002    IK1CHE
44.134.001.003    IW1BGS
44.134.001.004    IW1BBT
44.134.001.005    IW1BRM
44.134.001.006    IK1HJT
44.134.001.007    IW1AGP
44.134.001.008    IW1AYD
44.134.001.009    I1HUH
44.134.001.010    IW1PTG
44.134.001.011    I1XZZ

# 44.134.002.xxx * I2
44.134.002.001    I2BJS
44.134.002.002    I2KFX         # Pino Zollo, Milano
44.134.002.003    I2PHD
44.134.002.004    IW2BSG
44.134.002.005    I2XHO
44.134.002.006    I2JJR
44.134.002.007    I2OLW
44.134.002.008    IK2CAW
44.134.002.009    I2KBD
44.134.002.010    I2JDQ
44.134.002.011    I2JAQ

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

Date: 25 Jan 89 20:53:53 GMT
From: amdahl!pyramid!prls!philabs!briar.philips.com![e-mail]  (Robert Casey;6282;3.57;$0201)
Subject: Packet station mods (cure for flickering leds)

I put on the air a packet station consisting of a Kantronics KPC2 and a
modified Motorola HT220 radio with a 6W power amp.  I found that the
reciever squelch is a little slow to unsquelch, so I set the TNC to
detect via its software (SWDETENA command) signals from the unsquelched
radio.  This works fine, except that the RCV led on the TNC is
constantly flickering.  This is annoying, so I made this mod:  I
identified the squelch switch transister in the radio.  This transister
shorts to ground a bias circuit in the audio amp circuit, thus making
the radio quiet.  (this bias circuit also has the audio signal riding
on it, but the bias change does the real squelching)  I cut a trace on
the pcboard, isolating this switch transister, then ran a wire from
this transister collector to a new buffer circuit in the TNC.  This
buffer is just a pair of transisters connected in cascade to act as a
non-inverting buffer, the collector of the last transister is connected
to the non-ground side of the RCV led and the led side of the led's
resister.   When the radio's squelch switch transister is turned on by
the lack of a recieved signal, the TNC's RCV led is kept off by the
buffer shorting the led to ground.
                      _________
                      |   |+5v|
       antenna--|                     r   |   r   resister--led driver ic
    |--------------------------|          |   r   |----|
    | radio    Af--af amp--------->aud in |  _|--K    LED
    |            L_x_________________-----+-K_____|____|___gnd
    | squelch det---K  sq sw   |               TNC
    |                |         |<-----mic in-----------
    ________________gnd________|<-----ppt--------------

    -K is a transister   r is a resister   x is the cut trace

Of course, the same thing could be done by rewriting the TNC's microprocessor
code so the LED would light only on recieving a packet signal.  Not being a
software type, I found this hardware mod easier.
Now, the TNC recieves complete packets, and the RCV led really indicates a
packet comming in, and not just reciever hiss noise.  It probably took longer
to type this (vi has got to be the worst word processor program ever written
by man!) than it took to design this mod, and only a little less time to
actually build the mod!  Yea, it's trivial, but it got rid of an annoyance.

73 de WA2ISE

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

End of PACKET-RADIO Digest
******************************
28-Jan-89 02:00:50-MST,11618;000000000000
Return-Path: <[e-mail]>
Date: Sat, 28 Jan 89 01:30:46 MST
From: [e-mail]
Reply-To: [e-mail]
Subject: PACKET-RADIO Digest V89 #26
To: [e-mail]

PACKET-RADIO Digest         Sat, 28 Jan 89       Volume 89 : Issue  26

Today's Topics:
           How can I reduce phone charges?
        Packet station mods (cure for flickering leds)
           United States Packet Radio Stats
           What is latest version of KA9Q ?
            World Wide Packet Radio Stats
----------------------------------------------------------------------

Date: 18 Jan 89 18:41:00 GMT
From: mailrus!caen.engin.umich.edu![e-mail]  (Woody Kellum)
Subject: How can I reduce phone charges?

This seems to be the most appropriate place to ask this, so here
goes...

I live about a mile from my brothers house where I can install a phone
that is local to where I work. From my house, I  could easily run up $60/mo
phone charges by dialing direct. Short of moving my computer to his house
or running a wire cross-country, is there any cost-effective computer
equipment to allow me connetivity over that distance (or to work, which is
30 miles). Thanks  - Woody

--
Woody Kellum
Internet:  [e-mail]
Disclaimer: Whud he say?

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

Date: 27 Jan 89 19:47:38 GMT
From: mirror!necntc!necis![e-mail]  (Rich Bono)
Subject: Packet station mods (cure for flickering leds)

In article <[e-mail]>, [e-mail] (Robert Casey;6282;3.57;$0201) writes:
> I put on the air a packet station consisting of a Kantronics KPC2 and a
> modified Motorola HT220 radio with a 6W power amp.  I found that the
> reciever squelch is a little slow to unsquelch, so I set the TNC to
> detect via its software (SWDETENA command) signals from the unsquelched
> radio.  This works fine, except that the RCV led on the TNC is
> constantly flickering.  This is annoying, so I made this mod:  I
> identified the squelch switch transister in the radio.  This transister
> shorts to ground a bias circuit in the audio amp circuit, thus making
> the radio quiet.  (this bias circuit also has the audio signal riding

    [ deleted bunch of stuff]

  The kantronix (and maybe other TNC's too) have an input line called
somthing like 'cdetect'... (or some such thing)... It is on the connector
that goes to the radio... If you tie this line to a signal that goes to
ground when a desired signal is present, and enable the EXCARDET ( I may
have miss-spelled this.. I don't have my manual in front of me) then the
TNC will use this for the DCD function.  I use this line with my ICOM
gear (which has the proper signal coming right out the Mic connector
along with RX audio, PTT, and TX audio) all the time...

    Doing it this way works great for those times that you quickly
switch your radio to a voice repeater chanel to make a call... When the
squelch is open on the radio, the TNC won't xmit a packet burst through
the repeater.

    I also use this feature to tie TWO TNC's to my one VHF radio
to allow for the maximum use of my radio equipment...  My wife can't
complain that my radio equipment doesn't get enough use... I counted
about 10 (yes TEN) people using my (one) ICOM radio the other night!!!

        6 using NM1D (AutoConference on KAM)
        1 using NM1D-1 (PBBS built into KPC-2)
        1 using NM1D-2 (DOSGATE on KPC-2)
        1 (could have been 4) using NM1D-3 (KA-NODE on KPC-2)
        1 using NM1D-4 (Alias as a digipeater in KPC-2)

    I am sorry I didn't have my HF gateway in the KAM active,
for That could have been in use also!!

    Of course this was all on the same frequency (145.070 MHz)
as two other PBBS's and a NET-ROM, and, and, and,...

                Rich, NM1D
--
 /**************************************************************************\
 * Rich Bono (NM1D)    If I could only 'C' forever!!    [e-mail] *
 * [phone]         NEC Information Systems       NM1D @ WB1DSW-1     *
 \**************************************************************************/

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

Date: Fri, 27 Jan 89 11:55:29 EST
From: D H Bennett AMCRM-FTM  <[e-mail]>
Subject: United States Packet Radio Stats

           United States
          Recap by State
         As of 01-27-1989
         by K4NGC

The  following  is a computed recap of  the
WWPACKET.DBF file I maintain for the United
States.  It reflects the number and type of
activities  by  state.   If  you  have  any
changes to this file please address them to
K4NGC @ K4NGC.

State            PBBS  DIGI  TOTAL  PERCENT
---------------- ----  ----  -----  -------
Alabama            26    35    61     2.21%
Alaska              8    19    27     0.98%
Arizona            37    23    60     2.17%
Arkansas           14    19    33     1.20%
California        146    87   233     8.44%
Colorado           44    69   113     4.09%
Connecticut        23    18    41     1.48%
Delaware            3     3     6     0.22%
Dist of Columbia    0     1     1     0.04%
Florida            81    94   175     6.34%
Georgia            26    29    55     1.99%
Guam                0     0     0     0.00%
Hawaii             10    10    20     0.72%
Idaho               2     7     9     0.33%
Illinois           32    32    64     2.32%
Indiana            43    59   102     3.69%
Iowa               18    15    33     1.20%
Kansas             19    10    29     1.05%
Kentucky           17    41    58     2.10%
Louisiana          16     4    20     0.72%
Maine               9    11    20     0.72%
Maryland           47    58   105     3.80%
Massachusetts      41    28    69     2.50%
Michigan           39    24    63     2.28%
Minnesota          11    24    35     1.27%
Mississippi        13     6    19     0.69%
Missouri           22    43    65     2.35%
Montana            14    21    35     1.27%
Nebraska           11    19    30     1.09%
Nevada              1    14    15     0.54%
New Hampshire      16    15    31     1.12%
New Jersey         66    43   109     3.95%
New Mexico         16    17    33     1.20%
New York           86    57   143     5.18%
North Carolina     21    23    44     1.59%
North Dakota        7     5    12     0.43%
Ohio               62    60   122     4.42%
Oklahoma           15    25    40     1.45%
Oregon              8     9    17     0.62%
Pennsylvania       63    49   112     4.06%
Puerto Rico         0     0     0     0.00%
Rhode Island        5     4     9     0.33%
South Carolina     19    11    30     1.09%
South Dakota        6    11    17     0.62%
Tennessee          22    18    40     1.45%
Texas              59    27    86     3.11%
Utah                9    32    41     1.48%
Vermont             8     7    15     0.54%
Virginia           42    66   108     3.91%
Virgin Islands      0     0     0     0.00%
Washington         30    20    50     1.81%
West Virginia       6    12    18     0.65%
Wisconsin          29    24    53     1.92%
Wyoming            11    16    27     0.98%
         ----  ----  ----  --------
Total            1384  1377  2761   100.00%

The WWPACKET.DBF files are available on  my
LandLine Bulletin Board to all who want it.
My  Landline  BBS telephone number is  703-
680-5970.  These files are in text, ARC and
dBase formats.

Don Bennett (K4NGC)
15016 Carlsbad Road
Woodbridge, Va 22193
(Home) 703-670-4773
(Work) 703-274-9355/56
(LLBBS) 703-680-5970
(ARPANET) [e-mail]
(Packet) K4NGC @ K4NGC


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

Date: Fri, 27 Jan 89 08:27:00 cst
From: [e-mail]
Subject: What is latest version of KA9Q ?

I've been away from Phil's TCP/IP package for awhile and would like to start
playing with it again (ie, try and get some more activity going here in
the Twin Cities).  What is the most current version and on what server
would a person look to find it?  Several people here in town all claim
they have the most recent version...except all of them are different!

73 de Chris  N0JCF

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

Date: Fri, 27 Jan 89 11:54:59 EST
From: D H Bennett AMCRM-FTM  <[e-mail]>
Subject: World Wide Packet Radio Stats

             World Wide
         Recap by Countries
          As of 01-27-1989
              by K4NGC

The  following  is a computed recap of the World Wide
WWPACKET.DBF file I maintain.  It reflects the number
and type of activities by country.  If  you  have any
changes  to  this file please address them to K4NGC @
K4NGC.

State                      DIGI  PBBS  TOTAL  PERCENT
-------------------------- ----  ----  -----  -------
Argentina                     0     1     1     0.03%
Australia                    38    59    97     2.49%
Austria                       5     4     9     0.23%
Belgium                       0     5     5     0.13%
Canada                       25    96   121     3.10%
Colombia                     15    13    28     0.72%
Costa Rica                    6     2     8     0.20%
Denmark                       0    10    10     0.26%
Ecuador                       0     1     1     0.03%
Finland                      18    19    37     0.95%
France                        9    37    46     1.18%
Germany, Federal Rep         63    22    85     2.18%
Greece                        2     3     5     0.13%
Hong Kong                     0     9     9     0.23%
Hungary                       4     4     8     0.20%
Iceland                       0     2     2     0.05%
India                         0     1     1     0.03%
Indonesia                     0    16    16     0.41%
Ireland                       0     5     5     0.13%
Israel                        0     4     4     0.10%
Italy                        45    77   122     3.13%
Japan                         6   158   164     4.20%
Luxembourg                    1     0     1     0.03%
Malaysia                      0     2     2     0.05%
Mexico                        0     2     2     0.05%
New Zealand                   0     2     2     0.05%
Norway                       52    25    77     1.97%
Phillipines                   0    11    11     0.28%
South Africa                 13    12    25     0.64%
Spain                         0    10    10     0.26%
Sweden                        0    22    22     0.56%
Switzerland                   0     1     1     0.03%
United Kingdom                1   160   161     4.13%
United States              1377  1384  2761    70.74%
USSR                          0     1     1     0.03%
Venezuela                     0     1     1     0.03%
Yugoslavia                   18     4    22     0.56%
               ----  ----  ----  --------
Total                      2204  1699  3903   100.00%

The  WWPACKET.DBF files are available on my  LandLine
Bulletin Board to  all who want it.   My LandLine BBS
telephone number is 703-680-5970.  These files are in
Text, ARC and Dbase formats.

Don Bennett (K4NGC)
15016 Carlsbad Road
Woodbridge, Va 22193
(Home) 703-670-4773
(Work) 703-274-9355/56
(LLBBS) 703-680-5970
(ARPANET) [e-mail]
(Packet) K4NGC @ K4NGC


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

End of PACKET-RADIO Digest
******************************
29-Jan-89 01:41:10-MST,1634;000000000000
Return-Path: <[e-mail]>
Date: Sun, 29 Jan 89 01:30:38 MST
From: [e-mail]
Reply-To: [e-mail]
Subject: PACKET-RADIO Digest V89 #27
To: [e-mail]

PACKET-RADIO Digest         Sun, 29 Jan 89       Volume 89 : Issue  27

Today's Topics:
             PACKET-RADIO Digest V89 #26
             TTY-VT52-V100 Red Ryder Font
----------------------------------------------------------------------

Date: 28 Jan 89 21:41:00 EST
From: "SWEIGERT, DAVID" <[e-mail]>
Subject: PACKET-RADIO Digest V89 #26

I have just bought a new book on packet radio.

It is copyright 1988, written by K4TWJ, and published by howard Sams.

Topics: packet portable, mailboxing, networks, etc..

"Mastering Packet Radio" sells for $ 12.95 and has an ISBN number
of 0-672-22567-0, author is Dave Ingram.

WB9VKO
------

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

Date: 28 Jan 89 22:27:58 GMT
From: cs.utexas.edu!milano!lad-shrike![e-mail]  (R M Kriss)
Subject: TTY-VT52-V100 Red Ryder Font

Red Ryder 10.3 comes with the Font TTY-VT52-VT100 in 9, 12 & 20 points.

If someone has a 10 point version of this font, I sure would apprecate
a copy. Just put in in a seperate suitcase and E-mail in BinHex format.

The 9 is too small and the 12 is too big. Sure would like to have the
10 point version.

Dick Kriss
[e-mail]       ARPANET
KD5VU @ KB5PM                   Packet Radio

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

End of PACKET-RADIO Digest
******************************
30-Jan-89 01:57:48-MST,1024;000000000000
Return-Path: <[e-mail]>
Date: Mon, 30 Jan 89 01:31:10 MST
From: [e-mail]
Reply-To: [e-mail]
Subject: PACKET-RADIO Digest V89 #28
To: [e-mail]

PACKET-RADIO Digest         Mon, 30 Jan 89       Volume 89 : Issue  28

Today's Topics:
             PACKET-RADIO Digest V89 #27
----------------------------------------------------------------------

Date: 29 Jan 89 10:25:00 EST
From: "SWEIGERT, DAVID" <[e-mail]>
Subject: PACKET-RADIO Digest V89 #27

HR2510 modifications (10 meters)

  There is a ham in CALIF complying a list of mods to the PRESIDENT.
He advises there is a mod to run 60 watts, instaed of the 25 watts.  He is:

WA6OWM a WB6YMH


  You might want to leave him info via packet if
you know of other mods....

WB9VKO a W3ZH

dave
------

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

End of PACKET-RADIO Digest
******************************
31-Jan-89 01:46:45-MST,9185;000000000000
Return-Path: <[e-mail]>
Date: Tue, 31 Jan 89 01:30:29 MST
From: [e-mail]
Reply-To: [e-mail]
Subject: PACKET-RADIO Digest V89 #29
To: [e-mail]

PACKET-RADIO Digest         Tue, 31 Jan 89       Volume 89 : Issue  29

Today's Topics:
             Atari 800XL packet software
        Request for Packet Radio info (2 msgs)
                   TCP Info
            TCP Info - ka9q TCP/IP
            UUCP to Packet Radio Gateways?
              vk2sg rtty report
----------------------------------------------------------------------

Date: 30 Jan 89 14:05:32 GMT
From: voder!pyramid!prls!philabs!briar.philips.com![e-mail]  (Robert Casey;6282;3.57;$0201)
Subject: Atari 800XL packet software

copied from packet radio:
 Msg# TSP  Size Read To     @ BBS  From    Date  Time
 23705 BN   1437    0 NEED          DG3OW  890128 1846
 Subject: PACKET WITH ATARI 800XL

       de DG3OW @ DK0MAV

       Hello YL/OM!

       I'm using a Commodore plus/4 for Packet Radio in the moment, but
       I'd like to
       use this computer in Hannover only.
       At home I've got an ATARI 800XL. After a long search I found a
       programm for
       RTTY and CW for that computer, and I now hope, that possibly
       someone knows
       about a Packet Radio solution for the ATARI 800XL.
       If You can help me, please contact via DK0MAV

       TNX es 73 de Uwe - DG3OW

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

Date: Mon, 30 Jan 89 18:23:03 EST
From: Joseph Skoler <[e-mail]>
Subject: Request for Packet Radio info

Hello out there,
I'm operating mailnly on HF-SSB and am interested
in finding out more about Packet Radio (and RTTY,
SSTV etc.).  If anyone can send me the names of
some publications (i.e. starters manuals and such)
and where to find them IUd much appreciate it.
Also , If anyone has any suggestions about a
(simple homebrewed?) hook up from a Mac plus to a
Kenwood TS-530SP IUd sure like to here about it.
Thanks to all,
Joseph Skoler,  KC2YU
Skohc@Cunyvm
Compuserve 72446,3414
Genie Xtx50100

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

Date: Mon, 30 Jan 89 23:21:42 EST
From: Joseph Skoler <[e-mail]>
Subject: Request for Packet Radio info

Hello out there,
I'm operating mainly on HF-SSB and am interested
in finding out more about Packet Radio (and RTTY,
SSTV etc.).  If anyone can send me the names of
some publications (i.e. starters manuals and such)
and where to find them I'd much appreciate it.
Also , If anyone has any suggestions about a
(simple homebrewed?) hook up from a Mac plus to a
Kenwood TS-530SP I'd sure like to here about it.
Thanks to all,
Joseph Skoler,  KC2YU
Skohc@Cunyvm
Compuserve 72446,3414
Genie XTX50100

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

Date: Mon, 30 Jan 89 18:00:42 CET
From: [e-mail]
Subject: TCP Info

Subject:  ka9q TCP

Has there been a change to location for TCP info?  I have
been trying to acces PD1:<MISC.KA9Q-TCPIP> with no success for
the last week.  Where should I look?  Is there a way to get
a complete list of all the directories on PD1?
73, Jerry DA2CY/K7UPJ

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

Date: Mon, 30 Jan 1989  14:42 MST
From: Keith Petersen <[e-mail]>
Subject: TCP Info - ka9q TCP/IP

    Has there been a change to location for TCP info [at Simtel20]?  I have
    been trying to acces PD1:<MISC.KA9Q-TCPIP> with no success for
    the last week.  Where should I look?  Is there a way to get
    a complete list of all the directories on PD1?
    73, Jerry DA2CY/K7UPJ

Yes, the <MISC> directory was moved to the PD2: device as part of a
disk reorganization to equalize storage.

The ka9q TCP/IP files are in the PD2:<MISC.KA9Q-TCPIP> directory.

--Keith Petersen
Maintainer of the CP/M & MSDOS archives at wsmr-simtel20.army.mil [26.0.0.74]
DDN: [e-mail]
Uucp: {ames,decwrl,harvard,rutgers,ucbvax,uunet}!wsmr-simtel20.army.mil!w8sdz

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

Date: 30 Jan 89 19:22:51 GMT
From: att!alberta!ncc!adec23![e-mail]  (Mark Salyzyn)
Subject: UUCP to Packet Radio Gateways?

I am a new Amateur Radio Operator that doesn't wish to buy Packet Radio
equipment (I get enough of computers at work, don't need them at home) until
I've purchased my HF equipment. However, I would like to send some messages
between me (VE6MGS in Edmonton Alberta) and a friend in Toronto (VE3NUS).
My friend in Toronto has packet running on 2 (and I think 10) metres and
I believe a separate station license for his packet system (which I can
obtain later).

Is there a UUCP to packet gateway somewhere (hopefully in Edmonton Area)
that is capable of allowing e-mail to be exchanged between the two networks.
I'm sure that this service can not be provided on a general basis, and must
be heavily moderated.

If non, I would appreciate any e-mail comments on the legality of such a gateway
and the operation and setup of such a gateway.

73's de VE6MGS
-- Mark Salyzyn

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

Date: 30 Jan 89 01:04:40 GMT
From: killer!osu-cis!n8emr![e-mail]  (Gary Sanders )
Subject: vk2sg rtty report

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

RTTY DX NOTES FOR 27 JANUARY 1989
Bulletin ID: $RTDX2701

AFTER THE BRIEF BIT OF EXCITEMENT EARLY IN THE WEEK FROM WILLIS ISLAND
(VERY BRIEF), THE BANDS SEEM TO HAVE REVERTED TO THEIR NORMAL STATE, WITH
SOME GOOD DX IF YOU HAPPEN TO BE AROUND AT THE RIGHT TIME.  BUT THE NEXT
FEW WEEKS SHOULD SHOW MORE EXCITEMENT WITH SOME GOOD DX COMING UP.  OUR
THANKS THIS WEEK GO TO TG9VT, W1DA, VE3GU, OD5NG, I5FLN AND VK2EG.  THANKS
CHAPS FOR YOUR ASSISTANCE.

BANDPASS:

THURSDAY:
9K2DZ    14072 KHZ  AT  0400Z  ARQ
FK8BK    14074 KHZ  AT  1200Z  ARQ
RL8PYL   14090 KHZ  AT  1430Z
YI1BGD   14085 KHZ  AT  1457Z  QSL
3DA0AL   14088 KHZ  AT  1840Z  QSL
VK9ZW    28078 KHZ  AT  2145Z  QSL

FRIDAY:
OD5NG    14082 KHZ  AT  0600Z
VK9ZW    28081 KHZ  AT  2130Z
HK0BKX   21088 KHZ  AT  2240Z

SATURDAY:
EA8AVV   14075 KHZ  AT  0142Z  ARQ
J73EH    14083 KHZ  AT  0323Z
4U1ITU   14087 KHZ  AT  0745Z  QSL
TR8KMJ   14075 KHZ  AT  1750Z  QSL
VU2JX    14089 KHZ  AT  1803Z
9K2EC    14074 KHZ  AT  2033Z  ARQ
9Y4IBN   14081 KHZ  AT  2033Z

SUNDAY:
FM5FA    14090 KHZ  AT  0200Z
4U1ITU   21091 KHZ  AT  1410Z
CT3FF    21092 KHZ  AT  1515Z
FM5FA    21093 KHZ  AT  2128Z
4U1ITU   14087 KHZ  AT  2127Z
FO5LQ    21090 KHZ  AT  2128Z
VU2IJ    14085 KHZ  AT  2110Z

MONDAY:
J73EH    14083 KHZ  AT  0154Z

TUESDAY:
FO5MA    14092 KHZ  AT  0325Z

WEDNESDAY:
PZ1DX    14083 KHZ  AT  0315Z
FO5MA    14087 KHZ  AT  1015Z

QSL INFORMATION.

QSL CARDS FOR VK9ZM AND VK9ZW GO VIA NM2L.
3DA0AL COLLECTS HIS CARDS FROM BOX 549, MBABANE, SWAZILAND.
THE LATEST 4U1ITU CARDS GO VIA P.O. BOX 124, LUCE CEDEX 28113, FRANCE.
CARDS FOR TR8KMJ GO TO P.O. BOX 129, GABON.
YI1BGD CARDS GO VIA BOX 7075, BAGHDAD, IRAQ.

NOTES OF INTEREST.

THERE IS A REPORT THAT TWO OF THE RUSSIAN CREW WHO WILL BE GOING TO
VIETNAM WILL CALL IN AT SPRATLEY ISLAND ON THEIR WAY.  IT IS HOPED THAT
THEY GET A BETTER RECEPTION THAN THE LAST GROUP WHO TRIED TO OPERATE FROM
THERE.  THE RUSSIAN GROUP WILL OPERATE FROM VIETNAM (3W0-3W1-3W2) FROM
JANUARY 30TH TO FEBRUARY 10TH, AFTER WHICH THEY WILL PROCEED TO LAOS (XW8)
TO OPERATE FROM FEBRUARY 10TH UNTIL FEBRUARY 20TH.  IT HAS BEEN SAID THAT
THEY WILL HAVE RTTY GEAR WITH THEM IN 3W0 LAND, BUT THERE IS STILL SOME
DOUBT ABOUT RTTY IN XW8.  ALSO SPRATLEY IS A VERY BIG QUESTION MARK FOR
RTTY.

IN FEBRUARY WE HAVE, OF COURSE, THE XW8 GROUP OPERATING.  BUT ALSO WE HAVE
N3JT GOING BACK TO (HK0) SAN ANDRES FROM 15-22 FEBRUARY, IF HE CAN GET THE
TIME OFF.

LACCADIVES (VU7) SHOULD APPEAR LATE FEBRUARY OR EARLY MARCH.  WELL, THAT IS
THE LATEST STORY.

MARCH WILL SEE DJ6JC GOING TO BENIN AS TY6JC.  EXPECTED DATES WILL BE
AROUND EASTER, AND WILL BE FOUR DAYS.

ZL1AMO WILL BE GOING TO NORTH COOK ISLANDS AROUND THE MIDDLE OF THE
MONTH.

EARLY MAY WILL SEE XF4C ACTIVE FROM REVILLA GIGEDO BY XE1JEO, WE HOPE.

THERE SHOULD BE OPERATION FROM ANGOLA (D2) FOR A PERIOD OF SIX MONTHS BY AN
ITALIAN STATION.

QSL THE VIETNAM/LAOS GROUP TO PO BOX 49, TEMIRTAU, 472300, KAZAKH REP.,
USSR.

JOHN TG9VT ADVISES THAT HE NEEDS DX INFORMATION, AND STORIES FOR HIS DX
COLUMN IN THE RTTY JOURNAL.  CALL JOHN ON 14074 KHZ WHERE HIS ARQ MAILBOX
IS UP FROM ABT 0500 TO 1200 Z, AND ON RTTY FROM 1500Z TO 2200Z 14085.63,
WEEKDAYS, WX PERMITTING

GL DE DX1 (VK2SG)
Edited for packet distribution and relayed by Tad, KT7H @ KE7OM.  Thanks
to TG9VT and W9CD for relaying.

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

End of PACKET-RADIO Digest
******************************
31-Jan-89 18:37:36-MST,17908;000000000000
Mail-From: KPETERSEN created at 31-Jan-89 18:28:48
Return-Path: <[e-mail]>
Date: Tue, 31 Jan 89 18:28:47 MST
From: [e-mail]
Reply-To: [e-mail]
Subject: PACKET-RADIO Digest V89 #30
To: [e-mail]

PACKET-RADIO Digest         Tue, 31 Jan 89       Volume 89 : Issue  30

Today's Topics:
      A comparison between NET/ROM and TheNet (longish)
----------------------------------------------------------------------

Date: Tue, 31 Jan 89 12:07:21 EST
From: [e-mail] (Michael Chepponis)
Subject: A comparison between NET/ROM and TheNet (longish)

NET/ROM vs. TheNet, a Software Comparison


During the late summer of 1988, I obtained the source files of NET/ROM 1.3
from the author and the source files of TheNet version 1.0/1.1 from local
sources in order to do an independent comparison in light of claims by
Software 2000 of copyright infringement by the Northern German Packet Group,
NORD><LINK. This document reports my findings.

NET/ROM is a firmware replacement which converts a regulation TNC-2 to a
packet radio network node controller.  It was written by Ronald Raikes,
WA8DED.  Although I am a packet enthusiast, I have no connection with
Software 2000 nor any proprietary interest in NET/ROM.  My interest in doing
this evaluation was purely technical.


First Things First

I started this activity by copying all the NET/ROM and TheNet source files
to my hard disk.  After removing all tabs, the files were printed on a laser
printer and separated into two 3-ring binders.  After considerable time
reviewing the 2-inch stack of listings wondering how to attack the project,
I discovered a curious and consistent similarity.  Some routines in one set
appeared to have a counterpart routine in the other binder; they were of
similar lengths, had the same number of formal calling parameters, same
number of local variables, and virtually identical form of construction.

I decided to create a cross-reference table of routine names and their
associated file names so I could keep track of this manual progress through
the files.  I "visited" every routine in the NET/ROM binder and copied the
procedure name, the file name, and the number of parameters into a text
file.  After sorting on the column of procedure names, I printed the file to
use as a worksheet.

I began to search through the set of TheNet files to find some correlation
with the NET/ROM routines I had already cataloged. By narrowing each search
pass to just those files dealing with a single protocol layer (starting with
layer 7), the table was filled in rather quickly.  Nevertheless, this effort
took over two weeks of part-time work.  For every NET/ROM routine, there was
a matching NordLink routine, but I had four TheNet routines left over which
had no match in NET/ROM.  The result of this effort was a four page
reference of all routine and file names and number of parameters.

I compared every pair of routines visually, line by line.  When I ran my
index fingers down each page, the same pattern recurred; an IF followed by
an assignment, followed by a procedure call, followed by a pointer
increment, followed by a call, etc., ad infinitum.  Every called procedure
in TheNet could be cross- referenced to the matching NET/ROM routine I had
cataloged.  When NET/ROM called a C routine, so did TheNet.  When assembly
language was called, so did TheNet.  I became progressively more frustrated
at the slim prospect of doing this by some automated means, but I continued
with this painstaking process to the bitter end.


Findings

o  There are 234 NET/ROM routines in version 1.3.  I define "routine" as an
executable code segment named as public (global), which includes all C
functions and entry points to assembly language code.

o  One routine in NET/ROM, crlf (file LAYER7CN.C), is not referenced therein
and has no complement in TheNet.  This widowed code was probably an
oversight from a previous release of the firmware.

o  One routine in NET/ROM, staind (file TNC2N.MAC), is not referenced.  The
matching routine is referenced and used in TheNet as STAled (file TNL1.MAC).

o  Of the remaining 232 routines in NET/ROM, all are duplicated in TheNet
with identical numbers and types of passed parameters.  In cases where there
are two or more parameters in calling arguments, the order has been
consistently reversed in TheNet.  Reversing the order of the parameters was
no doubt due to an individual's preference.

o  In every TheNet C function, an identical number and type of auto variables
are allocated on the stack in the same order as they are in the
corresponding NET/ROM routine.

o  All structures in NET/ROM having preset data have an identical analogue in
TheNet including order and type of data initialized.  This includes all
character strings and procedure jump address tables.

o  TheNet routines l2init (in L2E.c), l3init (in TNL3.C), and inivar (in
TNL7A.C) differ from the corresponding NET/ROM routines only in that a
single statement has been deleted to remove callsign encryption.  l2init of
TheNet has one additional procedure call related to cold-booting.

o  Full duplex was later added to TheNet routine hstcmd (in TNL7C.C).  This
added a 20-line case 'F' to an existing switch statement and comprised three
if statements, six function calls, and two assignments.  In assembly
language, 16 bytes were required to complete this modification, including 3
lines in routine kicktx (in TNL1.MAC) and 11 lines of a new module, pushtx
(in TNL7B.C).  The IDENT command was renamed to INFO and the sysop's
password was initialized to a different string, both minor changes.

o  In NET/ROM layer 2, nine interrupt service routines dealing with low level
I/O and buffer allocation and de-allocation were manually recoded by the
author to ensure an adequate processing margin at 9600 bps.  These functions
were originally written in C for the AX.25 Level 2 user firmware for the
TNC-2.  An assembly language source file, created with a Q/C compiler
option, was used as a starting point.  It was then hand-optimized and
assembled.  This optimized set of assembly language functions is identical,
instruction for instruction, in TheNet (file L2D.C, #ifndef PORTABLE).

o  Two trivial routines, ccphig and ccplow, were added in TheNet to implement
the HIGH and LOW commands.  Each has 15 lines and comprises one if, three
procedure calls, and a switch with two cases.

o  There are minor differences in other assembly language files related to
NordLink's use of a later version of the C compiler (the Q/C compiler
supports in-line assembly language).  For example, the newer version of the
compiler can save one byte when clearing a double register.  In some cases,
TheNet used a variation on the subroutine entry macro.


o  TheNet uses a #define statement in its primary include file, ALL.H, to
define a preprocessor variable FIRMWARE.  When this variable is defined, the
source code is conditionally compiled into TheNet (the network node
controller), and when not defined, the code compiles into TheFirmware, a
replacement for the user firmware for the TNC-2.  The NET/ROM source is
similarly structured with a preprocessor variable, and conditionally
compiles the WA8DED AX.25 user firmware for the TNC-2.  That firmware is
available on many BBS, and is the foundation on which NET/ROM was built by
the author.

o  TheNet does not contain the code to support the PK-87 TNC. NET/ROM's
support for the PK-87 is conditionally compiled when a preprocessor variable
called PK87N is defined.

o  NET/ROM, in my opinion, is concise and easier to follow (notwithstanding
TheNet's extensive documentation in German).

Object File Comparison

I have not personally evaluated the hex files of the original and the
NordLink versions.  Members of NordLink on at least two occasions have
publicly suggested independent comparison of the binary files.  However,
they never recommended comparison at the source code level.  Many
well-meaning people in the U.S. have performed their own evaluations of the
programs' differences based on the only materials available to them, the hex
files. Their conclusions have ranged from "maybe 20-30 percent identical" to
"definitely a copy."  However, any judgment of the similarities of NET/ROM
and TheNet from the comparison of hex files is fallacious because of the
following:

o  A single difference in the relative placement of any global, local, or
static data item (simple item, table, structure, etc) will render slightly
different byte or word addresses. Since addresses comprise a major portion
of the object code, the hex address of the item will be different throughout
the module.

o  A minor addition or removal of code (full duplex, HIGH and LOW commands,
callsign encryption) will show as blocks of dissimilar code including
addresses of function entry points, followed by major discrepancies.

o  Even a minor reordering of object modules in the linking step will render
major differences in the hex file.  Sophisticated pattern matching programs
may be able to discover this reordering, however, jump addresses and
procedure entry points beyond the reordering point will change
significantly.

There is no possibility that the source programs for NET/ROM were obtained
by NordLink as they had never left the author's house until the electronic
version was loaned to me for review.  The only real determination of whether
TheNet is an original work can only be done at the source program level.


Evaluation

Based on a line-by-line comparison of the two products and 22 years of
software experience, I am convinced that the only way that TheNet could be
identical in the structure, calling sequences and variable definitions of
NET/ROM would be to have disassembled/de-compiled the object code from
NET/ROM.  TheNet is not an original development but rather a replica of the
thoughts, concepts, and the painstakingly developed design embodied in
NET/ROM.  According to NordLink, "disassembling NET/ROM and then rewriting
it in C would be silly."  However, since the source was not available, their
only alternative was to do exactly that - disassemble the binary code from a
NET/ROM 27C256 EPROM and construct a source program that would produce
identical binary code.


Disassembly and De-compilation Methodology

Without doubt, the starting point of this effort began with the low memory
and Q/C library routines, and the routing table structure and the layer
protocol definitions described in the NET/ROM documentation.  The hex files
of WA8DED's user firmware available in the public domain no doubt provided a
convenient set of low-level I/O routines.

Generating assembly language from object code is relatively simple;
disassemblers for all machine codes have been around a long time.
Converting assembly language to a higher order language like "C" requires
much more forbearance.

The Q/C compiler traces its heritage to Ron Cain's Small-C from the 8080
CP/M world (Hendrix "A Small-C Compiler").  It is a non- optimizing compiler
and, consequently, the structure of its generated object code for any C
construct is predictable and consistent.  With suitable automated tools,
much manual intervention and an intimate knowledge of the compiler's code
generator, any section of code suspected of originating from this C compiler
can be reconstructed into a syntactically correct source program.

Any programmer who has delved into compiler-generated object code will
recognize that variable names and function names do not exist at this stage,
merely address references to data and subprograms.  However, if meaningful
names are assigned to those addresses, and suitable comments placed in the
source code, the original meaning and intent of a function in terms of a
network controller will iteratively become evident.  I say iteratively
because a source program, when compiled, can eventually be modified to
generate a given object program.  When all object modules are linked in the
same order as the thing you're copying, an identical executable module will
result.  Minor changes of data location, removing callsign encryption,
adding full duplex or other minor features could confuse a (hex file)
comparison program, leading one to erroneously conclude that the executable
modules are very different.


Source Code Comparison

My visual examination of each routine showed that source code from both
programs was identical, statement by statement, with only variable, data,
and structure names changing.  However, the source code does not lend itself
well to comparison by automatic means.  Because the object code was analyzed
and equivalent source code was reconstructed from it, virtually no procedure
names or variable names are the same.  To perform even a cursory
quantitative evaluation, one would have to remove all comments and white
space from both versions, transliterate variable and procedure names into
common, but arbitrary, names and convert both sources to either upper or
lower case before a programmatic comparison could be attempted.

Additional problems thwarting an automatic comparison was TheNet's:

o  use of typedef, for example, 'typedef int VOID' and 'typedef unsigned
BOOLEAN', which created synonyms for common data types

o  use of #define to create new language constructs, for example, '#define
LOOP for(;;)' for an infinite loop

o  use of numeric constants in the source whose meaning was not necessarily
understood.  On the other hand, both programs made considerable use of
#define to give (different) names to important and frequently used constants

o  source coding variations when using a different set of data structures
(note: code generated to access the data was the same as NET/ROM's accessing
its own data structures!).

However, even after the automatic comparison, a manual examination would
still be necessary to resolve differences such as:

    if (a != 0) {...}
and
    if (!a) {...}

as being equivalent and identical, and to recognize that code segments such
as

    a = b; for (i=0; i<max; ++i,++a) {...}

and
    for (a=b,i=0; i<max; ++i,++a) {...}

or
    for (xyz=foo,w=0; w<limit; ++w,++xyz) {...}

are entirely equivalent and would compile to identical object code.

As a better example of this comparison difficulty, consider NET/ROM's layer
7 routine, validc, and TheNet's routine, fvalca, which validate a callsign:


    validc(call,valflg) char *call; unsigned int valflg; {
        return(*call== ' ' ? FALSE :
        (valflg == FALSE ? TRUE : valcsc(call)));
    }

    fvalca(pflag, call) char *call; BOOLEAN pflag; {
        if (*call == ' ' )return(0);
        if (!pflag) return (1);
        return (valcal(call));
    }

These equivalent routines return 1 if the callsign is valid; 0 or -1 if not
valid.  Although they look quite different to the untrained eye, the curious
programmer is invited to pass these examples through his favorite C compiler
(I used Borland's Turbo C) and generate the intermediate assembly language;
you don't necessarily need to target to a Z-80 or to a non-stack machine.
These listings are identical if the formal argument parameters in fvalca are
reversed, TRUE and FALSE are defined as 1 and 0 respectively (as they are in
NET/ROM and TheNet with #define statements), and typedef'ing BOOLEAN as
unsigned (as done in TheNet).  Other less trivial examples I have run
through my compiler show the same consistent comparisons at the assembly
language level.

One of the more complicated routines extracted from both versions was the
level 4 receive function l4rx (TheNet file TNL4.C) and l4rcve (NET/ROM file
LAYER4.C).  This particular pair of procedures was selected because it was
representative of an extensive use of C structures and pointers.  I was
careful to insert (#include) the same files used in the parent source file
and to reverse the arguments in TheNet's function calls before compiling.
There were five minor differences in the 631-line assembly language files
produced.  The object file length for NET/ROM was 2599; TheNet's was 2577.

This slight difference can be attributed to my use of a compiler that is
targeted to the 8086 family, stack-oriented processors unlike the Z-80; it
merely is the only C compiler I have.  As mentioned previously, Q/C is not
an optimizing compiler and it produces code that is not stack-oriented.
Optimization is standard for my compiler and cannot be disabled.  Minor
source coding variations can account for the order and manner in which
addresses are calculated.


Conclusion

It is my conclusion, and I believe would be the conclusion of any rational
reviewer, that TheNet is not an original development but rather a direct
copy of NET/ROM.  This exercise has left no question in my mind about the
method that NordLink used to make their "original" design fully compatible
with NET/ROM.  Rather than start with the description of the layer protocols
and the routing table, and then independently design and build a compatible
product (as the author hoped somebody would), they disassembled Software
2000's product and reused the design in its entirety, procedure by
procedure, and steadfastly proclaimed original work.  According to NordLink,
"it is truly a new and innovative program with many new features".  I have
seen no evidence of originality, innovation, significant enhancements or
functional changes.

Thomas M. Allen, WA6IGY
CIS [72537,1143]
January 1989

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

End of PACKET-RADIO Digest
******************************