Date: Thu, 25 Nov 93 04:30:02 PST
From: Advanced Amateur Radio Networking Group <tcp-group@ucsd.edu>
Errors-To: TCP-Group-Errors@UCSD.Edu
Reply-To: TCP-Group@UCSD.Edu
Precedence: Bulk
Subject: TCP-Group Digest V93 #305
To: tcp-group-digest


TCP-Group Digest            Thu, 25 Nov 93       Volume 93 : Issue  305

Today's Topics:
                   44.156 subnet routing question.
                         AOL and 9600 access
                 Cellular Data Transmission Standards
                            List New Stuff
                          NOS v. POPmail/PC
                       patent hassles (3 msgs)
       pktd11/pktd11a/pktd11b.zip - Crynwr v11.x packet drivers
                               Replies
                  Subscribe and Unsubscribe (2 msgs)
                      TCP-Group Digest V93 #301

Send Replies or notes for publication to: <TCP-Group@UCSD.Edu>.
Subscription requests to <TCP-Group-REQUEST@UCSD.Edu>.
Problems you can't solve otherwise to brian@ucsd.edu.

Archives of past issues of the TCP-Group Digest are available
(by FTP only) from UCSD.Edu in directory "mailarchives".

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, 23 Nov 1993 13:31:57 +0200 (CET)
From: ARATO@IIF.KFKI.HU (Arato Andras)
Subject: 44.156 subnet routing question.
To: tcp-group@ucsd.edu

Hello,

I tried to send the following letter to Brian Kantor. Maybe he
did not received. Can somebody help me with it?

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

From: IIF::ARATO        "Arato Andras"  3-NOV-1993 11:42
To: SMTP%"brian@ucsd.edu",ARATO       
Subj: 44.156.0.0 routing.

Dear Brian,

I am Andras Arato (HG5BDU)  working in Budapest Hungary  for
the KFKI Research  Institute for  Measurement and  Computing
Techniques. We  have  in our  institute  a B  class  network
(148.6.0.0). The administration is ready to support our  HAM
experiments with our Hungarian 44.156.0.0 subnet.

I saw that some  44.00.00.00 addresses (e.g  44.125.128.131)
are routed through mirrorshades.ucsd.edu. Is it possible  to
route  all  44.156.0.0  addresses  from  you  to  148.6.0.11
(hg5bdu.kfki.hu) which is a JNOS  gate in KFKI? The  amateur
community using  44.156.0.0 subnet  asked me  to direct  you
this question.

73! de Andras.

arato@iif.kfki.hu
 

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

Date: Tue, 23 Nov 93 15:06:28 EST
From: tstader@aol.com
Subject: AOL and 9600 access
To: tcp-group@UCSD.Edu

Those of you that frequent America Online and The Ham Radio Club there... you
can now access AOL via 9600 bps! If you have WAOL (rev. 38) or PCAOL (1.5a),
find your local 9600 bps SprintNet number, change your settings and off you
go.

Mac users will have to upgrade to the latest software (2.1) which will be
released very soon.

Stop by and join the 16,000 (last months count) other visitors to The Ham
Radio Club (keyword = ham radio).

73 for now.... c u on the shortwaves
Terry Stader - KA8SCP
America Online Ham Radio Club Host
Internet: tstader@aol.com (files <28K)  or
          p00489@psilink.com ( files >28K)
KA8SCP@WA1PHY.#EMA.MA.USA.NOAM
ka8scp@ka8scp.ampr.org [44.56.4.82] Mac
ka8scp-1@ka8scp-1.ampr.org [44.56.4.120] DOS Clone
(they're BOTH pc's!)

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

Date: Thu, 25 Nov 93 11:59:22 SST
From: harish@aslsng.csah.com (Harish Pillay)
Subject: Cellular Data Transmission Standards
To: tcp-group@ucsd.edu

This question is not directly related to ham radio, but I figure that
this group will be able to give a good answer.

What are the current cellular data standards that are fighting for dominance?
I have heard of AT&T/McCaw's Cellular Digital Packet Data standard.  I'm
sure there must be more.  Could someone point me to where I can find these?
Preferably in some form akin to a RFC and ftp'able.

