Date: Tue, 28 Sep 93 04:30:04 PDT
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 #251
To: tcp-group-digest


TCP-Group Digest            Tue, 28 Sep 93       Volume 93 : Issue  251

Today's Topics:
                     Baycom/NOS packet interface
                       HACKER ALERT: correction
                     Please be warned, intruders
                                 RIP
                           SMTPSERV.C Bug !
                      TCP-Group Digest V93 #250
                           TheNet X1? users
                  What to put on a CD-ROM? (2 msgs)
                     Why I hate patents (5 msgs)

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: Mon, 27 Sep 93 15:02:15 PDT
From: Glenn Engel <glenne@lsid.hp.com>
Subject: Baycom/NOS packet interface
To: tcp-group@ucsd.edu

Hi,

Does anyone have a pointer to some interface software for the Baycom 
modem which implements the low level interface needed by NOS ?  

I have a small (2.25x4.5") processor board which would make an ideal 
portable/remote packet system when combined with the Baycom modem hardware
running NOS.

Alternatively, a pointer to similar level 2a protocol software would be
helpful.

Thanks,

--
Glenn 

 --------------------------------------------
|          ___         |                    |
|         /  /         | Glenn R. Engel     |
| HEWLETT/hp/PACKARD   | (206) 335-2066     |
|       /__/           | NN7N               |
|   Lake Stevens       |                    |
| Instrument Division  | glenne@lsid.hp.com |
 --------------------------------------------

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

Date: Tue, 28 Sep 1993 00:45:48 +0100
From: "Fred N. van Kempen" <waltje@hacktic.nl>
Subject: HACKER ALERT: correction
To: tcp-group@ucsd.edu

Gerard PA0GRI @ CDC.COM comments on my note:

> >Hey, this is good news!  After you published it, make sure to
> >zap all old driver archives... I still find "drivers.arc" at
> >a lot of sites :-)
> >
> He is not in the position to do such things..

Hmm, why not?  He is the principal maintainer of the packet driver
collection, isn't he?  Of course, that doesn't mean that he *owns*
the stuff, but zapping any old stuff would be in the general inte-
rest, I think.  Correct me if I am wrong...

> >Cheers, Fred NL0WLT
>               ^^^^^^ now that looks like a call sign to many of us, it is
> just usable on dutch CB radio (where also packet is used)

Yes, that is correct.  I am busily studying for the normal license,
but until then (getting ready for next exam...) I will have to put
up with CB-Packet.

