Date: Fri, 2 Apr 93 04:30:15 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 #85
To: tcp-group-digest
TCP-Group Digest Fri, 2 Apr 93 Volume 93 : Issue 85
Today's Topics:
Applications (3 msgs)
Ftpmotd diffs for GRINOS v2.0p
Internet Gateway (6 msgs)
Internet Gateway and Advanced Packet
PacComm Tiny-2 KISS Bug (2 msgs)
prototypes
Re: NOS Prototypes.. more .. (4 msgs)
User Applications (2 msgs)
Utah Backbone/Network Services (2 msgs)
wampes for linux? (2 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: Thu, 1 Apr 93 09:44:45 -0500
From: grebus@isis1.bxb.dec.com (Gary Grebus)
Subject: Applications
To: tcp-group@ucsd.edu
As someone pointed out, there's not much reason to build a high-tech network
unless you have applications to run on it. Conversely, really good
applications will take hold in spite of the crude network technology.
The case in point is Packetcluster(tm). It's wildly popular. It's
what the PC folks call a "killer app"...a single application that justifies
(in the mind of the user) having the hardware. The analogy is to
spreadsheets on the original PC's. Why is it so popular?
1. It performs a service that (many) hams really want to have.
2. It does so in a way that is uniquely better than alternatives
(voice spotting nets, telephone alerting, etc).
3. It requires a modest financial investment from the user, and a
reasonable investment from the service provider.
So, while cloning the Internet-style services is a useful and good
thing, we also should keep looking for applications that are uniquely enabled
by packet radio.
/gary
K8LT
------------------------------
Date: Thu, 1 Apr 1993 13:29:46 -0800
From: George Farris <george@ve7frg.ampr.org>
Subject: Applications
To: tcp-group@ucsd.edu
On Apr 1, 9:44am, Gary Grebus wrote:
} Subject: re:Applications
>
> The case in point is Packetcluster(tm). It's wildly popular. It's
> what the PC folks call a "killer app"...a single application that justifies
> (in the mind of the user) having the hardware. The analogy is to
> spreadsheets on the original PC's. Why is it so popular?
>
> 1. It performs a service that (many) hams really want to have.
>
> 2. It does so in a way that is uniquely better than alternatives
> (voice spotting nets, telephone alerting, etc).
>
> 3. It requires a modest financial investment from the user, and a
> reasonable investment from the service provider.
4. It kills off all the really good DX. Who wants to get on the air
when you know that all those dam US and CAN stations are just going to
pile up on top of you. Now thats fun :-(.
My appologies to tcp-group but think about it.
--
==========================================================================
George Farris - VE7FRG Internet : george@ve7frg.ampr.org
Amprnet : george@ve7frg.ampr.org
Sidney, B.C. UUCP : sol.uvic.ca!ve7frg!george
(604) 656-0342 AX.25 : ve7frg@ve7vbb.bc.can.noam
------------------------------
Date: Fri, 2 Apr 93 11:47:01 EST
From: dave@eram.esi.com.au (Dave Horsfall)
Subject: Applications
To: george@ve7frg.ampr.org, tcp-group@ucsd.edu
| 4. It kills off all the really good DX. Who wants to get on the air
| when you know that all those dam US and CAN stations are just going to
| pile up on top of you. Now thats fun :-(.
5. It takes all the fun out of chasing DX. Why bother, when a computer
can do it for you? Yes, I can see how this is fun...
-- Dave
------------------------------
Date: Thu, 1 Apr 93 12:36:18 EST
From: Steve Urich <beyonet!steve@gvls1.VFL.Paramax.COM>
Subject: Ftpmotd diffs for GRINOS v2.0p
To: tcp-group@ucsd.edu
Here are the changes that I sent to Gerard. This is the Ftpmotd
from Jnos only in the 230- format like internet sites instead
of the strange 220- format. It works with the GRI client well
therefore the gri client doesn't have to be touched. This is also
backwards compatable with all versions of ka9q net. It should
also work with wampes clients and the latest ka9q nos.
73 Enjoy - Steve
-----Start ``diff -c'' GRINOS v2.0p ftpserv.c files.c files.h----
*** ftpserv.old Thu Apr 1 12:19:45 1993
--- ftpserv.c Thu Apr 1 12:21:26 1993
***************
*** 474,480
struct ftpserv *ftp;
char *pass;
{
! char *path;
char *p;
int anony = 0;
--- 474,480 -----
struct ftpserv *ftp;
char *pass;
{
! char *path,buf(128);
char *p;
FILE *fp;
int anony = 0;
***************
*** 476,481
{
char *path;
char *p;
int anony = 0;
path = mallocw(200);
--- 476,482 -----
{
char *path,buf(128);
char *p;
+ FILE *fp;
int anony = 0;
path = mallocw(200);
***************
*** 496,501
if((p = strchr(path,';')) != NULLCHAR)
*p = '\0'; /* delimit initial cd */
#endif
if(!anony){
usprintf(ftp->control,logged);
--- 497,509 -----
if((p = strchr(path,';')) != NULLCHAR)
*p = '\0'; /* delimit initial cd */
#endif
+ if((fp = fopen(Ftpmotd,"r")) != NULL) {
+ while(fgets(buf,sizeof(buf),fp)) {
+ rip(buf);
+ usprintf(ftp->control,"230- %s\n",buf);
+ }
+ fclose(fp);
+ }
if(!anony){
usprintf(ftp->control,logged);
*** filesc.old Thu Apr 1 12:20:16 1993
--- files.c Thu Apr 1 12:21:39 1993
***************
*** 21,26
char *Arealist = "/spool/areas"; /* List of message areas */
char *Helpdir = "/spool/help"; /* Mailbox help file directory */
char *Rewritefile = "/spool/rewrite"; /* Address rewrite file */
char *Signature = "/spool/signatur"; /* Mail signature file directory */
char *Popusers = "/popusers"; /* POP user and password file */
char *Newsdir = "/spool/news"; /* News messages and NNTP data */
--- 21,27 -----
char *Arealist = "/spool/areas"; /* List of message areas */
char *Helpdir = "/spool/help"; /* Mailbox help file directory */
char *Rewritefile = "/spool/rewrite"; /* Address rewrite file */
+ char *Ftpmotd = "/spool/ftpmotd.txt"; /* FTP message of the day */
char *Signature = "/spool/signatur"; /* Mail signature file directory */
char *Popusers = "/popusers"; /* POP user and password file */
char *Newsdir = "/spool/news"; /* News messages and NNTP data */
*** filesh.old Thu Apr 1 12:20:41 1993
--- files.h Thu Apr 1 12:21:48 1993
***************
*** 32,37
extern char *Arealist; /* List of message areas */
extern char *Helpdir; /* Mailbox help file directory */
extern char *Rewritefile; /* Address rewrite file */
extern char *Signature; /* Mail signature file directory */
extern char *Popusers; /* POP user and password file */
extern char *Newsdir; /* News messages and NNTP data */
--- 32,38 -----
extern char *Arealist; /* List of message areas */
extern char *Helpdir; /* Mailbox help file directory */
extern char *Rewritefile; /* Address rewrite file */
+ extern char *Ftpmotd; /* FTP message of the day */
extern char *Signature; /* Mail signature file directory */
extern char *Popusers; /* POP user and password file */
extern char *Newsdir; /* News messages and NNTP data */
-----End of diff cut here-----
--
|Stephen Urich| Internet:steve@zero.com |"Cattle mutilations |
|NIC: SU2 | UUCP:uunet!beyonet!steve |are up!" --Sneakers |
|ARS: WB3FTP | Packet:WB3FTP@WB3FTP.#EPA.PA.USA.NOAM |ax25<->PBBS<->IPGATE|
|Bensalem, PA |Radio:wb3ftp@wb3ftp.ampr.org[44.80.8.44]|TCP/IP-FTP-SMTP-UNIX|
------------------------------
Date: Thu, 1 Apr 93 7:56:37 EST
From: ddabay@ruacad.ac.runet.edu
Subject: internet gateway
To: TCP-group@UCSD.EDU
Matti writes:
I am commenting on user-interface things, while I still may be
talking a lot about nuts & bolts.. This became quite lengthy..
Steve, N5OWK wrote:
...
> >> I don't really like most of the "improvements" done since. When
> > I don't understand this either. What, exactly, don't you like?
>
STUFF DELETED
NSF-net backbone is T3, however that is between Big Sites (and Big Money).
Not every site has T3 (34 Mbps ?); there exists a lot T1 and 10Mbps links.
Applications are very important, and often their users (and/or providers)
don't quite see what others may want to have.
As a rule of thumb: Users want more applications which require less
information in advace to be usable; preferrably
no advance(d) knowledge...
(Definitely I don't like that attitude; it makes my work more difficult at
packing the information and services, but it is the way things are :( )
In some, if not most cases a lot of Universities use 9.6 Kbaud
and even that is paid/bought for by some other entity...We could
surely USE a 56k (or higher) but do we NEED it...May be hard to
justify the added cost.
In very short time a service known as Gopher has sprung into enormous
popularity all around the Internet. It belongs to vaguely defined category
of "User and Information services"; where its rivals are such a things as
WWW, WAIS, Whois++, X.500, ... Most important of all, Gopher protocol and
user interface are so simple, that most novice users can start to use them
without any great education. (Which is also its greatest difficulty, as
such users don't know that some piece of information really is not at their
fingertips/local machine, but at the other edge of the network...)
Of those services, here is my view of them in order of easy-to-less-easy
to use:
Gopher(+): Information browser developed at U of Minnesota
My view:
Gopher is O.K., but not what I would want to go into the next
century with. I don't think we should use that as the baseline
standard for growth.
Whois++: re-warmed edition of old whois protocol with distributed
databases, etc..
WWW: Information Hypertext tool/browser/organizer made at CERN
(CERN is European high-energy physics research facility in Swizerland)
X.500: ISO/OSI Directory service
WAIS: Wide Area Information Search; ANSI Z39.50 based search protocol
developed by Thinking Machines (makers of Connection Machines)
This seems to hold the most promise, at this point....the ones
that I have used support multi-protocol access and still use most
of the ability of those different protocols transparently.
And of course, if we start to run high bandwidth network with plenty of
users, we need high-power machines to run services (and dedicated routers..)
This is where the real money is needed, a lot of the backbone
machines are old, read: archaic technology. You can't sustain
the bandwidth that will be needed with a 2MB/sec machine...
Even when users have slow-speed access ports, all that aggregate dataflow
does quickly fill a large pipe.. (Important servers must be connected
with high-speed interfaces, of course..)
Here we must break out of the PC-bandwidth mentality and look at
60-100MB/sec transfer (and beyond) things like HIPPI, FDDI, or
CDDI type stuff. But if the big companies can't decide what is
best how can we lowly hams????:.)...
> >> I really appreciate the simplicity of Net/Rom node tables.
> > As compared to what? If you want simplicity, run RIP.
RIP is OK but try to find a problem without a slew of diag stuff...
Simple is not ALWAYS the best....
> You are wrong. We are not ready for applications software yet in amateur
> packet radio. It needs a better transport design first. You can't transport
> application data over a system that can't even transport a connect request.
My experience with Real Internet shows that money can't be gotten from
sources (usually tax-money), unless we can show that we have applications
which need all that bandwidth we are asking for..
This is basically true, if you can SHOW what the transport will do
you are definitely fighting an uphill battle to get anything more.
I think we need some real whiz bang apps (better than WAIS, gopher, etc) to actually show things like speed, reliability, error rates etc.
In an apples to apples comparison.
> 73, Steve, N5OWK
73, Matti, OH1MQK
Dave
--
Dave Dabay Telecommunications Network Supervisor 703-831-5482 KD3PC
Radford University Computer Services Internet: ddabay@ruacad.ac.runet.edu
------------------------------
Date: Thu, 01 Apr 1993 08:42:53 -0500
From: "Louis A. Mamakos" <louie@NI.umd.edu>
Subject: Internet Gateway
To: mea@Mea.cc.utu.fi ("Matti E. Aarnio [OH1MQK]")
> NSF-net backbone is T3, however that is between Big Sites (and Big Money).
> Not every site has T3 (34 Mbps ?); there exists a lot T1 and 10Mbps links.
Actually, there exist *quite* a few 56kbp/s and 9.6kbp/s links. I don't
know of very man 10Mbp/s links except for local ethernets at a site.
> >
> > I don't know what OSPF means (my dictionary is at home), but I bow to your
> > wisdom. What I meant by that is the current Net/Rom system is often abused
> > by net hoppers trying to see what is on the other end, rather than having all
> > that data available for update on the local node. Hard disks are cheap enough
> > that a database can be kept up to date using whatever protocol trips your
> > trigger.
> OSPF: Open Shortest Path First -- ISO/OSI connectionless routing protocol.
> NOS has a RSPF -- Radio Shortest Path First, which bases on OSPF, but does
> not go quite as far (and complex).
This is mostly wrong. While OSPF (an Internet protocols) uses an link
state routing alogorithm which floods its link state database to
neighbors. It is most definately NOT the OSI IS-IS routing protocol.
RSPF attempts to solve a different set of problems while also being a
link state routing protocol. From what I can tell, RSPF doens't seem
based on RSPF at all, other than being a routing algorithm in the
general class of "link-state based" routing protocols.
All of these protocols are link state, rather than distance-vector
based (such as RIP, IGRP, and the horrible thing used by NET/ROM,
etc). The link state based alogorithms are generally more resistant
to routing loops and generally require less network traffic as
connectivity changes. While there are certain changes you can make to
distance vector based alogithms, they certainly don't appear in the
NET/ROM routing protocol, and one one or two appear in RIP.
Having an up-to-date link state database, you can compute routes all
over the network, not just from your perspective. The trade-off is
higher computational and memory overhead. On the other hand, you have
the ability of being able to compute the complete path across the
network to your destination, not just the next hop. Since you know
the whole path and the state of the various links and their
characteristics, you can do multipath routing to share bandwidth of
multiple paths to the same destination.
> Discussion about this, and also about successor to AX.25 is starting at
> mailing list advaced-packet@pixar.com (list participation is hangled by
> listserv@pixar.com; send your signon requests to the server, not to the list..
Nothing I've seen so far seems particularly far afield from the general
topic of TCP/IP over amateur packet radio. None of if it is particularly
advanced.
Louis A. Mamakos
wa3ymh
------------------------------
Date: Thu, 1 Apr 1993 10:43:50 -0500
From: chk@alias.com (C. Harald Koch)
Subject: Internet Gateway
To: ssampson@sabea-oc.af.mil (Steve Sampson)
> >> I was on the Internet when it was pure uucp, and to tell the truth
> > The "Internet" was never pure UUCP. The "Internet" existed long
> > before most people had ever heard of UUCP.
>
> You may be refering to the ARPA net which developed about the same time as
> the Unix uucp network. Most colleges were only wired together into the uucp
> network and did not have access or the hardware to connect to the ARPA net.
> So the word "internet" has many uses of which I offer mine. The TCP/IP network
> has nothing to do with uucp of course, but the term "internet" was used widely
> to describe that network.
Ok, let's get this straight, right now.
"an internet" refers to a generic entity, a set of networks connected
together by gateways (or routers). My corporate WAN is an internet (we have
6 lans joined with routers). the AMPRNet is an internet.
"The Internet" has always refered to a specific set of machines connected to
each other using the TCP/IP protocols. Originally, The Internet was the
ARPANET, plus several affiliated research organizations and universities.
The ARPANET went away, and was replaced with the NSFNet. Today, there's also
several interconnected commercial network providers, which connect to the
NSFNet. This large, interconnected entity is what we refer to today as The
Internet. Any host that can contact other hosts over the NSFNet, or one of
the commercial providers, is "on the Internet". My corporate WAN is *not* on
the Internet (but see below).
The Internet has never had anything to do with UUCP, or UseNet. the UUCP net
is a set of machines that send and receive mail over dialup phone links
using the UUCP (Unix to Unix Copy Program) software. These machines are
usually able to forward mail to an Internet connected host, so they can
exchange mail with (and through) the Internet. However, they are *not* part
of the Internet. In the same manner, Compuserve and MCIMail are able to
exchange mail with the Internet, but are not part of it. Alias exchanges
mail with the University of Toronto via UUCP, so we are considered part of
the UUCP network.
UseNet is yet another set of hosts, exchanging a specific hierarchy of
newsgroups with each other (comp,misc,rec,news,talk,soc,sci). News exchange
is done over the Internet, using UUCP, using magnetic tape, and probably
over radio links. That doesn't mean that UseNet is part of the Internet;
it's merely available on the Internet. Alias exchanges news with two Toronto
sites; we're part of UseNet.
The Internet is a specific entity; please don't go confusing it with
anything else.
--
Main's Law: For every | C. Harald Koch Alias Research, Inc. Toronto, ON
action, there is an equal | chk@alias.com (work-related mail)
and opposite goverment | chk@gpu.utcs.utoronto.ca (permanent address)
program. | VE3TLA@VE3OY.#SCON.ON.CA.NA (AMPRNet)
------------------------------
Date: Thu, 1 Apr 1993 11:02:41 -0600 (CST)
From: Steve Sampson <ssampson@sabea-oc.af.mil>
Subject: Internet Gateway
To: TCP-Group@UCSD.Edu
Andy Warner says:
> Quite what the hell UUCP has to do with tcp over radio, I never did
> quite figure out..
You seem to have tuned in to the part of the letter that offers you a
chance to ridicule, but it was merely a thought swing of mine, that if
the purpose of networks is to send mail, transfer files, and chat, then
maybe the high speed systems don't need to be designed for gurus who
think that logins and mode switching is "cool". I was actually in a
good mood when I wrote all that...
> If you don't like flames, don't post flame-bait.
I can take a flame, but I thought when I signed up for this group that
they would see past the chance to bugger me and discuss the merits or
talk about packet radio in a light fashion, rather than at a doctorial
level. I used to spend some time on usenet but I found that it was a
magnet for flames for the sake of flames, therefore no one ever said
anything because all the assholes jump on every misspelled word or they
fear of some dweeb practicing his fun. Flames may correct someone,
or they may only chase away people who have something to offer, or worse
yet they will dwindle the conversation down to short beeps that don't leave
room for comment.
---
Steve N5OWK
------------------------------
Date: Thu, 1 Apr 93 11:17:48 CST
From: andyw@aspen.cray.com (Andy Warner)
Subject: Internet Gateway
To: tcp-group@ucsd.edu (TCP Group)
>
>
> Andy Warner says:
> > Quite what the hell UUCP has to do with tcp over radio, I never did
> > quite figure out..
>
> You seem to have tuned in to the part of the letter that offers you a
> chance to ridicule, but it was merely a thought swing of mine, that if
> the purpose of networks is to send mail, transfer files, and chat, then
> maybe the high speed systems don't need to be designed for gurus who
> think that logins and mode switching is "cool". I was actually in a
> good mood when I wrote all that...
>
> > If you don't like flames, don't post flame-bait.
>
> I can take a flame, but I thought when I signed up for this group that
> they would see past the chance to bugger me and discuss the merits or
> talk about packet radio in a light fashion, rather than at a doctorial
> level. I used to spend some time on usenet but I found that it was a
> magnet for flames for the sake of flames, therefore no one ever said
> anything because all the assholes jump on every misspelled word or they
> fear of some dweeb practicing his fun. Flames may correct someone,
> or they may only chase away people who have something to offer, or worse
> yet they will dwindle the conversation down to short beeps that don't leave
> room for comment.
> ---
> Steve N5OWK
>
--
andyw.
andyw@aspen.cray.com Andy Warner, Cray Research, Inc. (612) 683-5835
------------------------------
Date: Thu, 1 Apr 93 11:39:47 CST
From: andyw@aspen.cray.com (Andy Warner)
Subject: Internet Gateway
To: tcp-group@ucsd.edu (TCP Group)
Steve wrote :-
> Andy Warner says:
> > Quite what the hell UUCP has to do with tcp over radio, I never did
> > quite figure out..
>
> You seem to have tuned in to the part of the letter that offers you a
> chance to ridicule, but it was merely a thought swing of mine, that if
> the purpose of networks is to send mail, transfer files, and chat, then
> maybe the high speed systems don't need to be designed for gurus who
> think that logins and mode switching is "cool". I was actually in a
> good mood when I wrote all that...
Well, warn us if your mood takes a downturn. I could have picked out
a lot more stuff for ridicule, but whats the point, Lyndon did a pretty
good job, you'll probably not listen and life is far too short. I don't
think you'll find anyone here that thinks tcp over the radio is perfect;
but most of us think it's better & more useful than what preceeded
it. We're trying to push the envelope, if we're not pushing
hard enough or fast enough - lead the way. Folks like Walt are trying
to de-mystify the user interfaces of things like mail & file transfer,
just because I'm happy with elm, sendmail & ftp doesn't mean you should
be, but I'm not going to write the replacements for you.
There's a lot of technology driven people on this list, and not
many application driven people - maybe because you need the basic
communication capabilities before you can start shoveling things
like Gopher or weather maps (or mail or file transfer) on top. If
anything, the most limiting component of most TCP setups used over
the radio is the fact that they run on low end DOS boxes. It's
not possible to do much apart from logins & mode switching *and*
shuffle packets on that platform. Suggesting moving to more capable
machines to allow whizz-bang interfaces brings the "what about my
XT ?" crew out of the woodwork (for our bi-annual XT vs. 386/486
flamefest)..
> > If you don't like flames, don't post flame-bait.
>
> I can take a flame, but I thought when I signed up for this group that
> they would see past the chance to bugger me and discuss the merits or
> talk about packet radio in a light fashion, rather than at a doctorial
> level. I used to spend some time on usenet but I found that it was a
> magnet for flames for the sake of flames, therefore no one ever said
> anything because all the assholes jump on every misspelled word or they
> fear of some dweeb practicing his fun. Flames may correct someone,
> or they may only chase away people who have something to offer, or worse
> yet they will dwindle the conversation down to short beeps that don't leave
> room for comment.
When you signed up for this list, you signed up to take part in the
shaping of the group. This isn't the "Steve Sampson is right on all
counts list" or even the "Steve Sampson is wrong on all counts list",
but don't be surprised when folks react to a posting as full of
contention as yours (I still stand by the phrase flame-bait).
BTW - You might want to watch you language if you want to reach
the largest possible audience of possible converts. This list gets
sent over amateur links all round the world..
--
andyw. N0REN/G1XRL
andyw@aspen.cray.com Andy Warner, Cray Research, Inc. (612) 683-5835
------------------------------
Date: Thu, 1 Apr 1993 08:49:57 -0800 (PST)
From: Bruce Perens <bruce@pixar.com>
Subject: Internet Gateway and Advanced Packet
To: "Louis A. Mamakos" <louie@NI.umd.edu>
"Louis A. Mamakos" <louie@NI.umd.edu> Wrote:
>> Discussion about this, and also about successor to AX.25 is starting at
>> mailing list advaced-packet@pixar.com (list participation is hangled by
>> listserv@pixar.com; send your signon requests to the server, not to the
>> list..
>
> Nothing I've seen so far seems particularly far afield from the general
> topic of TCP/IP over amateur packet radio. None of if it is particularly
> advanced.
>
> Louis A. Mamakos
> wa3ymh
Well, we're just getting started, so the discussion is still mostly
administrative. At least there isn't name-calling.
I'd really like to get the technical argument started,
so if you have something to say, please subscribe and post. By the way,
in late April we will change the list name to something other than
advanced-packet, since that turns out to have been an unfortunate
choice.
To subscribe, send mail to LISTSERV@PIXAR.COM with the body text
SUBSCRIBE ADVANCED-PACKET YOUR-NAME-HERE
This is what we are discussing at the moment. If you would like to reply
to this, please subscribe to advanced-packet and post your reply there.
Bill Simpson and I have been working to transition advanced-packet into
an "official" working group of the IETF, the Internet Engineering Task
Force. As an IETF WG, we would have improved representation with the
other working groups that are establishing new protocols and policies
for the Internet. We would probably have enough weight to persuade the
FCC to allow use of of whatever we develop. The current commercial
developments on mobile-IP are divided along corporation boundaries. We
have an opportunity here for amateur radio to be the technical leader,
rather than a follower.
We will publish only recommended standards, _not_ mandates, as we don't
want to stand in the way of any packet-radio experimentation. Since we
are doing this on our own nickel, I don't expect to see much representation
of this group at the IETF meetings except by members who have other,
professionaly supported, business to do at IETF.
Here is the draft charter for the working group, which we would submit
to the IETF Area Director with our request to form the working group.
Please read it carefully, and direct your comments to
advanced-packet@pixar.com . Thanks to Bill Simpson for co-authoring
the charter with me.
Many Thanks
Bruce Perens KD6OTD
Amateur Packet Radio (ampr)
Charter
Chair(s):
Bruce Perens <bruce@pixar.com>
Internet Area Director(s)
Stev Knowles <stev@ftp.com>
Mailing lists:
General Discussion:ietf-ampr@pixar.com (what is now advanced-packet)
To Subscribe: listserv@pixar.com
Archive: ftp.pixar.com (does not yet exist)
Description of Working Group:
Systems on AMPRnet, the Amateur Packet Radio domain of the Internet,
suffer from the vicissitudes of radio propagation, and extreme
mobility. Thus, they do not fit the model of a well-connected network
that applies in the rest of the Internet. Current proposals for mobile
routing depend on base stations providing packet-tunneling through the
well-connected portion of the Internet, which is not a viable solution
for Amateur Radio. Existing Amateur Radio transmission protocols such
as AX.25 do not handle the problems of limited bandwidth and
susceptability to noise in the bands assigned to the Amateur Service.
The Amateur Packet Radio working group is chartered to develop improved
link-layer and routing protocols for using the Internet Protocol Suite
on Amateur Radio networks. Experimental protocols developed for
Amateur Radio are likely to have future application to other areas of
the Internet beyond mobile routing, such as the use of multicast in
partial-mesh general-topology networks. These experimental protocols
will be submitted to the IESG, and registered with the FCC and other
international regulatory agencies as proposed standards.
Goals and Milestones:
Mar 93 Mail list and archive established. 85 individual subscribers,
plus distribution to AMPRnet and site-local newsgroups.
Jul 93 Study existing proposals such as MOSPF, RSPF, SIP and CLOVER.
Determine what effect they will have on Amateur Radio
networking, and whether they address any of the problems we
are considering.
Nov 93 Final Internet Drafts describing transmission protocols.
Jul 94 Final Internet Drafts describing routing protocols.
<End of Document>
Criticism on the above that has been posted to advanced-packet or mailed to me:
1. Standardization inevitably depresses experimentation and
innovation. A standard such as we might develop might even be
made into a mandate by government agencies such as the FCC.
(speaker was more vehment, called it "A TERRIBLE IDEA").
2. Involvement in the IETF will only slow us down. We should do
the work first, and ask the IETF to put it in their archive
when we are done.
3. The time-lines are too short, and time-lines are a bad idea
for a hobby enterprise.
4. There is no need for any of the above. I can go mobile now
with NOS, as long as I stay in my own LAN.
I'm satisfied with counter-argument to the above, but I'd like to know what
you think. Again, I can't stop you from discussing this on tcp-group,
but it would be more appropriate to subscribe to advanced-packet and discuss
it there .
Thanks
Bruce KD6OTD
------------------------------
Date: 1 Apr 93 11:51:00 EST
From: "Charlie Ross Jr." <CROSSJR@eagle.ndhm.gtegsc.com>
Subject: PacComm Tiny-2 KISS Bug
To: "jvt" <jvt@its.bt.co.uk>
> > >PacComm Tiny-2 with "node" (higher speed) parts, port speed 9600 baud, radio
> > >speed 1200 baud, ROM rev. 1.1.6b (PacComm)
> > ^^^^^^
> > One of the firmware releases around this time was broken. It ignored the DCD
> > I think. The problem was fixed after I changed the EPROM.
>
> I had trouble with 1.1.6d4. In KISS mode it would only operate in FULL DUPLEX
> (or ignored DCD its the same thing).
I've been discussing this exact issue with PacComm and their rep, NX2P,
for about nine months. I bought a Tiny-2 in the late Spring '92 and I
consider the bug to be a warranty defect. I've long since changed over to
non-PacComm code. I should have bought the "node" version (which is the
same TNC sans EPROM) and just put in one of my own.
The latest info from NX2P (about one month ago) is that PacComm fixed the
bug in a beta version of the firmware, but that the fix hasn't been
incorporated in their released version. Last summer, they had promised me
a formal release by the end of September 1992, but it apparently never
happened.
He also said that PacComm *may* post the fixed code somewhere, someday,
and allow people to download it and burn their own EPROMs.
Until PacComm fixes this, IMHO, any TCP/IP operator should buy the TNC
without an EPROM and save themselves the $10. Unfortunately, NX2P also says
that PacComm may discontinue the EPROM-less option if they post the code
publicly.
--Charlie, NC1N
crossjr@eagle.ndhm.gtegsc.com (Internet)
nc1n@nc1n.ampr.org (New England amprnet)
NC1N @ WA1PHY.MA (AX.25)
------------------------------
Date: Thu, 01 Apr 93 16:22:35 MST
From: rnielsen@tapr.org (Bob Nielsen)
Subject: PacComm Tiny-2 KISS Bug
To: "Charlie Ross Jr." <CROSSJR@eagle.ndhm.gtegsc.com>
> Until PacComm fixes this, IMHO, any TCP/IP operator should buy the TNC
> without an EPROM and save themselves the $10. Unfortunately, NX2P also says
> that PacComm may discontinue the EPROM-less option if they post the code
> publicly.
The TAPR 1.1.8a code is available at ucsd.edu, as is at least one version
of KISS-only code. For those without ftp capability, they are also
available from file-request@tapr.org. Send a message to
file-request@tapr.org with the line "help" in the body of the message to
get more information.
Bob
------------------------------
Date: Thu, 1 Apr 93 14:23:52 EST
From: crompton@NADC.NADC.NAVY.MIL (D. Crompton)
Subject: prototypes
To: nos-bbs@hydra.carleton.CA
Ah, the battle of the prototypes. There is a way to keep both sides
<stuff deleteted>
73 de Jeff N3NPQ
jbj@USDesign.COM
Well I guess I could honestly say that I don't give a hoot about the old
way. That would be honest on my part but not very nice.
I wonder just how many people this effects? Keep in mind that I am refering
to the WG7J code specifically, not the late KA9Q. I suspect that 99.9% of
the users are using DOS and Borland compilers with WG7J. I know I will get
mail on that but not from the majority that use DOS and BC.
I don't see anything wrong with requiring a certain hardware/software
configuration to compile and/or run NOS. Making a general configuration
that suits every compiler and existing hardware configuration imaginable
is just not pratical. It also does not make the most efficient configuration
for the majority - the DOS users.
What you propose is yet another hack to make NOS work for some handful
of users who won't get with the program. Phil wants to cut out the
kludge and you want to put yet another one in.
The only way to modernize/update something like this is to force users
to comply. If you make it easy not to they never will!
Every function that has global functions should have a .h file prototyping
those functions. Static's can go in the .c file. Currently NOS has prototypes
all over the place, sometimes in not so logical places. I just use 'ts' to
find them. If every 'c' file had an 'h' file it would make things much easier.
Some things are logically grouped in one file which is OK but some are not.
Doug
------------------------------
Date: Thu, 1 Apr 1993 10:15:28 -0500 (EST)
From: jbj@USDesign.COM (Jeff Johnson)
Subject: Re: NOS Prototypes.. more ..
To: tcp-group@ucsd.edu
Ah, the battle of the prototypes. There is a way to keep both sides
happy.
Use a macro that looks like
#if defined(__STDC__) || defined(USE_PROTOTYPES)
#define P(x) x
#else
#define P(x) ()
#endif
and write all the prototypes as
extern int bcmp P((char *b1, char *b2, int len));
extern void bcopy P((char *b1, char *b2, int len));
extern void bzero P((char *b, int length));
Subroutines continue to be written the "old" way:
int
bcmp(b1, b2, len)
char *b1;
char *b2;
int len;
{ ....
rather than the new-fangled
int bcmp (char *b1, char *b2, int len) { ...
On the new fangled ANSI cc`s, you have prototypes. On older compilers
the macro expands to function definitions.
Works for me. Your mileage may vary ...
73 de Jeff N3NPQ
jbj@USDesign.COM
------------------------------
Date: Thu, 1 Apr 1993 13:52:27 -0600
From: miltonm@inetnode.austin.ibm.com (Milton Miller)
Subject: Re: NOS Prototypes.. more ..
To: jbj@USDesign.COM, tcp-group@ucsd.edu
Which is exactly how the the code is now :-) (in case anyone else hasn't
looked at the source) Works for me too.
milton
> Ah, the battle of the prototypes. There is a way to keep both sides
> happy.
>
> Use a macro that looks like
>
> #if defined(__STDC__) || defined(USE_PROTOTYPES)
> #define P(x) x
> #else
> #define P(x) ()
> #endif
>
> and write all the prototypes as
>
> extern int bcmp P((char *b1, char *b2, int len));
> extern void bcopy P((char *b1, char *b2, int len));
> extern void bzero P((char *b, int length));
>
> Subroutines continue to be written the "old" way:
>
> int
> bcmp(b1, b2, len)
> char *b1;
> char *b2;
> int len;
> { ....
>
> rather than the new-fangled
>
> int bcmp (char *b1, char *b2, int len) { ...
>
> On the new fangled ANSI cc`s, you have prototypes. On older compilers
> the macro expands to function definitions.
>
> Works for me. Your mileage may vary ...
>
> 73 de Jeff N3NPQ
> jbj@USDesign.COM
>
------------------------------
Date: Thu, 1 Apr 1993 16:02:34 -0500
From: chk@alias.com (C. Harald Koch)
Subject: Re: NOS Prototypes.. more ..
To: jbj@USDesign.COM (Jeff Johnson)
> Ah, the battle of the prototypes. There is a way to keep both sides
> happy.
tcp-group turns into comp.lang.c! Oh boy, as Sam would say.
> and write all the prototypes as
>
> extern int bcmp P((char *b1, char *b2, int len));
> extern void bcopy P((char *b1, char *b2, int len));
> extern void bzero P((char *b, int length));
>
> Subroutines continue to be written the "old" way:
>
> int
> bcmp(b1, b2, len)
> char *b1;
> char *b2;
> int len;
> { ....
>
> rather than the new-fangled
>
> int bcmp (char *b1, char *b2, int len) { ...
>
> On the new fangled ANSI cc`s, you have prototypes.
This only works if you know about K&R type promotion V.S. ANSI type
promotion.
For example, to an ANSI compliant compiler:
char *strchr(char *s, char c) {}
and
char *strchr(s, c)
char *s;
char c;
{
}
Mean two different things. In the latter case, K&R style type promotion is
done; c actually gets passed as an int, not a char. In the former case, c is
actually passed as a char. On many architectures, this will cause all sorts
of problems, since the caller and the function are using two different
methods for passing arguments, and will get confused.
(chars probably aren't a problem, since most machines are 16-bit aligned
nowadays. However, consider 32-bit ints v.s. shorts...)
I've seen far too many bugs caused by this problem to dismiss it lightly.
But wait! There's hope! GNU, for example, have a program called ansi2kr (or
something like that) which will convert ANSI style function declarations to
K&R style. with any reasonable make, you can simply write a rule that does
the equivalent of
ansi2kr file.c >file..c
cc -o file.o file..c
rm file..c
We now return you to our normal "How do I use NOS" discussions... :-)
--
Main's Law: For every | C. Harald Koch Alias Research, Inc. Toronto, ON
action, there is an equal | chk@alias.com (work-related mail)
and opposite goverment | chk@gpu.utcs.utoronto.ca (permanent address)
program. | VE3TLA@VE3OY.#SCON.ON.CA.NA (AMPRNet)
------------------------------
Date: Thu, 1 Apr 93 19:08:45 -0800
From: karn@qualcomm.com (Phil Karn)
Subject: Re: NOS Prototypes.. more ..
To: jbj@USDesign.COM, tcp-group@ucsd.edu
>Ah, the battle of the prototypes. There is a way to keep both sides
>happy.
>Use a macro that looks like
> #if defined(__STDC__) || defined(USE_PROTOTYPES)
> #define P(x) x
> #else
> #define P(x) ()
> #endif
That's exactly what I'm doing now, only the macro is named __ARGS()
instead of P(). (The specific name was suggested by Louie Mamakos who
saw it used on the Amiga.)
Only it can make for some really ugly declarations (consider a pointer to
a function that takes as an argument another pointer to a function...)
I would like to go through the code, remove the macros and rewrite everything
in new ANSI form. But only if it won't cause a hardship for somebody who's
still stuck with a pre-ANSI compiler and can't for some reason use unproto.
Phil
------------------------------
Date: 02 Apr 1993 12:09:43 +1000
From: CCDRW@cc.newcastle.edu.au
Subject: User Applications
To: tcp-group@ucsd.edu
In Carl's mail message dated 1-APR-1993 at 15:33 he said -
....
>
>Not only should we be looking at some new whizz bang transport protocol, we
>should also be looking at the services we want packet radio to provide for
>us. It is the services we want to provide which make packet radio useful.
>
>Carl.
>
>--
As an example, have any of you seen Novell's 'Host Presenter' in their LAN
workplace for DOS. I think they've got a good concept there, some very rough
edges, but Windows with files from the remote host that can be dragged to my
host without me manually FTPing to the host, selecting the (sub)directory,
typing the proper file name etc. is a neat concept. We add a distributed file
system and stop everyone having to R95 or whatever messages in BBS land.
WHILE WE WORK ON THE RELIABLE BANDWIDTH AND PROTOCOLS LETS KEEP SOME OF THESE
IDEAS GOING TOO!
Dave VK2XPX, sysop VK2RAP.
Internet | ccdrw@cc.newcastle.edu.au
Amprnet | vk2xpx@vk2xpx.ampr.org
------------------------------
Date: Thu, 1 Apr 93 21:12:17 MST
From: jsteinhu@nyx.cs.du.edu (Josh Steinhurst)
Subject: User Applications
To: tcp-group@ucsd.edu
> >Not only should we be looking at some new whizz bang transport protocol, we
> >should also be looking at the services we want packet radio to provide for
> >us. It is the services we want to provide which make packet radio useful.
> As an example, have any of you seen Novell's 'Host Presenter' in their LAN
> workplace for DOS. I think they've got a good concept there, some very rough
> edges, but Windows with files from the remote host that can be dragged to my
> host without me manually FTPing to the host, selecting the (sub)directory,
> typing the proper file name etc. is a neat concept. We add a distributed file
> system and stop everyone having to R95 or whatever messages in BBS land.
>
> WHILE WE WORK ON THE RELIABLE BANDWIDTH AND PROTOCOLS LETS KEEP SOME OF THESE
> IDEAS GOING TOO!
Although I am no real programmer (In fact it has been quite some time) It
seems to *ME* that all it would take to do this is A FTP client (assuming
that a new protocol is not introduced) capable of reading the directory
automaticly and presenting you with a graphic interface. A lot like a
gopher program. (In the DOS - WINDOWS scheme of life maybe network driver
that uses a window to set up a FTP connection, and then makes the
connected drive a 'networked' drive. Usable as any other directory.
)
Of course we are getting to the point where NOS can't hack it
because of it's single program approach (Not a flame in any way, simply a
statment of overstated fact) Although, (I am not a dos guy so read with a
salt block handy) maybe breaking the program down into TSRs( or INITs if
you are into macintoshs :) that intercept calls to the 'ftp' port or such
nosense, and then standalone programs that act as clients. Unfortunatly
this would be hard without multi-tasking.. :( (one solution to this is that
single free-standing programs useing the same protocols (i.e normal TCP-IP
suite stuff) would still be compatible with it.
basicly, my point is, (I admit i started writing about something
specific and couldn't stop) that once you enough low-leval protocaols the
application software is resposible. However the applications tend to
'rather' sparten. (I.e. FTP) even though there is no need. Things can be
improved a lot without increasing network traffic.
Well that is enogh rambling...
Disclaimer: I have never used a NOS set-up (Only read the docs) logged oh
maybe 3 hours of packet use altogether, am not a programmer anymore of
any-type, and am still in high school.
------------------------------
Date: Thu, 1 Apr 93 13:23:09 MST
From: "Marvin Match" <match@[128.110.44.31]>
Subject: Utah Backbone/Network Services
To: tcp-group@ucsd.edu
My comments spark such discussions.
I very much appreciate the comments I read on this group concerning my
proposed plans to build a T1-rate backbone through Utah. Rather than reply
to every post along this line, I'm going to try to interject several
comments all at once.
Steve Sampson wrote:
"Nothing we are doing today really is useful when high speed systems can
get you out of the 1200 baud limits. Who's working on this and where do
I subscribe?"
Steve, I'm working on this, and you subscribe right here.
Lyndon Nerenburg wrote:
"You are confusing network transport speed with lack of applications
software. Gigabit networks are about as useful as 1200 bps networks
if there are no applications to layer on top of them."
Agreed, but no applications are going to be written until a high-speed
network is in place.
Carl Makin wrote:
"eh? Without applications, at *any* speed, packet radio is
only a toy. Asignificant part of what has made packet radio popular is
the BBS network.Now I don't want arguments that it's crippled, I know
that, however it hasbeen a major factor in user population growth.
Without that userpopulation to provide funds for this "improved" network
it will *never*come about.
Applications have to be developed *at the same time* as the network they
will run on!"
Carl, this is a good point. Now, I'm trying to push some high-speed
hardware, guys are looking into the protocols, who's writing applications?
I see nobody. (If I'm incorrect, flame away) Why? Nothing to run them on.
Sure not going to happen as long as we're stuck with the 1200 baud AX.25
boondoggle.
Case in point. Why do all the BBS's have to forward everything to every
other BBS? Why not just propogate pointers the way Gopher does? It's
because the current network (sic) can't do it, that's why.
Incedently, I guess we keep comparing packet radio to resources on Internet
because all of us in this discussion have Internet access and are familiar
with it. This is OK, but I think that if we have a high-speed network of
our own, we could do some things that will probably never happen on The
Internet. How about adding a channel or two for analog voice and video?
It's do-able on the u-wave bands. Who's creating that application? Or
digitized voice and video? Who's doing that? No-one is and no-one will
until the HARDWARE is in place. (If anyone is thinking about these things
then go for it. Don't wait. If I get my way the hardware will be here
before you know it.) Packet radio will never be Internet, nor should it.
Speaking of protocols, Louis a. Mamakos wrote:
"Nothing I've seen so far seems particularly far afield from the general
topic of TCP/IP over amateur packet radio. None of if it is particularly
advanced.
Surely TCP/IP is an order of magnitude better than AX.25, but I hope no-
one believes that straight-out-of-the-box TCP/IP is the answer. Those
working on this part realize it. The Internet has almost outgrown the
current addressing scheme, so TCP/IP will have to evolve some. Anyway
TCP/IP via wire is a whole different animal than TCP/IP via radio, though
they share most of their genes. Maybe the next protocol will something
entirely new, I don't know, and I don't think it matters. The real problem
is in the hardware, at least for today.
Well enough for today. Just my 8 cents worth (inflation you know!)
Marvin Match
KA7TPH
------------------------------
Date: Thu, 1 Apr 93 21:11:57 -0800
From: karn@qualcomm.com (Phil Karn)
Subject: Utah Backbone/Network Services
To: match@civil.utah.edu, tcp-group@ucsd.edu
>Incedently, I guess we keep comparing packet radio to resources on Internet
>because all of us in this discussion have Internet access and are familiar
>with it. This is OK, but I think that if we have a high-speed network of
>our own, we could do some things that will probably never happen on The
>Internet. How about adding a channel or two for analog voice and video?
Uh, the Internet is already carrying voice and video. I'm typing this
from the IETF meeting in Columbus Ohio. This afternoon I gave a talk
on wireless data to the plenary, and it was carried live over the
Internet using the Multicast Backbone. The audio is conventional
64kb/s mu-law PCM, and the video is compressed medium-scan (several
frames/sec) B&W at 100-300 kb/s.
And there's something called "Internet Talk Radio" that's just starting
up. Obviously it's going to take a little more bandwidth to run similar
applications on AMPRNET.
>TCP/IP via wire is a whole different animal than TCP/IP via radio, though
>they share most of their genes.
Don't forget that the original motivation for TCP/IP was the
transparent interconnection of the ARPANET with the DARPA packet radio
networks. I doubt you'll see any radical changes in the architecture.
When Ethernet first came out, it was described as "packet radio on a
cable". Now you hear packet radio described as "ethernet over radio".
And so it goes.
Phil
------------------------------
Date: Thu, 1 Apr 93 21:23:44 EST
From: Lyman Byrd <lyman@attwat.twuug.com>
Subject: wampes for linux?
To: tcp-group@ucsd.edu
Could someone please email me the location of the lastest wampes port to
linux please? Thanks for the help. (BTW - I did check ucsd.edu and found the
version for hp-ux but no linux. If it is there then please let me know more
about it. tks)
--
Lyman/wa4yse
PBBS: wa4yse@kj4lq.va.usa.noam IP ADDRESS: [44.62.64.80]
INTERNET: lyman@attwat.twuug.com
------------------------------
Date: Thu, 1 Apr 93 22:49:00 MST
From: Dieter Deyke <deyke@mdddhd.fc.hp.com>
Subject: wampes for linux?
To: lyman@attwat.twuug.com, tcp-group@ucsd.edu
> Could someone please email me the location of the lastest wampes port to
> linux please? Thanks for the help. (BTW - I did check ucsd.edu and found the
> version for hp-ux but no linux. If it is there then please let me know more
> about it. tks)
> --
> Lyman/wa4yse
> PBBS: wa4yse@kj4lq.va.usa.noam IP ADDRESS: [44.62.64.80]
> INTERNET: lyman@attwat.twuug.com
There is no separate WAMPES version for linux, use the one you found on
ucsd.edu, it contains support for all systems in one package.
73,
Dieter
------------------------------
End of TCP-Group Digest V93 #85
******************************
******************************