Thanks for the assistance.
-- 
Harish Pillay     |  harish@ece.orst.edu 
Corporate Technical Consultant   |  +(65)-371-9820 (work)
CSA Holdings Ltd, 221 Henderson Rd #08-01, |  +(65)-278-1783 (fax)
Singapore 0315, Republic of Singapore.

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

Date: Wed, 24 Nov 93 03:13:52 UTC
From: n2psc@n2psc.UCSD.EDU
Subject: List New Stuff
To: tcp-group@n2psc.UCSD.EDU

Hello Dave,

As you said I feel that when you switch into a new mail area and there
is new mail NOS should list the new mail.  It would be a realy nice
feature to see.  

Also if you reed the message I send out to the group again you will
see other ideas about replacing the old -more- prompt with more of
a PBBS approach.  This is some ideas I had tell me what you think.

After you do a list and about 24 lines go by you would get a more
PBBS look rather than the old more prompt.

Example:

<CR> Continue <A>bort <R #> Read Message..>

Then after you would read a message of some sort the prompt
would follow like the above but with a extra command to 
reply to the message you just read.

Example:

<CR> Continue <A>bort <R #> Read Message <SR> Reply to Message..>

We all know that we would like to reply to messages when they
are fresh in our minds.  So what do you think??? 
Got any better Ideas???

-MIKE-

73 Mike

Tcp/Ip   n2psc@n2psc.ampr.org [44.68.8.44]
AX25     n2psc@n2psc.#nli.ny.usa.na
Internet n2psc@ferron.jvnc.net

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

Date: Thu, 25 Nov 93 12:16:24 CST
From: "Jan Dolejs" <jandol@mbox.fsv.cuni.cz>
Subject: NOS v. POPmail/PC
To: tcp-group@ucsd.edu, nos-bbs@hydra.carleton.ca,

Hello,
I am Jan Dolejs, computer administrator at the Charles University, 
faculty of Social Sciences, Czech Republic, Europe.
I run our faculty site as follows:
    
      +--------+ +--------+                                 +--------+
      ! Novell ! ! 386SX  !   60 386SX PC (30 diskless)     ! 386SX  !
      ! server ! !        !   4 MAC                         !        ! 
      +---+----+ +---+----+    . . . . . . . . . . . .      +---+----+
          !          !                                          ! 
   -------+----------+-------------+----------------------------+------
                                   !
                           +-------+-------+    386SX
                           ! KB r i d g e  !    2x WD8013 EP
                           +---------------+
       !
   -------+-----------------+------+-----------+-----------------+------
          !                 !                  !                 !
    +-----+-----+     +-----+-----+      +-----+-----+     +-----+-----+
    ! 386SX     !     ! 386SX     !      ! 386SX     !     ! C i s c o !
    ! DOS/LINUX !     ! NOS  BOX  !      ! LINUX     !     +-----+-----+
    +-----------+     +-----------+      +-----------+           !
    !- Netwatch       !- BOOTPD          !- NS #1            Internet
    !- DNPAP softw.   !- MBOX #1         !- MBOX#2(smail,elm)
    !- DOS TCPIP app  !- POP3            !- FTP
    !- etc.           !- NS #2           !- NFS
                      !- NNTP
                      !- FINGER
                      !- FTP


 My NOS BOX is built on a KA9Q(PA0GRI,N1BEE) version and I have made little