Note that this does not in any way mean that I am a grunt on the
topic of packet (just don't ask me to decode CW as I hear it...),
I have been involved in Packet and assorted stuff since 1989. I
also wrote the TCP/IP stack for Linux, and am implementing kernel-
based AX.25/NETROM suport for the latter right now.  I run a 4-
channel CB-Packet relay station here...

> The use of NOS (pa0gri nos and its many derivatives) outside HAM and
> educational institutions is actualy a nono. (see Copyright notes)

Ahhh.  And you are one of those people who consider CB people to be
lowlife, right?  I don't want to go into any sort of a flame here,
but I *do* think that *certain* (not *all* !) kinds of CB people
can be considered at least entry-level HAM's.

Comments regarding this to me personally please, will summarize if
the need arises from any party.

> It is noted that hacktic.nl users are HACKERS (the wrong kind !)
> Please be alerted on them.
Oh, dear.  If I am such a dangerous hacker, why do I have legitimate
sys admin access on a *NUMBER* of Internet sites accross the world,
including MILNET sites?  They all screened me, and found me to be OK.

The fact that my return address says ".hacktic.nl" doesn't automatically
mean that I am dangerous, Gerard.

Some info to correct your statement:

- Hack-Tic is a hacker's magazine in The Netherlands.  I agree that
  some of the people involved are have an at least dubious background.

- The Hack-Tic Network is a low-cost UUCP-based network in our country,
  making E-mail and Usenet available to people who cannot afford the
  cost of an NLnet link.  I will not go into this further - check your
  archives for comments on European networking costs.

- The Hack-Tic XS4ALL machine is a public access machine connected to
  the Internet, based on low-cost operation.  It supports normal shell
  access, BBS access and UUCP/SLIP access.  I am one of the people of
  the XS4ALL Support Team which maintains the system.

WHile it is true that some hackers ("of the WRONG kind") indeed can be
a true pain in the *ss, it is also true that not all people accessing
this machine are of that class.  Many people (me included) simply use
it to access the Internet on a legit basis, for sending mail, xferring
files and the lot.  What's wrong with this?

I am a guy interested in Packet Radio, and because of that I currently
devote my spare time into writing P-R software for the Linux operating
system.  Brian Kantor is aware of this - he told me that he quit the
same project (using 386bsd UNIX), so I started doing it for Linux. The
fact that (a) I am not a licensed HAM, thus having to revert to CB
packet, and (b) me using a public access machine for Internet mail
shouldn't upset too many of you guys out there, right?

Cheers,
 Fred N. van Kempen, NL0WLT
 waltje@uwalt.nl.mugnet.org
 waltje@sunsite.unc.edu
 waltje@nmrdc1.nmrdc.nnmc.navy.mil
 waltje@erc.msstate.edu
 waltje@aris.com
 waltje@muncca.fi
 waltje@hacktic.nl                   - want more addresses?
--
Fred N. van Kempen                             Certified Linux/PRO Engineer :-)
Mississippi State University Network Support             waltje@ERC.MsState.EDU
ARIS Technologies, Inc <=> Linux/PRO Development                waltje@aris.com

 Ze zijn terug, en niet terug gefloten,   (JazzPolitie)
  Hetzelfde slag, dezelfde vlag, hetzelfde lied.
 Ze zijn terug, en niet terug gefloten,
  dezelfde steen, en toch nog weer gestoten!
  dezelfde steen.................. (fade)

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

Date: Mon, 27 Sep 93 16:49:20 +0100
From: pa0gri@tophat.cdh.cdc.com
Subject: Please be warned, intruders
To: tcp-group@ucsd.edu

Body-Part: 1; forwarded -------------------------------------------------

Received: from ucsd.edu by tophat.cdh.cdc.com (5.61/1.34) id AA03453; Mon, 27 Sep 93 15:04:55 +0100
Received: by ucsd.edu; id AA27157
 sendmail 5.67/UCSD-2.2-sun
 Mon, 27 Sep 93 03:58:46 -0700
Errors-To: tcp-group-relay@ucsd.edu
Sender: tcp-group-relay@ucsd.edu
Precedence: List
Received: from xs4all.hacktic.nl by ucsd.edu; id AA27151
 sendmail 5.67/UCSD-2.2-sun via SMTP
 Mon, 27 Sep 93 03:58:41 -0700 for /usr/mail/listhandler tcp-group
Received: by xs4all.hacktic.nl id AA08829
  (5.65c/IDA-1.4.4 for tcp-group@ucsd.edu); Mon, 27 Sep 1993 11:56:32 +0100
