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

Text File | 1993-12-31 | 234.8 KB | 5,735 lines

Fri,  1 Mar 91 04:30:07 PST
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Reply-To: [e-mail]
Subject: Packet-Radio Digest V91 #56
To: packet-radio


Packet-Radio Digest         Fri,  1 Mar 91       Volume 91 : Issue  56

Today's Topics:
            Grapes/PI card wanted

Send Replies or notes for publication to: <[e-mail]>
Send subscription requests to: <[e-mail]>
Problems you can't solve otherwise to [e-mail].

Archives of past issues of the Packet-Radio Digest are available
(by FTP only) from UCSD.Edu in directory "mailarchives/packet-radio".

We trust that readers are intelligent enough to realize that all text
herein consists of personal comments and does not represent the official
policies or positions of any party.  Your mileage may vary.  So there.
----------------------------------------------------------------------

Date: Thu, 28 Feb 91 16:58
From: "Olaf Erb(DC1IK)"                           <[e-mail]>
Subject: Grapes/PI card wanted
To: [e-mail]

Does anyone know how to get info or addresses/prices about this
cards? We want to build up some of this 56kbps modems...
Many thanx,
Olaf
--
[e-mail]  [e-mail]  [e-mail]

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

End of Packet-Radio Digest
******************************
Date: Sat,  2 Mar 91 04:30:08 PST
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Reply-To: [e-mail]
Subject: Packet-Radio Digest V91 #57
To: packet-radio


Packet-Radio Digest         Sat,  2 Mar 91       Volume 91 : Issue  57

Today's Topics:
            Grapes/PI card wanted
            HF Packet A Silly Idea

Send Replies or notes for publication to: <[e-mail]>
Send subscription requests to: <[e-mail]>
Problems you can't solve otherwise to [e-mail].

Archives of past issues of the Packet-Radio Digest are available
(by FTP only) from UCSD.Edu in directory "mailarchives/packet-radio".

We trust that readers are intelligent enough to realize that all text
herein consists of personal comments and does not represent the official
policies or positions of any party.  Your mileage may vary.  So there.
----------------------------------------------------------------------

Date: Fri, 1 Mar 91 08:42:09 EST
From: [e-mail] (Barry McLarnon)
Subject: Grapes/PI card wanted
To: [e-mail]

The GRAPES WA4DSY 56kbps modem and the Ottawa PI card are separate items,
from separate groups.  All inquiries about the PI card should go to me:

[e-mail]

The contact for info on the modem is Doug Drye, KD4NC:

...gatech!emory!kd4nc!dug

Barry VE3JF

Barry McLarnon                  |  Internet: [e-mail]
Communications Research Centre  |  PBBS: [e-mail]
Ottawa, Canada  K2H 8S2         |  AMPRnet: [e-mail]3jf [44.135.96.7]

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

Date: Fri, 1 Mar 91 09:08 EDT
From: <[e-mail]>
Subject: HF Packet A Silly Idea
To: [e-mail]

Original Article:
True. Of course, at 300 bps, transmission time is less, so some types
of fading and QRM might be less likely to affect Packet. I agree that
AMTOR might be more resilient to poor path conditions, though. You
make a good point.

--
James L. Paul

***** Reply:

You bet Amtor is more resiliant!  I have seen stuff go through
even when you can hardly hear the station!  It's a super mode!
--Betsey Doane, K1EIC

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

End of Packet-Radio Digest
******************************
Date: Tue,  5 Mar 91 04:30:09 PST
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Reply-To: [e-mail]
Subject: Packet-Radio Digest V91 #58
To: packet-radio


Packet-Radio Digest         Tue,  5 Mar 91       Volume 91 : Issue  58

Today's Topics:
             TCP/IP, UUCP and HAM

Send Replies or notes for publication to: <[e-mail]>
Send subscription requests to: <[e-mail]>
Problems you can't solve otherwise to [e-mail].

Archives of past issues of the Packet-Radio Digest are available
(by FTP only) from UCSD.Edu in directory "mailarchives/packet-radio".

We trust that readers are intelligent enough to realize that all text
herein consists of personal comments and does not represent the official
policies or positions of any party.  Your mileage may vary.  So there.
----------------------------------------------------------------------

Date: 5 Mar 91 05:08:12 GMT
From: usc!zaphod.mps.ohio-state.edu!caen![e-mail]  (Ralph Seguin)
Subject: TCP/IP, UUCP and HAM
To: [e-mail]

Hi.  I have a friend who is curious whether or not it is possible to do TCP/IP
and UUCP via HAM radios.  He lives in Singapore (where network access and
phone calls to USA are EXPENSIVE!!).  What he's interested in doing is
getting a HAM radio, and using it for TCP/IP and UUCP.  Am I making any sense?
Can anybody help?  Please be verbose, as I know nothing of HAM radio.

            Thanks, Ralph

Ralph Seguin                    [e-mail]
536 South Forest Apt. #915      [e-mail]
Ann Arbor, MI 48104             [phone]

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

End of Packet-Radio Digest
******************************
Date: Wed,  6 Mar 91 04:30:07 PST
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Reply-To: [e-mail]
Subject: Packet-Radio Digest V91 #59
To: packet-radio


Packet-Radio Digest         Wed,  6 Mar 91       Volume 91 : Issue  59

Today's Topics:
         F6FBB BBS error in epurmess.ini file
        Terminal packet program for F6FBB BBS

Send Replies or notes for publication to: <[e-mail]>
Send subscription requests to: <[e-mail]>
Problems you can't solve otherwise to [e-mail].

Archives of past issues of the Packet-Radio Digest are available
(by FTP only) from UCSD.Edu in directory "mailarchives/packet-radio".

We trust that readers are intelligent enough to realize that all text
herein consists of personal comments and does not represent the official
policies or positions of any party.  Your mileage may vary.  So there.
----------------------------------------------------------------------

Date: Wed, 6 Mar 91 02:29:50 CST
From: [e-mail]
Subject: F6FBB BBS error in epurmess.ini file
To: [e-mail]

From:   HUTIN@PSI%EPSX25@MRGATE@PRSRTR
To:     "[e-mail]"@M_INTERNET@MRGATE@PRSRTR


  Hello all FBB software users,

A mistake was done in the 5.12 distribution. The example of EPURMESS.INI file
is not correct, as the Binary Mail directory is missing. Please correct this.

# definiion des parametres de l'epuration des messages.
#
# Directory fichiers messages
\MAIL\
#
# Directory fichiers messages binaires
\BINMAIL\                                    <-- Line missing
#                                            ================
# Directory archive messages
\OLDMAIL\

The file is well discribed in the documentation.

I apologize for doing this mistake. Best 73 from Jean-Paul, F6FBB.

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

Date: Wed, 6 Mar 91 02:49:04 CST
From: [e-mail]
Subject: Terminal packet program for F6FBB BBS
To: [e-mail]

From:   HUTIN@PSI%EPSX25@MRGATE@SNDRTR
To:     "[e-mail]"@M_INTERNET@MRGATE@SNDRTR


I have upload on tomcat (bbs/f6fbb/tpk_163.zip) and on nic.funet.fi
a terminal packet program from fc1ebn. This program when uses with
a f6fbb BBS allows recovery from a crash during a yapp transfert.

73s Remi fe6cnb

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

End of Packet-Radio Digest
******************************
Date: Thu,  7 Mar 91 04:30:09 PST
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Reply-To: [e-mail]
Subject: Packet-Radio Digest V91 #60
To: packet-radio


Packet-Radio Digest         Thu,  7 Mar 91       Volume 91 : Issue  60

Today's Topics:
             Help with TCP & Grapes Modem
         Looking for info on O'Neill Communications.

Send Replies or notes for publication to: <[e-mail]>
Send subscription requests to: <[e-mail]>
Problems you can't solve otherwise to [e-mail].

Archives of past issues of the Packet-Radio Digest are available
(by FTP only) from UCSD.Edu in directory "mailarchives/packet-radio".

We trust that readers are intelligent enough to realize that all text
herein consists of personal comments and does not represent the official
policies or positions of any party.  Your mileage may vary.  So there.
----------------------------------------------------------------------

Date: 6 Mar 91 21:54:53 GMT
From: mintaka!olivea!samsung!zaphod.mps.ohio-state.edu!wuarchive!swbatl![e-mail]  (Jim Burnes - 235-0709)
Subject: Help with TCP & Grapes Modem
To: [e-mail]

Anyone:

Can anybody help me find the following?

  1)  Phil Karn's Internet Address (KA9Q)
  2)  Anyone that belongs to or who can tell me the phone number
      of the people who make the GRAPES modem.  Are they on the
      Internet?
  3)  What is the street price for grapes modem and transverter
      unit for 220mhz (440mhz)?
  4)  I already have both an amiga and a xenix 386 box.  What kind
      of performance can I really expect to get.  Are we talking
      relatively error-free 56kb transmissions or is my transmitter
      receiver going to be coming down all the time.  I guess what
      I'm trying to say is, "How much is this going to cost me and
      once I get it setup is it going to be a nightmare to keep on
      the air?"

      Any help Appreciated,

      Jim Burnes


--
------------------------------------------+-----------------------------
Jim Burnes - System Engineer              !Its the Man in the Whitehouse
SouthWestern Bell Advanced Technology Labs!The Man under the steeple
Internet: [e-mail]       !Handin out Drugs to the

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

Date: 6 Mar 91 21:08:19 GMT
From: mintaka!ogicse!pdxgate!pdxgate.cs.pdx.edu![e-mail]  (Scott Peterson)
Subject: Looking for info on O'Neill Communications.
To: [e-mail]

In article <[e-mail]> [e-mail] (John Horvath) writes:

   Path: pdxgate!ogicse!hsdndev!think.com!zaphod.mps.ohio-state.edu!rpi!batcomputer!munnari.oz.au!johnh
   From: [e-mail] (John Horvath)
   Newsgroups: rec.ham-radio.packet,rec.ham-radio,rec.radio.amateur.packet,sci.electronics
   Keywords: LAWN modem supplier.
   Date: 5 Mar 91 02:44:01 GMT
   Sender: [e-mail]
   Lines: 16
   Xref: pdxgate rec.ham-radio.packet:1277 rec.ham-radio:9739 sci.electronics:5635
   Posted: Mon Mar  4 18:44:01 1991

   Hello.

       I am looking for address/telephone details for a company who supplies
       a LAWN interface unit (local-area wireless network) that connects to
       the serial port of a PC.

       The name of the company is: O'Neill Communications (Princeton, NJ).

       An article in June 1990 Byte on wireless LANs mentioned this company
       but gave no further details on their whereabouts.

   Thanks for any help.

   John (VK3DWT).

   (Sorry for the cross-posting)  :-)

O'Neill Communications
100 Thanet Circle
Princeton, NJ  08540
[phone]

I'm not affiliated with O'Neill, I'm just tracking developments in wireless
LANs.  This is by no means the only one.

If you're looking for a wireless ethernet-like network, I'm afraid this one
will disappoint you.  The information I have indicates the software included
provides support for file transfer and email.  No mention is made of file
sharing or a Novell driver.

See also:

LAN Magazine, September '90, pg 100 (LAWN and others)

LAN Times, October 22, '90, pg 23 (NCR WaveLan and others)

LAN Magazine, November, '90, pg 20 (Motorola's 18GHz ethernet "repeaters")


I'd like to take this opportunity to solicit leads on other wireless LAN
technologies.  I'm interested in all kinds, but especially general purpose
"802.x-like" technologies.

--- Scott Peterson
    [e-mail]
    (a.k.a.  {tektronix|verdix}!radix!sdp     - RadiSys Corp.)

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

End of Packet-Radio Digest
******************************
Date: Fri,  8 Mar 91 04:30:02 PST
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Reply-To: [e-mail]
Subject: Packet-Radio Digest V91 #61
To: packet-radio


Packet-Radio Digest         Fri,  8 Mar 91       Volume 91 : Issue  61

Today's Topics:
              Plee for NOS help
             TCP/IP, UUCP and HAM

Send Replies or notes for publication to: <[e-mail]>
Send subscription requests to: <[e-mail]>
Problems you can't solve otherwise to [e-mail].

Archives of past issues of the Packet-Radio Digest are available
(by FTP only) from UCSD.Edu in directory "mailarchives/packet-radio".

We trust that readers are intelligent enough to realize that all text
herein consists of personal comments and does not represent the official
policies or positions of any party.  Your mileage may vary.  So there.
----------------------------------------------------------------------

Date: 7 Mar 91 01:40:35 GMT
From: portal!cup.portal.com![e-mail]  (John L Ferguson)
Subject: Plee for NOS help
To: [e-mail]

A NOS question (since I'm having troubles with it).   Why is it that when
I do an   ne rou add ARA4 w0ljf-4 nos 192 w0ljf-4    and then try a
n c ARA4, ARA4 is treated like the real name instead of the alias, e.i.,
it tries to connect to ARA4 @ ARA4 and doesn't even go out over nos (nos
being my symbolic name of the tnc)?

John   KF0OU    [e-mail]

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

Date: 7 Mar 91 20:05:23 GMT
From: swrinde!zaphod.mps.ohio-state.edu!think.com!linus!linus!mir![e-mail]  (Douglas S. Rand)
Subject: TCP/IP, UUCP and HAM
To: [e-mail]

In article <[e-mail]>, [e-mail] (Ralph Seguin) writes:
> Hi.  I have a friend who is curious whether or not it is possible to do TCP/IP
> and UUCP via HAM radios.  He lives in Singapore (where network access and
> phone calls to USA are EXPENSIVE!!).  What he's interested in doing is
> getting a HAM radio, and using it for TCP/IP and UUCP.  Am I making any sense?
> Can anybody help?  Please be verbose, as I know nothing of HAM radio.
>
>                       Thanks, Ralph
>
> Ralph Seguin                  [e-mail]

Well your friend can do TCP/IP on ham radio but there are a bunch of provisos.
The major proviso is that he must be a licensed ham.  The next is that the
use of Amateur radio, in general, may not be for the purpose of replacing
a common carrier such as the phone company.  Third,  you may not conduct
business on ham radio.

Your friend may have another important problem.  What's the status of Singapore
in terms of third party agreements?  Someone out there in a position to know?

--
Douglas S. Rand
Internet:   <[e-mail]>
Snail:      MITRE, Burlington Road, Bedford, MA
Disclaimer: MITRE might agree with me - then again...
Amateur Radio: KC1KJ

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

End of Packet-Radio Digest
******************************
Date: Sun, 10 Mar 91 04:30:11 PST
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Reply-To: [e-mail]
Subject: Packet-Radio Digest V91 #62
To: packet-radio


Packet-Radio Digest         Sun, 10 Mar 91       Volume 91 : Issue  62

Today's Topics:
          AA4RE BBS Program V2.11 available

Send Replies or notes for publication to: <[e-mail]>
Send subscription requests to: <[e-mail]>
Problems you can't solve otherwise to [e-mail].

Archives of past issues of the Packet-Radio Digest are available
(by FTP only) from UCSD.Edu in directory "mailarchives/packet-radio".

We trust that readers are intelligent enough to realize that all text
herein consists of personal comments and does not represent the official
policies or positions of any party.  Your mileage may vary.  So there.
----------------------------------------------------------------------

Date: Sat, 09 Mar 91 07:22:48 PST
From: "Roy Engehausen" <[e-mail]>
Subject: AA4RE BBS Program V2.11 available
To: [e-mail]

Yes! after the long long wait, the AA4RE mailbox BB V2.11 is now
available.  Significant new features:

* Sorting of messages to be forwarded by type, size, age, etc
* Forwarding control based on message size, path, and time
* Forward aging (Eg: don't try second system until so many hours have passed)
* Added SYSOP action file
  - Hold or reject incoming messages based on many factors
  - Make a file from a message automatically
  - Control over user originated message based on class, address, etc
    (Eg. No more SP ALL @ ALLUS)
  - Ability to automatically kill messages that are superseded
    (Eg. AMSAT orbital data)
* Route messages to ? and the corresponding L? command to find bad addresses
* Multiple language support
* Emergency Mode for ARES/RACES support.  This is an implementation of
  the recommendations of the ARES/RACES/NTS meetings following the
  Oct 89 Northern California Earthquake

The are also a lot of minor improvements and fixes.

You can get this program by sending $5 US (or equivalent) to:

  Dave Larton, N6JQJ
  766 El Cerrito Way, #D
  Gilroy, CA  95020-4149
  [phone]

  John Anderson, N7IJI
  2729 Park Road
  Charlotte, NC  28209
  (704)-333-3249

Canadians can send 5.00 CDN to:

  A.R.E.S. Group
  Att: REBBS Update
  P.O. Box 35
  St-Jean Chrysostome,
  Quebec,  Canada    G6Z 2L3

For source code, include $2 more (needs multiple diskettes).  Indicate
which format diskette you need.  We can handle all formats of 5 1/4 and
3 1/2 inch diskettes Don't include diskette or mailer, we will supply.

The software can also be obtained by downloading from the following BBS:

   WA6RDH BBS -- 916-678-1535 -- 300/1200/2400/4800/9600 N81 V.32/MNP5
   WB3FFV BBS -- 301-625-0817 -- 1200 & 2400 (Non-MNP)
          -- 301-625-9482 -- 1200, 2400, 4800 & 9600 V.32/V.42/MNP5
          -- 301-625-9663 -- 1200, 2400, 9600 & 19200 (PEP)

The software is also loaded onto the W3IWI TOMCAT TCPIP server accessible
via both SLIP and thru the Internet.

BITNET users can receive the code direct from me.  Drop me a line at
ENGE at ALMADEN.

Sorry this version took so long but I think you will be happy with it.

Roy, AA4RE
Internet: ENGE @ IBM.COM
Bitnet: ENGE at ALMADEN
Packet: AA4RE @ AA4RE.#NOCAL.CA.USA.NA

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

End of Packet-Radio Digest
******************************
Date: Tue, 12 Mar 91 04:30:06 PST
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Reply-To: [e-mail]
Subject: Packet-Radio Digest V91 #63
To: packet-radio


Packet-Radio Digest         Tue, 12 Mar 91       Volume 91 : Issue  63

Today's Topics:
          Schematic for TAPR TNC-2 version A
                TCP/IP

Send Replies or notes for publication to: <[e-mail]>
Send subscription requests to: <[e-mail]>
Problems you can't solve otherwise to [e-mail].

Archives of past issues of the Packet-Radio Digest are available
(by FTP only) from UCSD.Edu in directory "mailarchives/packet-radio".

We trust that readers are intelligent enough to realize that all text
herein consists of personal comments and does not represent the official
policies or positions of any party.  Your mileage may vary.  So there.
----------------------------------------------------------------------

Date: Tue, 12 Mar 91 07:19 EST
From: "CHARLES LAYNO (WB4WOR)" <[e-mail]>
Subject: Schematic for TAPR TNC-2 version A
To: [e-mail]

I recently purchased a TAPR TNC-2, version A (the TNC-2 with only 4 LEDs and no
PTT LED), but it didn't have the schematics, even though it did have the
assemble manual. After contacting TAPR, they no longer keep that schematic in
stock. If you have a schematic for this unit, I would be happy to pay shipping
and copying costs.

Email to the following:

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Charles Layno             BITnet: [e-mail]
P.O. Box 8252             Internet: [e-mail]
Greensboro, NC            CompuServe: 71441,1562
27419-0252                Packet Radio Mail: WB4WOR @ WB4WOR.#GSO.NC.USA.NA
         "REALITY..................WHAT A CONCEPT!"
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

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

Date: 11 Mar 91 23:47:24 GMT
From: taco!eos.ncsu.edu![e-mail]  (JOHN CARROLL RUMBAUGH)
Subject: TCP/IP
To: [e-mail]

I'm looking for info on TCP/IP on packet.  Specifically, how does one
get an address for TCP/IP (other than this one, say for my call N4NOY)?

73
N4NOY

********************************************************************
[e-mail]         |  A.P. Liepins at NCSU EOS
[e-mail]    |  A.P. Liepins at NCSU Public

And, remember:
May you have champagne for your real friends
and real pain for your sham friends!
********************************************************************

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

End of Packet-Radio Digest
******************************
Date: Fri, 15 Mar 91 04:30:04 PST
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Reply-To: [e-mail]
Subject: Packet-Radio Digest V91 #64
To: packet-radio


Packet-Radio Digest         Fri, 15 Mar 91       Volume 91 : Issue  64

Today's Topics:
             Basic PBBS Question
    Basic PBBS Question (killing ongoing L(ist)) (2 msgs)

Send Replies or notes for publication to: <[e-mail]>
Send subscription requests to: <[e-mail]>
Problems you can't solve otherwise to [e-mail].

Archives of past issues of the Packet-Radio Digest are available
(by FTP only) from UCSD.Edu in directory "mailarchives/packet-radio".

We trust that readers are intelligent enough to realize that all text
herein consists of personal comments and does not represent the official
policies or positions of any party.  Your mileage may vary.  So there.
----------------------------------------------------------------------

Date: 12 Mar 91 17:13:24 GMT
From: [e-mail]  (Paul J. Dujmich)
Subject: Basic PBBS Question
To: [e-mail]

I have a very "basic" type question regarding the use of packet PBBS's.
Suppose I connect to a local Pbbs and issue an "L" command to list
the available measages. The list starts printing, but it's very long so
I want to tell the BBS to abort the dump. Exactly how do I do that?
I realize that the necessary control character or command will depend
upon what BBS software the BBS is running. Is there a universal command
to "abort" without disconnecting? What are some of the more common ones?
I have had experiences with several BBS's that won't abort a listing
for anything. Please excuse my ignorance, but this is never mentioned
in any of the "HELP" files that are usually available on said BBS's.

Thanks fer ur help
\paul
[e-mail]
WA3TLD @W2XO

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

Date: 14 Mar 91 22:02:52 GMT
From: usc!rpi!clarkson![e-mail]  (Tadd,KA2DEW, ,3152621123)
Subject: Basic PBBS Question (killing ongoing L(ist))
To: [e-mail]



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

Date: 14 Mar 91 11:58:38 GMT
From: dog.ee.lbl.gov!hellgate.utah.edu!caen!zaphod.mps.ohio-state.edu!unix.cis.pitt.edu!gvlf3.gvl.unisys.com!gvlv3![e-mail]  (Ed Naratil)
Subject: Basic PBBS Question (killing ongoing L(ist))
To: [e-mail]

In article <[e-mail]> [e-mail] writes:
>From article <[e-mail]>, by [e-mail] (Paul J. Dujmich):
>> Suppose I connect to a local Pbbs and issue an "L" command to list
>> the available measages. The list starts printing, but it's very long so
>> I want to tell the BBS to abort the dump. Exactly how do I do that?
>
>Some pBBSs accept a control C to stop listing.  Try sending your
>escape char (usually control V) followed by a control C, then a
>return.  Don't forget the return.
>
>Tadd, KA2DEW

Since not all PBBS's run identical software, I would suggest you send
a message to the SYSOP of the board asking your question.  Two other
ways that ALWAYS work are:
1) Send your escape char and then a 'd'.  This will disconnect your
   TNC and eventually the BBS will abort from too many retries.