corrections in BOOTP a NNTP. Almost all PC's in the site are PC 386SX 
(33,25 MHz). When using POPmail/PC(3.2.2) this problem seems to occur:
Within communication of this program and NOS BOX(either SMTP, or POP3) 
the connection of TCP in NOS BOX remains in 'Closing'. I have been trying 
to monitor this situation with TRACE. In this case the file and screen save
misinterpreted time sequences within receiving packets. Consequently, 
I monitored packets with another PC(Netwatch, DNPAP Gobbler). The result
what I come up with are following:


   Client   (POP3prot)  Server            Client   (POP3prot)   Server

                !                                        !
   QUIT-------->!                         QUIT---------->!
                !                                        !
                !<---- +OK Bye,..                        !<---- +OK Bye,..
      ACK------>!                              ACK------>!
                !                                        !
    ACK,FIN---->!                                        !<----ACK,FIN
                !                                        !
                !<----ACK,FIN               ACK,FIN----->!
                !                                        !
       ACK----->!                                        !<----ACK
                !                                        !
                !<----ACK                                !
                !
                !<----ACK,FIN                             TCP connection ends  
                !<----ACK,FIN                             expectivelly
                !      .
                !      .
                !
                      
                 TCP connection remains
                 in 'Closing/Last Ack'  

  For a complete information the state TCP connection in NOS BOX follow:

  Local: 192.108.140.149:pop3  Remote: 192.108.140.148:16200 State:Closing
        Init seq   Unack     Next     Resent  Cwind  Thrsh  Wind Queue Total  
  Send: 2a8fe000  2a8fe2f8  2a8fe2f9      21  1024    1024  2048     1   759
  Recv:    f4240               f4279       1                2048     0    55
  Backoff  19  Retrying Timer running (1430/3795 ms) SRTT 33ms Mean dev 38 ms
 

  Would you be willing to help me with this problem? 
  Where to find the mistake?
  How would you solve this situation?
  
  I assume:
  1) to slow a speed of a PC client hardware down (that is what I have been
     doing but there is a chance students would not pay much attention to 
     avoid the mistake (including myself));
  2) to change a hardware of NOS BOX with a faster one (either procesor or
     disk; the University would not currently be able to afford it);
     
  3) to slow a software of POPmail/PC down (I do not have a source code);
  4) to make some corrections in NOS (I am not an expert in tcp protocol);
  5) to get rid of the mistake (where?).

  I would be very thankfull for any help,
  
  Respectively,
              Jan Dolejs



!
Jan Dolejs                               e-mail: jandol@mbox.fsv.cuni.cz
Faculty of Social Scienses                       root@linux.fsv.cuni.cz
Charles University,Prague
Smetanovo nabrezi 6
Prague 1
Czech Republic,Europe

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

Date: Tue, 23 Nov 93 00:13:45 -0800
From: Phil Karn <karn@unix.ka9q.ampr.org>
Subject: patent hassles
To: tcp-group@ucsd.edu

Just to give you an idea of how silly this whole patent business would be
if it weren't all so serious, it is my understanding that Spectrum Information
Technologies (the company that John Scully just took over) claims a patent
on the concept of varying the block size of a link level protocol in order
to optimize its performance over poor radio links. This is a principle that
has long been obvious to even the most appliance-oriented amateur packet
radio operator (especially those on HF) but apparently it was new to the
patent office.

They also claim rights to using forward error correction, despite the fact
that it's been around almost as long as I have.

Phil

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

Date: Mon, 22 Nov 1993 22:35:29 -0800
From: karn@qualcomm.com (Phil Karn)
Subject: patent hassles
To: tcp-group@ucsd.edu

Anyone who reads the trade press or was at Comdex last week knows that
the world at large has finally discovered "wireless" communications.
(Amazing that the marketeers could take a quaint word for "radio" that
has been obsolete since the early 1900's and make it sound so high
tech!) Now we are seeing the beginning of an explosion in commercial
packet radio services, including Ardis, RAM, and now CDPD (Cellular
Digital Packet Data). And we hams can be proud that we helped blaze
the trail over the past decade. Even if the commercial guys haven't
given us much credit.

That's the rub. I'm afraid that Proxim's bogus patent on my MACA
scheme may be only the beginning of a very nasty trend.

Unfortunately, the present policy of the US Patent and Trademark
Office seems to be to grant virtually any patent application that
comes in over the transom, no matter how trivial or obvious to someone
skilled in the state of the art. (If you were truly skilled in the
state of the digital radio art, would you work as a patent examiner
for one half or one third of the salary you could get in private
industry? Especially if, like most talented engineers, you actually
want to *build* things?)

Patent office searches of the "prior art", never particularly thorough
in a rapidly moving field like digital radio, are now hopelessly
inadequate. My ARRL CNC article clearly would have stopped the Proxim
patent, for example, but obviously they don't read ARRL publications.
The Patent Office supposedly searches at least the prior patents in a
field, but I've even heard of a case in which two patents were granted
at different times to different people on the same invention.

What does all this mean? If we don't want the commercial world to
plant land mines (a great metaphor for patents) all around amateur
packet radio, and worse, stealing our technology as its own, we'll
have to get a LOT better at tooting our own horn. If you come up with
an idea, DOCUMENT IT! Even if, like me, you don't personally believe
in patents. Even if your idea seems trivial, or obvious, or you're too
busy to implement it right away, or it doesn't seem immediately useful
because of practical limitations. Write it down. Post it to the net.
Write an article for QEX or PSR. PUBLISH IT SOMEWHERE!!