Date: Mon, 27 Sep 1993 11:56:32 +0100
From: "Fred N. van Kempen" <waltje@hacktic.nl>
Message-Id: <199309271056.AA08829@xs4all.hacktic.nl>
To: nelson@crynwr.com, tcp-group@ucsd.edu
Subject: Re: What to put on a CD-ROM?
Body-Part: 1.1; Text
>
>Russ writes:
>
>> I'm putting together a CD-ROM of packet driver software.  I see all
>> these different versions of NOS being published, but I've only ever
>> run Phil's version.  Could someone tell me what versions of NOS to
>> put on it besides ucsd.edu:hamradio/packet/tcpip/ka9q/rcsdsrc.zip?
Great Russell..
>
>Hey, this is good news!  After you published it, make sure to
>zap all old driver archives... I still find "drivers.arc" at
>a lot of sites :-)
>
He is not in the position to do such things..
>Anyway, I guess you'd have to archive NOS, GRINOS, JNOS, WNOS
>, PE1CHL, WAMPES, and some others.  All of them have something
>special, and each of them has a typical use (although I am a
>big fan of Johan's JNOS...)

>Cheers, Fred NL0WLT
              ^^^^^^ now that looks like a call sign to many of us, it is
just usable on dutch CB radio (where also packet is used)
The use of NOS (pa0gri nos and its many derivatives) outside HAM and
educational institutions is actualy a nono. (see Copyright notes)
It is noted that hacktic.nl users are HACKERS (the wrong kind !)
Please be alerted on them.

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

Date: Mon, 27 Sep 93 9:59:14 CDT
From: jwhite@cuscus.mecc.mn.org (Jeff White)
Subject: RIP
To: tcp-group@ucsd.edu

Chuck Bland Said:
>At one time I remember seeing some config notes on RIP and RSPF in NOS.
>
>Anyone have pointers where they might be ?
>

I suppose while we're at it, I can announce RIP-2.  I've completed
implementing RIP-2, RFC1388, for JNOS.  It replaces the RIP code in
NOS, and implements both RIP-1 and RIP-2.  It also has many additional
features that RIP lacks.  These include: routing domains,
authentication, carrying the proper network mask, better logging and
tracing, selective filtering, proxy rip broadcasting, and new
documentation.

I will put the code and documentation up on UCSD tonight.  Consider
the code to be beta.  While it has been tested, bugs may still lurk.
Please report any problems, questions, or bugs to me.

73

-- 
Jeff White, N0POY                       MECC Senior Programmer 
INTERNET:  jwhite@hydra.n0poy.ampr.org  ICBMNET: 45^2', 93^13'
SKIPNET:   n0poy@tcman.#msp.mn.usa.noam USENET:  jwhite@cuscus.mecc.mn.org
PHONENET:  612-569-1714

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

Date: Tue, 28 Sep 93 02:12:54 EDT
From: "Barry Siegfried (Wayne, NJ 07470) [44.64.0.100]" <k2mf@k2mf.ampr.org>
Subject: SMTPSERV.C Bug !
To: tcp-group%ucsd.edu@wg2w.njit.edu

To the group...

I have uncovered a "feature" of the SMTP server in JNOS which
results in a real problem under a certain series of circumstances
where the "feature" is not meant to operate, but rather, another
set of operations should be taking place instead with respect to
the interpretation of mail headers by NOS.

The Feature
-----------
Johan (WG7J) put some code into SMTPSERV.C, which replaces any
period "." characters in the user field of an SMTP mail header
that is required to be interpreted by a NOS machine, with forward
slash "/" characters.  The idea here, according to the comment in
the source code, was to give NOS the ability to write mail into
mailfiles that exist in subdirectories underneath the standard
/spool/mail directory (or whatever other directory is defined
in the program as "Mailspool").

In other words, if a piece of mail arrives at a NOS machine (called
"nos.machine") addressed to:  subdir.user@nos.machine, NOS will
parse the user field into:  subdir/user, which will then be used
to write into the mailfile:  /spool/mail/subdir/user.txt.  In order
for this to work, however, subdirectory "subdir" must already exist
in the /spool/mail directory.  If it doesn't, a "mailfile busy" code
will be returned to the SMTP server by DOS when it goes to write the
mailfile, and NOS will then requeue the message to be sent to itself
again on the next smtp kick, with the hope that the "mailfile busy"
condition is only a temporary one.

In reality, what happens is the unattended NOS program enters an
infinite loop because the subdirectory "subdir" is never created
by the user, and this loop will go on ad infinitum, unchecked,
until all of the available disk space is used up on "nos.machine"!
This is obviously a very bad condition to have!

The Problem
-----------
The real problem arises when NOS is required to interpret bang "!"
characters in the user fields of UUCP email addresses.  The fact
is, NOS neither interprets nor parses these characters at all.

It has long been established that a UUCP email address of the form:
"target.machine!user" (where "target.machine" exists in a valid
Internet domain) needs to be converted to the general format:
"user@target.machine" in order to be processed correctly by NOS.
When a piece of UUCP email, addressed to:

"target.machine!user@nos.machine"

arrives at "nos.machine", instead of parsing the bang characters
in the user field correctly, and creating a new .WRK file which
should look like this:

target.machine
sending_user@sending.machine
user@target.machine

NOS instead re-queues the mail to itself (because of the code
described above), and creates a new .WRK file which looks like
this:

nos.machine
sending_user@sending.machine
target/machine!user   <--   note the forward slash "/" character
                            has replaced the period "." character
                            of the target machine name !

Then, every time the smtp timer kicks, NOS simply ends up requeueing
the mail to itself, and this will, within a relatively short amount
of time, cause all of the available disk space to be used up on
"nos.machine"!

The Fix
-------
NOS needs to interpret bang characters in user fields of UUCP
email addresses correctly and then branch around the period
character substitution trick when it detects that it has decoded
a UUCP email address!  Of course, the immediate fix to the source
code is to simply change the forward slash substitution character
to something more benign that will not cause a "mailfile busy"
condition when NOS goes to write the mailfile, but this solution
doesn't solve the real problem of how to correctly deal with UUCP
email addresses in the first place.

On the other hand, when writing the mail, the sender could also
manually correct the "To:" address from:

target.machine!user@nos.machine   - to -
user%target.machine@nos.machine

assuming that the UUCP "target.machine" is in a valid Internet
domain, which would also solve this problem, but not all senders
are wise enough to do this.  And what of special considerations,
such as:

1. Multiple machine hops via UUCP

   At the very least, a UUCP address of the form:

   target.1!target.2!user@nos.machine
   needs to be converted to:
   target.2!user%target.1@nos.machine

   assuming that the UUCP "target.1" machine is in a valid Internet
   domain.

2. UUCP mail via UUNET

   uunet.uu.net is the valid Internet mail gateway machine which
   will accept UUCP addressed mail for forwarding into UUNET.
   It's current IP address is:  [192.48.96.2].

   At the very least, a UUNET UUCP address of the form:

   uunet!target.machine!user@nos.machine
   needs to be converted to:
   target.machine!user%uunet.uu.net@nos.machine

   And, for multiple machine hops under this circumstance, at the
   very least:

   uunet!target.1!target.2!user@nos.machine
   needs to be converted to:
   target.1!target.2!user%uunet.uu.net@nos.machine

Since I am not enough of a 'C' programmer myself to develop the
necessary source code that will fix this problem in SMTPSERV.C, I
have posted this bug report to the tcp-group, with the hope that
somebody who is familiar with the module, able, and talented enough
will pick up the ball, make this very needed fix to NOS, and then
post the changes back here to the tcp-group mailing list.

- Barry Siegfried, K2MF >>

^________________________________]
^      Barry Siegfried, K2MF     ]
^   AmprNet: k2mf@k2mf.ampr.org  ]
^  InterNet: k2mf@wg2w.njit.edu  ]
^\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\]

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