2) Turn down your received audio and eventually (depending on the
   number of retries allowed by the BBS, it will abort from too
   many retries.


----
Ed Naratil                                     (All standard disclaimers apply)
Amateur Packet: W3BNR@N3LA.#epa.PA.USA.NA      [e-mail]

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

Date: (null)
From: (null)
Some pBBSs accept a control C to stop listing.  Try sending your
escape char (usually control V) followed by a control C, then a
return.  Don't forget the return.

                         Tadd, KA2DEW

[ KA2DEW @ KA2JXI.#NNY.NY.USA.NA                - Tadd Torborg             ]
[ [e-mail]                   - 26 Maple St - PO Box 330 ]
[ NEDA (North East Digital Association) Editor  - Colton, NY 13625         ]
[ Clarkson University                           - 315-262-1123             ]

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

End of Packet-Radio Digest
******************************
Date: Sat, 16 Mar 91 04:30:09 PST
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Reply-To: [e-mail]
Subject: Packet-Radio Digest V91 #65
To: packet-radio


Packet-Radio Digest         Sat, 16 Mar 91       Volume 91 : Issue  65

Today's Topics:
             Basic PBBS Question

Send Replies or notes for publication to: <[e-mail]>
Send subscription requests to: <[e-mail]>
Problems you can't solve otherwise to [e-mail].

Archives of past issues of the Packet-Radio Digest are available
(by FTP only) from UCSD.Edu in directory "mailarchives/packet-radio".

We trust that readers are intelligent enough to realize that all text
herein consists of personal comments and does not represent the official
policies or positions of any party.  Your mileage may vary.  So there.
----------------------------------------------------------------------

Date: Fri, 15 Mar 91 11:09:19 EST
From: [e-mail] (Barry McLarnon)
Subject: Basic PBBS Question
To: [e-mail]

Some PBBS's do (and all of them *should*) support an A [Abort] command.
Examples include MBL and FBBS.  You should be able to get a summary of
the available commands easily, to find out.  There is always a delay
before the command takes effect, due to buffering at the PBBS, and frames
in transit if you're connected via nodes.  Disconnecting to abort is
crude, but effective - but the suggestion someone made to render your
TNC deaf so that the BBS will retry out is, well, bizarre.

Barry

Barry McLarnon                  |  Internet: [e-mail]
Communications Research Centre  |  PBBS: [e-mail]
Ottawa, Canada  K2H 8S2         |  AMPRnet: [e-mail]

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

Date: Fri, 15 Mar 91 18:04:06 PST
From: uunet!m2xenix!puddle!f4.n494.z5.fidonet.org!RKWDP.PUKVM1 (RKWDP PUKVM1)
To: [e-mail]

Subject:ICOM 725-TRANSMIT ON OTHER FREQ'S OUTSIDE AMATEUR BANDS HELP NEEDED

Hi fellow Hams

I wonder if someone can help me.  Is there a modification
that can be made in a ICOM IC725 HF ALL MODE TRANCEIVER to
get it to transmit outside the normal amateur bands (legally under licence).
It is possible with e.g. the TS430S (Kenwood), etc.  Any help??

Please write to my e-mail address:
   RKWDP.PUKVM1@f494..z5.fidonet.org         (FIDONET)
or
   [e-mail]

Thanks in advance.

'73

Dan Pretorius
ZS4VG
--
uucp: uunet!m2xenix!puddle!5!494!4!RKWDP.PUKVM1
Internet: [e-mail]

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

End of Packet-Radio Digest
******************************
Date: Wed, 20 Mar 91 04:30:08 PST
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Reply-To: [e-mail]
Subject: Packet-Radio Digest V91 #66
To: packet-radio


Packet-Radio Digest         Wed, 20 Mar 91       Volume 91 : Issue  66

Today's Topics:
             SMTP Mail on PBBS? (2 msgs)

Send Replies or notes for publication to: <[e-mail]>
Send subscription requests to: <[e-mail]>
Problems you can't solve otherwise to [e-mail].

Archives of past issues of the Packet-Radio Digest are available
(by FTP only) from UCSD.Edu in directory "mailarchives/packet-radio".

We trust that readers are intelligent enough to realize that all text
herein consists of personal comments and does not represent the official
policies or positions of any party.  Your mileage may vary.  So there.
----------------------------------------------------------------------

Date: Mon, 18 Mar 91 22:45:33 EST
From: "Mark Bramwell" <[e-mail]>
Subject: SMTP Mail on PBBS?
To: "Packet Radio Digest" <[e-mail]>

I have been using KA9Q nos for quite a while now.  I am interested in trying
something else for awhile.  Unforunately, I don't find NOS stable enough, or
quick enough for AX25 use.  I would like to have a bbs program that supports
SMTP mail plus the messages come in as one file per user.  Does anyone know of
such a program?  There is MSYS here, but it stores each message separately.

Any ideas?


=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Mark Bramwell, VE3PZR                Located in sunny London, Ontario

Internet: [e-mail]  IP Address: 129.100.29.33
  Packet:  VE3PZR @ VE3GYQ               UWO Phone: [phone]

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

Date: 19 Mar 91 18:31:54 GMT
From: xanadu![e-mail]  (Jeff Crilly N6ZFX)
Subject: SMTP Mail on PBBS?
To: [e-mail]

In article <[e-mail]> [e-mail] writes:
>I have been using KA9Q nos for quite a while now.  I am interested in trying
>something else for awhile.  Unforunately, I don't find NOS stable enough, or
>quick enough for AX25 use.  I would like to have a bbs program that supports
>SMTP mail plus the messages come in as one file per user.  Does anyone know of
>such a program?  There is MSYS here, but it stores each message separately.
>
>Any ideas?
>
>
I am curious if anyone is doing NNTP over tcpip with the ka9q stuff.

Jeff Crilly (N6ZFX)
AMIX Corporation  2345 Yale Street  Palo Alto, CA  94306
[e-mail], {uunet,sun}!markets!jeff, N6ZFX@N6IIU.#NOCAL.CA.USA

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

End of Packet-Radio Digest
******************************
Date: Thu, 21 Mar 91 04:30:06 PST
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Reply-To: [e-mail]
Subject: Packet-Radio Digest V91 #67
To: packet-radio


Packet-Radio Digest         Thu, 21 Mar 91       Volume 91 : Issue  67

Today's Topics:
               packet radio information
            TNC Emulators on PC's

Send Replies or notes for publication to: <[e-mail]>
Send subscription requests to: <[e-mail]>
Problems you can't solve otherwise to [e-mail].

Archives of past issues of the Packet-Radio Digest are available
(by FTP only) from UCSD.Edu in directory "mailarchives/packet-radio".

We trust that readers are intelligent enough to realize that all text
herein consists of personal comments and does not represent the official
policies or positions of any party.  Your mileage may vary.  So there.
----------------------------------------------------------------------

Date: Wed, 20 Mar 91 13:39:45 EST
From: Mary Ayre <[e-mail]>
Subject: packet radio information
To: [e-mail]

Hi... I'm new to packet radio (I don't even have a licence yet) and I
am doing a paper on this particular topic for a networking class.  Could
someone give me some help in finding information for this project?  Thanks.

Mary Ayre

**********************************************************************
                  =
Mary C. Ayre                  =           ////
Central Michigan University   =          ////   AMIGA is cool!
Computer Science Dept.        =     ////     Don't underestimate
Sports Information            =     X///           it!
34ZEF4M@CMUVM                 =      XXX/
                  =
**********************************************************************

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

Date: 20 Mar 91 23:59:37 GMT
From: [e-mail]
Subject: TNC Emulators on PC's
To: [e-mail]

Some time ago, a European software package was announced that could
emulate a TNC on an IBM PC or PC Clone.  Besides that package, are
there any other IBM clones TNC emulators around?

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

End of Packet-Radio Digest
******************************
Date: Fri, 22 Mar 91 04:30:07 PST
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Reply-To: [e-mail]
Subject: Packet-Radio Digest V91 #68
To: packet-radio


Packet-Radio Digest         Fri, 22 Mar 91       Volume 91 : Issue  68

Today's Topics:
                  No Subject

Send Replies or notes for publication to: <[e-mail]>
Send subscription requests to: <[e-mail]>
Problems you can't solve otherwise to [e-mail].

Archives of past issues of the Packet-Radio Digest are available
(by FTP only) from UCSD.Edu in directory "mailarchives/packet-radio".

We trust that readers are intelligent enough to realize that all text
herein consists of personal comments and does not represent the official
policies or positions of any party.  Your mileage may vary.  So there.
----------------------------------------------------------------------

Date: 21 Mar 91 21:24:28 GMT
From: [e-mail]
Subject: No Subject
To: [e-mail]



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

End of Packet-Radio Digest
******************************
Date: Sat, 23 Mar 91 04:30:06 PST
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Reply-To: [e-mail]
Subject: Packet-Radio Digest V91 #69
To: packet-radio


Packet-Radio Digest         Sat, 23 Mar 91       Volume 91 : Issue  69

Today's Topics:
                Administrivia
          ? how to route with tcpip (2 msgs)
         Anonymous ftp site for BayComm ??? (2 msgs)
           anybody RUNNING 9600 ?? (2 msgs)
                APLINK
            Baycom Circuit Wanted
         Class C IP address for packet radio?
               Dayton - Digital Suite?
               Digital repeater network
            G3RUH 9600 baud users on UO-14
         Hierarchical Forwarding pounds (#) (13 msgs)
           How to get email from packet???
         Inadvertant "clear screen" (4 msgs)
              KA9Q & mbox BBS forwarding
            KA9Q v910308 problems
              KAM dual-mode enhancement
      Monthly On-Line Elmers Resource Directory (2 msgs)
               New packet user
                  No Subject
       Packet BBS SID and personal mbox reverse forward
            PK-88 Pinouts (2 msgs)
               portable packet (4 msgs)
              SMTP Mail on PBBS?
           STS-37 SAREX Information Summary
              TAPR meeting notes
                TCP/IP
                Thanks
        The Amateur Radio BBS - How to access
             The N2GTE Packet Mail Switch
            TNC Emulators on PC's (3 msgs)
           WANTED: Docs for NETPC (DL3DBT v891105)
             Where can I download Baycom?

Send Replies or notes for publication to: <[e-mail]>
Send subscription requests to: <[e-mail]>
Problems you can't solve otherwise to [e-mail].

Archives of past issues of the Packet-Radio Digest are available
(by FTP only) from UCSD.Edu in directory "mailarchives/packet-radio".

We trust that readers are intelligent enough to realize that all text
herein consists of personal comments and does not represent the official
policies or positions of any party.  Your mileage may vary.  So there.
----------------------------------------------------------------------

Date: Fri, 22 Mar 91 14:04:58 -0800
From: brian (Brian Kantor)
Subject: Administrivia
To: info-ham-digest, packet-radio-digest

Sorry about the deluge of digests; I just fixed the gateway and we had 10
days worth of traffic to catch up on.  Things should tame out now.

As many of you know, these mailing lists are gatewayed bidirectionally with
newsgroups on Usenet.  Recently those newsgroups underwent a reorganization,
with the ham-radio group being split into several groups, primarily splitting
off a "policy" group for the discussion of things like no-code, license
classes, rules and regulations, etc.

That newsgroup is now available as a separate digest from ucsd, the ham-policy
digest.  You may subscribe, as always, by sending mail to [e-mail].

Now that everything is working, I'm going on vacation for a week.  Flames will
be extinguished when I get back.
    - Brian

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

Date: 23 Mar 91 02:46:37 GMT
From: usc!samsung!munnari.oz.au!manuel!csc.canberra.edu.au!echo![e-mail]
Subject: ? how to route with tcpip
To: [e-mail]

In <[e-mail]> [e-mail] (Jeff Crilly N6ZFX) writes:

>It seems that this should be doable without have to change the routing
>table (using arp and route add) on kg6kf.  If not, then everyone has to be
>able to hear everyone else; and only direct connections would be possible.

I haven't found a way yet. :-(  I have a similar problem here in Canberra.
Hidden Transmitters are the norm.  The only solution we have come up with
is to have every station you want to talk to that isn't direct pointed to
by a route and/or arp entry and they also have to have you defined.

We have another problem here in Australia.  IP routing isn't legal over the
air. (Yet, we're trying)  To talk to stations out of line of site we HAVE to
use digipeaters. :-(  Usually we end up having all the people we normally
talk to defined to ARP with a digipeater chain. :-(

Carl.

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

Date: 23 Mar 91 01:51:06 GMT
From: swrinde!zaphod.mps.ohio-state.edu!usc!apple!fernwood!portal!cup.portal.com![e-mail]
Subject: ? how to route with tcpip
To: [e-mail]

>... So the question is, how can I get arp to send to kg6kf via wn6i-7
>instead of replying directly?

You might try adding the following "route" entry:

ax25 route add kg6kf wn6i-7

That's what I had to do to get to a local tcp/ip station thru a digi.

John, KF0OU
[e-mail]
[e-mail] [44.20.0.38]        Good luck, hope it helps!

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

Date: 13 Mar 91 16:44:03 GMT
From: bonnie.concordia.ca!s3![e-mail]
Subject: Anonymous ftp site for BayComm ???
To: [e-mail]

I am looking for a anonymous ftp site from which I could get BayComm.
Is there such a site somewhere ? Thank you.

Marc, VE2HQI



--
Marc Lefebvre,                     IREQ: Institut de Recherche d'Hydro-Quebec
Analyste Ressources Informatiques        1802 Montee Ste-Julie, Varennes,
                     Prov. Quebec, CANADA  J3X 1S1.
[e-mail]                Tel: [phone]  fax: [phone]

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

Date: 15 Mar 91 15:04:39 GMT
From: orion.oac.uci.edu!ucivax!jarthur!elroy.jpl.nasa.gov!swrinde!zaphod.mps.ohio-state.edu!think.com!snorkelwacker.mit.edu!bloom-beacon!eru!hagbard!sunic!news.funet.fi!kannel![e-mail]
Subject: Anonymous ftp site for BayComm ???
To: [e-mail]

> I am looking for a anonymous ftp site from which I could get BayComm.
> Is there such a site somewhere ? Thank you.

> Marc, VE2HQI

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

Date: 13 Mar 91 15:43:37 GMT
From: norand![e-mail]
Subject: anybody RUNNING 9600 ??
To: [e-mail]

I am interested in anyone's experiences in modifying and OPERATING
commercial and ham equipment to operate 4800-9600 baud packet.

This question is concerned with modifying FM radios for terrestrial links,
not satellite work through SSB equipment.

In particular, I'd like to hear any experiences with setting up the radios
and what performance figures are being seen (like dBm for 10-6 BER,
bandwidths for various baudrates, deviation values that worked, radios
that worked better than others, etc.)

I would like to try to use the older rock-bound commercial gear like Micors,
Maxars, MASTR EXEC's, etc.

Email is fine, I will summarize and re-post what I hear by that means.

Thanks,

Ron Luse, KD9KX
Norand Data Systems
Cedar Rapids, Iowa
uunet!norand!ron  |  norand![e-mail]  |  kd9kx @ wa0rjt.ia

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

Date: 13 Mar 91 18:52:48 GMT
From: [e-mail]
Subject: anybody RUNNING 9600 ??
To: [e-mail]

In article <[e-mail]> [e-mail] (Ron Luse) writes:
>I am interested in anyone's experiences in modifying and OPERATING
>commercial and ham equipment to operate 4800-9600 baud packet.
>I would like to try to use the older rock-bound commercial gear like Micors,
>Maxars, MASTR EXEC's, etc.

I have been modifying several of these kinds of radios for 9600 bps
operation recently.

The MASTR Exec-II won't do it easily; it's got a phase modulator and
won't do flat dev.  The receiver works fine, so we'd thought about
shoving the modulation into the temperature compensation voltage line
to see if we could move the tempcomp varicap around to get true FM.
That might work, but we never got around to trying it.

The old lowband Mocom-70 will work at 9600 bps, but our experience is
that you really need to use them at 4800, because they have enough
frequency drift that the IF might wind up shaving off the edges of
received signals if one end is drifting opposite the other.

The MICOR will work just fine on 450 MHz, since there is a direct-FM
modulator on the TX offset oscillator.  The highband and some lowband
models have phase modulators, which won't work, and the serrasoid
modulator on lowband is hopeless.  I did have success in using a 450
channel element in a highband Micor TX, and shoving the modulation into
the AFC input of the element, but it wasn't real clean.  All bands have
plenty of receive IF bandwidth.

The Maxar is ideal because its transmitter has a direct-fm varicap
modulator.  You just pop one end of the 10uF DC blocking cap off and
feed the modem into there.  The receiver has sufficient IF bandwidth
but the detector is loaded down by the deemphasis network that hangs
off pin 6 of the detector chip; just chop off the 2.7k resistor and
take the output directly from pin 6 to the modem.

The Mitrek is pretty much the same as the MAXAR except that you have to
feed the transmit modulation directly into the modulation input line
for the channel element, since the previous stage is part of the
splatter lowpass filter.  We'll be using Mitreks on the hill since
they have a much better front end than the Maxar does.

Hope that helps.
    - Brian

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

Date: 20 Mar 91 02:20:42 GMT
From: swrinde!elroy.jpl.nasa.gov!usc!zaphod.mps.ohio-state.edu!think.com!linus!linus!mwunix.mitre.org![e-mail]
Subject: APLINK
To: [e-mail]

If that is not the required syntax for a posting a certain "Elmer" is
going to suffer the Wouff Hong.

I, and I presume others, would like some information on APLINK bulletin
board systems.  They seem to be fairly common on hf Amtor and to be linked
with the national BBS system.  I would like to know:
  *  What is APLINK
  *  What can it do
  *  How is it linked to the rest of the world
  *  Where can the software to run it be obtained (APLINK 5.03)
  *  How is the frequency/band/beam heading scanning accomplished
  *  Any other lurid details:  Enquiring minds want, you know

Thanks:  John WA9FCH [e-mail]

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

Date: 14 Mar 91 18:16:00 GMT
From: rosevax!bert.Rosemount.COM![e-mail]
Subject: Baycom Circuit Wanted
To: [e-mail]

I am looking for the schematic for the circuit as described in
the "BAYCOM" documentation.

I realize that there are boards available for the DIGICOM version,
but this requires an external power supply.

The circuit for the BAYCOM gets power from the RS232 port to power
the board.  The documentation suggests sending 89 Deutch Marks
to an adress in Germany, but I don't have a readily available
source for the Deutch Marks and I don't think that I want to send
cash (even German) thru the mail.

I don't know how else to send for it or how long it would take
if I did find a way to order thru Germany.

Does anyone have a copy of the schematic for this circuit or
suggestions on how to order it?

[e-mail]

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

Date: 19 Mar 91 03:52:39 GMT
From: usc!zaphod.mps.ohio-state.edu!uwm.edu!bionet!hayes.ims.alaska.edu!acad3.alaska.edu![e-mail]
Subject: Class C IP address for packet radio?
To: [e-mail]

     I have some questions for the amateur radio IP community.  I have
an Arcnet LAN and have been thinking about getting a Class C IP network
address for it.  This would greatly simplify some projects that I am
working on.  However, there appear to be some pitfalls.  Questions follow:

1.   How many of you have Net 44 dependant routing?  For an example with
     KA9Q, Net 44 packets are routed to a KISS serial port and everything
     else is routed to a campus Ethernet ultimately connected to Internet.

2.   How many of you have amateur radio IP nodes with addresses outside
     Net 44?  Have you had problems with routing as described above?

Philip Munts N7AHL
NRA Extremist, etc.
University of Alaska, Fairbanks

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

Date: 18 Mar 91 18:24:16 GMT
From: pilchuck!ssc![e-mail]
Subject: Dayton - Digital Suite?
To: [e-mail]

In article <[e-mail]>, [e-mail] (Mark J. Bailey) writes:
> Hi,
>
> Who all is planning to go to Dayton this year?  War's over, travel is probably
> getting safer again, economy may rebound....
>
> Also, will there be another gathering of the "Digital Suite" at the Stouffer
> and if so, same place, same day (Friday) and time?

I organized the Digital Suite at Stouffers last year.  I'm not going to
Dayton this year.  The Digital Suite was a one time thing on my part.
A friend had reserved the Orville Wright Suite the year before, then
didn't use it.  He gave it to me for free, and I thought it would be
fun to gather usenet/fidonet/packet/RTTY hams for a party.  It
was great fun, but NO WAY could I ever afford to do this again, at
least with my money.


Tad Cook
Seattle, WA
Packet: KT7H @ N7ENT.#WWA.WA.USA.NA
Phone: [phone]
MCI Mail: 3288544
Telex: 6503288544 MCI UW
USENET:...uw-beaver!sumax!amc-gw!ssc!tad
or, [e-mail]

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

Date: 13 Mar 91 21:29:21 GMT
From: sdd.hp.com!caen!sol.ctr.columbia.edu!cunixf.cc.columbia.edu!cunixb.cc.columbia.edu![e-mail]
Subject: Digital repeater network
To: [e-mail]

Has anyone looked into the feasibility of creating a digital repeater network?
It seems to me that this would allow most any ham to talk to most any other,
anywhere, using a simple handheld radio. This seems like a logical extension
of the current plans to create an analog system using dynamic links to a
long distance backbone.  The problem with this scheme is:  what happens
if a link in the backbone fails; and if more than one user wants to use the
system at the same time?  It would be a very resource intensive system,
anyway.

In short:  why couldn't the Amateur community set up the equivalent of a
digital cellular network with modest user requirements, linked exclusively
by radio and therefore immune to damage to the hard-wired systems such as
the telephone network.

Phil: can you hear me?
 * * * * * * *  ======================= Meir Green
* * * * * * * * ======================= [e-mail]
 * * * * * * *  ======================= N2JPG

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

Date: 14 Mar 91 19:01:54 GMT
From: swrinde!zaphod.mps.ohio-state.edu!samsung!rex!rouge!pc.usl.edu![e-mail]
Subject: G3RUH 9600 baud users on UO-14
To: [e-mail]

Here's a list of users and their equipment summary, of satellite UO-14.
This pacsat operates at 9600 baud full duplex.

*UO-14 Users List rev.10            Compiled by JA6FTL  03-10-1990
========================
    Uploader:18 Countries 84 stations are counted (~ Mar.10)
CT1DIA
DB2OS DD1EG DF5DP DL1YDD DL8NCI DF3LZ DL6KG DL1SBY
EA2ARU EA2CLS EA4BPN
G3YJO G4WFQ G8NOB G0K8KA G0MJW G3RUH G4AXC G8TZJ G3PJA
HB9BOM
I2KBD I3RUF IV3IBX I6CGE
JA6FTL JR1EDE JR1ING JA1OGZ JA1QHQ JH1TWZ
KF4WQ K8YAH K7PYK K8IRC
      WC8J WA2LQQ W3QNS WB6YMH WD0E W7KRC W9FMW WB0KSL WA9FMQ WD3Q W3GYJ
      N4HY NK6K N6HBB N5AHD N5BF N3FKV
LU8DYF
OH2SN OH2YU
ON6UG ON5PV ON4KVI
PE1CHL PA3DVG PE1HML PE1DNA
SM5BVF SM0TER
SV1IT SV3KH
UA3CR RK3KP
VK2BKQ VK3DTO VK5AGR VK7ZBX VK6BMD VK6VV VK5HI VK2XLG VK7ZBX VK3DFI VK2AIT
YN1UNI
ZL1AOX ZL1TRE ZL1TJK
***********************************************

*UO-14 USERS INFO (59 entries Mar.10)
=====================================
CALL   ! name  ! MODEM ! ANT dwnlnk    ! RX dwnlnk   ! ANT trak ! uplnkPWR   !
       ! HM-BBS! TNC   ! ANT uplnk     ! TX uplnk    ! Freq trak! CPU  remarks*
-------------------------------------------------------------------------------
DB2OS  ! Peter ! G3RUH ! 2x20 XY Maspro! TS-811E     ! OSCAR-ST ! <50W       !
       ! DK0MAV! TNC2S ! 2x12 XY Maspro! TS-700G     ! -        ! AT286 16MHz!
DD1EG  ! Det   ! G3RUH ! 2x20 XY Maspro! IC-471H     ! AMSAT-DL ! <25W       !
       ! DB0IZ 1 TNC-2 ! 2x12 XY       ! FT-225RD    ! -        ! V-20 8MHz  !
DF3LZ  ! Roland! G3RUH ! 2x19 XY       ! C500        ! KCT      ! 10W        !
       ! DB0OQ ! TNC2C ! 2x12 XY       ! TS-700      ! -        ! AT386/387sx!
DF5DP  ! Bert  ! G3RUH ! 2x20 XY Maspro! FT726R      ! KCT      ! -          !
       ! DB0IZ ! TNC2A ! 2x12 XY       ! IC-475H     ! -        ! AT386 33M  !
DL1YDD ! Hart  ! G3RUH ! 2x7 3M BOOM   ! FT-780R+AMP ! HB TSR   ! 100W       !
       ! DB0IZ ! TNC2C ! 2x16 3M BOOM  ! FT-480R     ! -       !386/387 33MHz!
DL1SBY ! Axel  ! G3RUH ! 2x12 XY RHCP  ! IC-275      ! MANUAL   ! 100W       !
       ! -     ! TNC2C ! 2x20 XY RHCP  ! IC-475      ! -        ! AT 12MHz.  !
DL6KG  ! Hans  ! G3RUH ! 4x12 ele.horiz! FT-726R     ! MirageMTI! <25W       !
       ! DB0IE ! TNC-2 ! 2x9 wle XY    ! TS-711E     ! MANUAL   ! AT286 16MHz!
DL8NCI ! Matt  ! G3RUH ! 17 ele vert.  ! FT-726R     ! MANUAL   ! 10/100W    !*
       ! DB0GE ! TNC-2 !  7 ele vert.  ! FT-726R     ! MANUAL   ! 80286      !
EA2ARU ! JABI  ! G3RUH ! 2x19 XY TONNA ! TS-790S     ! KCT      ! 45W        !
       ! EA2RCG! TNC-2 ! 2x14 XY TONNA ! TS-790S     ! -        ! AT286 12MHz!
EA2CLS/! Tom   ! G3RUH ! KLM 435-40CX  ! TS-790A     ! KCT/     ! 45W        !
 kb7hta! EA2CDN! PK-88 ! KLM 2M-22C    ! TS-790A     ! -        ! AT386 33MHz!
EA4BPN ! Rafael! NB-96 ! 5/8+5/8 vert. ! TR-851E     ! -        ! 25W        !
       ! EA4URE! TNC-2 ! 19ele Hor.    ! TS-711E     ! -        ! AT286 16MHz!
G4AXC  ! Peter ! G3RUH ! 10 ele XY     ! FT-736      ! MANUAL   ! 25W        !
       ! PLYBBS! TINY2 ! 10t Helix     ! FT-736      ! MANUAL   ! 286        !
G4WFQ  ! Dave  ! G3RUH ! MBM88EL       ! FT736R      ! MANUAL   ! 25W        !
       ! GB7DDX! TNC220! KLM14C        ! FT736R      ! MANUAL   ! PC286 8MHz.!
G8TZJ  ! Andrew! G3RUH ! 17 el XY RHCP ! IC-471E     ! HB VIC-20! 60W        !
       ! GB7FCI! TINY2 !  6 el XY RHCP ! IC-211E     ! HB AFC   ! 8086 8MHz  !
I3RUF  ! GINO  ! G3RUH ! 1x21 orriz    ! TS-790E     ! KCT      ! 50W        !
       ! I3YPJ ! TNC200! 1x16 orriz    ! TS-790E     ! -        ! 386/387 33M!
I6CGE  ! Alfio ! G3RUH ! 2x17+17 ele   ! FT-736      ! KCT      ! <80W       !
       ! I6CGE !MFJ1270! 10+10 ele     ! TS-790      ! AUTO     ! 286 21MHz  !
IV3IBX ! FULVIO! G3RUH ! 2x19 XY       ! TS-790E     ! KCT      ! 50W        !
       ! IV3PFF! TNC2  ! 2x9 XY        ! TS-790S     ! -        ! 386/287 25M!
JA1OGZ ! Akira ! G3RUH ! 2x19 XY       ! FT-780      ! KCT      ! 30W        !
       ! JL1ZIJ! TNC-2 ! 12 XY         ! TR-9000+amp ! MANUAL   ! 5530z-SX   !
JA1QHQ ! Ehara ! G3RUH ! F9FT 19 XY*2  ! IC-371      ! MANUAL   ! 40W        !
       ! JL1ZIJ! TNC200! F9FT 9 XY     ! IC-251+amp  ! MANUAL   ! Dynabook   !
JH1TWZ ! nojyu ! G3RUH ! 2x25 vert     ! FT-736      ! MANUAL   ! 50W        !
       ! JL1ZIJ!TNC-20H! 2x12 vert     ! FT-736      ! MANUAL   !DynaBook(XT)!
JR1EDE ! Kohjin! NB96  ! -             ! TS-790S     ! KCT/IT1.0! 50W        !
       ! JL1ZIJ! TINY2 ! -             ! TS-790S     ! hb AFC   ! 386        !
JA6FTL ! sueo  ! NB96  ! 19 ele XY     ! TS-790S     ! KCT/IT1.0! 50W        !*
       ! JA6FTL!mPOWER2! 12 ele XY     ! TS-790S+amp ! hb AFC   ! 5530z-SX16M!
K7PYK  ! Wes   !PacComm! 2xKLM435-40CX ! FT-736R     ! KCT/QT   ! 125W       !
       ! K7PYK ! TNC-2 ! 2xKLM2M-22C   ! FT-736R     ! KCTune/QT! 386&286    !
K8IRC  ! BART  ! NB-96 ! 40ele KLM     ! FT-736      ! KCT      ! 25W        !
       ! KA0REW! TINY2 ! 20ele Cir.    ! FT-736      ! KCT-tuner! XT 10MHz   !
K8YAH  ! RON   ! NB96  ! 6 ele HORZ    ! IC-475A     ! MANUAL   ! 25/200     !
       ! W8CQK ! TNC200! 4 ele VERT    ! IC275A+amp  ! MANUAL   ! TURBO XT   !
OH2SN  ! Pate  ! G3RUH ! 19 ele XY     ! IC-490E     ! Auto     ! 150W       !
       ! OH2RBI! TNC2C ! 2x9 ele. HOR. ! IC-251/Mutek! Auto dplr! 386        !*
OH2YU  ! Sirpo ! G3RUH ! 2x17 XY RHCP  ! FT-736R     ! Auto PC  ! 20W        !
       ! OH2RBA! TNC-2 ! 2x10 XY RHCP  ! FT-736R     ! Manual   ! 386sx 16MHz!
ON4KVI !RENAULD! G3RUH ! 17ele XY      ! TS811       ! MANUAL   ! 100W       !
       ! ON7RC ! TNC2S !  9ele XY      ! TS711       ! MANUAL   ! PCXT 8MHz. !
ON5PV  ! PHIL  ! G3RUH ! 17ele V-H     ! FT-726R     ! MANUAL   ! 40W        !
       ! ON7RC ! TNC2S !  6ele V-H     ! TM221E      ! MANUAL   ! 286 16MHz  !
ON6UG  ! Freddy! G3RUH ! 2M Dish       ! FT-736R     ! HB Auto  ! 80W        !
       ! ON7RC ! TNC2C ! 9 ele XY      ! FT-736R     ! -        ! 386SX 16MHz!
PA3DVG ! AREND ! G3RUH ! 2x17 CD HOR.  ! FT-736R     ! KCT      ! 100W       !
       ! PI8JYL! PK87  ! 2x15 CD HOR.  ! FT-736R     ! KCT      ! 386 25MHz  !
PE1CHL ! Rob   ! G3RUH ! 2x15 XY RHCP  ! FT-712RH    ! fixed elv! 45W        !*
       ! PI8UTR! HB    ! 2x6  XY RHCP  ! FT-212RH    ! -        ! Atari520ST !
PE1HML ! Hendrik!G3RUH ! TURNSTYLE     ! FT-780      ! NONE     ! 12W        !*
       ! PI8ZAA!SCC8530! VERTICAL      ! FT-480      ! NONE     ! 8MHz PC    !
PE1DNA ! Joop  ! G3RUH ! 19ele Yagi    ! IC-475      !MANUAL(IT)! -          !
       ! -     ! none  ! 15ele Yagi    ! IC-275      ! -        ! AT clone   !*
RK3KP  !ClubSTn! NB96  ! 2x20 XY Maspro! FT-736R     ! KCT      ! -          !*
       ! RK3KP ! TINY2 ! 2x12 XY       ! FT-736      ! MANUAL   ! 286        !
SM0TER ! BRUCE ! G3RUH ! 4x14 SKEWED CP! TX790A      ! HB 8052  ! 45W        !
       ! SM0ETV! TINY2 ! 2x9  SKEWED CP! TX790A      ! HB AFC   ! COMPAQ286  !
SM5BVF ! HENLY ! G3RUH ! 2x13 skewed   ! IC-475      ! KCT      ! 50W        !
       ! SM0ETV! TNC200! 2x6  skewed   ! IC-275      ! HB       ! 386 16MHz  !
SV1IT  ! Kostas! G3RUH ! 9ele vertical ! TR851       ! MANUAL   ! 25W        !
       ! UOSAT3! TNC-2 ! 19ele vertical! TR751       ! MANUAL   !COMPAQLTE386!
SV3KH  ! Nick  ! NB96  ! 2x22ele K1FO  ! IC-475      ! MANUAL   ! 25W        !
       ! SV8RV !MFJ1270! 2x9ele TONA   ! IC-275      ! -        ! 386sx 16MHz!
UA3CR  ! Leo   ! G3RUH ! 9ele F9FT     ! FT-736      ! Fixed    ! -          !
       ! RK3KP ! TNC2  ! Helix 10T     ! FT-736      ! MANUAL   ! XT         !
VK2AIT ! Geoff ! G3RUH ! 15 ele HOR    ! FT-780R     ! MANUAL   ! <50W       !
       ! VK2XY ! TINY2 ! 12 ele HOR    ! FT-480R     ! MANUAL   ! 386 33MHz  !
VK3CFI/! Maggie! G3RUH !  Maspro       ! IC-251A     ! -        ! -          !*
 VK3DFI! VK3JAV!mPOWER2!  Maspro       ! IC-471H     ! -        ! T3100E     !
VK3DTO ! Andy  ! G3RUH ! 2x12 XY 18ver ! TS-711A     ! -        ! -          !
       ! -     !mPOWER2! 2x11 XY       ! TS811,IC490A! -        ! -          !
VK5AGR ! Graham! G3RUH ! 2x20 XY Maspro! IC-271A     ! KCT/IT1.0! 25W        !
       ! VK5WI ! PK87  ! 2x12 XY       ! IC-471A     ! MANUAL   ! AT286 12MHz!
VK5HI  ! Colin ! G3RUH ! 2x9 ele KLM   ! TS-700A     ! MANUAL   ! 10/100W    !
       ! -     ! TINY2 ! 2x7 ele KLM   ! TS-811A     ! MANUAL   ! 386sx 20MHz!
VK6BMD ! Bruce ! G3RUH ! 2x19 el vert  ! IC-471H     ! MANUAL   ! 25W        !
       ! VK6BBS! FRASH ! 1x17 el vert  ! IC-290H     ! MANUAL   ! XT 8MHz.   !
VK6VV  ! Arnold! G3RUH ! 16T Helical   ! TS-790A     ! MANUAL   ! 45W        !
       ! VK6BBS!PAD-205! 14 ele Vert   ! TS-790A     !JA6FTL AFC! AT286 16MHz!
VK7ZBX !Richard! G3RUH ! 16T Helix RHC ! FT-736R     ! MANUAL   ! 25W        !
       ! VK7GL ! PK-88 ! 10 XY RHC     ! FT-736R     ! MANUAL   ! 286 20MHz. !
W3GYJ  ! ROD   ! NB96  ! KLM44CX       ! FT-736R     ! KCT/QT4.0! 25W        !
       ! -     ! TINY2 ! CR144-20      ! FT-736R     ! KCT-Tuner! 386 25MHz. !
W7KRC  ! Wally ! NB96  ! KLM44CX       ! FT-726R     ! XCT/xt   ! 25W        !
       ! K7ZTM ! TINY2 ! KLM22C        ! FT-726R     ! MANUAL   ! Laptop12MHz!
W9FMW  ! Jack  ! NB96  ! 2xKLM 40CX    ! IC-475A     ! Graftrak ! 100W       !
       ! KA9LQM! TNC200! 2xKLM 22C     ! IC-274A+amp ! 2xKCT    ! 286 16MHz  !
WA2LQQ ! Rip   ! NB96  ! KLM435-40CX   ! TS-790A     ! KCT/GT   ! 45W        !
       ! WA2SNA! TNC-2 ! KLM2M-22C     ! TS-790A     ! KCTune/GT! 286 12Mhz. !
WA9FMQ ! Gary  ! NB96  ! KLM-14c       ! TS-790      ! KCT/QT4.0! -          !*
       ! -     !mPOWER2! KLM-22c       ! TS-790      ! KCT Tuner! Zeos386sx  !
WB6MPQ ! Al    ! NB-96 ! KLM-40C       ! FT-736      ! MANUAL   ! 50W        !
       !NN2Z.NJ! PK232 ! KLM-22C       ! FT-736      ! MANUAL   ! 386 20MHz  !
WC8J   ! Rich  ! G3RUH ! 20ele RH-XY   ! ICOM 471H   ! HB + IT  ! -          !
       ! -     ! 1270B ! 40ele XY      ! ICOM 275H   ! -        ! 286 16MHz  !
WD3Q   ! Eric  ! NB96  ! KLM-14c       ! TS-790      ! KCT      ! -          !*
       ! -     !mPOWER2! KLM-22C       ! TS-790      ! KCT-tuner! Zeos386sx  !
ZL1AOX ! Ian   ! G3RUH ! 15T HELIX RHC ! IC-475H     ! MANUAL   ! <75W       !
       ! ZL1AB !MFJ1270! KLM22C,5/8COLI! IC-275H     ! MANUAL   ! XT 10MHz   !
ZL1TRE ! Mark  ! G3RUH ! KLM40CX       ! TS-811A     ! MANUAL   ! 25W        !
       ! ZL1AB !MFJ1270! KLM22C        ! TS-711A     ! MANUAL   ! 386 26MHz  !
-------------------------------------------------------------------------------
Remarks
DL8NCI : developing own ftl0/bdcast s/w.
JA6FTL : AFC for 790/736 document is uploaded to this board.
PE1CHL : developing PACSAT s/w for Atari ST&PC,TCP/IP PE1CHL version with FTL0
PE1HML : Using NET TCP/IP with ftl0 by PE1CHL
PE1DNA : No TNC's 2*OPtoPcScc card by PA0HZP (4 8530s)
RK3KP  : Amsat-U-Sputnik.Club Stn of Center of Science & Technology for Youth
VK3CFI : CFI:Maggie, DFI:Lou
WD3Q/WA9FMQ : VITA station in Rosslyn,VA,Washington.DC
OH2SN  : rx freq controled by 1khz steps with freq.calclat. tracking program
-------------------------------------------------------------------------------
    PLEASE give me your comment about this format and send your station
information with above form via UO-14/AO-16/FO-20.IF you have general remarks,
Pse inform me within one line.

73s    SUEO ASATO  JA6FTL @ja6ftl.jnet6.jpn.asia

= = = = = = = = = = = = = = = = = = = =
Reposted (without permission ;-) by:


--
-- James Dugal, N5KNX           Internet: [e-mail]
Associate Director              Ham packet: n5knx@k5arh
Computing Center                US Mail: PO Box 42770  Lafayette, LA  70504
University of Southwestern LA.  Tel. [phone]       U.S.A.

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

Date: 15 Mar 91 02:50:40 GMT
From: swrinde!zaphod.mps.ohio-state.edu!maverick.ksu.ksu.edu!matt.ksu.ksu.edu![e-mail]
Subject: Hierarchical Forwarding pounds (#)
To: [e-mail]

While using hierarchical addressing on the packet network, what is
the use of the pound (#) in the address.  An example would be:

KB0AGD @ K0VAY.#NEKS.KS.USA.NA

I realize that #NEKS means North East Kansas, but what is the #
for?  A flyback from the days of early sub-netting?

-Steve Schallehn, KB0AGD
 Kansas State University

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

Date: 18 Mar 91 15:23:41 GMT
From: mcsun!ukc!axion!kitkat![e-mail]
Subject: Hierarchical Forwarding pounds (#)
To: [e-mail]

>
> The main reason for having the # before the second field is to eliminate any
> problem which may arise from having a local hierarchical address which is
> the same as a country or continent designator. If, for example, you had a
> local address of NA (for Northern Australia, say), then the BBS would try to
                                  ^^^^^
> send the message to North America, as that is what NA is supposed to be.
>
That should have been `might', rather than `would', depending on how the
forwarding file was set up. The important thing is that the BBS would have
to know the difference between NA meaning Northern Australia and NA meaning
North America.
    Brian

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

Date: 15 Mar 91 05:16:57 GMT
From: [e-mail]
Subject: Hierarchical Forwarding pounds (#)
To: [e-mail]

In article <[e-mail]> [e-mail] (Steve Schallehn) writes:
>While using hierarchical addressing on the packet network, what is
>the use of the pound (#) in the address.  An example would be:
>KB0AGD @ K0VAY.#NEKS.KS.USA.NA

The # (sharp, octothorp, hash, pound, etc ad nauseum) means that the
"regional" name following is a non-standardized one, as if the others
were more standardized.  In particular, it means that it's a more
localized routing indicator than ones that don't have the # in front of
them, and can be skipped without error if the station attempting to route
doesn't know what it means. (I.e., if you don't know what #NEKS means,
you may unhesitatingly skip over it and attempt to route at the KS.USA.NA)
(Note that the TELLUS.SOL.MW is implied in this address and need not be
supplied.)

Do not confuse these with the Internet hierarchical domains.  They don't
have any thing to do with the DNS, despite their identical format.  Grr.
    - Brian

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

Date: 19 Mar 91 10:44:24 GMT
From: ucselx!bionet!apple!mips!spool.mu.edu!munnari.oz.au!manuel!csc.canberra.edu.au!echo![e-mail]
Subject: Hierarchical Forwarding pounds (#)
To: [e-mail]

In <[e-mail]> [e-mail] (Brian Lloyd) writes:

>The idea of scanning from left to right is to find the most direct route to
>the destination. If I was to forward a message to you, the BBS would perform
>the following steps :
>If, on the other hand, I had a direct link to VK6BBS I would forward the
>message there, rather than to Australia, as VK6BBS is much closer to you
>Australia in general.

Hang on.  It would be stupid to route only on the first match.  I can't believe
Internet domain routers operate by only matching the first match from right to
left!

What you are saying is that EVERY segment of an address must be unique
world wide.  This, obviously, won't work!  The higher levels in the address
MUST be taken into consideration when making a match.

Carl.

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

Date: 19 Mar 91 02:50:20 GMT
From: munnari.oz.au!yoyo.aarnet.edu.au!sirius.ucs.adelaide.edu.au![e-mail]
Subject: Hierarchical Forwarding pounds (#)
To: [e-mail]

Organization: Adelaide University
NNTP-Posting-Host: snap.adelaide.edu.au

Just a note about the H-addressing.

The new AA4RE v2.11 BBS software DOES now search like the internet
style. Eg if you have an address of,

   VK5ZWI@VK5TTY.#SA.AUS.OC

the AA4RE BBS can be set to search for,

VK5TTY.#SA.AUS.OC
#SA.AUS.OC
AUS.OC
OC

The first one that matches is the one that the mail will go to.

This means the # is no longer required. BUT I wouldnt go suggesting
it be dropped because there are still many BBS systems that dont
search that way.

Cheers de Grant VK5ZWI

   Grant Willis (VK5ZWI) - Adelaide University, South Australia -
     ** 2nd/3rd Year Electrical Engineering Student **
Packet Radio: VK5ZWI@VK5TTY.#SA.AUS.OC    AmPR TCP/IP: [44.136.171.11]
AARNet/Internet1: [e-mail]
ACSnet/Internet2: [e-mail]
Disclaimer: What I write is mine. The Uni has nothing to do with it!

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

Date: 18 Mar 91 15:06:24 GMT
From: mcsun!ukc!axion!kitkat![e-mail]
Subject: Hierarchical Forwarding pounds (#)
To: [e-mail]



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

Date: 18 Mar 91 21:52:39 GMT
From: swrinde!zaphod.mps.ohio-state.edu!casbah.acns.nwu.edu![e-mail]
Subject: Hierarchical Forwarding pounds (#)
To: [e-mail]

In article <[e-mail]> [e-mail] writes:
>The idea of scanning from left to right is to find the most direct route to
>the destination. If I was to forward a message to you, the BBS would perform
>the following steps :
>
>Do I know where VK6ZJM is?
>No - do I know where VK6BBS is?
>No - do I know where #WA is?
>No - do I know where AUS is?
>Yes - forward the message in that direction.

In proper domain-style addressing, a la the Internet, this would rather be:

Do I know where VK6ZJM.WA.AUS is?     No
Do I know where WA.AUS is?            No
Do I know where AUS is?               Yes
Forward in direction AUS

Note that the complete tail is a part of the address.  Thus, VK6ZJM.WA.AUS
could not be confused with, for example W0BBS.WA.US.NA; if my
(non-existent) system N9ITP.IL.US.NA connected it would try:

    W0BBS.WA.US.NA      Not found           VK6ZJM.WA.AUS      Not found
    WA.US.NA            Found -> forward    WA.AUS             Not found
                        AUS                Found -> forward

See how easy it becomes?

       73 de N9ITP   U R 599+9600 BPS KN + @
--
hpa = H. Peter Anvin (in case you wondered) * Heja Sverige!
INTERNET:   [e-mail]   FIDONET:  1:115/989.4
HAM RADIO:  N9ITP, SM4TKN             RBBSNET:  8:970/101.4

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

Date: 21 Mar 91 17:07:46 GMT
From: swrinde!elroy.jpl.nasa.gov!sdd.hp.com!spool.mu.edu!munnari.oz.au!uniwa!cc.curtin.edu.au![e-mail]
Subject: Hierarchical Forwarding pounds (#)
To: [e-mail]

In article <[e-mail]>, [e-mail] (Brian Lloyd) writes:
> The problem comes when we
> comes across a sub-field which is not unique (eg #WA could be Western
> Australia or the Watsui province of Japan). The BBS somehow needs to know
> that there is a #WA in Australia and another one in Japan, and at present I
> don't think that's possible. What needs to be added, therefore, is some way
> of allowing the BBS to forward to #WA.AUS or #WA.JAP

   This is the point I was trying to make in my original post. There IS such
a way, without adding anything. If you scan from right to left, with all fields
significant, then there's no ambiguity. To use your example, #WA.AUS is
obviously not the same as #WA.JAP, and any software that thinks it is clearly
brain-damaged. It's like telling someone that he can't call himself
"John Smith" because there's already a "John Jones" somewhere else in the
world, regardless of the fact that they're bound to have different higher-order
addresses (ie one lives in Sydney and the other lives in Oslo).

.....Ron
--

===============================================================================
 Internet: [e-mail]                | "You can lead a horse to
 ACSnet: [e-mail]                      | water, but if you can
 Bitnet: [e-mail]    | get him to float on his
 UUCP  : uunet!munnari.oz!cc.curtin.edu.au!Murray_RJ | back you've really got
Amateur Packet Radio: VK6ZJM@VK6BBS.#WA.AUS.OC       | something"
           TCP/IP: 44.136.204.14, 44.136.204.19  |    -- Murphy's Law I
===============================================================================

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

Date: 16 Mar 91 20:25:48 GMT
From: usc!apple!bionet!hayes.ims.alaska.edu!acad3.alaska.edu![e-mail]
Subject: Hierarchical Forwarding pounds (#)
To: [e-mail]

In article <[e-mail]>, [e-mail] (Steve Schallehn) writes...
>While using hierarchical addressing on the packet network, what is
>the use of the pound (#) in the address.  An example would be:
>
>KB0AGD @ K0VAY.#NEKS.KS.USA.NA
>
>I realize that #NEKS means North East Kansas, but what is the #
>for?  A flyback from the days of early sub-netting?
>
This is an excerpt from documentation provided with AA4RE's BB
bulletin board program:

"W0RLI, VE3GYQ, and N6VV have devised a scheme called hierarchical
addressing.  Here's their description of their idea:

(stuff deleted)

"As an example, say that we send something to W0RLI @ W0RLI.CA.USA.NA,
and that the only entries that we have in the forward file are for
CA.  That match would be sufficient to allow the message to be forwarded.
If W0RLI were found, that entry would take precedence (because
it is more left in the field than CA) and would of course also
ensure delivery.  The best way to look at it is 'W0RLI AT W0RLI
which is in CA which is in USA which is in NA'.  So far so good.

But the Japanese network wants to use area routing numbers.  For
example, JA1ABC.42.JPN.AS ... and everyone says, 'So what, let
them!'  Of course, that is very mature of all of us, but the trouble
is that the 42 in that string may also match wild-card ZIP codes
that some folks keep in their forward file, such as 42*.  The
solution we propose is to use an agreed upon key character for
designators below the state and province level, and we recommend
the octothorpe, '#'.

So now the above address would be JA1ABC @ JA1KSO.#42.JPN.AS ..."

(etc.)

Hope that explains a little more fully the reasoning ...

John

>-Steve Schallehn, KB0AGD
> Kansas State University

--

John Stannard
[e-mail]              BITNET:  IFJRS@ALASKA
[e-mail]           kl7jl.ampr.org  [44.22.0.1]

"God is the Answer!"   "Oh?? ... er, ... What was the Question?"

--

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

Date: 21 Mar 91 01:49:06 GMT
From: sdd.hp.com!spool.mu.edu!munnari.oz.au!manuel!csc.canberra.edu.au!echo![e-mail]
Subject: Hierarchical Forwarding pounds (#)
To: [e-mail]

In <[e-mail]> [e-mail] (Brian Lloyd) writes:

>comes across a sub-field which is not unique (eg #WA could be Western
>Australia or the Watsui province of Japan). The BBS somehow needs to know
>that there is a #WA in Australia and another one in Japan, and at present I

Precisly.  The WHOLE address needs to be taken into consideration when
routing.  You cannot route to just "#WA".  You must route to "#WA.AUS.OC".

>> VK6ZJM) should ONLY be considered for routing purposes if it is shown as part
>I think that when someone moves the first person they tell (in the packet
>world) is the SYSOP of their local BBS, otherwise that BBS is going to keep
>trying to forward mail to them when they're not there. Being able to forward
>on the TO field is often very useful - remote SYSOPs often like to have mail
>addressed to SYSOP forwarded on to them, for example.

Forwarding on the TO field shouldn't be enabled.  The ONLY thing the TO
field should be used for is allowing the destination station (named in the TO)
to read his private mail.  It certainly shouldn't be used for forwarding.
Most (if not all) programs allow remapping of addresses.  If your remote
SYSOP (mentioned above) wanted to get his bulletins then they should be
remapped to SYSOP@<his BBS>.

Maybe things are different in the UK but here in Canberra I don't try to
forward mail to individual users.  They log on to my BBS to read it.  I
have 2 users who run PMSs who get mail forwarded and I have asked them to
detail their heirarchical addresses as;
(for example)
[e-mail]
and no other BBS except me has to have routing information for them.
(I also remap vk1mc@vk1kcm to [e-mail] as few
amateurs understand heirarchical addressing. :-( )

The TO field on Bulletins is another story. :-(  It shouldn't be there
at all.

Carl.
[e-mail]
[e-mail]
3:620/241.7
[44.136.0.5][14][16] PC/BBS/Xenix

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

Date: 19 Mar 91 18:21:01 GMT
From: swrinde!zaphod.mps.ohio-state.edu!usc!snorkelwacker.mit.edu!bloom-beacon!eru!hagbard!sunic!mcsun!ukc!vision!mgc![e-mail]
Subject: Hierarchical Forwarding pounds (#)
To: [e-mail]

In article <[e-mail]> [e-mail] writes:
>From article <[e-mail]>, by [e-mail] (Ron Murray):
>>
>> 1. The whole hierarchical forwarding process as implemented is a kludge (like
>>    half of the rest of packet's "protocols"): why in hell should it scan left
>>    to right when it makes more sense to scan right to left?
>
>The idea of scanning from left to right is to find the most direct route to
>the destination. If I was to forward a message to you, the BBS would perform
>the following steps :
>
>Do I know where VK6ZJM is?
>No - do I know where VK6BBS is?
>No - do I know where #WA is?
>No - do I know where AUS is?
>Yes - forward the message in that direction.
>

It's equally true to say:

Do I know where AUS is? Yes - continue; No - warn Sysop
Do I know where #WA is? Yes - continue; No - forward using AUS
Do I know where VK6BBS is ? Yes - continue; No - forward using #WA
Do I know where VK6ZJM is ? Yes - forward, No - forward using VK6BBS

So right to left is OK, too...and is much more in line with most other mail
system algorithms (although that might not count for much!). However, with
your method, you might get the answer:

VK6ZJM - no
VK6BBS - no
#WA - yes......it's the Watsui province of Japan, so send it there.

Right to left precedence is required.

And while I'm pontificating (:-) the left most callsign (in the above examples
VK6ZJM) should ONLY be considered for routing purposes if it is shown as part
of the domain segment (eg VK6ZJM.VK6BBS.#WA.AUS). Once the '@' is reached in
the right to left scan, routing should stop. The reason is this: the originator
of the message may know that VK6ZJM has moved QTH - routing software wouldn't
always know this.


--
Dave Lockwood          [e-mail]                 G4CLI@GB7DCC._199.GBR.EU
Head of Technology           ...!uunet!mcsun!ukc!vision!mgc!dave

MG Computer Systems Ltd, PO Box 50, Doncaster, DN4 5AW [phone]

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

Date: 18 Mar 91 01:13:21 GMT
From: sdd.hp.com!samsung!munnari.oz.au!uniwa!vax7![e-mail]
Subject: Hierarchical Forwarding pounds (#)
To: [e-mail]

In article <[e-mail]>, [e-mail] (STANNARD JOHN R) writes:

 (quoting from the AA4RE documentation)
>
> "As an example, say that we send something to W0RLI @ W0RLI.CA.USA.NA,
> and that the only entries that we have in the forward file are for
> CA.  That match would be sufficient to allow the message to be forwarded.
> If W0RLI were found, that entry would take precedence (because
> it is more left in the field than CA) and would of course also
> ensure delivery.  The best way to look at it is 'W0RLI AT W0RLI
> which is in CA which is in USA which is in NA'.  So far so good.
>
> But the Japanese network wants to use area routing numbers.  For
> example, JA1ABC.42.JPN.AS ... and everyone says, 'So what, let
> them!'  Of course, that is very mature of all of us, but the trouble
> is that the 42 in that string may also match wild-card ZIP codes
> that some folks keep in their forward file, such as 42*.  The
> solution we propose is to use an agreed upon key character for
> designators below the state and province level, and we recommend
> the octothorpe, '#'.
>

   So far, it all seems to make sense (even if about as easy to read as Attila
the Hun's laundry list). Here in Australia they went a little further...

   If you look at my .sig below, you'll see the #WA between the BBS call and
the abbreviation for Australia. We were told that this was necessary (rather
than the much more obvious "WA" for Western Australia) because the hierarchical
forwarding software would assume that it was the abbreviation for Washington
state in the US because it scans the address from left to right. This leads me
to conclude that either:

1. The whole hierarchical forwarding process as implemented is a kludge (like
   half of the rest of packet's "protocols"): why in hell should it scan left
   to right when it makes more sense to scan right to left? Internet domain
   names are scanned in this fashion. It's a bit like telling someone that he
   can't call himself "John Smith" because there's already a John Smith
   somewhere else. Or worse, that he has to call himself #Fred Bloggs because
   there's a Fred Bloggs in Outer Mongolia.

or

2. Someone in Australia mis-read the documentation and decided that this name
   change was necessary. This is probably the more likely.

Suggestions and corrections welcome.

....Ron

--

===============================================================================
 Internet: [e-mail]                | "You can lead a horse to
 ACSnet: [e-mail]                      | water, but if you can
 Bitnet: [e-mail]    | get him to float on his
 UUCP  : uunet!munnari.oz!cc.curtin.edu.au!Murray_RJ | back you've really got
Amateur Packet Radio: VK6ZJM@VK6BBS.#WA.AUS.OC       | something"
           TCP/IP: 44.136.204.14, 44.136.204.19  |    -- Murphy's Law I
===============================================================================

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

Date: 20 Mar 91 11:06:55 GMT
From: gatech!bloom-beacon!eru!hagbard!sunic!mcsun!ukc!axion!kitkat![e-mail]
Subject: Hierarchical Forwarding pounds (#)
To: [e-mail]



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

Date: 20 Mar 91 21:27:34 GMT
From: swrinde!elroy.jpl.nasa.gov!usc!apple![e-mail]
Subject: How to get email from packet???
To: [e-mail]

I'm a relative newcomer to the world of packet radio, and am interested
in getting email via packet.  How might this be accomplished?  If someone
could point me to references, books, etc. that might help (something current)
I'd really appreciate it!

Ed Carp, N7EKG/6
Alameda, CA
--
Ed Carp  N7EKG/6        [e-mail]         ...uunet!khijol!erc
            Alameda, CA

Computers HAVE caused a revolution in how much information we
can safely ignore!    [e-mail] (Rob Schaeffer)

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

Date: 15 Mar 91 20:06:53 GMT
From: hpl-opus!hpnmdla![e-mail]
Subject: Inadvertant "clear screen"
To: [e-mail]

In rec.radio.amateur.packet, [e-mail] (Andre Molyneux) writes:

>I've been experiencing an odd problem with my packet station.  Basically,
>my screen gets cleared by the transmissions of other stations.  The problem
...>developed as follows:

>I understand that I can set the TNC to filter out specific characters that
>are incompatible with the terminal in use.  Obviously ctrl-z is one of them,
>but I need to find what the other "clear screen" character is.  Any idea on
>how I should go about this?

The ASCII "formfeed" character (12 decimal) is used as a "clear screen"
command by many terminals.

AL N1AL

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

Date: 18 Mar 91 19:37:51 GMT
From: swrinde!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac,
Subject: Inadvertant "clear screen"
To: [e-mail]

In article <[e-mail]> [e-mail] (Gary Coffman) writes:
>formfeed will be one character you'll want to filter. Most nodes, and
>all TCP/IP stations transmit some packets in fully binary mode so you
>will often have characters on your screen in monitor mode that will

The 1.1.7 tapr firmware (MFJ adds WEFAX and calls it 1.2.7) includes
a MNONAX25 ON/OFF command, to eliminate tcp/ip, netrom routing, and
other packets having a PID different from that of AX.25.

73,
--
-- James Dugal, N5KNX           Internet: [e-mail]
Associate Director              Ham packet: n5knx@k5arh
Computing Center                US Mail: PO Box 42770  Lafayette, LA  70504
University of Southwestern LA.  Tel. [phone]       U.S.A.

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

Date: 17 Mar 91 18:45:47 GMT
From: usc!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac,
Subject: Inadvertant "clear screen"
To: [e-mail]

In article <[e-mail]> [e-mail] (Andre Molyneux) writes:
>I've been experiencing an odd problem with my packet station.  Basically,
>my screen gets cleared by the transmissions of other stations.  The problem
>developed as follows:
[deleted]
>I understand that I can set the TNC to filter out specific characters that
>are incompatible with the terminal in use.  Obviously ctrl-z is one of them,
>but I need to find what the other "clear screen" character is.  Any idea on
>how I should go about this?  (I've asked another packet operator to see if
>he get's any "unusual" characters from the node in question.  He reports
>that he doesn't see anything out of the ordinary when he connects to this
>node.)

Some TNCs have a filter command that removes all non-printing characters
from the incoming stream. I don't believe the MFJ 1274 is one of them.
I think you are limited to 10 characters in your filter list. Certainly
formfeed will be one character you'll want to filter. Most nodes, and
all TCP/IP stations transmit some packets in fully binary mode so you
will often have characters on your screen in monitor mode that will
cause your terminal to do strange things.  You'll need to sit down with
your terminal book and TNC manual and figure out what to kill.

Gary KE4ZV

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

Date: 14 Mar 91 23:39:46 GMT
From: pyramid![e-mail]
Subject: Inadvertant "clear screen"
To: [e-mail]

I've been experiencing an odd problem with my packet station.  Basically,
my screen gets cleared by the transmissions of other stations.  The problem
developed as follows:

I bought a MFJ 1274 TNC and hooked it up to a XT clone using Procomm.
Everything ran fine.  Decided to free up the PC by getting a dedicated
terminal for packet.  Borrowed a Lee Data (don't remember the model #)
terminal from a friend, which ran in VT200 emulation mode.  Found that
the screen would get cleared everytime my TNC tried to display a packet
from a local node (SFO on 145.01 in the SF bay area).  I connected to
this node and found that any option I chose would result in a cleared
screen.

I didn't worry about it too much considering that the terminal was a
loaner.  Well, this past weekend I went to the Foothill College swapmeet
and picked up an old Televideo terminal (TVI 321???).  Fired it up and
found that it too would get its screen cleared by the same node.  In
addition, I found that the character used to indicate the end of a
message on mailboxes (ctrl-z), also clears the screen of the Televideo
(ctrl-z didn't bother the Lee Data).

I understand that I can set the TNC to filter out specific characters that
are incompatible with the terminal in use.  Obviously ctrl-z is one of them,
but I need to find what the other "clear screen" character is.  Any idea on
how I should go about this?  (I've asked another packet operator to see if
he get's any "unusual" characters from the node in question.  He reports
that he doesn't see anything out of the ordinary when he connects to this
node.)

+---------------------------------------------------+--------------------------+
| Andre Molyneux KA7WVV  [e-mail] |*** GENERIC DISCLAIMER ***|
+---------------------------------------------------+--------------------------+
|      -=-------- PYRAMID TECHNOLOGY CORPORATION    |All the usual disclaimers |
|    ---===------ 1295 Charleston Road              |apply although, as far as |
|  -----=====---- Mountain View, California 94043   |I can tell, my employer   |
|-------=======-- [phone]                    |doesn't care what I think!|
+---------------------------------------------------+--------------------------+

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

Date: 20 Mar 91 04:20:39 GMT
From: uhccux!uhcmtg.phys.hawaii.edu![e-mail]
Subject: KA9Q & mbox BBS forwarding
To: [e-mail]

I need some assistance from any kind soul in mbox message forwarding.

I'm trying to setup a PC running KA9Q to forward messages to non-TCP/IP
stations.  Suppose I want messages for AH6BW to be forwarded to AH6BW@AH6BW-2
where AH6BW-2 is a different machine that doesn't handle TCP/IP.

In my /alias file I have:

ah6bw ah6bw@ah6bw-10

In my /spool/forward.bbs file I have:

----
ah6bw-10
ax25 ax1 ah6bw-10
ah6bw
----

When the SMTP timer kicks in I get a message about ah6bw-10 being an unknown
host (as if it wants to deliver the message via TCP/IP and it fails on a
hostname lookup).  Shouldn't the entry in the forward.bbs file be enough to
tell NOS that ah6bw-2 is NOT a TCP/IP station?  What am I missing here?

I'm running the latest version of NOS from thumper.

Tony
AH6BW
[e-mail]


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

Date: 21 Mar 91 17:13:53 GMT
From: swrinde!elroy.jpl.nasa.gov!sdd.hp.com!spool.mu.edu!munnari.oz.au!uniwa!cc.curtin.edu.au![e-mail]
Subject: KA9Q v910308 problems
To: [e-mail]

   When I run KA9Q version 910308 on my XT clone, it works fine on a SLIP link
to my AT at 9600 baud. If I try an AX25 connect to a non-TCP/IP system, it
crashes after a few K of data has been received. I don't think it happens
on a Telnet session over AX25, but I can't test it due to a complete lack of
other stations here in Perth running TCP/IP (Philistines!). It certainly
didn't crash the one time I tried a Telnet to it from someone else's computer,
but I might have been lucky.
   Has anyone else experienced this?

.....Ron
--

===============================================================================
 Internet: [e-mail]                | "You can lead a horse to
 ACSnet: [e-mail]                      | water, but if you can
 Bitnet: [e-mail]    | get him to float on his
 UUCP  : uunet!munnari.oz!cc.curtin.edu.au!Murray_RJ | back you've really got
Amateur Packet Radio: VK6ZJM@VK6BBS.#WA.AUS.OC       | something"
           TCP/IP: 44.136.204.14, 44.136.204.19  |    -- Murphy's Law I
===============================================================================

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

Date: 17 Mar 91 00:44:36 GMT
From: sdd.hp.com!zaphod.mps.ohio-state.edu!maverick.ksu.ksu.edu!matt.ksu.ksu.edu![e-mail]
Subject: KAM dual-mode enhancement
To: [e-mail]

[hopefully there is enough interest to merit this reply]

A question came over the net a few weeks ago asking if a Kantronics
KAM could do both VHF packet and HF RTTY operation simultaneously.

After talking to Karl Medcalf of Kantronics, I have just found out
that Kantronics is testing new firmware to allow any HF operation and
VHF packet operation to occur at the same time on a Kantronics KAM.
With the firmware upgrade and a specialized program running on a PC,
one could, for example, log into a DX cluster and work RTTY at
the same time.

Availability for the upgrade scheduled mid-spring.  Pricing for upgrades
is somewhere around $100.

---
-Steve Schallehn, KB0AGD
 Kansas State University

PS:  I am not affiliated with Kantronics.

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

Date: 15 Mar 91 18:16:15 GMT
From: swrinde!zaphod.mps.ohio-state.edu!caen!kuhub.cc.ukans.edu!zeus.unomaha.edu![e-mail]
Subject: Monthly On-Line Elmers Resource Directory
To: [e-mail]

As part of the multi-pronged strategy of Project SAVE THE BANDWIDTH, I
will now put out a call for On-Line Elmers.  These are people, who by
virtue of skill and knowledge in an area of expertise in ham radio,
are willing to field E-mail by readers of the rec.radio.* groups.

Volunteers need only send me their name, E-mail address, and area of
expertise.  "Generalists" or "Miscellaneous" Elmers are also quite
welcome. Naturally, the more that volunteer, the more the work is
distributed.  If upon volunteering, you are unable to meet your
obligations, simply write to me and I will remove your name from the
list.   I could also add that because of "personal committments" or
"career broadening" you no longer are available to Elmer on a regular
basis.

I will be the point-of-contact for this project.  I will maintain the
list, post it to the groups at least monthly, and have the latest copy
placed in the supplemental archives at ftp.cs.buffalo.edu in
subdirectory pub/ham-radio.

Here is the latest version of the list.  If you sent me mail and are
not on it, please resend as it may have been lost on the way or once
it reached my host.

73, Paul, KD3FU

[e-mail]  uunet!unocss!zeus!acmnews  137.48.1.1

[e-mail]        uunet!mimsy!umail!ps67     128.8.10.28


ON-LINE Elmers Resource Directory (as of 03/15/91)
------------------------------------------------------

Dan Halbert, KB1RT
QTH is West Newton, MA, near Boston.

[e-mail]

Building homebrew QRP gear, Advice on simple antennas

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

Paul W. Schleck, KD3FU

[e-mail]
[e-mail]

Miscellaneous, Internet, College Clubs

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

Mike Waters    AA4MW/7

[e-mail]

Miscellaneous

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

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

Date: 22 Mar 91 00:42:34 GMT
From: dog.ee.lbl.gov!ncis.tis.llnl.gov!lll-winken!uwm.edu!caen!kuhub.cc.ukans.edu!zeus.unomaha.edu![e-mail]
Subject: Monthly On-Line Elmers Resource Directory
To: [e-mail]

(Note:  Although less than a month has gone by, my list of volunteers
has nearly quadrupled.  Also, someone suggested that I add a list
of suggested areas of expertise.  So, here is the latest list...)

As part of the multi-pronged strategy of Project SAVE THE BANDWIDTH, I
will be compiling a directory of On-Line Elmers.  These are people
who, by virtue of skill and knowledge in an area of expertise in ham
radio, are willing to field E-mail by readers of the rec.radio.*
groups.

Volunteers need only send me their name, E-mail address, and area of
expertise.  As requested, here is a suggested list of areas of
expertise that are needed:

 1.  Volunteer Examiners
 2.  Novice Instructors
 3.  DX'ers and Contesters
 4.  QRP
 5.  Homebrewers
 6.  Packet Ops (both AX.25 and TCP/IP)
 7.  VHF and Repeaters
 8.  OSCAR and other satellites
 9.  MARS (Military Affiliate Radio System)
10.  CAP (Civil Air Patrol)
11.  ARES (Amateur Radio Emergency Service)
12.  RACES (Radio Amateur Civil Emergency Service)
13.  Skywarn (Amateur Weather Spotters)
14.  ARRL Field Organization (American Radio Relay League)

"Generalist" or "Miscellaneous" Elmers are also quite welcome.
Naturally, the more that volunteer, the more the work is distributed.
If upon volunteering, you are unable to meet your obligations, simply
write to me and I will remove your name from the list.   I could also
add that because of "personal committments" or "career broadening" you
no longer are available to Elmer on a regular  basis.

I will be the point-of-contact for this project.  I will maintain the
list, post it to the groups at least monthly, and have the latest copy
placed in the supplemental archives at ftp.cs.buffalo.edu in
subdirectory pub/ham-radio.

Here is the latest version of the list.  If you sent me mail and are
not on it, please resend as it may have been lost on the way or once
it reached my host.

73, Paul, KD3FU

[e-mail]  uunet!unocss!zeus!acmnews  137.48.1.1

[e-mail]        uunet!mimsy!umail!ps67     128.8.10.28


ON-LINE Elmers Resource Directory (as of 03/21/91)
-----------------------------------------------------

John Brewer WB5OAU

[e-mail]

Miscellaneous, Wire antennas,

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

Dan Halbert, KB1RT
QTH is West Newton, MA, near Boston.

[e-mail]

Building homebrew QRP gear, Advice on simple antennas

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

R.D. Keys

Dept. of Crop Science
NCSU
Raleigh, NC 27695-7620

[e-mail]

de NA4G, "Boat Anchor Bob", an ol' cw fart .....

If I can be of assistance in older equipment, junk-boxing
your way to hamdom, the cheapskate's approach, let me
know.

22 yrs a ham, extra class, mostly cw, mostly boat anchors
and radio in the traditional sense.

{Telegraphy has been in my family for almost 100 years!}

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

Dave Potter, K1MBO

[e-mail]

electronics theory, regulations, antennas and
transmission lines, operating practices.

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

Tony Reeves
KK6XC
QTH Beach Area of So. Los Angeles
Torrance, Redondo Beach, Hermosa Beach, Manhattan beach

[e-mail]

Novice training, local VE for Novice-Tech tests,
General questions

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

Paul W. Schleck, KD3FU

[e-mail]
[e-mail]

Miscellaneous, Internet, College Clubs

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

Tom Sefranek  WA1RHP

[e-mail]

Elmering for the last 20 years.
Almost all fields,
Specializing in power supplies, micro-controllers, antennas

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

Diana L. Syriac
Leominster, MA
[e-mail]
KC1SP

QSL Bureaus (how to use them)
Volunteer Examiner Service (how to become one)
Macintosh Hamstacks
Civil Air Patrol

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

Mike Waters    AA4MW/7

[e-mail]

Miscellaneous

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

Bob Witte              HP Colorado Springs Division
[e-mail]        P.O. Box 2197
Phone:[phone]   Colorado Springs, CO  80901
Radio: KB0CY
"All Disclaimers Apply."

Miscellaneous

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

End of Directory

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

Date: 14 Mar 91 15:24:00 GMT
From: swrinde!zaphod.mps.ohio-state.edu!magnus.acs.ohio-state.edu!csn!boulder!bohemia!f510.n5000.z200.METRONET.ORG![e-mail]
Subject: New packet user
To: [e-mail]

Hi Clay and welcome to Ham Radio and Packet. I run packet with
little more than a terminal program on an old CPM machine and it
works fine. One thing you will need is some local help for finding
your local BBS on packet; equipment set up; etc. Thats a little
tough to do here. Once on the air, you can connect to the local BBS
and send messages all over the world. Most BBS's have a help file
that will describe the commands. While connected to any other packet
station, or even to your own mailbox, your computer works as a
terminal, so I would n't worry about operating system. Just have a
terminal emulator program available. You can work up to a dedicated
package like LanLink (which is for DOS) later.
By the way, when you get running send me a note. My call is N0JCG
and my home BBS is WA0CQG. You would address a message to me at
N0JCG @ WA0CQG. I think you'l like packet. I QSO with England,
Greece and Israel regularly with it.
---
 * Origin: The Computer Lab (200:5000/510)

--
=============================================================================
Gary Box - via MetroNet node 200:5000/301
The Bohemia BBS System, Boulder Colorado [phone]
UUCP:  [e-mail]
 or :  ...!boulder!bohemia.METRONET.ORG!510!Gary.Box
=============================================================================

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

Date: 21 Mar 91 21:24:28 GMT
From: [e-mail]
Subject: No Subject
To: [e-mail]



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

Date: 13 Mar 91 22:08:24 GMT
From: swrinde!zaphod.mps.ohio-state.edu!usc!apple!bionet!hayes.ims.alaska.edu!acad3.alaska.edu![e-mail]
Subject: Packet BBS SID and personal mbox reverse forward
To: [e-mail]

In article <[e-mail]>, [e-mail] (J. Craig Farrar) writes...
>Problem: Home BBS (MBL) will forward to personal mailbox in my TNC, but the TNC
>will not respond to the reverse forward poll when it sees it.
>
(Stuff deleted)
>
>The MBL board is a busy one and successfully forwards and reverse forwards
>with several neighboring boards.  The problem with the TNC mailboxes seems
>to be that they don't have a '$' in their SID.  That is reasonable since they
>are intended for private mail forwarding and not the flood forwarding that
>needs BID checking.  However, it causes the reverse forwarding to fail because
>the full-service BBS stations seem to require it.
>
>Checking with the sysop of the MBL board we learn that this is a built-in
>feature and can't be changed.  Is this really true?  It would really be nice
>to have reverse forwarding work as it has been advertised, but we seem to have
>an impasse.  Do any of you in the net know a solution?
>
A user here in Alaska has a KAM with the same problem--he adds the
SID _with_ the '$' in his "connect" text msg--it seems to work
quite well.  Hope this works for you in _your_ situation.

73, John

>---------
>J. Craig Farrar   [e-mail]   [e-mail]
>Ohio University, Athens, Ohio

--

John Stannard
[e-mail]              BITNET:  IFJRS@ALASKA
[e-mail]           kl7jl.ampr.org  [44.22.0.1]

"God is the Answer!"   "Oh?? ... er, ... What was the Question?"

--

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

Date: 20 Mar 91 20:27:21 GMT
From: newstop!eastapps!Sun.COM![e-mail]
Subject: PK-88 Pinouts
To: [e-mail]

I bought a PK-88 a few months ago and am now ready to use it,
but I seem to have misplaced the manual.  Can anyone tell me
the pinouts on the 8 pin tx/rc connector?

Thanks....Keith Erskine - KA1RHO

ps: I'm connecting this to an old Yaesu FT-22R 2M all-band.  Any
special considerations I should know about? - thx ke

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

Date: 21 Mar 91 17:34:42 GMT
From: sdd.hp.com!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!att!pacbell.com!tandem!netcom![e-mail]
Subject: PK-88 Pinouts
To: [e-mail]

In article <[e-mail]> [e-mail] (Keith Erskine - Sun Technical Marketing - Boston) writes:
>I bought a PK-88 a few months ago and am now ready to use it,
>but I seem to have misplaced the manual.  Can anyone tell me
>the pinouts on the 8 pin tx/rc connector?

    1       Ground          Brown
    2       Mic Audio       White
    3       Push-To-Talk    Red
    8       Receive Audio   Green
    7       Squelch Input   Black (optional)

Using the provided cable, follow the colors above to match up with the
manual, when you find it.

By the way, I am reasonably computer literate, network literate and
radio literate and I wouldn't attempt to do much with this TNC without
the book.  It's worth getting another copy from AEA, since the TNC is
loaded with commands and features.
                    -edg
--
Ed Greenberg, WB2GOH/6
San Jose, CA
[e-mail]

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

Date: 17 Mar 91 02:39:05 GMT
From: ogicse!unicorn![e-mail]
Subject: portable packet
To: [e-mail]

I do not own a packet
although I am thinking about buying one soon, one thing you might try though is purchasing one of the new breed of "notebook" size pc laptops.  Most I have
seen come with serial and parallel ports, vga lcd, screen and a fair amount
of memory, and a 1.44mb 3.5in disk - all for between 1800-3600$.  Zeos, Austin
and a few others all make IBM compatible machines with 80286 12-16hz processors
for about 2000 dolloars.  Take a look in the March Computer Shopper for a run-
down on most the latest of these notebook sized machines weighing generally
less than 6lb.
          hope you find what you're looking for,
                Chris

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

Date: 14 Mar 91 19:37:07 GMT
From: swrinde!cs.utexas.edu!ut-emx!ccwf.cc.utexas.edu![e-mail]
Subject: portable packet
To: [e-mail]

I am planning a cross country expedition (by *RAIL*) and would like
to take along my packet radio system. I have a couple of issues I'd like
to discuss:

DUMB TERMINALS (or, 'Why is this lap-top so heavy?')
My girlfriend agreed to loan me her laptop computer (bless her heart)
but it just HURLS RF at 145.01 MHz. In addition, I'd just use it to run
PROCOMM anyway. (It weighs more than my entire packet setup!)
So I was at the mall this morning and saw something that
I found intriguing (as Cmdr. Data would say). Have you seen the Casio
B.O.S.S. model SF-9500? or model SF-800? These are little clock, calendar,
memo, telephone number, rolodex, scratch your back, do everything hand-held
LCD display things with little alpha-numeric keypads... and guess what...
There's a serial port on the little guy and the literature states that
"you can hook it up to your PC..."!
Has anyone heard of any sort of modern little hand held LCD thing being used
as a dumb (RS232) terminal? I'd only need a couple of lines (with scrollback
perhaps) and I'd let my TNC do all the work.

In closing, the other issue I was concerned about is...
Should I even bother attempting to try 2 meter work from within a
huge steel rail car moving at 80 mph? I love trains and have traveled coast
to coast more than 10 times (I don't fly), and I have met other hams aboard
the train with their HT's by their side. What do you think?
All aboard!
David
their HT's on their belts

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

Date: 14 Mar 91 22:40:55 GMT
From: sdd.hp.com!zaphod.mps.ohio-state.edu!know!tegra![e-mail]
Subject: portable packet
To: [e-mail]

In article <[e-mail]> [e-mail] (david lee) writes:

   DUMB TERMINALS (or, 'Why is this lap-top so heavy?')
   My girlfriend agreed to loan me her laptop computer (bless her heart)
   but it just HURLS RF at 145.01 MHz. In addition, I'd just use it to run
   PROCOMM anyway. (It weighs more than my entire packet setup!)
   So I was at the mall this morning and saw something that
   I found intriguing (as Cmdr. Data would say). Have you seen the Casio
   B.O.S.S. model SF-9500? or model SF-800? These are little clock, calendar,
   memo, telephone number, rolodex, scratch your back, do everything hand-held
   LCD display things with little alpha-numeric keypads... and guess what...
   There's a serial port on the little guy and the literature states that
   "you can hook it up to your PC..."!
   Has anyone heard of any sort of modern little hand held LCD thing being used
   as a dumb (RS232) terminal? I'd only need a couple of lines (with scrollback
   perhaps) and I'd let my TNC do all the work.

I had the idea of connecting tha cable from my BOSS into the speaker
jack of my IC-24, put a NOS prompt on the screen and send it in to QST
as portable packet.

The answere to your question is: no.  The BOSS will transfer data to
another computer running the appropriate software with a simple Intel
Hex based protocol.  There is no "terminal mode" although I bet Casio
could sell a few more BOSSs if they added one.

The BOSS is a really neat and useful device although the only amateur
radio uses I have found for it are alternate time (GMT) and saving
repeater control codes and frequency information for reference.


"theobromine: a compound which, contrary to it's name,
contains neither bromine nor God" -- David Throop
 _____
|     | Johnathan Vail | [e-mail]
|Tegra| [phone] | N1DXG@448.625-(WorldNet)
 -----  [e-mail] {...sun!sunne ..uunet}!tegra!vail

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

Date: 16 Mar 91 15:45:34 GMT
From: swrinde!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac,
Subject: portable packet
To: [e-mail]

In article <[e-mail]> [e-mail] (david lee) writes:
>I am planning a cross country expedition (by *RAIL*) and would like
>to take along my packet radio system. I have a couple of issues I'd like
>to discuss:
>
>DUMB TERMINALS (or, 'Why is this lap-top so heavy?')

A friend of mine uses his Sharp Wizard with a pocket packet TNC. The
major problems are the screen and keyboard being smaller than standard.
Most packeteers format their messages for 80 column and this makes it
hard to read on a 40 col display. Secondly, the keyboards on these little
jewels aren't really suited to touch typing. Keyboard QSOs are slow anyway,
but having to hunt and peck on the little keyboard makes it intolerable
to me anyway. The new Wizard (the one with the QWERTY keyboard) has a
serial port that works up to 9600 baud. I don't know the baud rates
available on the BOSS series. I have another friend who has one of
these and I'll ask him. The consensus around here is that the Wizard
is a better value than the BOSS, but if you're only going to use it
as a terminal, then that probably doesn't matter.

One lightweight system I've used for portable packet is the Radio
Shack Mod 100. It suffers from the 40 col screen, but the keyboard is
decent and it has a built in terminal program. Used Mod 100s should
be lots cheaper than the BOSS or the Wizard. RCA used to make a simple
dumb terminal with a 2 line 80 col display and a full size keyboard.
These are a little smaller than a Mod 100 and I've seen them at
hamfests for $25.

Your HT should work fine on the train. I'd make a twinlead J-pole
and tape it to a window for best results. Between your terminal and
your TNC, there should be enough digital hash that I'd want to locate
the antenna a few feet from the noise. Also the extra gain of the
J-pole will help on voice too.

Do be aware that train power may not be 110 VAC 60 Hertz. So battery
elimination or charging may become a problem if you don't have the
proper adapters. Check this out ahead of time with your travel agent
or call the train company's maintence yard and talk to their electrician.

Have fun!

Gary KE4ZV

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

Date: 19 Mar 91 03:45:33 GMT
From: ARDSLEY.BUSINESS.UWO.CA![e-mail]
Subject: SMTP Mail on PBBS?
To: [e-mail]

I have been using KA9Q nos for quite a while now.  I am interested in trying
something else for awhile.  Unforunately, I don't find NOS stable enough, or
quick enough for AX25 use.  I would like to have a bbs program that supports
SMTP mail plus the messages come in as one file per user.  Does anyone know of
such a program?  There is MSYS here, but it stores each message separately.

Any ideas?


=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Mark Bramwell, VE3PZR                Located in sunny London, Ontario

Internet: [e-mail]  IP Address: 129.100.29.33
  Packet:  VE3PZR @ VE3GYQ               UWO Phone: [phone]

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

Date: 21 Mar 91 17:13:28 GMT
From: agate!eos!aio![e-mail]
Subject: STS-37 SAREX Information Summary
To: [e-mail]

STS-37 SAREX
Shuttle Amateur Radio EXperiment
Information Summary


Table of Contents
-----------------
o Introduction
o Keplerian Element Set
o SAREX Uplink/Downlink Frequencies
o SAREX Packet Operating Hints
o Mission Audio Retransmissions
o W5RRR Special Event Station
o W1AW Voice Bulletins
o AMSAT Net Operations
o JSC INFO BBS
o NASA Select Video Broadcast
o STS-37 SAREX Timeline

Revised: 910321 N5QWC
============================================================

SAREX Introduction

STS-37 Crew:
  N5RAW, Steve Nagel, Mission Commander
 KB5AWP, Ken Cameron, Pilot
  N5QWL, Jay Apt, Mission Specialist
  N5RAX, Linda Godwin, Mission Specialist
  N5SCW, Jerry Ross, Mission Specialist

SAREX equipment on this flight includes a 2m (144-146 Mhz) Motorola radio
(output 2.3 watts), Robot 1200C slow scan convertor, Heath HK-21 packet TNC,
a 70cm FSTV receiver, a video camera, and a Monitor/VCR.  Planned operations
include voice contacts, packet robot, downlinking orbiter video via SSTV,
uplinking FSTV video to the orbiter.

During sleep periods and when no other SAREX activities are scheduled the
equipment will be left on in packet robot mode.  If time permits the crew
will setup SAREX to transmit SSTV using orbiter video cameras during the GRO
satellite release and during the EVA.  The GRO satellite release is
scheduled for MET 2/03:00 (2 days 3 hours after launch) for 1 hour.  The EVA
is scheduled for MET 2/22:00 thru MET 3/05:00.  With 5 hams on the flight
there may be many unscheduled opportunities for operation, I suggest you
monitor both downlink frequencies on all passes starting with orbit 1 until
landing, even during sleep periods you could hear something other than
packet.  Contacts between the shuttle and school children will be
retransmitted by W5RRR, see timeline for times, and W5RRR frequency
information below.

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

Keplerian Element Set

STS-37
1 00037U          91 94.64868056  .00023000           17236-3 0    49
2 00037  28.4683 237.6443 0006982 279.6613  80.3332 15.37985111    23

Satellite: STS-37
Epoch time:      91094.64868056
Element set:     JSC-004
Inclination:       28.4683 deg          Space Shuttle Flight STS-37
RA of node:       237.6443 deg              Keplerian Elements
Eccentricity:     .0006982            from pre-launch post OMS-2 vector
Arg of perigee:   279.6613 deg          Launch:  04 APR 91  14:20 UTC
Mean anomaly:      80.3332 deg
Mean motion:   15.37985111 rev/day                 W5RRR
Decay rate:       2.30E-04 rev/day^2      NASA Johnson Space Center
Epoch rev:               2

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

SAREX Uplink/Downlink Frequencies

Downlink/Uplink Frequencies for Voice/Packet/SSTV to be used on Upcoming
Mission

Get out your HTUs and HT programming manuals.  You will want to program your
2 meter FM transceivers with the following information.  Note that only
stations with prior arrangements can uplink FSTV signals (special
authorization is required from the FCC).  It is expected that uplinking FSTV
will require about 15kw ERP.  FSTV ops and 2m can occur simultaneously.

Mode           Downlink Freq Uplink Freq
-------------- ------------- -----------
Voice/SSTV     145.55        144.95 (primary), 144.91, 144.97
Packet         145.51        144.91 (primary), 144.93, 144.99
FSTV           none          70cm band

Please note that the frequencies they will be listening for stations ARE
DIFFERENT than the one they will transmit on.  This is a very important fact
to understand.  They will transmit to earth (downlink) on a single frequency
145.55 MHz for voice and SSTV.  They will listen for stations transmitting
to the shuttle (uplink) on the other frequencies listed.  This "split"
operation is used quite successfully by DXers when operating in an
environment where large pile ups are expected.

There will be no simplex operation with SAREX on either voice or packet.
Although packeteers are not accustomed to operation with a TX/RX offset, in
this case, it is the only way to connect to SAREX.  If you transmit on
145.55 or 145.51 MHz the only people who will hear you are those other Hams
in your area trying to hear the shuttle.

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

SAREX Packet Operating Hints

FULLDUP OFF
DWAIT   0.1 - 0.5 seconds
FRACK   > 3.0 seconds
C KB5AWP

The packet call sign on board the shuttle is KB5AWP (SSID=0).  Your TNC
should be in half-duplex mode (FULLDUP OFF) with CD active just like you do
for normal VHF packet operations.  If you can compensate for doppler shift
it is worth the extra effort.  The bandwidth of the SAREX radio is +/-4Khz,
maximum doppler is around 3.3Khz.  If you canUt compensate for doppler your
best chance for contact is when the shuttle is at peak elevation at your
site.

You should be careful with the setting of two of your TNC's timers: DWAIT
and FRACK.  DWAIT is the time interval after your Carrier Detect light goes
out and before your transmitter turns on.  You want to make sure your
connects requests and ACKs are contained in the 3 second FUDtimer window.
If everybody runs the same DWAIT (like the typical 0.1 - 0.5 second values
used for terrestrial packet), then everybody will be transmitting at the
same time.  Part of the key to your success when uplink QRM is heavy is to
pick a DWAIT that nobody else is using!  (sort of like picking a lottery
number!)

FRACK sets the time interval between your transmissions.  After you send a
frame, your TNC waits for the FRACK time, and then waits for the Carrier
Detect signal to drop, then waits DWAIT, and then tries again.  You should
make sure your FRACK is at least 3 seconds so that you are not transmitting
when the robot's FUDtimer decides it is time for it to transmit -- if you
are transmitting at the same time, you will miss any packets the shuttle is
addressing to you and you won't have a successful QSO.

Note that your DWAIT (how soon do I transmit?) and FRACK (then how long do I
wait?) parameters and the need to stop transmitting so you can hear a reply
are just like you encounter when working a DXpedition pileup on HF.  If the
DX station has a pattern of listening for a few seconds (=FUDtimer) before
transmitting, you may have better luck being the LAST station they hear,
after the din dies down.  The differences are that (1) the robot is a
computer and is very predictable and (2) the robot can be working several
stations at one time.

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

Mission Audio Retransmissions

The following stations will retransmit the mission audio from the shuttle
and ground controllers.

WA3NAN - Goddard Space Flight Center (GSFC), Greenbelt, Maryland.
W5RRR  - Johnson Space Center (JSC), Houston, Texas
W6VIO  - Jet Propulsion Laboratory (JPL), Pasadena, California.
W6FXN  - Los Angeles
K6MF   - San Francisco
W4MWG  - Mebane, NC

Station    VHF     10m     15m     20m    40m    80m
------   ------  ------  ------  ------  -----  -----
WA3NAN   147.45  28.650  21.395  14.295  7.185  3.860
W5RRR    146.64
W6VIO    224.04          21.340  14.270
W6FXN    145.46
K6MF     145.58                          7.165  3.840
NASA/JSC 171.15
W4MWG                            14.230 (SSTV)

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

W5RRR Special Event Station

W5RRR - Johnson Space Center (JSC) ARC, Houston, TX.  Special event station
with bulletins, updated element sets, and current flight information will be
making contacts and answering questions using SSB on the HF bands.  The
frequencies are listed below.  The special event station will start after
launch and run up thru landing.  W5RRR will also retransmit the audio from
the contacts between STS-37 and schools.  Three of the 5 bands will be in
use at any given time, band selection will be determined by propagation
(usually 10/15/20m daytime, 20/40/80m night).

Station  10m     15m     20m    40m    80m
-----  ------  ------  ------  -----  -----
W5RRR  28.400  21.350  14.280  7.227  3.850   (+/- QRM)

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

W1AW Voice Bulletins

W1AW will be broadcasting daily bulletins with updated information on SAREX
during the flight.  Voice bulletins are transmitted daily at 0230 UTC and
0530 UTC on the following frequencies:

Station  10m     15m     17m     20m    40m    80m
-----  ------  ------  ------  ------  -----  -----
W1AW   28.590  21.390  18.160  14.290  7.290  3.990

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

AMSAT Net Operations

Information will also be available from the AMSAT net, tune in for
bulletins.  The net operates every week on:

    Sunday  1800-2100 UCT (international)  14.282 Mhz USB
    Tuesday 0130-0300 UCT (USA)             3.840 Mhz LSB

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

JSC INFO BBS

The Public Affairs Office at the Johnson Space Center operates a BBS to
provide information to the public.  Check this board for updates to the
keplerian element sets during the flight.

To access the BBS, call [phone] using 1200 baud, 8-N-1, at the ENTER
NUMBER: prompt, enter "62511" and you will be connected to the BBS.  Check
file area 30 or 99 for latest element sets.

NASA JSC's Electronic Space Information BBS is intended to provide 24-hour
access to biographies of NASA officials and astronauts, news releases, space
flight mission presskits and television schedules, space shuttle systems
information, flight manifests and schedules, and other information about the
space program.

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

NASA Select Video Broadcast

The continental United States will receive NASA Select television, 24 hours
a day throughout the mission, via:

SATCOM F2R
Transponder 13
72 degrees West Longitude
3960 MHz (Video)
6.8 MHZ (Audio)

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

STS-37 SAREX Timeline (unofficial summary)

           MET                                                (ST/DST)**
UTC          D  H  M Rev     Event                            PT     CT     ET
-----------  ------- --- ----------------------------------- ---- -------- ----
4/4/91 1420  0 00 00   1 LAUNCH                              0620 4/4 0820 0920
4/4/91 2115  0 06 55   5 Start SAREX Setup                   1315 4/4 1515 1615
4/4/91 2120  0 07 00   5 Begin Pre-Sleep Activity            1320 4/4 1520 1620
4/4/91 2140  0 07 20   5 Finish SAREX Setup                  1340 4/4 1540 1640
4/5/91 0020  0 10 00   7 Begin Sleep Period                  1620 4/4 1820 1920
4/5/91 0820  0 18 00  12 Begin Post-Sleep Activity           0020 4/5 0220 0320
4/5/91 1120  0 21 00  14 End Post-Sleep Activity             0320 4/5 0520 0620
4/5/91 1210  0 21 50  15 Cabin depress to 10.2 PSI           0410 4/5 0610 0710
4/5/91 1332  0 23 12  16 AOS FSTV w/N9AB, US Bridge          0532 4/5 0732 0832
4/5/91 1350  0 23 30  16 LOS FSTV w/N9AB, US Bridge          0550 4/5 0750 0850
4/5/91 1511  1 00 51  17 AOS School #1 via US Bridge         0711 4/5 0911 1011
4/5/91 1529  1 01 09  17 LOS School #1 via US Bridge         0729 4/5 0929 1029
4/5/91 1649  1 02 29  18 AOS School #2 via US Bridge         0849 4/5 1049 1149
4/5/91 1707  1 02 47  18 LOS School #2 via US Bridge         0907 4/5 1107 1207
4/5/91 1829  1 04 09  19 AOS School #3 via US Bridge         1029 4/5 1229 1329
4/5/91 1845  1 04 25  19 LOS School #3 via US Bridge         1045 4/5 1245 1345
4/5/91 2020  1 06 00  20 Begin Pre-Sleep Activity            1220 4/5 1420 1520
4/5/91 2020  1 06 00  20 AOS School #4 via SA Bridge         1220 4/5 1420 1520
4/5/91 2041  1 06 21  20 LOS School #4 via SA Bridge         1241 4/5 1441 1541
4/5/91 2320  1 09 00  22 Begin Sleep Period                  1520 4/5 1720 1820
4/6/91 0720  1 17 00  27 Begin Post-Sleep Activity           2320 4/6 0120 0220
4/6/91 1020  1 20 00  29 End Post-Sleep Activity             0220 4/6 0420 0520
4/6/91 1120  1 21 00  30 GRO Grapple                         0320 4/6 0520 0620
4/6/91 1130  1 21 10  30 GRO Unberth                         0330 4/6 0530 0630
4/6/91 1230  1 22 10  30 GRO Solar Array Deploy              0430 4/6 0630 0730
4/6/91 1350  1 23 30  31 GRO High Gain Antenna Deploy        0550 4/6 0750 0850
4/6/91 1431  2 00 11  32 AOS FSTV w/W5RRR, KE4PT w/US Bridge 0631 4/6 0831 0931
4/6/91 1451  2 00 31  32 LOS FSTV w/W5RRR, KE4PT w/US Bridge 0651 4/6 0851 0951
4/6/91 1730  2 03 10  34 GRO Release                         0930 4/6 1130 1230
4/6/91 2020  2 06 00  35 Begin Pre-Sleep Activity            1220 4/6 1420 1520
4/6/91 2320  2 09 00  37 Begin Sleep Period                  1520 4/6 1720 1820
4/7/91 0720  2 17 00  42 Begin Post-Sleep Activity           2320 4/7 0020 0120
4/7/91 1020  2 20 00  44 End Post-Sleep Activity             0120 4/7 0320 0420
4/7/91 1020  2 20 00  44 Begin EVA Prep                      0120 4/7 0320 0420
4/7/91 1210  2 21 50  46 Unscheduled SSTV/Packet             0310 4/7 0510 0610
4/7/91 1235  2 22 15  46 Airlock Depress/Egress              0335 4/7 0535 0635
4/7/91 1340  2 23 20  47 Unscheduled SSTV/Packet             0440 4/7 0640 0740
4/7/91 1510  3 00 50  48 Unscheduled SSTV/Packet             0610 4/7 0810 0910
4/7/91 1640  3 02 20  49 Unscheduled SSTV/Packet             0740 4/7 0940 1040
4/7/91 1850  3 04 30  50 Airlock Ingress/Repress             0950 4/7 1150 1250
4/7/91 1935  3 05 15  50 Begin Pre-Sleep Activity            1035 4/7 1235 1335
4/7/91 2235  3 08 15  52 Begin Sleep Period                  1335 4/7 1535 1635
4/8/91 0535  3 15 15  57 Begin Post-Sleep Activity           2035 4/7 2235 2335
4/8/91 0835  3 18 15  59 End Post-Sleep Activity             2335 4/8 0135 0235
4/8/91 0835  3 18 15  59 Cabin repress to 14.7 PSI           2335 4/8 0135 0235
4/8/91 1314  3 22 54  62 AOS School #5 US Bridge             0414 4/8 0614 0714
4/8/91 1333  3 23 13  62 LOS School #5 US Bridge             0433 4/8 0633 0733
4/8/91 1452  4 00 32  63 AOS Backup FSTV or w/W5RRR US Bridg 0552 4/8 0752 0852
4/8/91 1512  4 00 52  63 LOS Backup FSTV or w/W5RRR US Bridg 0612 4/8 0812 0912
4/8/91 1925  4 05 05  66 Begin Pre-Sleep Activity            1025 4/8 1225 1325
4/8/91 1930  4 05 10  66 Start SAREX Stow                    1030 4/8 1230 1330
4/8/91 2000  4 05 40  66 Finish SAREX Stow                   1100 4/8 1300 1400
4/8/91 2225  4 08 05  68 Begin Sleep Period                  1325 4/8 1525 1625
4/9/91 0625  4 16 05  73 Begin Post-Sleep Activity           2125 4/8 2325 0025
4/9/91 0925  4 19 05  75 End Post-Sleep Activity             0025 4/9 0225 0325
4/9/91 1325  4 23 05  77 Deorbit Burn                        0425 4/9 0625 0725
4/9/91 1430  5 00 10  78 EDW Landing                         0530 4/9 0730 0830

** PT (Pacific Time), CT (Central Time) and ET (Eastern Time) starts as stan-
dard time then changes to daylight savings time on April 7, 0200 local time.

============================================================
###
--
Gary Morris                    Internet: [e-mail]
Lockheed, Houston, Texas       UUCP:     lobster!avocado!gamorris
N5QWC/W5RRR                    Phone:    [phone]

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

Date: 23 Mar 91 01:21:04 GMT
From: epic![e-mail]
Subject: TAPR meeting notes
To: [e-mail]

In article <[e-mail]>, [e-mail] (Paul Williamson) writes:
|>
|> A detailed blow-by-blow account of the 1991 TAPR Annual Meeting in Tucson
|> is available for FTP on tomcat.gsfc.nasa.gov in /public/tapr/blowby.txt
|> and on thumper.bellcore.com in /pub/ka9q/incoming/blowby.txt (until Phil
|> moves it to a permanent location).

I've moved it to /pub/ka9q/misc/blowby.txt.

Phil

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

Date: 18 Mar 91 00:48:18 GMT
From: usc!elroy.jpl.nasa.gov!sdd.hp.com!zaphod.mps.ohio-state.edu!rpi!uupsi!phage!helix.cshl.org![e-mail]
Subject: TCP/IP
To: [e-mail]

Can someone offer me a hand? I am new to both the Internet, and to packet
so please bear with me. I have a PK232 and am ineterested in using the
KA9Q TCP/IP package with it. Does anyone have a basic document that they
could mail me on the proper techniques of its use? How does one obtain
their address? etc. Any help would be greatly appreciated..

    Thanks, Peter N2IFC

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

Date: 18 Mar 91 23:05:35 GMT
From: sdd.hp.com!usc!rpi!uupsi!phage!helix.cshl.org![e-mail]
Subject: Thanks
To: [e-mail]

Thanks to all the people who responded to my posting yesterday. I
think I have all the info I need, or atleast were I can find it.

Thanks again, Peter N2IFC

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

Date: 19 Mar 91 02:57:23 GMT
From: uvaarpa!haven!boingo.med.jhu.edu!aplcen!wb3ffv![e-mail]
Subject: The Amateur Radio BBS - How to access
To: [e-mail]

+------------------------------------------------------------------------------+
    HOW TO ACCESS THE WB3FFV AMATEUR RADIO TELEPHONE BBS !!!


 I have placed a BBS system on-line that is mainly oriented towards the
Amateur Community (but there is other stuff on-line). As of now I have not
attempted to promote this system any place except in the amateur channels
(PACKET, USENET, & word of mouth), and will continue under this policy, as
I hope to keep it oriented toward amateur radio. The various software for
UP/DOWNload is available via telephone dialup and Packet TCP/IP, and through
user support I hope to keep the latest and greatest ham software on-line.
Below is the information that is needed in order to access the BBS via
Telephone -or- TCP/IP, please pass it around to as many ham's as possible.

 System Name: WB3FFV
 User Login: bbs
 Number: (301)-625-0817 -- 1200 & 2400 (Non-MNP)
 Number: (301)-625-9482 -- 1200,2400,4800,9600,19200,38400 V.32 (V.42bis/MNP5)
 Number: (301)-625-9663 -- 1200 & 2400 (MNP5), 9600 & 19200 (PEP)
 Data Settings: 8 Bits, NO Parity, 1 Stop Bit
 Times: 24hrs/365days  (except for routine maintenance)
 Software: XBBS  (UNIX/Xenix Multiuser BBS)
 IP Address: 44.60.128.1 {wb3ffv.ampr.org} [for FTP access on 145.650 mhz ONLY]
 Misc. Info: Machine is an 80486 computer running UNIX V.3.2 and features 800
         Meg of on-line storage. Most transfer protocols are available!!


 I attempt to keep the latest and greatest HAM software on-line, and encourage
all to upload anything new that they come up with, as it is of benefit to all.
Here is a sample of a couple pieces of software that is available for DOWNLOAD:

 KA9Q TCP/IP Software for the PC (Latest OFFICIAL release + TEST Versions)
 KA9Q TCP/IP for the Atari-ST, MAC, & Amiga
 KA9Q TCP/IP for UNIX based systems
 KA9Q TCP/IP (The NOS release)  [UNIX, MS/DOS, Amiga]
 KA9Q TCP/IP (Version by G1EMM, PE1CHL, PA0GRI, Etc.)
 N2GTE Packet Mail Switch [GTEPMS] (Version 1.2)
 WA7MBL BBS for the PC (Versions 3.31, 4.31 & 5.1[2,3,4])
 W0RLI BBS for the PC (Versions 6.xx, 7.xx, 8.xx, 9.xx, 10.xx, 11.xx)
 MSYS BBS for the PC running KISS TNC's  (Version 1.07-1.10)
 AA4RE BBS for the PC (Version 2.10)
 Various BBS utilities and enhancements
 Several MORSE CODE Tutors
 TheNet software by NORD><LINK  (Version 1.01 & 2.06)
 Modifications for many HAM Rigs and Scanners
 Digital Signal Processing software (DSP)
 DX and contesting programs
 ARRL Newsletters & Gateway
 W5YI Electronic Edition

 There is much more available on the BBS, and I don't want to waste a lot of
PACKET BBS space trying to list it all, so if you are interested give it a
call and see for yourself !!!

If you are interested in using UUCP to connect to the BBS, this can also be
done as I support Anon-uucp. The login to the system is 'uucpanon', and there
is NO password. The listing of avalible archives are stored in a file called
'FILES', and it is located in the /usr/spool/uucppublic. To retrieve the files
listing just use the following command:

uucp wb3ffv!~/FILES /usr/spool/uucppublic

This will move a copy of my files listing into your uucppublic directory.  If
you have any questions or problems, feel free to contact me at one of the
numbers/adresses below. Good Luck...

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

Date: 19 Mar 91 02:53:46 GMT
From: uvaarpa!haven!boingo.med.jhu.edu!aplcen!wb3ffv![e-mail]
Subject: The N2GTE Packet Mail Switch
To: [e-mail]

    Hello All,

As I promised about two weeks ago, here is a little more detail on the N2GTE
Packet Mail Switch.  I would have written back sooner, but getting the flu
caused my bed to take priority over Email :-(

Many of you on here have talked about the problems with the TCP/IP section of
the MSYS package, but here is a BBS (if you want to run a BBS) that won't have
the problems listed since it actually uses NET (from Phil - KA9Q) so everything
should work.

The BBS is a multi-user/multi-tasking system that runs inside of DesqView 2.3x
and uses DesqView like I have seen no other packaged do.  To achive very good
efficiency it uses multiple windows to acomplish it's tasks, and will open and
close user and forwarding windows as needed.

Also one unique feature of the BBS is it's ability to learn new routes to other
BBS systems.  GTEPMS if not sure how to resolve a message, will send a request
to other GTEPMS systems in the area and ask them if they know how to resolve
the mail, and if so it will learn the path and add it to it's own tables.

I won't go into a big thing here on just what all the BBS will do, but will
leave info below on how you can download the doc's if you desire.

Where I really like this BBS program is in it's ability to exchange mail
between the BBS and NET.  I a message arrives on the BBS and it is destined
for an IP address (.AMPR, .AMPR.ORG, or whatever you specify), or the user
is listed in the forward file.  The BBS will place the message in the
SPOOL\MQUEUE directory and setup the job for SMTP transfer.   Also if a job
arrives via SMTP and the next host can't be found in the HOSTS table ( this
assumes you have it set to place the unresolved jobs in RQUEUE), and the
job gets placed in SPOOL\RQUEUE.  The GTEPMS system will scan the RQUEUE
directory and attempt to resolve the message.  So if the unresolved message
was for say W3XYZ @ WB3FFV.MD.USA.NA, it will accept that message and place
it in the BBS for forwarding in the BBS network.

As you can see this provides a complete gateway between the BBS and TCP/IP
worlds, and avoids many of the problem IP implementations in other BBS
systems by actaully using NET.  I personally wanted to receive the local
BBS bulletins (and used the IP mbox, but it had many problems), but wasn't
willing to stop running NET/NOS to do this.  This BBS package (GTEPMS) has
allowed me to do both, and since becoming a beta tester for Doug's code I
have very much enjoyed the package.

One thing that should NOT be overlooked, this is a BIG system and requires
the mimimum configuration listed below:

80286 based system      (The faster the better)   {386 if at all possible}
Desqview 2.3x           (QEMM-386 5.x if using a 386)
2Meg of DRAM            (4Meg if also using NET)
G8BPQ PC-Node Software  (Version 3.57 to 3.59)
GTEPMS Version 1.2      (of course :-)

I personally use an 80386sx-20 with 4MB of RAM to run the system, but with
this configuration I can also use TC++ at the same time!

OK, so you want to know where you can get the software.  The code can be
downloaded from my telephone BBS, and I will once again post in a seperate
message the information on how to reach my BBS.  I will also try and post
the files on thumper and tomcat over the next couple days when I have time
to upload them, but for now it is only on the BBS.

Hopefully this will answer the questions some of you have on the BBS, and if
you decided to try it I would really like to hear what you think of it as well..


-------------------------------------------------------------------------------
Internet  : [e-mail]     |       Howard D. Leadmon
UUCP      : wb3ffv!howardl              |       Advanced Business Solutions
TELEX     : 152252474                   |       210 E. Lombard St - Suite 410
FAX       : [phone]              |       Baltimore, MD 21202
PACKET    : WB3FFV @ WB3FFV.MD.USA.NA   |       Phone: [phone]

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

Date: 20 Mar 91 23:59:37 GMT
From: [e-mail]
Subject: TNC Emulators on PC's
To: [e-mail]

Some time ago, a European software package was announced that could
emulate a TNC on an IBM PC or PC Clone.  Besides that package, are
there any other IBM clones TNC emulators around?

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

Date: 21 Mar 91 00:28:45 GMT
From: theory.tn.cornell.edu![e-mail]
Subject: TNC Emulators on PC's
To: [e-mail]

In article <[e-mail]> [e-mail] (Robert Giden N7KCG) writes:
>Some time ago, a European software package was announced that could
>emulate a TNC on an IBM PC or PC Clone.  Besides that package, are
>there any other IBM clones TNC emulators around?

    Yes, there is.  I've written a program called PMP (Poor Man's Packet)
that is in use here in the Ithaca, NY area.  The gory details of the serial
protocol are not as cleanly implemented as Baycom (my program hangs the
machine during RX and TX) and I don't have as many features as Baycom.
But overall, I think my program is much more cleanly implemented (overall
structure, user interface, configuration).

    Originally, I was going to make the program shareware.  Now, with
the usual lack of time, I'm giving it away as "guiltware"--send me what
you think it is worth.  I offer no guarantees;  I may never get around to
fixing bugs.  But I will give you some help:  full source code (Turbo C).

    If there is any interest, I will make it available via anonymous
FTP.
--
=  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =
Andrew C. Payne, N8KEI        UUCP:  ...!cornell!batcomputer!payne
              INTERNET:  [e-mail]

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

Date: 21 Mar 91 21:55:06 GMT
From: usc!wuarchive!waikato.ac.nz!comp.vuw.ac.nz!cc-server4.massey.ac.nz![e-mail]
Subject: TNC Emulators on PC's
To: [e-mail]

>>> Re PMP - A user's comments

An excellent program.  I've been using it for about a year and it
works well.  Several other users down in this part of the world have
been using it quite successfully too ...

One disadvantage (which apparently is shared by BAYCOM) is that you
cannot upload/download binary files (no YAPP/XMODEM ...) support.

I've been using the second parallel port, but as the port address, the
active bit and which level is active are defined in the config file
(PMP.CFG) you should be able to use either serial or parallel port to
talk to the modem.

The modem side is simply a 7910 based modem for 1200 baud.

These comments apply to PMP version 0.93.  Andy may have released a
later version.

Cheers
Giovanni  ZL2BOI



--
------------------------------------------------------------------------------
Giovanni Moretti, Consultant       | [e-mail], Pkt-ZL2BOI@ZL2BFJ
Computer Centre,  Massey University| Ph 64 63 69099 x8398, FAX [phone]
Palmerston North, New Zealand      | QUITTERS NEVER WIN, WINNERS NEVER QUIT
------------------------------------------------------------------------------

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

Date: 20 Mar 91 15:26:23 GMT
From: usc!apple!well![e-mail]
Subject: WANTED: Docs for NETPC (DL3DBT v891105)
To: [e-mail]

I am running the net.exe called netpc developed in Germany by
DL3DBT and group.  I have it running fine on two ports with
tcp/ip and net/rom.

I need the documentation for this (in English, I hope).  Many features
like NOS are handled with this program and it has color and windowing
support.

If anyone knows where I can ftp the docs please contact me.  Thanks!

-- Ken


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

Date: 21 Mar 91 17:57:32 GMT
From: agate!apple!veritas!amdcad!sono![e-mail]
Subject: Where can I download Baycom?
To: [e-mail]

I am looking for a copy of Baycom and noticed in a previous
posting that someone (don't remember who, unfortunately)
mentioned downloading it. Does anyone know of a site which
has Baycom and which could e-mail a uuencode'd copy (I do
not have ftp access)?

Thanks in advance,

Michael Stratford Collins
[e-mail]
sun!sono!collins

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

Date: (null)
From: (null)
> And while I'm pontificating (:-) the left most callsign (in the above
> examples
> VK6ZJM) should ONLY be considered for routing purposes if it is shown as part
> of the domain segment (eg VK6ZJM.VK6BBS.#WA.AUS). Once the '@' is reached in
> the right to left scan, routing should stop. The reason is this: the
> originator
> of the message may know that VK6ZJM has moved QTH - routing software wouldn't
> always know this.
>
I think that when someone moves the first person they tell (in the packet
world) is the SYSOP of their local BBS, otherwise that BBS is going to keep
trying to forward mail to them when they're not there. Being able to forward
on the TO field is often very useful - remote SYSOPs often like to have mail
addressed to SYSOP forwarded on to them, for example.

----
Brian Lloyd
Software Management & Control,          # By e-mail : [e-mail]
Software Technology Division,           # By Phone  : [phone]
SSTF Building, BTRL, Martlesham Heath,  # By Fax    : [phone]
Ipswich, Suffolk. UK. IP5 7RE           # By Packet : [e-mail]

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

Date: 19 Mar 91 05:01:47 GMT
From: gatech!udel!haven!ni.umd.edu!sayshell.umd.edu![e-mail]
To: [e-mail]

References <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject : Re: Hierarchical Forwarding pounds (#)

In article <[e-mail]> [e-mail] (Peter Anvin) writes:
>In proper domain-style addressing, a la the Internet, this would rather be:
>
>Do I know where VK6ZJM.WA.AUS is?     No
>Do I know where WA.AUS is?            No
>Do I know where AUS is?               Yes
>Forward in direction AUS
>

Bzzzzzt - wrong.  In domain-style "addresses", names are just names,
and DO NOT imply routes.  There are names, addresses, and routes; it
is important to keep the distinction between each of them.

Internet style names are broken into an administrative heirarchy which has
(by design and absolute intent) nothing to do with routing or addresses.

If you are going to cite Internet style domain names, please don't change
the meaning while you're at it.

Yes, some of us are really sensitive about this distinction.

louie
WA3YMH

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

Date: 19 Mar 91 10:35:36 GMT
From: ucselx!bionet!apple!mips!spool.mu.edu!munnari.oz.au!manuel!csc.canberra.edu.au!echo![e-mail]
To: [e-mail]

References <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject : Re: Hierarchical Forwarding pounds (#)

In <[e-mail]> [e-mail] (Ron Murray) writes:
>> the octothorpe, '#'.
>2. Someone in Australia mis-read the documentation and decided that this name
>   change was necessary. This is probably the more likely.

FAR FAR more likely.  :-)  Browsing thru the mail on my BBS (VK1KCM) I notice
South Australia and Western Australia both use the "#" at the state level
while everybody else only uses it below the state. (#SA, #WA and ACT, NSW etc)

It's rare, however, for there to be any identifiers below the state level.
My address here in Canberra is;
[e-mail]

Also the "Asianet" sysops, mainly Brian Beamish Vk4BBS decided that we wouldn't
use .au as our domain.  Instead we have to use .oc (for Oceania).  Needless to
say none of these people are on the internet. :-(


Carl.

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

Date: 15 Mar 91 03:12:15 GMT
From: swrinde!elroy.jpl.nasa.gov!sdd.hp.com!uakari.primate.wisc.edu!umriscc!maverick.ksu.ksu.edu!matt.ksu.ksu.edu![e-mail]
To: [e-mail]

References <[e-mail]>, <[e-mail]>, <[e-mail]>ck.ks
Subject : Re: Digital repeater network


>Has anyone looked into the feasibility of creating a digital repeater network?
>It seems to me that this would allow most any ham to talk to most any other,
>anywhere, using a simple handheld radio. This seems like a logical extension
>of the current plans to create an analog system using dynamic links to a
>long distance backbone.  The problem with this scheme is:  what happens
>if a link in the backbone fails; and if more than one user wants to use the
>system at the same time?  It would be a very resource intensive system,
>anyway.

I have thought of this idea.  With current A/D and DSP technology, it
would be easy to build a fully Digital Audio Repeater (DAR).  Just convert
the received audio with an A-to-D, add filtering/CW tones/ect
with a DSP and spit out the result using a D-to-A.  If
output to a network is wanted, just send the digital streams
to a RF modem as well as the transmitter.  Also, voice mail could
easily be implemented with the addition of secondary storage. (it could
even be transferred as normal mail over conventional packet channels.)

>In short:  why couldn't the Amateur community set up the equivalent of a
>digital cellular network with modest user requirements, linked exclusively
>by radio and therefore immune to damage to the hard-wired systems such as
>the telephone network.

A similar 'what if' was presented at the _9th Computer Networking Conference_
by Jon Bloom, KE3Z.  The technology is getting there, but it will take
even more time before the idea catches on.  We have a large base of
old technology voice repeaters that will not go away.  :-)

-Steve Schallehn, KB0AGD
 Kansas State University

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

Date: (null)
From: (null)
--Kauto, OH5LFM

--
****************** Kauto Huopio ([e-mail]) **********************
*  Mail: Kauto Huopio, Punkkerikatu 1 A 10, SF-53850 Lappeenranta,Finland   *
*****************************************************************************

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

Date: 20 Mar 91 02:49:36 GMT
From: swrinde!elroy.jpl.nasa.gov!sdd.hp.com!zaphod.mps.ohio-state.edu!casbah.acns.nwu.edu![e-mail]
To: [e-mail]

References <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject : Re: Hierarchical Forwarding pounds (#)

In article <[e-mail]> [e-mail] (Louis A. Mamakos) writes:
>Bzzzzzt - wrong.  In domain-style "addresses", names are just names,
>and DO NOT imply routes.  There are names, addresses, and routes; it
>is important to keep the distinction between each of them.
>
>Internet style names are broken into an administrative heirarchy which has
>(by design and absolute intent) nothing to do with routing or addresses.
>
>If you are going to cite Internet style domain names, please don't change
>the meaning while you're at it.

I stand corrected -- to a degree.  What I should have said, I guess, would
be something like ``this is the intent of hierarchial **addressing**''.

As you correctly point out, Internet host names are hierarchial but do not
necessarily imply addressing.  They do if and only if they point to a
non-IP subdomain for mail traffic, such as fidonet.org, where routing is
provided through UUCP to different gateways depending on a specified
subdomain.

In the store-and-forward landline network Fidonet, addresses are
hierarchial but numerical on the form

    NNN:NNN/NNN.NNN      (the punctuation allows for abbreviation only)

The Fidonet address is left-major, opposite the direction of the Internet
and Amateur Packet hierarchial names, but partially similar to the IP
numbering system (NNN.NNN.NNN.NNN).

If a system is to send mail to, say, 2:206/203.1 it uses an algorithm like
this:

    [THIS IS VERY SIMPLIFIED AS ANYONE FAMILIAR WITH FIDONET WOULD SEE
     IMMEDIATELY]

    Do I have a route to 2:206/203.1?     No
    Do I have a route to 2:206/203.0?     No
    Do I have a route to 2:206/0.0?       No
    Do I have a route to zone 2?          YES - 1:115/500.0 -> forward

The amateur AX.25 network is different from Fidonet, Internet and UUCP in
topology, nature of the nodes, the information each node has, and
addressing format.  Thus what applies to one does not necessarily aplpy to
the other.  That doesn't prevent us from learning from each other and find
a good combination of techniques needed for each individual network.

            /Peter

--
hpa = H. Peter Anvin (in case you wondered) * Heja Sverige!
INTERNET:   [e-mail]   FIDONET:  1:115/989.4
HAM RADIO:  N9ITP, SM4TKN             RBBSNET:  8:970/101.4

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

Date: (null)
From: (null)
The idea of scanning from left to right is to find the most direct route to
the destination. If I was to forward a message to you, the BBS would perform
the following steps :

Do I know where VK6ZJM is?
No - do I know where VK6BBS is?
No - do I know where #WA is?
No - do I know where AUS is?
Yes - forward the message in that direction.

If, on the other hand, I had a direct link to VK6BBS I would forward the
message there, rather than to Australia, as VK6BBS is much closer to you
Australia in general.

The main reason for having the # before the second field is to eliminate any
problem which may arise from having a local hierarchical address which is
the same as a country or continent designator. If, for example, you had a
local address of NA (for Northern Australia, say), then the BBS would try to
send the message to North America, as that is what NA is supposed to be.

I hope this helps a bit.

Brian
([e-mail])

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

End of Packet-Radio Digest
******************************
Date: Sun, 24 Mar 91 04:30:05 PST
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Reply-To: [e-mail]
Subject: Packet-Radio Digest V91 #70
To: packet-radio


Packet-Radio Digest         Sun, 24 Mar 91       Volume 91 : Issue  70

Today's Topics:
               AmigaNOS V2.5 bug report
                   inquiry
            KA9Q v910308 problems
                  Radio Mods

Send Replies or notes for publication to: <[e-mail]>
Send subscription requests to: <[e-mail]>
Problems you can't solve otherwise to [e-mail].

Archives of past issues of the Packet-Radio Digest are available
(by FTP only) from UCSD.Edu in directory "mailarchives/packet-radio".

We trust that readers are intelligent enough to realize that all text
herein consists of personal comments and does not represent the official
policies or positions of any party.  Your mileage may vary.  So there.
----------------------------------------------------------------------

Date: 23 Mar 91 18:21:54 GMT
From: usc!apple!portal!cup.portal.com![e-mail]
Subject: AmigaNOS V2.5 bug report
To: [e-mail]

Found a bug in AmigaNOS 2.5 this morning.  When doing an FTP get command, if
the response coming back is a 500 permission denied, a trapped guru occurs.

John, KF0OU

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

Date: 23 Mar 91 13:12:47 GMT
From: [e-mail]
Subject: inquiry
To: [e-mail]

Dear list reader,

RW3DR Vassily and UA3-170-679 Kirill from Moscow, Russia, Soviet Union
are interested in any information concerning 9600 and 56000 bps packet
radio hard- and softwares. We will appreciate any comments, point to
the sources of information, hints, tips etc.

Please reply to the list or to the adresss below

73 fm Moscow !!


Kirill Tchashchin/Newsbytes News Network * Moscow bureau

GEnie: NB.MOW
UUCP: ...!fuug!casino!490!20!Kirill.Tchashchin
INTERNET: [e-mail]
or Fido: Kirill Tchashchin at 2:490/20
(do NOT misspell the name!!)
fax: [phone] (1530 to 2330 EST)
--
Kirill Tchashchin - via FidoNet node 2:220/801
UUCP: ...!fuug!casino!490!20!Kirill.Tchashchin
INTERNET: [e-mail]

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

Date: 23 Mar 91 13:03:36 GMT
From: math.fu-berlin.de!opal!unido!infoac![e-mail]
Subject: KA9Q v910308 problems
To: [e-mail]

This version like to hang on several oportunities, f.i.:

If you "record" an ax25 session and disconnect before you "record off"
nothing happens, even <CTRL><ALT><DEL> does notwork.
Resolving of well known addresses takes longer than with earlier versions.
Some SMTP session tend to hang.

--

Anybody nows how to implement the RSPF module to the rest?

73
Rupert

--
*****************************************************************
   ___  ____  ___    _  _ ___ ___   ___ ___ ___     ___ _  _
  /__/ / / /   /    /\ / /__   /   /__//__//   /__//__ /\ /
 / \  /   / __/_   /  / /__   /   /  //  //__ /  //__ /  /

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

Date: 22 Mar 91 20:12:33 GMT
From: vsi1!daver!ditka!zinn!ubbs-nh![e-mail]
Subject: Radio Mods
To: [e-mail]

I am looking for a source of mods for various radio equipment.  I know
for example that they can be obtained by packet from KJ6FY's server in
California, however, that seems to be stretching it a bit.

He alludes to the existence of other "local" servers in one of his
messages, but no further info is given, and I haven't been able to find
one as yet in New England.

Additonally, it might be more "efficient" to snarf the files I want via
e-mail... so I have a two part question:

1.      Does anyone know of any packet mod servers in the Nashua, NH
    area?  Or even in New England.

2.      Does anyone know of any mail servers where I can snarf these
    files.

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

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

End of Packet-Radio Digest
******************************
Date: Mon, 25 Mar 91 04:30:05 PST
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Reply-To: [e-mail]
Subject: Packet-Radio Digest V91 #71
To: packet-radio


Packet-Radio Digest         Mon, 25 Mar 91       Volume 91 : Issue  71

Today's Topics:
            Packet Networks in NE U.S.A. ?
           Packet Radio in YU (Yugoslavia)

Send Replies or notes for publication to: <[e-mail]>
Send subscription requests to: <[e-mail]>
Problems you can't solve otherwise to [e-mail].

Archives of past issues of the Packet-Radio Digest are available
(by FTP only) from UCSD.Edu in directory "mailarchives/packet-radio".

We trust that readers are intelligent enough to realize that all text
herein consists of personal comments and does not represent the official
policies or positions of any party.  Your mileage may vary.  So there.
----------------------------------------------------------------------

Date: 22 Mar 91 21:22:00 GMT
From: [e-mail]
Subject: Packet Networks in NE U.S.A. ?
To: [e-mail]

For starters, in Western New York, there is a very good packet network
supported by the North East Digital Assoc. If you are in Rochester, you
can access the NEDA network via MONROE, MONROE-1, MONROE-2, MONROE-3....
MONROE-15 on 144.97. From this node, you can connect to remote places in New
York, PA, New Jersey, Masssachusetts, Connecticut, Vermont, New Hampshire,
and even Maine (if you have the patience).

There is also another node that you might be able to hit. It's located
in Canandaigua. On 445.6 mhz. it has a user port that you can connect to. It's
440 user port call is CANDG2. Alternatively, you can connect to its two meter
port (which has the call CANDGA) and its on either 01, 03, 05, or 07.

Please send me e-mail direct if you need more info.

73's de
Bernie NU1S/2

Internet: [e-mail]
Bitnet  : [e-mail]

Packet  : NU1S @ WB2WXQ.#WNY.NY.USA.NA

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

Date: 24 Mar 91 15:26:00 GMT
From: [e-mail]
Subject: Packet Radio in YU (Yugoslavia)
To: [e-mail]

FYI...I have been corresponding via the Internet with Iztok.  I thought some
of the other Packet Radio Digest readers might be interested in some of the
interesting packet radio developments taking place in Yugoslavia.

Scott Loftesness W3VS
Date:     Sun Mar 24, 1991  2:30 pm  GMT
Source-Date: 24 Mar 91 15:15 +0100
From:     Iztok Saje, IJS-E1, YU3FK
      EMS: INTERNET / MCI ID: 376-5414
      MBX: [e-mail]

TO:       Scott Loftesness / MCI ID: 380-1143
Subject:  Link works
Message-Id: 32910324143023/0003765414NB2EM
Source-Msg-Id: <[e-mail]>

Hello Scott !
Your answer arrived here OK, so link is usable both ways.
I've seen Mirko YT7MM yesterday - we had yearly YU3 HAMFEST.
Quite a nice meeting.

Please QSP which info is of interest to you, and how can we got
info from Compuserve HAM conference. Maybe in some digest form,
which can be put to packet network ?

Main legal questinons in YU (for HAMs, of course) are 50 MHz,
160 m and CEPT licences. HAM lobby is pushing, but government
seems to be busy with not so important topics. There is some
pirat operation on 6m, especially with terrific condx last few
weeks. But, officially YU is not yet on 50 MHz.
We want our segment on 160 m to be extended. 1820 to 1850 is just not
enough.
There are some promisses YU will join CEPT licencing this year, maybe
before tourist seazon starts. I do not like all that paper work, needed
for licencing around EU, Hi.

Abt packet:
Network in north YU is unique - Matjaz, YT3MV developed wide bandwith
23cm stations and manchester modems. This rigs are used for 38400 bd
backbone, linking most 2m and 70cm nodes. On user QRGs we use
1200 bd FSK and 2400 bd manchester modulation. Last packet project
is building of wide bandwith 70cm FM radios for 19200 bd users.

There is quite known rule in Europe: For each 10 users there is a radio
station permanently used in the network. (BBS, nodes, clusters etc).
We have quite high user density in north YU, but south YU is not so
well populated by packet users, so most of links there are on 144.675.

Neighbours: Our best cooperation is with OE and HA. There is quite
chaotic packet network in Italy, with plenty of not-so-well coordinated
nodes and BBSes. YU5 boys are working on linking SV to YU, but
such links are still sporadic.

LZ and YO HAMs are showing some interest
for packet, but it is generally too expensive for them. Just illustration
from OK: Normal HAM must work three months to get enough kronas to buy
300 DM for TNC... In USA that is comparable to price of 5 000 US $.
(100 DM is 2200 kronas.. Bottle of beer is 4.5 kronas.)
How much packet would be QRV overthere with such price ?
(BTW: YUs must work one week for TNC).

So much for today.
Maybe you already know all about HAM radio here; maybe there
is no interest for such information - please let me know, if I can be
of any help.

We are allways interested for INFO from all the world - especially
those details, not published in QST, CQ-Ham Radio, packet BBS network etc.

Like: What is going on in US packet scene ? Is W8 already linked with
PackeTens on 56 kbps ? How abt W6 0.25 Mbps project ?

Best of luck, many DX, cheerio de Iztok, YU3FK

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

End of Packet-Radio Digest
******************************
Date: Tue, 26 Mar 91 04:30:04 PST
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Reply-To: [e-mail]
Subject: Packet-Radio Digest V91 #72
To: packet-radio


Packet-Radio Digest         Tue, 26 Mar 91       Volume 91 : Issue  72

Today's Topics:
          ? how to route with tcpip (2 msgs)
              AX.25 or TCP/IP ??
               Hello From Japan
          Hierarchical Forwarding pounds (#)
               SkipNet routing.

Send Replies or notes for publication to: <[e-mail]>
Send subscription requests to: <[e-mail]>
Problems you can't solve otherwise to [e-mail].

Archives of past issues of the Packet-Radio Digest are available
(by FTP only) from UCSD.Edu in directory "mailarchives/packet-radio".

We trust that readers are intelligent enough to realize that all text
herein consists of personal comments and does not represent the official
policies or positions of any party.  Your mileage may vary.  So there.
----------------------------------------------------------------------

Date: 25 Mar 91 17:33:04 GMT
From: swrinde!zaphod.mps.ohio-state.edu!unix.cis.pitt.edu!dsinc!netnews.upenn.edu!platypus![e-mail]
Subject: ? how to route with tcpip
To: [e-mail]

In article <skcm.669696397@ise>, [e-mail] (Carl Makin) writes:
>
> We have another problem here in Australia.  IP routing isn't legal over the
> air. (Yet, we're trying)

How is this possible??  IP Frames are nothing but data stuffed inside AX25
frames.  I can't see how routing can be illegal if the data is legal in a
point-to-point situation.  Can you possibly explain why it is illegal??

bill   KB3YV

PS.  I have the same problem here (kinda).  But once we get a router set up
in a high location, I suspect these problems will go away (thanks to RSPF.)



--
     Bill Gunshannon          |        If this statement wasn't here,
     [e-mail]   |  This space would be left intentionally blank
     [e-mail]    |         #include <std.disclaimer.h>

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

Date: 25 Mar 91 23:57:40 GMT
From: usc!apple!xanadu![e-mail]
Subject: ? how to route with tcpip
To: [e-mail]

In article <[e-mail]> [e-mail] (John L Ferguson) writes:
> In a previous article [e-mail] writes:
>>... So the question is, how can I get arp to send to kg6kf via wn6i-7
>>instead of replying directly?
>
>You might try adding the following "route" entry:
>
>ax25 route add kg6kf wn6i-7

I tried this over the weekend.  It turns out that the mac software doesn't
have a route command for ax25.

But I did get a note from kg6kf, who added me to the route table for wn6i-7.
So we'll see how that works out.

Thanks for the info, everyone.

Jeff Crilly (N6ZFX)
AMIX Corporation  2345 Yale Street  Palo Alto, CA  94306
[e-mail], {uunet,sun}!markets!jeff, N6ZFX@N6IIU.#NOCAL.CA.USA

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

Date: 25 Mar 91 20:12:20 GMT
From: usc!sdd.hp.com!uakari.primate.wisc.edu!pikes!mercury.cair.du.edu!isis![e-mail]
Subject: AX.25 or TCP/IP ??
To: [e-mail]

I'm fairly new to packet and have just been up and running for about 4 months.
Running a straight MFJ AX.25 TNC with no problems and having fun with the local
BBSs and operating through nodes.

The question is:  just what is the difference between plain vanilla AX.25 and
running TCP/IP?   I know it has something to do with addressing and routing,
but just what are the real world advantages or TCP/IP in an amateur packet
system?

The only answer I've been able to get is, "...well they are difference and
sometimes cause problems if they run on the same frequency..."

Inquiring minds want to know a little more...like is it worth the trouble
to change over?

Please post responses to this newsgroup...thanks.

--
Bill Hester, Ham Radio N0LAJ, Denver CO., USA | N0LAJ @ W0LJF.CO.USA.NA
Please route replies to: [e-mail] or uunet!nyx!whester
Public Access Unix @ University of Denver, Denver Colorado USA
(no official affiliation with the above university)

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

Date: 26 Mar 91 00:10:37 GMT
From: [e-mail]
Subject: Hello From Japan
To: [e-mail]

Hello from Japan. We are alive and well here. Please advise newer Hams
that if they hear or see (packet) KA2RC that iam not in 2land. The BBS
that is used by me and some other ka2xx people is KJ6.SUBIC.PHL.OC
send mail. I know it is confusing for some but KA2RC is in Japan and
KJ6WO is in the Philippines. 73 to all de KA2RC (Roland)

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

Date: 25 Mar 91 11:20:33 GMT
From: mcsun!ukc!axion!kitkat![e-mail]
Subject: Hierarchical Forwarding pounds (#)
To: [e-mail]



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

Date: 26 Mar 91 06:06:57 GMT
From: usc!zaphod.mps.ohio-state.edu!maverick.ksu.ksu.edu!matt.ksu.ksu.edu![e-mail]
Subject: SkipNet routing.
To: [e-mail]

Another Packet BBS network question to ask:

How does routing of BBS traffic through SkipNet work?  I know that
SkipNet is a bunch of BBS's that exchange mail on HF, but routing
seems to be 'random.'  I received several messages from California (I am
in Kansas) and all the traffic seemed to take a different route when
it got onto the SkipNet.

What the reasoning behind random routing?

----
-Steve Schallehn, KB0AGD
 Kansas State University              KB0AGD @ K0VAY.#NEKS.KS.USA.NA
obg quote:  "I don't know how it works, but I am sure glad it does!"

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

End of Packet-Radio Digest
******************************
Date: Wed, 27 Mar 91 04:30:09 PST
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Reply-To: [e-mail]
Subject: Packet-Radio Digest V91 #73
To: packet-radio


Packet-Radio Digest         Wed, 27 Mar 91       Volume 91 : Issue  73

Today's Topics:
          ? how to route with tcpip (2 msgs)
            Beginners's Question (2 msgs)
             Digicom V4.01 -- available?
             IP address coordinators list
             Packet Networks in NE U.S.A.
       PMP, a software TNC for the PC available via FTP
                   Problem
              We've Moved to New Groups

Send Replies or notes for publication to: <[e-mail]>
Send subscription requests to: <[e-mail]>
Problems you can't solve otherwise to [e-mail].

Archives of past issues of the Packet-Radio Digest are available
(by FTP only) from UCSD.Edu in directory "mailarchives/packet-radio".

We trust that readers are intelligent enough to realize that all text
herein consists of personal comments and does not represent the official
policies or positions of any party.  Your mileage may vary.  So there.
----------------------------------------------------------------------

Date: 26 Mar 91 08:00:01 GMT
From: usc!apple!xanadu![e-mail]
Subject: ? how to route with tcpip
To: [e-mail]

In article <[e-mail]> [e-mail] (John L Ferguson) writes:
>In a previous article [e-mail] writes:
>>... So the question is, how can I get arp to send to kg6kf via wn6i-7
>>instead of replying directly?
>
>You might try adding the following "route" entry:
>
>ax25 route add kg6kf wn6i-7

It turns out that on the mac the ax25 command doesn't have a route add
sub-command.

However, kg6kf read my note and put me in his route table for wn6i-7
(i.e. we'll just specify the routing at both ends).

We'll see how that works.

Thanks everyone.

Jeff Crilly (N6ZFX)
AMIX Corporation  2345 Yale Street  Palo Alto, CA  94306
[e-mail], {uunet,sun}!markets!jeff, N6ZFX@N6IIU.#NOCAL.CA.USA

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

Date: 26 Mar 91 16:38:45 GMT
From: hpl-opus!hpnmdla![e-mail]
Subject: ? how to route with tcpip
To: [e-mail]

Jeff
  If your routing table has entries of the form

route add default <intfc> <gateway>
routed add <local> <intfc>

where <gateway> is probably SanJose   (44.4.0.96)    and <local>
is only stations that you can hit as well or better than
the gateway *all the time* directly, then your end of the
situation is probably pretty well taken care of. Getting Marc, kg6kf,
to fix his end similarly is the remaining part of the solution.
  As indicated by others, getting static routing properly set up
and maintained appears to be nearly an insurmountable task.

As of the moment, SanJose.ampr.org, aa6iw.ampr.org and SantaRosa.ampr.org
appear to "do the right thing" with packets. SantaRosa also routes
(over a rather shaky link) to 44.2/16, the Sacramento Valley block
which also appears to have its house in fair order... at least there
seems to be end-end connectivity among all the above.

I think we are still trying to overcome the legacy of early documentation
which suggested
route add default <intfc>
was a good idea.

I believe the philosophy wants to be something like:
"Explicitly route to any hosts which you can hit as well or better
than anyone else. Route everything else to the host(s) most likely to be
able to achieve success."

Maybe someone else has a better idea.


Glenn Elmore -N6GN-

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

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

Date: 26 Mar 91 13:50:02 GMT
From: o.gp.cs.cmu.edu!andrew.cmu.edu![e-mail]
Subject: Beginners's Question
To: [e-mail]

A while back, I posted a question about "How do you stop a long listing
from a PBBS without disconnecting. Well, I did receive some answers, but
the bottom line seems to be that it depends upon the software that the
PBBS is running. For the Pittsburgh BBS's (W2XO, NO3M, KC8JN, KA3JSD),
"A" seems to abort most of them. It causes the listing to stop, and
returns you to the command prompt. One of the BBS's, I can't remember
which one, will not stop dumping the listing for anything. The newer version
of MYSYS BBS software all will abort using "A".

    Now......another beginers question. I connect to a local digi, and
issue the "N" (NODES) command. The digi sends me back a list of "nodes"
that it has access to. Is this node list just a list of stations using
the digi at any given time, or are the nodes something special? I notice
that all nodes listed have aliases. Is this what makes them a node.
If I connect to station X through this digi, does that make me one of
the digi's nodes? I am sort of confused about this point. I am aware that
any station's TNC can be used as a digipeater, provided that DIGIPEAT is
ON. Maybe the digi's node list is really it's MHEARD list in that those
are the stations that *it* can actually hear.

Is there any difference between    c w3cyo-2
                     ( connected ok)
                   n  (get his nodes) (pick no3m)
                   c no3m
                      (get connected)


OR

       c no3m VIA w3cyo-2


I mean, is one method better than the other?
Excuse all the questions, but USENET is a might faster than Pittsburgh
1200 baud packet, and since I discovered this storehouse of knowledge,
I thought I might as well make good use of it.

Please post any replies to the net.

tnx
\paul
Paul Dujmich
WA3TLD

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

Date: 26 Mar 91 16:54:53 GMT
From: sdd.hp.com!wuarchive!rex!rouge!pc.usl.edu![e-mail]
Subject: Beginners's Question
To: [e-mail]

[e-mail] (Paul J. Dujmich) writes:
>Is there any difference between    c w3cyo-2
>                                     ( connected ok)
>                                   n  (get his nodes) (pick no3m)
>                                   c no3m
>                                      (get connected)
>
>OR
>       c no3m VIA w3cyo-2
>

Paul, there is indeed a difference:
Assuming w3cyo-2 runs NetRom or emulates it, the nodes command reveals
all the netrom nodes it knows about, even if it has to connect to intervening
nodes to get to them.  So when you pick a node from this list, and try a
connect to that node, you might end up going through several other nodes,
not in a digi fashion, but in a netrom circuit fashion.

Now if you instead did "c no3m via w3cyo-2" you would have to reach no3m
in one hop from w3cyo-2 since you are using it as a digi instead of a
circuit switch.

One way to see which nodes are one hop away is to issue the netrom Routes
command.  Just remember that the route quality numbers change too slowly
to be very reliable.  Your PBBS SHOULD have info files on netrom operation
available; if not drop a note to the owner of the netrom!

73,
--
-- James Dugal, N5KNX           Internet: [e-mail]
Associate Director              Ham packet: n5knx@k5arh
Computing Center                US Mail: PO Box 42770  Lafayette, LA  70504
University of Southwestern LA.  Tel. [phone]       U.S.A.

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

Date: 27 Mar 91 00:05:25 GMT
From: swrinde!elroy.jpl.nasa.gov!usc!zaphod.mps.ohio-state.edu!wuarchive!rex!rouge!pc.usl.edu![e-mail]
Subject: Digicom V4.01 -- available?
To: [e-mail]

A local Commodore 64 user asked that I try to find him a source for
a newer version of the Digicom software.  He is using 3.51 currently,
and has heard that 4.01 exists, but has been unable to find how to
obtain it.  Can anyone help him?

Thanks & 73, de
James N5KNX
--
-- James Dugal, N5KNX           Internet: [e-mail]
Associate Director              Ham packet: n5knx@k5arh
Computing Center                US Mail: PO Box 42770  Lafayette, LA  70504
University of Southwestern LA.  Tel. [phone]       U.S.A.

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

Date: 26 Mar 91 13:10:57 GMT
From: [e-mail]
Subject: IP address coordinators list
To: [e-mail]

    AMPRNet IP address coordinators as of 25 March 1991

44.002  Bob Meyer               K6RTV   Calif: Sacramento
44.004  Douglas Thom            N6OYU   Calif: Silicon Valley - San Francisco
44.006  Don Jacob               WB5EKU  Calif: Santa Barbara/Ventura
44.008  Brian Kantor            WB6CYT  Calif: San Diego
44.010  Brian Roode             KA6CCF  Calif: Orange County
44.012  Steven King             KD7RO   Eastern Washington,Idaho
44.014  John Shalamskas         KJ9U    Hawaii & Pacific Islands
44.016  Jeff Angus              WA6FWI  Calif: Los Angeles - S F Valley
44.018  Geoffrey Joy            KE6QH   Calif: San Bernardino & Riverside
44.020  Fred Schneider          K0YUM   Colorado: Northeast
44.022  John Stannard           KL7JL   Alaska
44.024  Dennis Goodwin          KB7DZ   Washington state: Western (Puget Sound)
44.026  Ron Henderson           WA7TAS  Oregon
44.028  Don Adkins              KD5QN   Texas: Dallas
44.030  J Gary Bender           WS5N    New Mexico
44.032  Bdale Garbee            N3EUA   Colorado (Colorado Springs)
44.034  Jeff Pierce             WD4NMQ  Tennesee
44.036  Doug Drye               KD4NC   Georgia
44.038  Mike Abbott             N4QXV   South Carolina
44.040  Jeff Jacobsen           WA7MBL  Utah
44.042  Phil Akers              WA4DDE  Mississippi
44.044  Rolfe Tessem            W3VH    Massachusetts: western
44.046  William Simmons         WB0ROT  Missouri
44.048  Jacques Kubley          KA9FJS  Indiana
44.050  Ron Breitwisch          KC0OX   Iowa
44.052  Gary Grebus             K8LT    New Hampshire
44.054  Ralph Stetson           KD1R    Vermont
44.056  Don Hughes              KA1MF   Eastern Mass
44.058  Rich Clemens            KB8AOB  West Virginia
44.060  Howard Leadmon          WB3FFV  Maryland
44.062  Jim Dearras             WA4ONG  Virginia (not DC)
44.064  Dave Trulli             NN2Z    New Jersey: northern
44.065  John Pearce             WB2MNF  New Jersey: southern
44.066  unassigned
44.068  Norm Sternberg          W2JUP   New York: Long Island
44.069  Paul Gerwitz            WA2WPI  New York: upstate
44.070  Gary Sanders            N8EMR   Ohio
44.072  Dick Gulbrandsen        WD9DBJ  Chicago - North Ill.
44.074  James Curran            KA4OJN  North Carolina
44.076  Kurt Freiberger         WB5BBW  Texas: central?
44.077  Rod Huckabay            KA5EJX  Texas: west
44.078  Joe Buswell             K5JB    Oklahoma
44.080  John Gayman             WA3WBU  Pennsylvania: eastern
44.082  Steven Elwood           N7GXP   Montana
44.084  Bob Ludtke              K9MWM   Colorado: western
44.086  Reid Fletcher           WB7CJO  Wyoming
44.088  Jon Bloom               KE3Z    Connecticut
44.090  Mike Nickolaus          NF0N    Nebraska
44.092  Pat Davis               KD9UU   Wisconsin, upper peninsula Michigan
44.094  Gary Sharp              WD0HEB  Minnesota
44.096  Don Bennett             K4NGC   District of Columbia
44.098  Garry Paxinos           (waiting)       Florida
44.100  Ken Adkisson            WB4FAY  Alabama
44.102  Jeff King               WB8WKA  Michigan (lower peninsula)
44.104  Ed Rasso                WA2FTC  Rhode Island
44.106  Bob Austin              N4CLH   Kentucky
44.108  James Dugal             N5KNX   Louisiana
44.110  Richard Duncan          WD5B    Arkansas
44.112  Bob Hoffman             N3CVL   Pennsylvania: western
44.114  Steven Elwood           N7GXP   N&S Dakota
44.116  Tom Kloos               WS7S    Oregon: NW&Portland,Vancouver WA
44.118  Jon Andrews             WA2YVL  Maine
44.120  unassigned
44.122  Dale Puckett            K0HYD   Kansas
44.124  David Dodell            WB7TPY  Arizona
44.125  Earl Petersen           KF7TI   Nevada
44.126  Karl Wagner             KP4QG   Puerto Rico
#
# 44.128 is reserved for testing.  Do not use for operational networks.
# You may safely assume that any packets with 44.128 addresses are bogons
# unless you are using them for some sort of testing
#
44.128  TEST
#
# International subnet coordinators by country
#
44.129  Japan           JG1SLY Tak Kushida, JH3XCU Joly Kanbayashi
44.130  Germany         DL4TA
44.131  United Kingdom  G4CLI   Dave Lockwood
44.132  Indonesia       YB1BG   Robby Soebiakto
44.133  Spain           EA4DQX  Jose Antonio Garcia.  Madrid. (EA4DQX @ EA4DQX)
44.134  Italy           I2KFX
44.135  Canada          VE3GYQ  David Toth
44.136  Australia       VK2ZXQ  John Tanner
44.137  Holland         PA0GRI  Gerard Van Der Grinten
44.138  Israel          4X6OJ   Ofer Lapid
44.139  Finland         OH1MQK  Matti Aarnio
44.140  Sweden          SM0RGV  Anders Klemets
44.141  Norway          LA4JL   Per Eotang
44.142  Switzerland     HB9CAT  Marco Zollinger
44.143  Austria         OE1YSS  Irmela Gagern
44.144  Belgium         ON7LE
44.145  Denmark         OZ1EUI
44.146  Phillipines     DU1UJ   Eddie Manolo
44.147  New Zealand
44.148  Ecuador         HC5K    Ted
44.149  Hong Kong       VS6EL
44.150  Yugoslavia      YU3FK   Iztok Saje
44.151  France          FC1BQP  Pierre-Francois Monet
44.152  Venezuela       OA4KO/YV5       Luis Suarez
44.153  Argentina       LU7ABF  Pedro Converso
44.154  Greece          SV1IW   Manos
44.155  Ireland         EI9GL   Paul Healy
44.156  Hungary         HA5DI   Markus Bela
44.157  Chile           CE6EZB  Raul Burgos
44.158  Portugal        CT1DIA  Artur Gomes
44.159  Thailand        HS1JC   Kunchit Charmaraman
44.160  South Africa    ZS6BHD  John
44.161  Luxembourg      LX1YZ   Erny Tontlinger
44.162  Cyprus          5B4TX   C. Costis
44.163  Central America TI3DJT  Chuck Hast

44.193  Outer Space-AMSAT       W3IWI           Tom Clark

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

Date: 26 Mar 91 17:03:17 GMT
From: [e-mail]
Subject: Packet Networks in NE U.S.A.
To: [e-mail]

CANDGA user port is on 144.99 MHz.

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

Date: 26 Mar 91 23:13:34 GMT
From: theory.tn.cornell.edu![e-mail]
Subject: PMP, a software TNC for the PC available via FTP
To: [e-mail]

After much prodding from friends, I've dusted off my Poor Man's Packet (PMP)
program and released it for public consumption.  It is freely copyable for
non-commercial amateur radio uses.  It is not public domain--I retain the
copyright.

PMP is a software TNC for 1200 baud amateur packet radio for the IBM PC.  The
PMP program, a PC (with a parallel port), a VHF or UHF radio, and an
inexpensive single-chip modem are all you need to get on packet.  The program
(*with* source code, yippee!) is available via anonymous FTP from
helios.tn.cornell.edu (thanks to Lew, N2KNV for providing the FTP site):

    /pub/pmp10.zip          Binaries and documentation
    /pub/pmpsrc10.zip       Complete source code (Turbo C 2.0)

If you don't have anonymous FTP, first try using one of the FTP mail servers
(send a message with the subject HELP and message HELP to
[e-mail]).  If that fails, I can send out UUENCODEs of the
.ZIPs.  If *that* fails, send a pre-formatted 360K disk to, with return mailer
and postage to:

    Andrew C. Payne
    201 Maple Ave, Apt B14
    Ithaca, NY  14850

For modem construction details, see the February, 1989 issue of 73 (pp. 42-43).
See the PMP documentation on how to interface this modem to the PC's parallel
port.

Due to time constraints, I'm afraid that I'm not going to be able to provide
much support.  I will fix obvious bugs and try to serve as a clearinghouse
for those interested in making contributions and enhancements.  I doubt if
I will be able to do any more substantial development.

Enjoy!
--
=  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =
Andrew C. Payne, N8KEI        UUCP:  ...!cornell!batcomputer!payne
              INTERNET:  [e-mail]

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

Date: 26 Mar 91 16:03:00 GMT
From: [e-mail]
Subject: Problem
To: [e-mail]

I have received two digests with no text--
both copies of Vol. 91 No. 68!

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

Date: 26 Mar 91 15:26:34 GMT
From: isis![e-mail]
Subject: We've Moved to New Groups
To: [e-mail]

I see there are still some people posting to this group.  This group has
been moved to a new group...

     rec.ham-radio       --> rec.radio.amateur.misc
     rec.ham-radio.packet -> rec.radio.amateur.packet
     rec.ham-radio.swap  --> rec.radio.amateur.swap

There are also some new groups including:

     rec.radio.shortwave
     rec.radio.policy
     rec.radio.noncom   (or something like that for non-commercial radio)

Don 't be left alone, come and join us in the new groups.

--
Bill Hester, Ham Radio N0LAJ, Denver CO., USA | N0LAJ @ W0LJF.CO.USA.NA
Please route replies to: [e-mail] or uunet!nyx!whester
Public Access Unix @ University of Denver, Denver Colorado USA
(no official affiliation with the above university)

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

End of Packet-Radio Digest
******************************
Date: Thu, 28 Mar 91 04:30:08 PST
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Reply-To: [e-mail]
Subject: Packet-Radio Digest V91 #74
To: packet-radio


Packet-Radio Digest         Thu, 28 Mar 91       Volume 91 : Issue  74

Today's Topics:
        2400 bd manchester with normal radios
             BPQ and MULTIKISS ??
           Casio BOSS - Using as a Terminal
              First 38400 bd packet QSO
KA9Q - What is the current release and where can it be found? (2 msgs)
          Looking for info on a specific freq. band
             Turbo TNC-2 (9.8 MHz clock)
             YU 38400 bd network by YT3MV

Send Replies or notes for publication to: <[e-mail]>
Send subscription requests to: <[e-mail]>
Problems you can't solve otherwise to [e-mail].

Archives of past issues of the Packet-Radio Digest are available
(by FTP only) from UCSD.Edu in directory "mailarchives/packet-radio".

We trust that readers are intelligent enough to realize that all text
herein consists of personal comments and does not represent the official
policies or positions of any party.  Your mileage may vary.  So there.
----------------------------------------------------------------------

Date: 27 Mar 91 08:58:00 GMT
From: [e-mail]
Subject: 2400 bd manchester with normal radios
To: [e-mail]

This TEXT was send to HARDWA @EU , February 1991

There is quite a number of questions regarding YU packet network,
especially manchester modulation we use. This message was written in response
to DG3FCE questions; but on the end it finished as bulletin.
2400 bd manchester works fine here with unmodified FM radios.

Our manchester modem is simply BI-phase-PSK; same as used on JAS-1/uSATs.
Manchester code is known from Ethernet cables etc, it is simple and robust.
JAS modems are complicated because of Doppler shift compensation and mistuning
of frequency, SSB RX and TX are never exactly on the same QRG.

But, we use FM stations, not SSB - so modems are VERY simple.
There is no need for QRG compensation so simple digital PLL can
recover TX clock. TX side is same as JAS modem, and RX use same circuit
after clock is recovered (XOR between data and clock, nothing more).

Telephone modems use QPSK for duplex 2400 bd; so BI-PSK has same troughput.
(4 phases/twice 2400 bd is same as 2 phases/2400 bd)
(QPSK pack two data bits in one sample, so it is twice 1200 baud, while
with BI-PSK one bit is one baud)

About performances:
You saw parameters on LJU2:4N3L-2 node. (LJU2:4N3L-2 and GO70:4N3N-7 are
nodes running 2400 bd manchester).
Everything is just twice as fast as 1200 bd. We use digital DCD, so TXDELAY
can be as low as 100 ms. 2400 bd can be used with normal, unmodified
FM radios, but we build some wide-bandwith FM stations also. YU backbone
is on 23cm, running 38400 bd, and we are just now completing user network
on 70cm/19200 bd using 100 kHz wide FM stations.

Why do not everybody use this "simple" modulation ?

Main reason: You can not buy factory made modem.
Second reason: everybody starts with complicated designs, or telephone
chips, like Kantronics 2400 bd modems. (some 100$ per modem...)
Good old days are forgotten, when tape was only data medium.
Manchester (and simmilar codings) were used on home computers for
"Tape loading error" messages... Hi.

Of course, there is a bad side: not every stn is OK for 2400 bd; some
have crazy preemphasis. Same troubles as already discovered by JAS users.
I had to change one resistor to get my IC-02 TX working OK.
(resistor in TNC, not in handie).

There are two modems developed by YT3MV:
first one with EPROM state machine,
simmilar as one used in original TNC-2 to regenerate RX clock. This one
is used on 38400 bd network with DC8SE TNCs (and 9.8 MHz clock).
DCD is also generated with this modem, but up to now nobody made QSO on
2400 bd with this kind of modem. I tried, but got only one-way qso; must
attack it with scope sometime.

Second modem is made of few standard 74HC chips. It is used by YT3MV
TNC-2 clone with internal digital DCD circuit. YT3RM made new layout of
YT3MV TNC, so TNC with manchester modem is one EUROPA sized PCB. Optional
FSK modem can be added as piggi-back for compatibility with old nodes.

This TNC was primary developed for 2400 bd/2m; 19200 bd/70cm and
38400 bd/23cm. Modem can be used with Digicom on C-128, because same
circuit is used on TX to regenerate TX clock. (It is NOT duplex modem).
YT3MV TNC was published in Italian magazine CQ Elettronica, as well as
23cm radios.

There is also third modem - software one, which runs fine on YT3MV
M68010 based DSP computer.

And, of course, original JAS (TAPR, G3RUH [not 9600 !!]) modems should
work fine on 2400 bd - but nobody here tried this approach. Few components
should to be changed for 2400 bd operation.

Now some theory on manchester code:


    ! data 1 = 1  !      1      !     0      !     0      !   bits

    -------!      !------!            !------!      !------   manchester
       !      !      !            !      !      !         data from/to
       !------!      !------------!      !------!         radio



    !      !------!      !------!      !------!      !------!
    !      !      !      !      !      !      !      !      !   clock
    !------!      !------!      !------!      !------!      !---

    !      1      !      1      !      0      !      0      !   bits

   -----------------------------!
                !                              NRZI data
                !---------------------------   from/to TNC

Here you see, how simple it is, to translate NRZI to manchester, once you
have good clock.  One XOR gate can do the job. There is one signal transition
in the middle of every bit - so clock recovery is easy task.

If you look into manchester coded signal, it has no DC component. If there are
only 1 or 0 in signal, it is pure 2400 Hz signal. With data, spectrum is
wider, but it is centered on 2400; most of energy is in 1200 to
3600 Hz region, within audio passband of most HAM FM radios.

More details can be found in most communications textbooks.

73 de Iztok, YU3FK

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

Date: 27 Mar 91 12:29:01 GMT
From: bloom-beacon!eru!hagbard!sunic!ugle.unit.no!mack.uit.no!cs.uit.no![e-mail]
Subject: BPQ and MULTIKISS ??
To: [e-mail]

At LA3T BBS we are using FBB 5.12 BBS software and BPQ 3.59 node switch software.
We are now trying to implement a multi-port node, using BPQ's MULTIKISS option and
the JKISSP prom image. It seems to work all right.

But: We are thinking about upgrading to BPQ 402a, and we are a little bit confused.
The documentation (the CHANGES.BPQ file) says that the MULTIKISS option is no longer
supported, and we can't find any JKISSP or BPQKISS enclosed with the BPQ 402a release.

The PORTS.DOC file still mention the MULTIKISS option.

Our question is: What kind of multidropped KISS do the BPQ402a support? It is possible
to use the same JKISSP proms as we use with version 3.59?



73 de

Rolv/LA5WBA and Oyvind/LA7ECA   (Sysops at LA3T BBS)

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

Date: 27 Mar 91 22:17:57 GMT
From: zephyr.ens.tek.com!gvgpsa!gold.gvg.tek.com![e-mail]
Subject: Casio BOSS - Using as a Terminal
To: [e-mail]

If have seen some references in posting to the use
of the Casio BOSS as a terminal. Would someone
please inform us as to how this is done?

What does one do to the BOSS to put it in terminal mode?
Baud rate, parity, etc.?

Finally - how successful is this process? Does the size
and portability of the BOSS outweigh the disadvantage of
the small screen and miniscule keyboard?

I am interested in retrieving e-mail and accessing packet
bulleting boards while on the road. File transfer is of
little interest to me.

Any comments?

thanks,

Grover Cleveland, WT6P

The Grass Valley Group Inc.
Grass Valley, CA

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

Date: 27 Mar 91 11:02:00 GMT
From: [e-mail]
Subject: First 38400 bd packet QSO
To: [e-mail]

38400 bd packet
De: YU3FK @ YT3A
To: All @ EU

It was already reported on YU backbone 23 cm project. Matjaz YT3MV
designed 1.2 GHz station for packet network and Manchester code modem.

PIN diodes TX/RX switch and non-stop powered XTAL oscillators with carrier
detect build in modem state machine are keeping TXDELAY between 10 and 15 ms.

The problem was - what about software and TNC ?
TNC-2 limit is 19200 bd, but we tried 38400 with
turbo TNC (Z80H, Z80B-SIO, 200ns EPROM, 9.8 MHz CPU clock).

38400 bd packet radio results:
(test made April 9th, 1989 by YU3RM, YT3RM and YU3FK)

First station used (YU3RM):
 - PC-AT 16 MHz, YAPP program, 9600 bd RS-232 to TNC
 - turbo TNC with 38400 bd PSK modem and N2WX 1.1.4 software
 - TNC parameters:
   FRACK 1  DWAIT 0 MAXFRAME 7 PACLEN 0 TXDELAY 2
   TRANSPARENT mode

Second station (4N3H-12):
 - turbo TNC with NORD><LINK the NET 1.1 software
 - parameters:
   TXDELAY 2, node PARAMS
   70 1 100 255 6 5 3600 10 60 2 2 180 6 6 3600 255 1 1 7 10 5 18000 1 1 0 1

test file:
 YU3C WW WPX contest log, 1918 QSOs, 122 752 bytes, less LF 120834 bytes
 (Linefeeds are not transfered using YAPP ASCII download)

YU3RM connected YU3RM via 4N3-12 (first test, level 2)
YU3RM connected 4N3H-12, then back to YU3RM (second test, level 3 ? )

Both tests gave same result: 120 834 bytes transfered in 222 seconds.
FRACK 7 and PACLEN 0 (256) means there were 67 INFO packets with
473 frames. 67 acknowledge (RR) frames/packets were send also.

Effective data transfer speed using two radio links (to node and back)
is 4350 bits/second; thus giving 8700 b/s for one radio link.

YU 23 cm backbone is build for single QRG interconnection of 1200/2400 bd
user access nodes and main BBSes. It had to be compatibile with existing
network (theNET and NET/ROM nodes, 1200 bd DIGICOM users etc). We feel
this configuration is maximum that can be obtained with TNC-2 and existing
software on single QRG.

Some changes to modem and station are expected, and they HAD to be
tested on real packet traffic. In next few months first real nodes
will be interconnected with 23 cm stations. Results will be
reported to BBS network.

Best 73 and good packeting de Iztok, YU3FK @ YT3A
***END

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

Date: 25 Mar 91 23:58:07 GMT
From: sdd.hp.com!cs.utexas.edu!execu!sequoia!uudell!bigtex!texsun!Athena!mismpc![e-mail]
Subject: KA9Q - What is the current release and where can it be found?
To: [e-mail]

I have found a version of KA9Q which is version "890421.0" and successfully
compiled it on my system.  It is also pretty apparent that this verision is
absolutely ancient - all attempt to UUCP to "winfree" as in the manual have
not gotten through, and I do not have internet ftp access, although I can
transfer Internet mail.  Anybody know the most current version and where I
can download it from????

            Thanks,
            Tim Dawson/N8EAU

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

Date: 27 Mar 91 23:36:15 GMT
From: epic![e-mail]
Subject: KA9Q - What is the current release and where can it be found?
To: [e-mail]

The current versions are kept on thumper.bellcore.com and are available
by anonymous FTP. The directories to search are all under /pub/ka9q.

Unfortunately I am unable to distribute my code directly by means other
than anonymous FTP. Several BBSes do pick up my code from thumper and
make them accessible to regular phone line users; I believe WB3FFV in
Baltimore is one such system.

Phil

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

Date: 27 Mar 91 19:59:36 GMT
From: sdd.hp.com!zaphod.mps.ohio-state.edu!ncar!noao!stsci![e-mail]
Subject: Looking for info on a specific freq. band
To: [e-mail]

 Sorry for such wide distribution (for anyone it might bother)...

I'm looking for information on who might be broadcasting
between 174 MHZ and 199 MHZ.....

I just bought a wireless mike system which uses this frequency
band (10 different available channels), and was wondering if
I would be competing with anything??/??

please mail to [e-mail]

thanks
calvin

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

Date: 27 Mar 91 08:48:00 GMT
From: [e-mail]
Subject: Turbo TNC-2 (9.8 MHz clock)
To: [e-mail]

I found few bulletins on my disk, I hope they give some
picture on our packet project.

This text was send to ALL @ EU April 6th, 1989


Turbo TNC-2

It is known that TNC-2 with 4.9 MHz clock can run up to 19200 bd
on radio port. Most users use 1200 bd, and it is all OK.

Matjaz, YT3MV, designed 23 cm stations (1.5 W; FM, wide band) and
PSK modems (Manchester code). They can be used up to 76800 bd,
but we have no TNCs to run this speed.

Initial tests were made on 19200 bd. All worked OK, and over 4000 bd
effective were measured on good link between two stations
exchanging 100 kb file. (WW contest logs, of course).
38400 was tried, and there were so many retries it was
slower than 19200. 4.9 MHz TNC was to slow to process each
incomming character.

So, TNCs should be faster.
Modifications for faster TNCs are simple. 2.4 MHz oscilator is
added to take care of baud rates, and original XTAL is replaced
with new one. TNC-2 (Eisch electronic clone) was running OK on
7.1 MHz.

It is known that stated maximum frequency is garanted, but much
higher speeds and access times can be expected.
Normal Z80 and SIO, stated 2.5 MHz, work OK in 4.9 MHz TNCs.
(At least those I tested). Technology today is better as it
was 10 years ago when specifications were made.

With Z80H, stated 8 MHz, we can expect some 10 MHz. Same with
SIO-B. It is stated 6 MHz... With little luck and selected
devices...
But what about memory ? Fastest Z80 memory access is M1
cycle, when instructions are feched. It takes slightly less than
1.5 clock cycle - less than 150 ns on 10 MHz system. RAM access
is slower, but our RAMs are 120 ns, so no need to worry about
RAM.

Experiment was made with two Eisch TNC-2 clones. They use 74HC
chips in address decoding. Z80A was replaced by Z80H and
Z80A-SIO was replaced with Z80B-SIO. Different EPROMs and XTALs
were tested.

One 250 ns EPROM worked OK with 11.16 MHz, but not with 12.7 MHz.
Another EPROM (200 ns) worked OK on 10 MHz. Few 250 ns EPROMs
failed between 8 and 10 MHz. Different software was tested on
the air (theNet, TF8, N2WX) to check all possible interrupts and
instructions.

So, whenever TNC-2 is used on high-speed links (9600 bd duplex
or 38400 CSMA) we can simply get better performances by doubling
TNC-2 speed. With 9.83 MHz XTAL we can use spare 7474 flip flop
to devide it by four and get 2.4 MHz from single XTAL.
Z80H and Z80B-SIO are used; 150 ns EPROMs are reccomended.
With selected devices even higher XTAL QRG can be used.
All turbo TNCs should be tested carefully. It is better for TNC
to crash on testing than to crash on the mountain !

This modification is not worth to try for stations
running 1200 bd on radio port ! There will be no better
performances, because radio speed is limiting your TNC.

So, while we wait for better NODE controllers, good old TNC-2
with all the software can be used for speeds up to 38400 bd.

TNX for attention, 73 and good packeting de Iztok, YU3FK @ YT3A.

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

Date: 27 Mar 91 08:54:00 GMT
From: [e-mail]
Subject: YU 38400 bd network by YT3MV
To: [e-mail]

This text is dated October 1989. All described projects were
published in Italian magazine CQ Ellectronica

      23cm 38.4kbps Packet Radio Network in Slovenia (YU3)
             Hardware Technical Description
              Matjaz Vidmar, YT3MV

1. Introduction
---------------
     Already at the very beginning of packet radio in our area we noticed the
severe limitations of a single channel, 1200bps CSMA network: the terrain
configuration requires many repeaters to serve all the amateur population and
our network has to handle the traffic among Austria, Italy, Hungary and other
parts of Yugoslavia as well.
     The solution we found is to build a network of nodes with user-access
channels in the 2m and 70cm bands at low speeds (1200bps and soon 2400bps),
interlinked with 38.4kbps links operating in the 23cm band. At the time of
writing this message the network has three such high-speed links linking
four main nodes: 4N3K, 4N3L, 4N3H and 4N3P. The network is operating well and
several other nodes are  currently under construction.
     The 1.2GHz, 23cm network in Slovenia is the result of a collective effort
of a group of more than 10 enthusiasts, whose work was coordinated by Iztok
YU3FK. Within this group I was in charge of developing the hardware and in
this message I am going to describe the technical aspects of our network.

2. Selecting the transmission standards
---------------------------------------
     It was immediately clear that we could not use standard narrowband
amateur transceivers and low speed modems for our network interlinks and some
new hardware had to be developed. Further we could not use the 70cm band since
the latter only extends from 432 to 438MHz in Yugoslavia without overriding
the IARU bandplan. Finding a clear, wideband channel in this frequency band
is a challenge too! Therefore it was decided to use the 23cm band.
     The modulation standard also had to be selected, considering the
constraints of both modem and transceiver design. Coherent modulation
techniques (like straightforward PSK) provide the best spectrum efficiency and
longest communications range. Unfortunately they require a very good frequency
stability of both transmitters and receivers. Further, the lock-in time of the
demodulator may require long synchronization headers (long TXDELAY). Finally,
the transceivers themselves have to be designed for this particular
transmission standard: alignment and testing may be very difficult for
amateurs without much test equipment.
     Considering the above constraints it was decided to build wideband FM
transceivers equipped with 200kHz wide ceramic filters (like FM broadcast
receivers). Such transceivers together with suitable modems can support
digital communications up to about 64kbps. The penalty for using a FM
discrimiator in place of a coherent demodulator is around 5dB in terms of
receiver sensitivity or communications range, with well-designed modems.
     The FM transceiver could be straightforward modulated with the NRZI data.
Unfortunately the NRZI data has a noticeable DC component, which requires a
DC restoration network in the receiver, even with data randomization
(scrambling). Manchester coding was therefore selected: although it requires
twice the bandwidth, a manchester coded signal has no DC or low frequency
component. Manchester modems can be built as simple digital state-machines
(no alignment!) with a fast and reliable digital carrier-detect logic.
     To remain 100% compatible with the exsisting network, TNC2 clones with
NETROM or TheNet software are used. This software packages can operate up to
about 40kbps with a 10MHz Z80 clock, so a standard speed of 38.4kbps was
selected for the network. Initial problems with TNC2 clones operating at 10MHz
were solved by a careful selection of the components used and by designing a
new TNC2 clone logic with less critical timings.
     Right from the beginning it was agreed to use simplex transceivers and
CSMA like with low-speed 1200bps packet-radio on 2m and 70cm. A network
with full-duplex transceivers could provide a slightly higher capacity at a
significantly higher cost: each node would require two or three transceivers
with bulky duplexer filters and dedicated TNCs. The selection of the operating
frequencies in the network would cause problems too. Further, such a network
could not support advanced high-speed users in the 1.2GHz band, thus precluding
the possibility for any further experimentation. Finally, such a complicated
solution was considered out-of-reach for our limited resources!

3. Transceiver design
---------------------
     The wideband transceiver is a simple single-channel crystal-controlled
FM transceiver. Except for the RX/TX antenna and supply switches the receiver
and the transmitter circuits are completely independent.
     The receiver is a double conversion receiver: the first (variable) IF is
in the 65MHz range and the second IF is 10.7MHz. A single crystal oscillator
operating between 26.5 and 27MHz, is used for both conversions. The oscillator
output is multiplied by 45 (5*3*3) for the first conversion and by 2 for the
second conversion. The receiver has two RF amplifier stages at 1.2GHz (BFQ69
and BFR91), a mixer 1.2GHz/65MHz (BFR34A), another mixer stage 65MHz/10.7MHz
(BF981) and a standard 10.7MHz FM IF (CA3089). The receiver acheives a noise
figure of about 4dB.
     The transmitter includes a varactor-modulated crystal oscillator in the
9.8 to 10MHz range followed by 7 frequency doubler stages for a total
multiplication factor of 128 and a power amplifier. High-speed switching
transistors (BSX39) are used up to 300MHz. The last two multiplier stages use
a BFR91 and a BFR96. Finally, the four stage power amplifier uses a BFR91,
two BFR96s and a BFQ68, supplying between 1.5 and 2W at 1.2GHz.
     All the RX/TX switching (supply, antenna) is fully electronic. The RF
switch uses four BA379 PIN diodes. To speed-up the switchover the receiver is
powered on all the time except for the two front-end RF amplifier stages.
The transceiver was found to be able to work reliably with a TXDELAY of only
5ms, but for reliability reasons the TXDELAY parameter was finally set to 2
(20ms).

3. Modem design
---------------
     Two different modems were developed. Both modems include a state machine
that operates with a clock that is 64 times the bit-rate frequency. The same
state machine is used both during transmission and during reception to
synchronize a 50% duty-cycle square wave with the incoming signal.
     Both demodulators include a limiter followed by an exclusive-or gate and
an integrator. Limiting the incoming signal degrades the demodulator
sensitivity by 2 to 3dB: this is the price paid for such a simple circuit.
A few dB are lost in the integrator too, which is a simple RC lowpass followed
by a voltage comparator in place of a synchronized integrate-and-dump.
     The first modem has an EPROM based state machine together with a 74HC374
8bit D-latch. Most of the analog functions are performed with a LM339 quad
comparator. A 16 bit shift register (two 74HC164) generates a 1/4 bit delay
for the DCD detector since this modem was developed to work with standad TNC2
clones. The modem may have its own clock oscillator, but for 38.4kbps the
required 2.4576MHz clock can also be derived from the TNC.
     The second modem uses 74LS logic only, thus eliminating the need for a
relatively slow EPROM, that needs to be programmed too. The state machine is
built with just four TTL ICs: 74LS86 ex-or gates, 74LS153 multiplexer, 74LS163
counter and 74LS175 D-latches. LM311 comparators are used for the analog
functions. Since this modem is intended to work with the new TNC2 clone (to
be described later) and the latter already has a very reliable DCD circuit,
no DCD circuit was included in the modem itself.
     The described manchester modems were also tested with standard amateur
narrowband FM transceivers. By connecting the modem to the MIC and SPKR
connectors a very reliable operation was possible at 2400bps. Higher speeds
(up to 4800bps) require a direct connection to the varactor and discriminator.
We belive that 2400bps manchester is a valid and cheaper alternative for user
links to the now widely used BELL-202 1200bps. Unfortunately 2400bps
manchester is not compatible to the Kantronics 2400bps QPSK standard, but in
our area very little amateurs have commercially-built TNCs anyway.

4. Revised TNC2 clone
---------------------
     The first experiments at 38.4kbps and the first internode link were made
with off-the-shelf TNC2 clones. These have a number of drawbacks that can be
summarized as follows:
A) Most clones have a very unreliable RESET circuit/nonvolatile RAM protection
   logic. This leads to very undesirable "latchups", especially if the TNC is
   installed on a difficult-to-reach mountain top!
B) Although the original TNC2 had an EPROM-based state machine RX
   synchronization, most clonemakers replaced it by a 74LS393 counter with a
   rough RESET logic. The performance of this circuit is very poor with weak
   signals.
C) Most clones have a poorly designed address decoder. MREQ is gated with A15
   to select the 27256 EPROM. This circuit requires a very fast 150ns EPROM
   for a 10MHz Z80 clock operation. Gating MREQ with RD releases the EPROM
   access time requirement by at least 50ns.
D) TNC2 clones usually do not have a digital carrier-detect logic. This is not
   a problem for manchester modems, where a reliable DCD can be built easily.
   It is a problem with AFSK modems (BELL-202): the transceiver squelch has
   to be adjusted critically and an unnecessary long TXDELAY is required...
E) The RS-232 drivers and related negative supply are a source of troubles.
   In a multiple NETROM or TheNet node it is much simplier to interconnect
   the TNCs at TTL levels.
F) Many TNC2 clones have other design mistakes that cause an unreliable
   operation. These are different from one TNC to another.
     To avoid all these problems a revised TNC2 clone was developed. The
latter includes a very reliable RESET logic and an improved address decoder.
The RX synchronizer is a state machine operating with a clock that is 32 times
the bit-rate frequency. The state machine uses four TTL ICs: 74LS86 ex-or
gates, 74LS157 multiplexer, 74LS163 counter and 74LS175 D-latches. The state
machine includes a DCD logic that looks where do the transitions occur. If
the latter occur at the beginning or towards the end of the bit time, the
signal is OK, if they occur in the middle of a bit, the input is considered
noise. A RC lowpass followed by a LM311 comparator finally supplies the DCD.
     The remaining circuits are similar to other TNCs: a 74LS74 and an ex-or
gate are used for the NRZI/NRZ conversion and a 74LS109 is used for the
NRZ/NRZI conversion. A 74LS14 drives the asynchronous port: RS-232 receivers
do accept TTL signals while the TTL inputs can be protected by resistors form
RS-232 voltages. The clock oscillator uses a 74HC00, followed by a 74LS74 and
a 4040. There are of course the four big chips too: Z80CPU, Z80SIO-0, EPROM
and RAM. Interestingly, in spite of all the additions and improvements, the
revised TNC2 has LESS chips than some clones?

5. Experimental results
-----------------------
     The results of some early test were already reported by YU3FK in two
previous messages. The most important information is certainly the capacity
of the link, which was experimentally measured as 8.7kbps of useful data
(not including headers, address information and acknowledge packets) between
two stations on an otherwise clear channel.
     The theoretical range between two transceivers in free space is around
1000km with medium gain antennas (10dBd). This is about 10dB less than a
link with transceivers with ideal coherent modems could do. The range was
confirmed by a practical experiment: the link 4N3K-12, 4N3L-12, 99km apart,
operated reliably with an additional 20dB attenuator in the antenna cable.
     The single channel, CSMA network allows us to do something we did not
even think about. It alows us to monitor the propagation conditions on 1.2GHz.
With good propagation conditions we noticed connections between nodes that
do not have a common visibility nor antennas oriented in the rigth direction.
Although these effects are a nuisance for a packet-radio network, they can
be easily made unharmful by a correct setting of TheNet parameters.
     Additional information about our network is being prepared, including a
new map. We intend to publish all the circuit diagrams and other details of
our network in popular magazines.
                              73 de Matjaz YT3MV

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

Date: 28 Mar 91 05:39:43 GMT
From: sdd.hp.com!spool.mu.edu!munnari.oz.au!manuel!csc.canberra.edu.au!echo![e-mail]
To: [e-mail]

References <[e-mail]>, <skcm.669696397@ise>, <[e-mail]>
Subject : Re: ? how to route with tcpip

In <[e-mail]> [e-mail] (Bill Gunshannon) writes:

>In article <skcm.669696397@ise>, [e-mail] (Carl Makin) writes:
>>
>> We have another problem here in Australia.  IP routing isn't legal over the
>> air. (Yet, we're trying)

>How is this possible??  IP Frames are nothing but data stuffed inside AX25
>frames.  I can't see how routing can be illegal if the data is legal in a
>point-to-point situation.  Can you possibly explain why it is illegal??

It comes down to the addressing requirements we have.  Our regs state that
each packet must have;
The callsign of the originating station,
The callsign of the destination station, and (where different from one above)
the callsign of the station transmitting the packet.

When IP routing each packet only has the transmitting station's call and
the call of the next station in the routing chain.  DoTC doesn't recognise
IP numbers as valid addresses.

NOTE: We're not just suffering with TCP/IP.  NET/ROM and so on are all
illegal under our rules. :-(  We have BIG digipeater chains. :-(

We aren't limited to only using AX.25.  There is no protocol as such defined
in the regs.  As long as we follow the callsign requirements listed above
we can use anything.  (That actually means V3 is legal in Aus. :-)

This rule was enacted before NET/ROM, TCP/IP, ROSE etc came along (or were
very widespread) and at the time it was meant to be as lenient as possible
while maintaining the identification requirements that the local administration
so loved. :-(

There has since been a slight relaxation of the above rules and now on a
backbone link which has NO user access only the transmitting station has
to identify.  (That's not what the rule says but is how it's being
interpreted by DoTC regional offices. ) (DoTC, Department of Transport and
Communications.  Our equivelant of the FCC.)  The relaxation allows ROSE
to be used, but only where a SEPARATE interlinking frequency between nodes
is used. :-( )

Also NET/ROM L3 operation is legal so long as the end points in the chain
are using L3 capable equipment.  ie using NET/ROM between (say) two G8BPQ
nodes or MSYS BBSs or NET (KA9Q) stations and routing is legal but no user
can come in or go out at L2. :-(

There is actually going to be a meeting of packet people here in Canberra
in April which was called by the WIA (Wireless Institute of Australia, our
ARRL. :-) which is going to try and sort out these stupid problems and set
some sort of guide to packet's future in Australia.  Hopefully solutions
to these problems will be sorted out then.

>PS.  I have the same problem here (kinda).  But once we get a router set up
>in a high location, I suspect these problems will go away (thanks to RSPF.)

These problems are typical of any mountainous area. :-(


Carl,
[e-mail]
[e-mail]
3:620/241.7
[44.136.0.5][14][16] PC/BBS/Xenix.

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

End of Packet-Radio Digest
******************************
Date: Fri, 29 Mar 91 04:30:07 PST
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Reply-To: [e-mail]
Subject: Packet-Radio Digest V91 #75
To: packet-radio


Packet-Radio Digest         Fri, 29 Mar 91       Volume 91 : Issue  75

Today's Topics:
              NOS for ATARI ST ?
             Packet Networks in NE U.S.A.

Send Replies or notes for publication to: <[e-mail]>
Send subscription requests to: <[e-mail]>
Problems you can't solve otherwise to [e-mail].

Archives of past issues of the Packet-Radio Digest are available
(by FTP only) from UCSD.Edu in directory "mailarchives/packet-radio".

We trust that readers are intelligent enough to realize that all text
herein consists of personal comments and does not represent the official
policies or positions of any party.  Your mileage may vary.  So there.
----------------------------------------------------------------------

Date: 28 Mar 91 07:30:14 GMT
From: bloom-beacon!eru!hagbard!sunic!news.funet.fi![e-mail]
Subject: NOS for ATARI ST ?
To: [e-mail]

    Hello ,
does anybody know where to find NOS ( ka9q ) for
the atari st series computers ? I prefer FTP site
name but can accept also floppies ( 3.5 or 5 1/4) .

My ST has 1 Mb and it has no other use, so I'd like
to set it as NOS node, my PC makes too much noise

        73 de OH3LKU

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

Date: 28 Mar 91 09:08:55 GMT
From: dog.ee.lbl.gov!ncis.tis.llnl.gov!lll-winken!elroy.jpl.nasa.gov!sdd.hp.com!zaphod.mps.ohio-state.edu!rpi!clarkson![e-mail]
Subject: Packet Networks in NE U.S.A.
To: [e-mail]



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

Date: (null)
From: (null)
For maps, operational info, and newsletter information write to
NEDA Box 563 Manchester NH 03105.

Associate membership is $15/year for US
Members receive the NEDA Quarterly 4 times annually.  This includes
membership roster, board of directors meeting minutes, tech and network
articles, 6 or more pages of maps, etc etc.
Members also receive the NEDA Annual Membership Package which is a
operation manual for the network, including theory and node construction
info.
New members, server ops and node ops are welcome.  The club is starving
from lack of administrative talent and also has lots of room for
technoids.

NEDA currently has 240 members.  The club managed network consists of
37 multiport TheNET node sites with about 140 radios/TNCs.  The network
exists in Buffalo, Rochester, Syracuse, Elmira, Utica, Albany, Poughkeepsie,
(New York);  Springfield MA, north of Hartford CT, All of southern NH and
the northern Boston metro area.  Expansion is welcome and is occuring.
Redundant projects are encouraged.

The network is utilized for DxClusters, BBS forwarding, users accessing
the above, Games, Callbook servers, conferences, chatting etc.. 24 hours
a day with no restrictions except that all users have equal priority and
servers are supported via dedicated access ports only.  In other words
servers don't exist on user access frequencies.  The user must connect
into the network, then to the server's access node, then to the server.

The next board of directors meeting is Jan 26th in Keene NH.  Board
meetings are open to voting members only ($25/year).  Upgrades are
available at the meeting.

THe club uses dues money to fund documentation and projects to create
custom hardware neccesary for network construction.  The most recent
club project is the Hexipus which is a 6 way diode matrix board.  Send
a SASE to the club POBox for more information.


Attn stations who email to me at clarkson:  I have gotten a few email
messages that I have not been able to return due to routing difficulty
from clutx.clarkson.edu.  If I don't return your mail try sending me
your mailing address so I can send you off a postcard or letter.

Also I and several other NEDA members, officers atc.. will be at Dayton.
Look for the guys carrying around ICOM 1200Mhz HTs and wearing NEDA badges.
We'll have a flea market space for giving out propaganda but I don't have
the number for the space.  Some of the NEDA people will be using 147.135/r
for talkaround in the evening.

                Tadd, KA2DEW - NEDA Editor

[ KA2DEW @ KA2JXI.#NNY.NY.USA.NA                - Tadd Torborg             ]
[ [e-mail]                   - 26 Maple St - PO Box 330 ]
[ NEDA (North East Digital Association) Editor  - Colton, NY 13625         ]
[ Clarkson University                           - 315-262-1123             ]

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

Date: 28 Mar 91 15:27:27 GMT
From: [e-mail]
To: [e-mail]

References <skcm.669696397@ise>, <[e-mail]>, <skcm.670138783@ise>
Subject : Re: ? how to route with tcpip

A relatively simple modification to the net/rom implementation (not even
to the protocol) may fix your problem: if the last station in a
forwarding chain were to cause the packet to exit to AX.25 level-2
appearing to have been digipeated from the last station, rather than
having the last station spoof the callsign of the originator, wouldn't
that fix it with DoTC?

I've done a tiny bit of experimentation with that scheme, and as far as
I can see, its only side effect is that it causes the station connected
to to set its FRACK up by one digipeat - which is usually a desireable
thing, since most users have their FRACK set 'way too short anyway.

You can make that mod to TheNet and NOS reasonably easily, I would
guess.  Changing silicon net/rom is nearly impossible, though.
    - Brian

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

Date: 28 Mar 91 19:47:14 GMT
From: epic![e-mail]
To: [e-mail]

References <skcm.669696397@ise>, <[e-mail]>, <skcm.670138783@ise>
Reply-To : [e-mail]
Subject : Re: ? how to route with tcpip

In article <skcm.670138783@ise>, [e-mail] (Carl Makin) writes:
|> It comes down to the addressing requirements we have.  Our regs state that
|> each packet must have;
|> The callsign of the originating station,
|> The callsign of the destination station, and (where different from one above)
|> the callsign of the station transmitting the packet.

This is an interesting list of requirements, because it would also
seem to outlaw BBSes as they are commonly used. When you read a
message from a local BBS, the AX.25 frames on the channel contain only
the callsigns of the BBS and the user. The callsign of the originator
of the message being read or transferred is given only in the header
of the message when it is passed as data; it does not appear in the
AX25 address header.

So by strict interpretation of these regulations, only pure
datagram-oriented packet radio networks are legal, and all link and
network layer addresses used in the network have to be callsigns.
There can be no connection-oriented gateways within the network.
Furthermore, all end systems (hosts) attached to the network have to
be single-user, i.e., used only for sending messages originated by the
local user of that host - no forwarding of BBS traffic, and no
"server" BBSes. Is this true?

Carl, I hope you can get these restrictions lifted...

Phil

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

Date: 29 Mar 91 04:42:52 GMT
From: usc!samsung!munnari.oz.au!manuel!csc.canberra.edu.au!echo![e-mail]
To: [e-mail]

References <[e-mail]>, <skcm.670138783@ise>, <[e-mail]>
Subject : Re: ? how to route with tcpip

In <[e-mail]> [e-mail] (Brian Kantor) writes:

>A relatively simple modification to the net/rom implementation (not even
>to the protocol) may fix your problem: if the last station in a
>forwarding chain were to cause the packet to exit to AX.25 level-2
>appearing to have been digipeated from the last station, rather than
>having the last station spoof the callsign of the originator, wouldn't
>that fix it with DoTC?

Not entirely.  There is still the L2 uplink from the originating user to
the first node.  We would have to do a reconnect (or something similar)
with the destination node in the digipeat field and so on.  It get's messy. :-(

>You can make that mod to TheNet and NOS reasonably easily, I would
>guess.  Changing silicon net/rom is nearly impossible, though.

Is there an english version of TheNet (source) available yet?

Carl,
[e-mail]
[e-mail]

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

Date: 29 Mar 91 04:47:29 GMT
From: usc!samsung!munnari.oz.au!manuel!csc.canberra.edu.au!echo![e-mail]
To: [e-mail]

References <[e-mail]>, <skcm.670138783@ise>, <[e-mail]>
Subject : Re: ? how to route with tcpip

In <[e-mail]> [e-mail] (Phil R. Karn) writes:

>In article <skcm.670138783@ise>, [e-mail] (Carl Makin) writes:
>|> It comes down to the addressing requirements we have.  Our regs state that
>|> each packet must have;
>|> The callsign of the originating station,
>|> The callsign of the destination station, and (where different from one above)
>|> the callsign of the station transmitting the packet.

>This is an interesting list of requirements, because it would also
>seem to outlaw BBSes as they are commonly used. When you read a

No it doesn't.  The regs relate to the packet.  Not it's content.  A
packet's content is controlled by the third party regulations. (Another
can of worms. :-( ) Interestingly we are allowed fully unattended operation
on packet, RTTY and AMTOR on all legal frequencies.  When these regs were
produced, the guy writing them really tried to make it as free and easy
as he could.  Unfortunately we got nailed by a technicality. :-(

>So by strict interpretation of these regulations, only pure
>datagram-oriented packet radio networks are legal, and all link and
>network layer addresses used in the network have to be callsigns.
>There can be no connection-oriented gateways within the network.

Not exactly.  The regs only say that the callsigns must appear in the packet.
There is nothing about what form the addressing must be.  For example;
suppose we have a sliding window protocol carried over AX.25.  In this
situation it is possible for data from several stations be carried by
the 1 AX.25 packet.  As long as the callsigns of ALL stations having info
in this packet appear somewhere within the packet as well as the callsign
of the transmitting station and the callsigns of any stations receiving data
from this packet (eventually) the packet is legal.

It all comes down to the definition of "originating station" and "destination
station".  The regs were designed when digipeating was the only way of
extending your range (ignoring normal repeaters) and the definition seems
to be that you are an originating station if your station initiated the
sequence of actions which resulted in a packet being sent. <phew FX Wipes Brow>
ie. I connect to the NET/ROM node and issue a connect to another node, so this
circuit between the two nodes is said to be originated by me.

>Furthermore, all end systems (hosts) attached to the network have to
>be single-user, i.e., used only for sending messages originated by the
>local user of that host - no forwarding of BBS traffic, and no
>"server" BBSes. Is this true?

Again, not exactly.  The status of multiple users at a single site is still
unclear however any message appearing on our network must either originate
from an amateur or be checked by one and manually forwarded into the network.

BBS Traffic is legal however I'm not sure about
the status of something like making (say) the US callbook available off
CD-ROM.  I could certainly post it as messages as then it comes from an
Amateur but I might have to certify I had read the entire database and
certified it for packet. :-(

Remember that packets themselves and message traffic are viewed as separate
entities by DoTC.  Message traffic is controlled by our third party regs
while packet has a separate mention.


>Carl, I hope you can get these restrictions lifted...

So do I
<crossed fingers>

Thanks for the reply.  You've given me much to think about. :-)

Carl
[e-mail]
[e-mail]

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

End of Packet-Radio Digest
******************************
Date: Sat, 30 Mar 91 04:30:05 PST
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Reply-To: [e-mail]
Subject: Packet-Radio Digest V91 #76
To: packet-radio


Packet-Radio Digest         Sat, 30 Mar 91       Volume 91 : Issue  76

Today's Topics:
             Beginners's Question
               Help with NETPC!
           Wanted : Proceedings of 5th CNC

Send Replies or notes for publication to: <[e-mail]>
Send subscription requests to: <[e-mail]>
Problems you can't solve otherwise to [e-mail].

Archives of past issues of the Packet-Radio Digest are available
(by FTP only) from UCSD.Edu in directory "mailarchives/packet-radio".

We trust that readers are intelligent enough to realize that all text
herein consists of personal comments and does not represent the official
policies or positions of any party.  Your mileage may vary.  So there.
----------------------------------------------------------------------

Date: 29 Mar 91 17:00:29 GMT
From: swrinde!cs.utexas.edu!wuarchive!emory!wa4mei!ke4zv![e-mail]
Subject: Beginners's Question
To: [e-mail]

In article <[e-mail]> [e-mail] (Paul J. Dujmich) writes:
>
>    Now......another beginers question. I connect to a local digi, and
>issue the "N" (NODES) command. The digi sends me back a list of "nodes"
>that it has access to. Is this node list just a list of stations using
>the digi at any given time, or are the nodes something special? I notice
>that all nodes listed have aliases. Is this what makes them a node.
>If I connect to station X through this digi, does that make me one of
>the digi's nodes? I am sort of confused about this point. I am aware that
>any station's TNC can be used as a digipeater, provided that DIGIPEAT is
>ON. Maybe the digi's node list is really it's MHEARD list in that those
>are the stations that *it* can actually hear.
>
>Is there any difference between    c w3cyo-2
>                                     ( connected ok)
>                                   n  (get his nodes) (pick no3m)
>                                   c no3m
>                                      (get connected)
>OR
>       c no3m VIA w3cyo-2
>
>I mean, is one method better than the other?

First off a node is a different thing from a digi. A digi listens to the
channel and stupidly repeats any packet it heres on the channel that has
it's call in the next unrepeated digi field. It knows nothing about the
state of any other station on the frequency. It knows nothing about routing.
A node, on the other hand, knows about all it's neighbor nodes. A node
knows how to route a packet to another node by way of intervening nodes.
A node keeps track of it's connected users and the status of outstanding
packets. A node does hop by hop acknowledgement of packets. With a digi,
acknowledgements must travel end to end. Nodes are *usually* a big
improvement over digis. Nodes add to the congestion of a network by
requiring hop by hop acknowledgement packets. Nodes add to the congestion
of a network by periodic route table broadcasts. Nodes can be overwhelmed
by too many circuit requests. Nodes don't offer end to end acknowledgements.
Smarter, more powerful nodes, using a routing protocol like IP, coupled with
an end to end protocol like TCP have the best features for a sustainable
network. I hasten to add that using the TCP/IP package available to
amateurs over a network consisting of a mixture of digis and relatively
dumb TNC2 based nodes can be a source of painful frustration. But if you
are running over a network consisting solely of TCP/IP switches, then
packet becomes much more of a pleasure. Especially if that network
operates at 56 kilobaud. (smug grin)

Gary KE4ZV

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

Date: 29 Mar 91 09:45:11 GMT
From: ucselx!bionet!uwm.edu!spool.mu.edu!munnari.oz.au!darwin.ntu.edu.au![e-mail]
Subject: Help with NETPC!
To: [e-mail]

Hello,
       can somebody tell me where to find a program called NETPC
written by DL1DBT ( I THInK ) . its a tcpip program sporting windows
and color

thanks

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

Date: 28 Mar 91 11:23:26 GMT
From: deccrl!bloom-beacon!eru!hagbard!sunic!mcsun!ukc!acorn![e-mail]
Subject: Wanted : Proceedings of 5th CNC
To: [e-mail]

I'm looking for a copy of the proceedings of the 5th CNC - the ARRL no
longer have stocks and I've failed to find one elsewhere.

Does anybody have a copy surplus to requirements that I could buy,
beg or borrow ?

Thanks,

Adrian (g7hwn)

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

Date: 29 Mar 91 22:37:15 GMT
From: epic![e-mail]
To: [e-mail]

References <skcm.670138783@ise>, <[e-mail]>, <skcm.670222049@ise>
Reply-To : [e-mail]
Subject : Re: ? how to route with tcpip

In article <skcm.670222049@ise>, [e-mail] (Carl Makin) writes:
|> >This is an interesting list of requirements, because it would also
|> >seem to outlaw BBSes as they are commonly used. When you read a
|>
|> No it doesn't.  The regs relate to the packet.  Not it's content.

Okay then, why isn't TCP/IP legal in Australia under the current
rules? The IP datagram occupies the data field of the AX.25 packet,
just as the contents of a message being autoforwarded by a BBS would
occupy the data field of an AX25 packet. In both cases the AX25
address fields give only the callsigns of the immediate transmitter
and the immediate receiver of the packet; in neither case do you have
the callsign of the originating station in each and every packet.

Actually, we could probably solve the immediate problem of IP quite
easily by just adding an option to the IP header to carry the callsign
of the "originating" station for the benefit of the regulations.  The
routers would ignore it. But it would be much better to get the
regulations revised. Good luck.

Phil

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

End of Packet-Radio Digest
******************************
Date: Sun, 31 Mar 91 04:30:09 PST
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Reply-To: [e-mail]
Subject: Packet-Radio Digest V91 #77
To: packet-radio


Packet-Radio Digest         Sun, 31 Mar 91       Volume 91 : Issue  77

Today's Topics:
KA9Q - What is the current release and where can it be found? (2 msgs)

Send Replies or notes for publication to: <[e-mail]>
Send subscription requests to: <[e-mail]>
Problems you can't solve otherwise to [e-mail].

Archives of past issues of the Packet-Radio Digest are available
(by FTP only) from UCSD.Edu in directory "mailarchives/packet-radio".

We trust that readers are intelligent enough to realize that all text
herein consists of personal comments and does not represent the official
policies or positions of any party.  Your mileage may vary.  So there.
----------------------------------------------------------------------

Date: 30 Mar 91 06:19:47 GMT
From: pacbell.com!att!emory!samsung!caen!uakari.primate.wisc.edu!aplcen!wb3ffv![e-mail]
Subject: KA9Q - What is the current release and where can it be found?
To: [e-mail]



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

Date: 31 Mar 91 05:58:30 GMT
From: usc!samsung!munnari.oz.au!manuel!csc.canberra.edu.au!echo![e-mail]
Subject: KA9Q - What is the current release and where can it be found?
To: [e-mail]

>> The current versions are kept on thumper.bellcore.com and are available
>> by anonymous FTP. The directories to search are all under /pub/ka9q.

>Phil is 100% correct, I try and keep all of the latest NOS/NET releases on
>my BBS.  I generally get them within a day or so of there release, so you

In Australia recent releases usually make it to Peter Hallgarton,
VK3AVE's Telephone BBS in Melbourne reasonably soon after they are released.

The number is;
[phone].

Carl,
[e-mail]
[e-mail]
3:620/241.7
[44.136.0.5][14][16]  PC/BBS/Xenix

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

Date: (null)
From: (null)
    Hello,

Phil is 100% correct, I try and keep all of the latest NOS/NET releases on
my BBS.  I generally get them within a day or so of there release, so you
can consider the BBS a good source for TCP/IP code.  I posted the access
information for my BBS here on USENET not long ago, so I won't do it again
yet.  If anybody wants this information, just drop me a note via Email and
I will be glad to mail a copy of the access info to you...


-------------------------------------------------------------------------------
Internet  : [e-mail]     |       Howard D. Leadmon
UUCP      : wb3ffv!howardl              |       Advanced Business Solutions
TELEX     : 152252474                   |       210 E. Lombard St - Suite 410
FAX       : [phone]              |       Baltimore, MD 21202
PACKET    : WB3FFV @ WB3FFV.MD.USA.NA   |       Phone: [phone]

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

Date: 31 Mar 91 05:41:41 GMT
From: usc!samsung!munnari.oz.au!manuel!csc.canberra.edu.au!echo![e-mail]
To: [e-mail]

References <[e-mail]>, <skcm.670222049@ise>, <[e-mail]>
Subject : Re: ? how to route with tcpip

In <[e-mail]> [e-mail] (Phil R. Karn) writes:

>|> >This is an interesting list of requirements, because it would also
>|> >seem to outlaw BBSes as they are commonly used. When you read a
>|> No it doesn't.  The regs relate to the packet.  Not it's content.

>Okay then, why isn't TCP/IP legal in Australia under the current
>rules? The IP datagram occupies the data field of the AX.25 packet,

It all comes down to the definition of "originating" and "destination"
station. I tried to explain it in an earlier message.  Maybe I wasn't
too successful. :-(

>and the immediate receiver of the packet; in neither case do you have
>the callsign of the originating station in each and every packet.

In the case of a BBS forwarding traffic then the BBS is the "originating"
station.  In the case of someone navigating his way thru the network
then HE remains the "originating station" despite how many links may
be carrying his traffic.  The "destination" station BTW seems to be
the station who the "originating" station finally intends to connect to. :-(

So with a BBS forwarding the "originating" and "destination" callsigns
as they seem to be defined are in the packet.

This definition wasn't strictly defined.  It has sort of grown over the
years.  We have real problems here with interpretations of rules between
different offices (Each state office interprets the rules their own way. :-( )
In some state the local DoTC offices actually allowed Ip routing but
complaints from amateurs in other states led to a clampdown on packet from
the Federal office.  Unfortunately the man in charge is a stickler for the
book.  If it's not in the book you can't do it. :-(

>Actually, we could probably solve the immediate problem of IP quite
>easily by just adding an option to the IP header to carry the callsign
>of the "originating" station for the benefit of the regulations.  The
>routers would ignore it. But it would be much better to get the
>regulations revised. Good luck.

Yes that would work as long as both the "originating" and "destination"
callsigns were included.  It's more overhead though and could be significant
over low speed links. (Where 99% of our traffic is)

Carl.
[e-mail]
[e-mail]
3:620/241.7
[44.136.0.5][14][16] PC/BBS/Xenix

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

End of Packet-Radio Digest
******************************