This is especially important if you are already discussing the idea
verbally with others. In my case, I had been talking up the ideas
behind MACA for some time before I wrote that paper for the ARRL CNC.
This included people in the wireless industry, which I was (and am)
entirely willing to let use MACA for free.  (E.g., Xerox PARC, which
has been quite gracious in giving me credit.)  I never thought anyone
would be so bold as to try to patent it out from under me. And it was
only dumb luck on my part that my CNC paper appeared more than a year
before the Proxim patent was filed. Otherwise I might have had a much
harder time showing the existence of "prior art".

I don't know if logs of public USENET and BBS discussions could serve
as evidence in a patent case, but it certainly wouldn't hurt to keep
them either. I know I have stuff archived from the early days of EIES,
over 10 years ago (the beginning of the Great Virtual Circuit and
Datagram protocol Wars). Finally, a very good reason to be a packrat!
Anybody have extensive logs of rec.ham-radio.packet and its
predecessors?

I (probably) got lucky this time. Next time may be different.

Phil

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

Date: Wed, 24 Nov 1993 10:34:59 -0500
From: goldstein@carafe.tay2.dec.com (k1io, FN42jk)
Subject: patent hassles
To: tcp-group@ucsd.edu

Fortunately, old Usenet discussions are archived!

The "QRZ" CD-ROM from Walnut Creek CDROM has several years of old
rec.radio.amateur messages on it.  Yes, you can relive the old flame
wars of the eighties in the privacy of your very own home just by
buying this one little CDROM, which also has many forms of NOS, etc.
on it (the entire UCSD archive hamradio snapshot).

I suspect that amongst the thousands and thousands of messages there,
you can find some of Phil's MACA discussions.  Of course I suggest a
triple-speed CDROM player and a fast computer; there's a lot to search!
The CDROM includes a message title index file, but it's megabytes long.

I suppose this counts as "publishing", since the CDROM messages have
dates in them.  But I suppose that's up to the courts to decide.
   fred k1io

(PS - I'm not opposed to valid patents.  I play the game myself.
But I agree that it's preposterous to patent the obvious, or prior
art, as your own.)

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

Date: Tue, 23 Nov 93 00:24:07 EST
From: nelson@crynwr.com (Russell Nelson)
Subject: pktd11/pktd11a/pktd11b.zip - Crynwr v11.x packet drivers
To: MSDOS-Ann@SimTel.Coast.NET (MS-DOS upload announce)

I have uploaded to the SimTel Software Repository, available by anonymous
ftp from the primary mirror site OAK.Oakland.Edu (141.210.10.117) and its
mirrors:

pub/msdos/pktdrvr/
pktd11.zip      Crynwr v11.x packet drivers executables & docs
pktd11a.zip     Crynwr v11.x packet drivers source, part 1of2
pktd11b.zip     Crynwr v11.x packet drivers source, part 2of2

The packet drivers are for PC's running MS-DOS.  They hide the
differences between Ethernet cards, and allow multiple protocols to
have simultaneous access to the same card.  Benefits of the Crynwr
Packet Drivers over competing drivers:

  o One stop shopping.  Collection includes drivers for most popular cards.
  o Small memory footprint.
  o Supported by many commercial and freely-copyable packages.
  o Source for all drivers is always available.
  o Support is available for a fee.
  o Programming specification is included.
  o Sample source code is included.

The Crynwr Packet Driver Collection contains the same software as the
former Clarkson Packet Driver Collection.  Crynwr Software owns the
copyright.  The permissions on the copyright remain the same.  Clarkson
is out of the packet driver business.

Summary of changes in the 11.x release:

        New drivers: Aquila, Kodiak, Eagle NE2100 (&NE1500), Exos 205T
                Thomas-Conrad TC5045, Parallel port to Parallel port,
                Ottawa PI, Vaxmate, Racal-Datacomm es3210, 3Com
                EtherLink III, SMC (formerly Western Digital)/IBM
                Ethernet/A, Zenith Z-Note, Cabletron DNI Exxxx and Mylex.
        New utility: pktwatch.
        New switches added (-p to disable promiscuous mode, -u to
                uninstall, -i to select class 11 if available).
        Intel Netware driver (PDIPX) is now included.
        Bug fixes in all drivers, including the key/mouse lossage for 8390-
                using drivers (ne1/2000, smc_wd, hppclan, 3c503).
        Parameters changed: 3c503, 3c505, 3c507, winpkt