Date: Mon, 27 Sep 1993 21:15:18 +0300
From: eb15@postoffice.mail.cornell.edu (Edward Bade)
Subject: TCP-Group Digest V93 #250
To: TCP-Group@UCSD.EDU

unsub tcp-group-digest

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

Date: Tue, 28 Sep 1993 0:03:33 -0400 (EDT)
From: MIKEBW@ids.net (Mike Bilow)
Subject: TheNet X1? users
To: tcp-group@ucsd.edu

Has anyone compiled a list of users of TheNet X1? users?  If not, I
would be willing to do this.  It might be useful in resolving support
issues for new users.

-- Mike Bilow, mikebw@ids.net
               N1BEE @ WA1PHY.#EMA.MA.USA.NA

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

Date: Mon, 27 Sep 1993 11:56:32 +0100
From: "Fred N. van Kempen" <waltje@hacktic.nl>
Subject: What to put on a CD-ROM?
To: nelson@crynwr.com, tcp-group@ucsd.edu

Russ writes:

> I'm putting together a CD-ROM of packet driver software.  I see all
> these different versions of NOS being published, but I've only ever
> run Phil's version.  Could someone tell me what versions of NOS to
> put on it besides ucsd.edu:hamradio/packet/tcpip/ka9q/rcsdsrc.zip?