Uploaded by the author.

The 11.x packet driver release obsoletes the following files:
3c509a.zip, at1500.zip, at1700.zip, drivers.zip, drivers1.zip,
drivers2.zip, drivers3.zip, exp16104.zip, and znote.zip.

- -
-russ <nelson@crynwr.com>      ftp.msen.com:pub/vendor/crynwr/crynwr.wav
Crynwr Software   | Crynwr Software sells packet driver support.
11 Grant St.      | 315-268-1925 (-9201 FAX)       | Quakers do it in the light
Potsdam, NY 13676 | LPF member - ask me about the harm software patents do.

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

Date: Wed, 24 Nov 93 03:12:23 UTC
From: n2psc@n2psc.UCSD.EDU
Subject: Replies
To: tcp-group@n2psc.UCSD.EDU

Along with Dave I feel that we should have replies going back to the
group.

73 Mike

Tcp/Ip   n2psc@n2psc.ampr.org [44.68.8.44]
AX25     n2psc@n2psc.#nli.ny.usa.na
Internet n2psc@ferron.jvnc.net

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

Date: Tue, 23 Nov 93 22:12:20 PST
From: Bill Healy <healy@ee.unr.edu>
Subject: Subscribe and Unsubscribe
To: tcp-group@ucsd.edu (tcp-group)

> In article <9311221246.AA13637@sabea-oc.af.mil> you write:
> >I notice a lot of people are using the publication to do
> >their subscription requests.  Are these people just stupid or
> >is the software broken causing them to revert to this?
> 
> No, the software isn't broken.  These people are simply clueless.
> Get used to it; as the network encompasses more people, more clueless
> people will be included.  Fact of life.
> 

Don't these people automatically get subscribed to the 'clueless' list? 

Bill

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

Date: Thu, 25 Nov 93 2:31:04 CST
From: jim@rwsys.lonestar.org (James Wyatt KA5VJL)
Subject: Subscribe and Unsubscribe
To: TCP-Group@UCSD.EDU

> >I notice a lot of people are using the publication to do
> >their subscription requests.  Are these people just stupid or
 [ ... ]
> No, the software isn't broken.  These people are simply clueless.
> Get used to it; as the network encompasses more people, more clueless
> people will be included.  Fact of life.
> 
> [Remember that the next time you get an urge to spread networking among
> the masses.  Humans are the only animals who s**t where they eat.]

Brian! We just got over the fact that "some of us" have this sent over
packet radio (or was that another list for nos? 8{) and you profane our
netwaves with this (very accurate) observation.

Could we consider putting a header at the front about refraining from
language that disallows automagic routing via packet? (or RTTY? 8{)
-- 
James Wyatt  KA5VJL  jim@rwsys.lonestar.org  Will do MultiMedia for food...
Now working on digital cameras and digital RF transponders for a railroad.

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

Date: Tue, 23 Nov 1982 08:11:37 +119304028 (CST)
From: schellew@wu1.wl.aecl.ca (Wayne Schellekens)
Subject: TCP-Group Digest V93 #301
To: TCP-Group@UCSD.EDU

> > 1). kf0ox posted a message on the ax.25 bbs network about someplace
> >     in Kansas, Mo. selling 'their' 2 watt data radios for $90. Is
> >     TEKK located in Kansas, Mo? Anyone have a number for them? If not,
> >     does anyone know someone in Kansas, Mo. that sells TEKK radios for
> >     $90?
> 
> 1-800-521-TEKK
> 

Could someone in the USA please call the number and find out their
'non' 1-800 number?  The 1-800 number does not work from Canada.

Thanks.
Wayne

-- 
Wayne Schellekens, VE4WTS          Internet: schellew@wu1.wl.aecl.ca
AECL Research                         AX.25: VE4WTS@VE4KV.#WPG.MB.CAN.NA 
Whiteshell Laboratories        Twisted pair: (204)753-2311 x2317
PINAWA, MB  Canada  R0E 1L0             Fax: (204)753-2455

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

End of TCP-Group Digest V93 #305
******************************
******************************