Hey, this is good news!  After you published it, make sure to
zap all old driver archives... I still find "drivers.arc" at
a lot of sites :-)

Anyway, I guess you'd have to archive NOS, GRINOS, JNOS, WNOS
, PE1CHL, WAMPES, and some others.  All of them have something
special, and each of them has a typical use (although I am a
big fan of Johan's JNOS...)

Cheers, Fred NL0WLT

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

Date: Tue, 28 Sep 93 09:34:46 EST
From: dave@eram.esi.com.au (Dave Horsfall)
Subject: What to put on a CD-ROM?
To: tcp-group@ucsd.edu

| Anyway, I guess you'd have to archive NOS, GRINOS, JNOS, WNOS
| , PE1CHL, WAMPES, and some others.  All of them have something
| special, and each of them has a typical use (although I am a
| big fan of Johan's JNOS...)

What would be nice is a summary of their various features, so that
people (like myself) who have to fit packet in between other activities
can get up to speed on them.

-- Dave

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

Date: Mon, 27 Sep 93 16:37:02 -0700
From: karn@qualcomm.com (Phil Karn)
Subject: Why I hate patents
To: tcp-group@ucsd.edu

This item came in today. I've been hearing rumors for some time that
others have been trying to patent my MACA scheme, though it now
appears to have occurred in a company other than the one I had
suspected.

It was always my intention that MACA go into the public domain. Under
US patent law, anything disclosed publicly more than a year before
filing passes into the public domain and can no longer be patented, so
this patent is *clearly* invalid. I'll leave it up to the individual
to decide on the motivations of the "inventors" or the competence of
the Patent Office in searching for prior art.

This case underscores the importance of publishing your work even (or
especially) if you don't want to claim a patent on it yourself. --Phil


X-Ns-Transport-Id: 0000AA001285B157306A
Date:  Mon, 27 Sep 1993 13:56:28 PDT
Sender: Mark_Weiser.PARC@xerox.com
From: weiser.PARC@xerox.com
Subject: Proxim Patent on MACA
To: wireless@tandem.com, karn
Cc: weiser.PARC@xerox.com

Ref: U.S. Patent 5,231,634, Medium Access Protocol for Wireless Lans.  This
basically describes Karn's MACA.  It makes no reference to Karn, and
specifically not to "Karn 90. Karn, P. MACA - A New Channel Access Method for
Packet Radio. Proceedings of the ARRL 9th Computer Networking Conference,
London Ontario, Canada, September 22, 1990. ISBN 0-87259-337-1."

The filing date is December 18,1991.

The "inventors" are Rick R. Giles, and Paul G. Smith, the assignee is Proxim.

Abstract: Access to a radio communications medium shared by at least two agents
to provide peer-to-peer communication therebetween is controlled by sensing the
communications medium at a first agent to determine if the communications
medium is in use, transmitting from the first agent, if the first agent
determines that the communications medium is not in use, a request-to-send
message that includes reservation duration information, and receiving the
request-to-sent message at a second agent.  The second agent then transmits a
clear-to-send message including reservation duration informatoin on behalf of
the first agent, after which the first agent then transmits information to the
second agent while a reservatin duration indiciated by the reservatin duration
informatoin has not elapsed.  A possible third agent within receiving range of
only one of the first and second agents is thereby guaranteed to receive the
reservation duratin information and is expected to observe the reservation
according to rules disclosed.

Anyone from Proxim on this list care to comment on the timeliness of this
patent relative to Karn's paper over a year before, and his public distrubution
of MACA source code well before that?

-mark

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

Date: Mon, 27 Sep 1993 23:42:35 -0400 (EDT)
From: MIKEBW@ids.net (Mike Bilow)
Subject: Why I hate patents
To: karn@qualcomm.com, tcp-group@ucsd.edu

This is appalling.  I haven't been as shocked to read anything about
patent law since someone managed to claim rights to big endianism.

If the quoted abstract is accurate, the patent claim is probably even
more inclusive than Karn's MACA, although that is obviouslt the target.
My cursory reading is that the claim includes the handshaking scheme
itself, which has certain similarities to IEEE-488 (on wire), separate
from the more distinguishing characteristics of MACA.

-- Mike

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

Date: Mon, 27 Sep 93 23:08:42 WET DST
From: dp@hydra.carleton.CA (Dave Perry VE3IFB)
Subject: Why I hate patents
To: tcp-group@UCSD.EDU

Could Apple Localtalk also be considered prior art?

Dave

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

Date: Mon, 27 Sep 1993 23:15:45 -0500 (CDT)
From: Don Loflin <dll@sirius.cc.utexas.edu>
Subject: Why I hate patents
To: tcp-group@ucsd.edu

On Mon, 27 Sep 1993, Phil Karn wrote:

> It was always my intention that MACA go into the public domain. Under
> US patent law, anything disclosed publicly more than a year before
> filing passes into the public domain and can no longer be patented, so
> this patent is *clearly* invalid. I'll leave it up to the individual
> to decide on the motivations of the "inventors" or the competence of
> the Patent Office in searching for prior art.
> 
> This case underscores the importance of publishing your work even (or
> especially) if you don't want to claim a patent on it yourself. --Phil

I dunno, Phil, it seems that you're making a case for *not* publishing
your work.  If you publish some great idea, intending it to be public
domain, a company could come along 6 months later and file for a patent. 
There'd be no prior art published more than a year before.  What if Proxim
had filed for that patent in August '91 instead of December?  Then they
might have a valid patent.  Yipes!  True, if you don't publish, there's
nothing to stop a patent if someone else comes up with the same idea, but
if you do, everyone has a year to patent your idea, or so it seems. 

I think the patent law needs to afford some protection for explicitly
public domain work--i.e if it states clearly "this is public domain", then
it can't be patented, effective the date of publication, not one year
after.  Does anyone more law-knowledgeable know if copyright+patent law
supports such protection?  Perhaps I've misinterpreted and it's not a
*requirement* that something be around for more than a year to be
considered prior art, just a case when it definitely is prior art?


--Don Loflin
  Computation Center,
  Univ of Texas at Austin

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

Date: Tue, 28 Sep 93 01:52:37 -0700
From: karn@qualcomm.com (Phil Karn)
Subject: Why I hate patents
To: dll@sirius.cc.utexas.edu

>I dunno, Phil, it seems that you're making a case for *not* publishing
>your work.  If you publish some great idea, intending it to be public
>domain, a company could come along 6 months later and file for a patent. 

First of all, I'm not a patent attorney. But as an engineer I've found
it impossible to avoid learning the basic rules.

Much more than the 1-year rule can be at play here; I dwell on it
mainly because it makes things absolutely trivial in this case.  Once
something has been published for a year, it's unpatentable in the US.
Period. End of story. This much I reconfirmed with my company's patent
attorney yesterday afternoon.

However, if somebody steals and patents an invention I publish less
than a year earlier, it would be a little more difficult but still not
impossible to have it tossed out.  I'd file what I believe is called
an "interference" claiming prior invention of the idea. The patent
holder would have to prove, through dated records such as witnessed
laboratory notebooks, that he had initially conceived the idea before
me. Whoever establishes the earliest date wins.

Since a journal's publication date is fairly easily established, this
is probably the best evidence to use. But if I needed to establish an
earlier date, I could draw on anything else that the court would
accept, e.g., witnesses, personal notes, paper drafts, or email
messages discussing the idea.  Naturally, if they had stolen the idea
from me in the first place, they would not be able to produce records
dated earlier than my own. Assuming, of course, that I keep records in
the first place, which is why documentation is so important.

Phil

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

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