Date: Thu, 1 Apr 93 04:30:08 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 #84
To: tcp-group-digest
TCP-Group Digest Thu, 1 Apr 93 Volume 93 : Issue 84
Today's Topics:
Internet Gateway (8 msgs)
KA9Q NOS questions
NOS Prototypes.. more.. (2 msgs)
TCP-Group Digest V93 #83 (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: Wed, 31 Mar 93 09:20:49 MST
From: Lyndon Nerenberg <Lyndon.Nerenberg@ns.unbc.edu>
Subject: Internet Gateway
To: Steve Sampson <ssampson@sabea-oc.af.mil>
> It relies on the "*** LINKED TO" command
> which is priveleged in NOS (because people want to use NOS with
> Internet, they cripple the Amateur Radio functions).
I don't undrstand this statement. Could you clarify what you mean here?
> 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.
> I don't really like most of the "improvements" done since. When
I don't understand this either. What, exactly, don't you like?
> someone asks me how they can get on the Internet, I ask them why
> they would want to; given the fact that they can design a much
> faster system using cheap modems and keeping their data internal.
Will this system allow them access to sites such as uunet, simtel,
wuarchive? Will it let them get near realtime solar and propogation
information from the University of Lethbridge? Will it let them
subscribe to Internet Talk Radio? And just what are these cheap
modems that are faster than the current T3 backbone - I want some!
> Mostly they just want to subscribe to alt.sex.beastiality or some
> such nonsense. What they really need is Internet mail transport,
> which can be done with the cheaper uucp protocol.
Usenet != Internet. Mail can be transported over damned near anything.
Just look at the current AX25 BBS forwarding fiasco for an example
of how little it really takes.
> I really appreciate the simplicity of Net/Rom node tables.
As compared to what? If you want simplicity, run RIP.
> access port should be updated with node lists from other systems
> on the network. Each network link should know how to route the
> datagrams to get one user node to a distant node.
Sounds a lot like OSPF to me. Of course, that's one of those "improvements"
you are against.
> [ ... ] 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?
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. Why don't you
start writing some?
------------------------------
Date: Wed, 31 Mar 1993 16:12:47 -0600 (CST)
From: Steve Sampson <ssampson@sabea-oc.af.mil>
Subject: Internet Gateway
To: TCP-Group@UCSD.Edu
Lyndon Nerenberg says:
> [a bunch of self-righteous finger-pointing stuff deleted]
I don't really appreciate replies that are total paraphrasing attacks or
spelling Bee check marks. I'm Human, I make errors...
Rather than take issue with each and every point I made, maybe a better
approach would be to outline in your own words where I'm wrong and offer a
better alternative. Expand the discussion rather than cut it off. You can
point out errors, I can take it. But if your sole purpose is to show us how
smart you are as compared to the rest of us, then please unsubscribe and find
another outlet for your ego. I'm too old for it...
------------------------------
Date: Wed, 31 Mar 93 17:37:30 CST
From: andyw@aspen.cray.com (Andy Warner)
Subject: Internet Gateway
To: tcp-group@ucsd.edu (TCP Group)
Steve recently wrote :-
> [...]
> point out errors, I can take it. But if your sole purpose is to show us how
> smart you are as compared to the rest of us, then please unsubscribe and find
> another outlet for your ego. I'm too old for it...
Whoa, hold on a minute - you're the one that graced us with your view
of the world & what you thought of it, prefaced with "since things
are a little quiet on tcp group right now..", or words to that
effect.
Quite what the hell UUCP has to do with tcp over radio, I never did
quite figure out..
If you don't like flames, don't post flame-bait.
--
andyw. N0REN/G1XRL
andyw@aspen.cray.com Andy Warner, Cray Research, Inc. (612) 683-5835
------------------------------
Date: Wed, 31 Mar 1993 17:46:24 -0600 (CST)
From: Steve Sampson <ssampson@sabea-oc.af.mil>
Subject: Internet Gateway
To: TCP-Group@UCSD.Edu
>> It relies on the "*** LINKED TO" command
> I don't undrstand this statement. Could you clarify what you mean here?
yes, it means that when you come out of a distant TEXNET node your
callsign is that of the node. Therefore some method of switching the callsign
back to yours is needed. Thus the "*** LINKED TO W1AW" command or whatever, is
used. Check out the source code for how it works. But in NOS it is a
priveleged command. So when I come out of TEXNET and connect to a NOS machine,
I type a *** Linked to n5owk and he's supposed to say: oh hello n5owk! At that
point any further transactions are done with my callsign.
>> 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.
>> I don't really like most of the "improvements" done since. When
> I don't understand this either. What, exactly, don't you like?
The point that you missed was that I don't think we can solve our amateur
radio needs by hopping onto a wire-line non-RF based system. Beyond that,
the internet was an effective means to transfer files and send mail. The
improvements I don't like (as compared to uucp, or windows) is the long
sets of commands to get to the point where you can send a file. I have
done, and seen others perform an FTP at 1200 baud, and it takes several
minutes over distance to get to the point where bytes are flowing. You
have to log on, switch to binary, etc, etc. Surely this isn't the final
version of FTP??
>> someone asks me how they can get on the Internet, I ask them why
>> they would want to; given the fact that they can design a much
>> faster system using cheap modems and keeping their data internal.
> Will this system allow them access to sites such as uunet, simtel,
> wuarchive? Will it let them get near realtime solar and propogation
> information from the University of Lethbridge? Will it let them
> subscribe to Internet Talk Radio? And just what are these cheap
> modems that are faster than the current T3 backbone - I want some!
You assume those archive sites and services are so important that any
computer network would be incomplete without them and that you can afford
the overhead (data and price) of thousands of users playing Talk Radio while
you're trying to ship a damn database to the accountants office of the XYZ
company. I can get the performance they need with a 14.4 modem and direct
dial and save them 21 hops to the west coast. We're running a 19.2 kbps modem
at this site, so your assumption that the whole network is T3 is not true.
>> I really appreciate the simplicity of Net/Rom node tables.
> As compared to what? If you want simplicity, run RIP.
What I would like to see is a list of english (or spanish, or whatever) words
that tell me where I can get to via this network. Maybe a city name, followed
by a list of servers that are available. Rather than a list of callsigns and
low level node statistics of which interest only a the typical guru type.
>> access port should be updated with node lists from other systems
>> on the network. Each network link should know how to route the
>> datagrams to get one user node to a distant node.
> Sounds a lot like OSPF to me. Of course, that's one of those "improvements"
> you are against.
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.
>> [ ... ] 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?
> 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. Why don't you
> start writing some?
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 letter was mean't to state my feeling that 1200 baud packet is probably
alot of fun for two people, but that the Utah group has taken the right steps
in both speed and configuration to transport those two people into a larger
network. The hardware design from Ham Radio which is published in the latest
ARRL Handbook will probably support this design very well. But then you can't
very well hook this fancy stuff up to a Net/Rom clone, and something of
greater substance software-wise needs to be attached to the hardware to
complete the transport of user data. That's where my interest is.
---
73, Steve, N5OWK
------------------------------
Date: Wed, 31 Mar 93 16:29:22 HST
From: Antonio Querubin <tony@mpg.phys.hawaii.edu>
Subject: Internet Gateway
To: Steve Sampson <ssampson@sabea-oc.af.mil>
> Lyndon Nerenberg says:
> > [a bunch of self-righteous finger-pointing stuff deleted]
^^^^^^^^^^^^^^
That's odd. Your choice of words in your original message made me
think the same thing.
Antonio Querubin
tony@mpg.phys.hawaii.edu / ah6bw@uhm.ampr.org / querubin@uhunix.bitnet
------------------------------
Date: Wed, 31 Mar 93 21:44:47 EDT
From: "Ross Patterson" <n4yyh@wa2hee.ampr.org>
Subject: Internet Gateway
To: ssampson@sabea-oc.af.mil
On Tue, 30 Mar 1993 19:44:10 -0600 (CS, Steve Sampson wrote:
>Oklahoma doesn't have any Internet gateways because Amateur
>Radio has never attracted the colleges or the National Weather
>Service. They each have all they can handle or need, and Hams
>would just bog things down at 1200 baud (30 baud effective on a
>good day).
If your NWS hasn't been attracted to packet radio, point them at the NWS
Washington Forecast Office, in Sterling VA (one of the Washington DC burbs).
During "The Blizzard of '93", hams operated a SkyWarn net using both 2m FM
and 2m packet to collect over a thousand storm reports. SkyWarn has a
large involvement with the Amateur community here, and they're learning to
love packet, especially for reports from areas beyond the reach of voice
repeaters.
73,
Ross N4YYH
------------------------------
Date: Thu, 1 Apr 1993 14:07:59 +1000
From: makinc@hhcs.gov.au
Subject: Internet Gateway
To: tcp-group@ucsd.edu
>> 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. Why don't you
>> start writing some?
> 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.
eh? Without applications, at *any* speed, packet radio is only a toy. A
significant 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 has
been a major factor in user population growth. Without that user
population 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!
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.
--
Carl Makin (VK1KCM) Systems Programmer
Internet: makinc@hhcs.gov.au
Amprnet: vk1kcm@vk1kcm.act.aus.oc
Work Phone: +61 6 289-9443
------------------------------
Date: Thu, 1 Apr 1993 09:54:29 +0200 (EET)
From: mea@Mea.cc.utu.fi ("Matti E. Aarnio [OH1MQK]")
Subject: Internet Gateway
To: TCP-Group@UCSD.EDU
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?
>
> The point that you missed was that I don't think we can solve our amateur
> radio needs by hopping onto a wire-line non-RF based system. Beyond that,
> the internet was an effective means to transfer files and send mail. The
> improvements I don't like (as compared to uucp, or windows) is the long
> sets of commands to get to the point where you can send a file. I have
> done, and seen others perform an FTP at 1200 baud, and it takes several
> minutes over distance to get to the point where bytes are flowing. You
> have to log on, switch to binary, etc, etc. Surely this isn't the final
> version of FTP??
Yes, it is archaic, isn't it ? However that is the FTP protocol.
Nobody says that your FTP client must let difficult points of the
protocol to be visible to you. (They usually do, unfortunately..)
> >> someone asks me how they can get on the Internet, I ask them why
> >> they would want to; given the fact that they can design a much
> >> faster system using cheap modems and keeping their data internal.
> >
> > Will this system allow them access to sites such as uunet, simtel,
> > wuarchive? Will it let them get near realtime solar and propogation
> > information from the University of Lethbridge? Will it let them
> > subscribe to Internet Talk Radio? And just what are these cheap
> > modems that are faster than the current T3 backbone - I want some!
>
> You assume those archive sites and services are so important that any
> computer network would be incomplete without them and that you can afford
> the overhead (data and price) of thousands of users playing Talk Radio while
> you're trying to ship a damn database to the accountants office of the XYZ
> company. I can get the performance they need with a 14.4 modem and direct
> dial and save them 21 hops to the west coast. We're running a 19.2 kbps modem
> at this site, so your assumption that the whole network is T3 is not true.
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 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
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)
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..)
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..)
> >> I really appreciate the simplicity of Net/Rom node tables.
> > As compared to what? If you want simplicity, run RIP.
>
> What I would like to see is a list of english (or spanish, or whatever) words
> that tell me where I can get to via this network. Maybe a city name, followed
> by a list of servers that are available. Rather than a list of callsigns and
> low level node statistics of which interest only a the typical guru type.
>
> >> access port should be updated with node lists from other systems
> >> on the network. Each network link should know how to route the
> >> datagrams to get one user node to a distant node.
> > Sounds a lot like OSPF to me. Of course, that's one of those "improvements"
> > you are against.
>
> 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.
This talk about low-level nuts and bots of network is meaningless in
point of view of end-user, when user applications hide such a things
deep inside the machine. When applications let everything to be visible,
users will see those nuts and bolts, and get confused..
Still, I will talk about nuts & bolts also:
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).
Hard-disks may be cheap enough, however currently average network router
interaction overhead at the Internet is in order of 2-5 % of total bandwidth.
(and that is on HIGH-speed rarely chancing network configuration..)
In the end we need a Mobile-IP routing in addition to stationary station
routing, and while stationary (home) stations do tend to keep their positions
in the routing matrix, Mobiles don't..
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 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?
> > 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. Why don't you
> > start writing some?
>
> 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..
> My letter was mean't to state my feeling that 1200 baud packet is probably
> alot of fun for two people, but that the Utah group has taken the right steps
> in both speed and configuration to transport those two people into a larger
> network. The hardware design from Ham Radio which is published in the latest
> ARRL Handbook will probably support this design very well. But then you can't
> very well hook this fancy stuff up to a Net/Rom clone, and something of
> greater substance software-wise needs to be attached to the hardware to
> complete the transport of user data. That's where my interest is.
Well, the AX.25 is flawed, TEXNET (ROSE) X.25 is absurd as well,..
We do need new style of parcels, which I hope contain HDLC framing,
but what will be proper modulation, and what else to put into those
frames in addition to the user data ?
To have forward-error-correction in modulated datapath would be nice
in deed... However TNC will no more be simple ASYNC-HDLC converter
plus 1200 bps modem, but also FEC-(de)coder.
Present price of necessary hardware should not scare developers.
In electronics business everything which is mass-produced does get
cheaper all the time. ( Try to recall what IBM PC did cost when
it was introduced, and what it had at that price! )
It just takes some time...
> 73, Steve, N5OWK
73, Matti, OH1MQK
------------------------------
Date: Wed, 31 Mar 93 22:53:51 BST
From: john@its.bt.co.uk
Subject: KA9Q NOS questions
To: tcp-group@ucsd.edu
Wed Mar 31: Steve Wright <Steve_Wright@kcbbs.gen.nz> wrote:
>
> >From: gerry@cs.tamu.edu (Gerald J Creager)
> >Subject: KA9Q NOS questions...
> >3. TNC config:
> >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).
John
--
Office: jvt@its.bt.co.uk
Home: john@its.bt.co.uk || john@g4rev.ampr.org || G4REV @ GB7TCP.#16.GBR.EU
------------------------------
Date: Wed, 31 Mar 93 10:16:59 EST
From: crompton@NADC.NADC.NAVY.MIL (D. Crompton)
Subject: NOS Prototypes.. more..
To: nos-bbs@hydra.carleton.CA
Well I spend a few hours last night cleaning up the prototype problems
in NOS(wg7j). I ended up with a DIFFERENT exe size, larger by about 200 bytes.
This tells me that some parameters were possibly not being passed or
returned correctly. I also caught a few parameter problems that resulted
in compile errors once a prototype was defined.
The bottom line is this - WE MUST use prototypes - take the -w-pro option
out of the makefile! Also why do we use the .h dependencies in the makefile?
This is just another area where errors can arise. Why not use .autodepend
instead.
I have not fixed everything because many modules are ifdef'ed out depending
on the configuration. Two that are particuliary bad (pages of errors) are
converse.c and twin_at, neither of which I use.
Actually all warnings could probably be turned off and corrected but at
the moment I just attacked the prototype problem.
Another point - why are we not using the MODERN declaration style, at
least in new code. I have done it in any code that I write for NOS -
at times others have changed it back!
This reminds me of the 8088 syndrome - that is progress is impeded because
everything is tied to some old standard. Lets get with the modern way of
'c' programming PLEASE!!
Before we go on to make anymore feature changes to NOS lets take a few
moments to clean up the current base. I will send my changes to Johan
and hopefully he will start out with a new - no reported errors version.
Doug
------------------------------
Date: Wed, 31 Mar 1993 15:49:24 -0600
From: miltonm@inetnode.austin.ibm.com (Milton Miller)
Subject: NOS Prototypes.. more..
To: crompton@NADC.NADC.NAVY.MIL, nos-bbs@hydra.carleton.CA
In <9303311516.AA13067@NADC.NADC.NAVY.MIL>, Doug Crompton <crompton@NADC.NADC.NAVY.MIL> writes:
> The bottom line is this - WE MUST use prototypes - take the -w-pro option
> out of the makefile! Also why do we use the .h dependencies in the makefile?
> This is just another area where errors can arise. Why not use .autodepend
> instead.
If you want to use features of your compiler, fine. But don't
impeed others without such features as autodepend.
> Another point - why are we not using the MODERN declaration style, at
> least in new code. I have done it in any code that I write for NOS -
> at times others have changed it back!
1) You still have the protoype, if your compiler supports them.
2) When I compile with a NON-ANSI compiler, I don't have to fix
every function.
milton
------------------------------
Date: Wed, 31 Mar 93 15:18:18 EST
From: Postmaster@alis3.daytonoh.ncr.com
Subject: TCP-Group Digest V93 #83
To: tcp-group@ucsd.edu
Returned Mail: Could not find any To: or Cc: recipients.
*** Returned Mail Message Follows: ***
------------------------------
Date: Wed, 31 Mar 93 04:30:10 PST
From: Advanced Amateur Radio Networking Group <tcp-group@ucsd.edu>
Subject: TCP-Group Digest V93 #83
To: tcp-group-digest@ucsd.edu
TCP-Group Digest Wed, 31 Mar 93 Volume 93 : Issue 83
Today's Topics:
Internet Gateway (2 msgs)
KA9Q NOS questions
ka9q telnet linemode support
rec.radio.amateur.packet Frequently Asked Questions
subscribe local-tcp-group@nebulus.ampr.ab.ca
TCP-Group Digest V93 #82 (3 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: Tue, 30 Mar 1993 19:44:10 -0600 (CST)
From: Steve Sampson <ssampson@sabea-oc.af.mil>
Subject: Internet Gateway
To: TCP-Group@UCSD.Edu
Well since the group isn't very busy right now, I thought I'd
inject some commentary on the state of packet networking. Alot
of the problems Marvin is experiancing are common. Even here in
Oklahoma most of the packet activity is 1200 baud. There has
never been a real need for data and therefore most communica-
tions are voice. We had some experimentation with repeater
voice links, but these quickly died off when the maturity level
wasn't sufficient enough to justify it. These links are magnets
for abuse, although making the access ports UHF only tends to
chop off a lot of this. The Oklahoma packet system is based on
a 1200 baud 446 MHz "backbone" (the backbone is so two BBS's can
forward and they use up the total bandwidth) and a 1200 baud 145
MHz user access. Its performance is pretty bad because it's an
uncoordinated system. Users who want to participate and extend
the outward links to Oklahoma City are mostly interested in BBS
forwarding or communications with friends in other cities. They
quickly find that the links can't support the added nodes, and
shut them down about as fast as they start up. The BBS's
forward on the same frequencies that the users access them!
They usually forward during the evening hours when most normal
people would access them, thus they are a cut above worthless.
Tulsa is not as active in packet as the rest of the state and
supports mostly BBS and DX cluster activity. One man based in
Texas (WB5CQU) has strung a 9600 ROSE link from Dallas to Pauls
Valley OK (south of OKC) and connects to OKC via a DIGI in Ada
OK. Brians last message quoting Marshall Rose as saying OSI is
dead, is pretty funny since Mr. Rose never met ROSE :-) Then
there is the Texnet link to Fort Gibson OK and Fayetville AR.
Anyone who has used either system quickly finds that you have to
know where you're going in order to get there, because Texnet
doesn't have a heard list, and changes your callsign to that of
the distant node. It relies on the "*** LINKED TO" command
which is priveleged in NOS (because people want to use NOS with
Internet, they cripple the Amateur Radio functions). Rose has a
heard list but most people go to sleep waiting for it. OSI *is*
dead and the slow ROSE proves it. Even at 9600 ROSE is too damn
slow. I often wonder how it would improve if they were all
Net/Rom.
Oklahoma doesn't have any Internet gateways because Amateur
Radio has never attracted the colleges or the National Weather
Service. They each have all they can handle or need, and Hams
would just bog things down at 1200 baud (30 baud effective on a
good day). Most of the Hams I know who are into advanced
networking appreciate the fact that you can connect to Australia
via 2 meter packet links to the Internet, but I can do that via
a phone modem also, so why bother with RF? We can give 2 meters
and 70 cm to business users and go strictly phone operation at
much greater throughput. This will reduce the National problem
of spectrum expansion. One town in Oklahoma has converted its
whole phone system to RF, so that's the economical way to go, as
you don't need to invest in the infrastructure of poles, wires,
or employees that mess with these things. Also you reduce your
insurance premiums by removing multi-million dollar lawsuits
that occur everytime some moron (who deserves to die in order
to clean out the weak genes) runs into a pole at 70 MPH.
So with that introduction I really appreciate the steps that the
Utah group have advanced. Full Duplex, *very* high speed
packet. This will get us up to the 1950's RF technology-wise,
and improve the system greatly. Bonneville Power Administration
(BPA) had microwave repeaters and multiplexed up to 24 voice
channels way back then (Philco CLR-6: 1 Watt RF at 6.2 GHz for
20 to 40 mile links, FM, 6 MHz Deviation with 20 MHz channel
bandwidth). This very old RF technology combined with modern
high speed modems (56 kbps and 1.5 Mbps) is the way to trunk or
backbone the states. Every trunk site should have a 1200 bps
access node (unless no one lives within it's view). This is
amateur style and could be as good or better than Internet. I
was on the Internet when it was pure uucp, and to tell the truth
I don't really like most of the "improvements" done since. When
someone asks me how they can get on the Internet, I ask them why
they would want to; given the fact that they can design a much
faster system using cheap modems and keeping their data internal.
Mostly they just want to subscribe to alt.sex.beastiality or some
such nonsense. What they really need is Internet mail transport,
which can be done with the cheaper uucp protocol.
I really appreciate the simplicity of Net/Rom node tables. Each
access port should be updated with node lists from other systems
on the network. Each network link should know how to route the
datagrams to get one user node to a distant node. There needs
to be some thinking as to how the user ports are linked to the
high speed network and that means shoving all of that 1200 bps
architecture off your desk and into the wastebasket. When I
connect to an user port, all I want is to be transported to a
BBS that handles data that I'm interested in (let's get rid of
the current bullshit of covering the whole spectrum on every
damn BBS and sucking the channels dry by forwarding this crap),
or be zoomed to some city so that I can get a list of amateurs
interested in what I am, etc, etc. 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?
Well I see my time is up...
---
73, N5OWK, Steve
------------------------------
Date: Tue, 30 Mar 93 20:00:01 -0800
From: karn@qualcomm.com (Phil Karn)
Subject: Internet Gateway
To: Steve Sampson <ssampson@sabea-oc.af.mil>, TCP-Group@UCSD.Edu
At 07:44 PM 3/30/93, Steve Sampson wrote:
Rose has a
>heard list but most people go to sleep waiting for it. OSI *is*
>dead and the slow ROSE proves it.
Actually, ROSE isn't even OSI. It's just the X.25 packet layer on top
of AX.25. Now if you can imagine all of the bloated OSI upper layers
riding on top of that...
Phil
------------------------------
Date: 31 Mar 1993 23:05:12 +1200
From: Steve_Wright@kcbbs.gen.nz (Steve Wright)
Subject: KA9Q NOS questions
To: tcp-group@ucsd.edu
>Date: Sat, 27 Mar 1993 11:41:17 -0600 (CST)
>From: gerry@cs.tamu.edu (Gerald J Creager)
>Subject: KA9Q NOS questions...
Message-Id: <9303312227.AA05995@kcbbs.gen.nz>
Date: 31 Mar 93 22:27:32 EST (Wed)
Hi Gerry.
>3. TNC config:
>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.
regards,
Steve.
------------------------------
Date: Tue, 30 Mar 93 7:48:31 EST
From: John Ackermann AG9V <John.Ackermann@DaytonOH.NCR.COM>
Subject: ka9q telnet linemode support
To: "C.E. Piggott" <cep4478@ultb.isc.rit.edu>
You (C.E. Piggott) write:
>
> Can anybody more qualified than me assess how much work it would be to
> implement RFC-1184 (and the other references to telnet LINEMODE) into
> the incoming telnet support (mailbox) of NOS?
>
> On our IBM AIX 3.2 machine, telnetting into the NOS switch means you
> don't have backspace, kill, etc. processing, unless you escape back to
> telnet and type:
>
> telnet> mode line-by-line
>
> however, if the NOS mailbox requested line mode prior to asking for the
> username, it would work OKAY.
That's a good idea. I always start out (using the WIN-TCP telnet
client) by simply entering telnet, then telling it "linemode" and then
doing an open to the NOS box. That's a pain.
Would it make sense to have the linemode request controlled by the state
of echo accept/refuse? It seems to me that the two are closely
related... if you don't want character echoing, you may as well get data
from the other end a line at a time, too.
John
------------------------------
Date: Tue, 30 Mar 93 14:26:54 +0200
From: ignatios@cs.uni-bonn.de (Ignatios Souvatzis)
Subject: rec.radio.amateur.packet Frequently Asked Questions
To: tcp-group@ucsd.edu
Hi!
I'm member of a group trying to get going an amateur TCP/IP (cable) network in
and around Bonn, Germany. We are using the JNOS 1.08 version of KA9Q NOS on AT's
and 386AT's as router boxes in several places, as it provides (via the packet
driver interface) access to ISDN and ETHERNET cards. We also want to use its PPP
capabilities for modem-dialin access to the network.
Our current problem is the setup of the PAP authentification code of PPP. Has
anybody ever used that and can give us advice as to how to setup it quickly? We
have no success so far.
--
Ignatios Souvatzis
ignatios@cs.uni-bonn.de souva@babsy.mpifr-bonn.mpg.de
(can read 8bit encoded charset iso8859-1 mail: DV\dv|_)
"Digital Incasso Gloriously Increasing To Absolute Limit"
------------------------------
Date: Tue, 30 Mar 1993 20:33:47 -0700
From: dennis@nebulus.ampr.ab.ca (Dennis Breckenridge VE6TCP)
Subject: subscribe local-tcp-group@nebulus.ampr.ab.ca
To: tcp-group@ucsd.edu
subscribe local-tcp-group@nebulus.ampr.ab.ca
--
-------------------------------------------------------------------------------
Dennis Breckenridge VE6TCP To be sure of hitting the target, shoot
dennis@nebulus.ampr.ab.ca first, and call whatever you hit the target.
-------------------------------------------------------------------------------
------------------------------
Date: Tue, 30 Mar 93 16:03:43 EST
From: Postmaster@alis3.daytonoh.ncr.com
Subject: TCP-Group Digest V93 #82
To: tcp-group@ucsd.edu
Returned Mail: Could not find any To: or Cc: recipients.
*** Returned Mail Message Follows: ***
------------------------------
Date: Tue, 30 Mar 93 04:30:09 PST
From: Advanced Amateur Radio Networking Group <tcp-group@ucsd.edu>
Subject: TCP-Group Digest V93 #82
To: tcp-group-digest@ucsd.edu
TCP-Group Digest Tue, 30 Mar 93 Volume 93 : Issue 82
Today's Topics:
Internet gsteway
ka9q telnet linemode support
Marshall Rose on OSI
TCP-Group Digest V93 #80 (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: Mon, 29 Mar 93 10:28:22 MST
From: "Marvin Match" <match@[128.110.44.31]>
Subject: Internet gsteway
To: keithm@wicat.com, tcp-group@ucsd.edu
>
>Date: Fri, 26 Mar 1993 18:46:59 GMT
>From:
mvb.saic.com!unogate!news.service.uci.edu!usc!zaphod.mps.ohio-state.edu!darwin.s
ura.net!sgiblab!spies!wicat!keithm@network.UCSD.EDU
>Subject: Internet Gateway
>To: packet-radio@ucsd.edu
>
>My office mates and I are preparing to put in a packet/internet
>gateway in our office.
Keith, this is great!, but how about trying to co-ordinate with the rest
of the Utah packet community. Have you been following the the discussions
about developements in Utah? I'll try to fill you in.
1. Recently, (last 2 or 3 months) we've had an increadable amount
of INTER-CLUB discussion about the current state of the packet
radio network in Utah. Representatives from UPRA, UARC, UUARC,
BYUARC, VHF society, TCP-IP Users Group, Utah County ARES,
The State of Utah, and others have voiced their disappointment
in the current state of affairs, and have pledged time and
money to correct the problems. As we look into things we're
finding that most of the problems we see (frequent collisions,
high traffic caused by bbs transfers, etc., you name it) are
a result of thinking that "Well, the packet net is grinding to a
halt, therfore we need to add more nodes to handle more traffic"
and of course this compounds the problem because it doesn't
provide a better path, just adds traffic.
2. There is already an Internet gateway going in at BYU. It'll
likely land on 70cm. and provide 9600 baud access.
3. We have asked John Lloyd for additional freqs. in the past as
individuals, and he has (rightly so) commented that "I'm willing
to co-ordinate more freqs. for packet, but before I do, maybe
we should get the blessing of the other groups, so as to assure
that everyone agrees that this is the thing to do."
To this end, we (read group of various Utah ham clubs) will
(or maybe have by now) ask John for at least one additional
2M freq. for Utah county, and 1 or 2 addititional 70cm freqs. for
Utah county. This way ARES can have 145.03 all to themselves.
4. I proposed to the group that we build a real backbone through
Utah. (I know, this has been talked about before) My plan calls
for full-duplex, 1.5Mbps, microwave relay stations crossing the
state East to West and North to South, with access nodes in
each major population center, providing 56Kbps, and 9600bps
spigots. To date, this plan has been recieved well enough that
funds have been committed to study the proposal and to build
a prototype. I've repeatedly posted to tcp-group asking for
comments, and most of the responses have been in agreement with
the plan.
Now, in the interest of Internet bandwidth, I'll come back to earth
>We have an ethernet connection in the office
>and would like to gateway this to packet (probably on 2m).
>
Assuming that this is the best use of this resource (I'm not convinced
that it is). How about considering 70cm, 9600 or 19.2K bps, and let
another node (or two, or three) service the 1200 baud 2M guys and
funnel that traffic to you at the higher rate?
>I have a few questions that are un answered at this point, but mostly
>what I would like is to correspond via e-mail to someone who has done
>this.
>
We are currently bringing an Internet-packet gateway on line here at
the University of Utah. We're using JNOS 108c. We've had mucho problemo
getting this thing to work. It's been a couple of months in the making,
so I hope you guys have alot of time. Are you familiar with NOS?
To be fair, many of the problems we've been chasing are a result of
using an HP9000-S850 to provide a SLIP link. We've recently aquired
an ethernet card (thanks Matt!) so we'll soon abandon the HP.
>My current thoughts are to use the KA9Q NOS as the gateway running
>on a spare 286 PC that we have.
This'll work, but you need 640K base mem and a Meg or so of extended
or the machine will spend all of it's time pounding its hard drive to
death.
>I understand that NOS can talk
>to a KISS mode TNC as well as to ethernet, but may require Clarkson
>drivers for the ethernet. Do these drivers come with NOS? If not
>can I FTP them from somewhere?
>
Depends on the particular ethernet card. Tell me what card you have. I
probably have the driver, or I can tell you where to ftp it from.
>Anyone care to elmer me through this project?
>
Sure. As long as you're willing to co-ordinate with the rest of us! I think
this is where the discussion should start.
Please get involved with us. We need everyone's input. I hope my earlier
comments don't dissuade you and your office-mates. Things always look
harsher in print than intended. My point is, that I would like to see you
do something that can be integrated into the overall plan.
>Thanks!
>
>--
> Keith McQueen, Wicat Systems Inc. , (801)224-6400 | My opinions are |
> Packet: n7hmf @ nv7v.UT.USA.NA | all mine... |
> Internet: keithm@wicat.com | ...so there! |
>
>------------------------------
My pleasure,
Marvin Match
KA7TPH
------------------------------
Date: Mon, 29 Mar 1993 17:54:11 -0500
From: cep4478@ultb.isc.rit.edu (C.E. Piggott )
Subject: ka9q telnet linemode support
To: tcp-group@ucsd.edu
Can anybody more qualified than me assess how much work it would be to
implement RFC-1184 (and the other references to telnet LINEMODE) into
the incoming telnet support (mailbox) of NOS?
On our IBM AIX 3.2 machine, telnetting into the NOS switch means you
don't have backspace, kill, etc. processing, unless you escape back to
telnet and type:
telnet> mode line-by-line
however, if the NOS mailbox requested line mode prior to asking for the
username, it would work OKAY.
Chris
------------------------------
Date: Mon, 29 Mar 93 11:31:49 -0800
From: brian (Brian Kantor)
Subject: Marshall Rose on OSI
To: tcp-group
"... OSI is effectively dead, and is therefore unlikely to exhibit any
positive influence on the market. [...] the author merely notes that,
although he has spent a lot of time working with OSI, he's come to the
conclusion that OSI is now more of a problem than a solution. True,
there are some good ideas there, but these are overshadowed by many
more bad ideas. So, perhaps the future of OSI is that we will scavange
bits and pieces of it, but the author believes that OSI as a whole has
already reached its apogee and is now approaching the 'crash and burn'
phase."
- Marshall T. Rose, _The Internet Message_, p19
------------------------------
Date: Mon, 29 Mar 93 10:08:55 EST
From: Postmaster@alis3.daytonoh.ncr.com
Subject: TCP-Group Digest V93 #80
To: tcp-group@ucsd.edu
Returned Mail: Could not find any To: or Cc: recipients.
*** Returned Mail Message Follows: ***
------------------------------
Date: Sun, 28 Mar 93 04:30:11 PST
From: Advanced Amateur Radio Networking Group <tcp-group@ucsd.edu>
Subject: TCP-Group Digest V93 #80
To: tcp-group-digest@ucsd.edu
TCP-Group Digest Sun, 28 Mar 93 Volume 93 : Issue 80
Today's Topics:
Ftpmotd in jnos v108d (2 msgs)
G8BPQ with IP Router
KA9Q NOS questions... (2 msgs)
TCP-Group Digest V93 #79 (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: Sat, 27 Mar 93 17:43:49 EST
From: Steve Urich <beyonet!steve@gvls1.VFL.Paramax.COM>
Subject: Ftpmotd in jnos v108d
To: TCP-Group@ucsd.edu
Hello, for those of you who are interested I have changed the
ftpmotd in jnos ftpserv to conform to internet standards. I
have put the motd in my version of net and also in a version
of pa0gri. It works with most of the original ka9q ftpcli
including net and most nos except the jnos client with has
a verbose default problem that somebody changed. I sent my
changes to Johan and explained the problem. Its due to the
client remaining quiet till a remote command is ordered
giving it a V_NORMAL verbose. Then the ftpmotd gets shown
when a data port is able to be read verbose. It works normal
with net and other versions of nos clients showing the motd
at 230 AFTER the login as it should be. I mainly changed the
motd routine and added it also to my server because of the
way it was sent out at 220 breaking my ka9q net client. Since
I don't have a dos box to compile jnos I can't fix the jnos
client myself without some debugging since the initial test
with wa3dsp Doug has proven to be ok with my client by a
slight difference in the jnos client because of its verbose.
Since I can't debug and compile jnos because I don't have
a dos box I had wa3dsp compile it for me. It worked ok for
me but the jnos client was coded differently then the vanilla
client code. It looks easy enough to debug if I had a dos
machine an compiler. Here are the diffs to the change from
220 to 230 for the motd.
73 - Steve
----Start `diff -c' ftpserv.c v1.08d----
*** ftpserv.old Wed Mar 24 18:20:45 1993
--- ftpserv.new Fri Mar 26 01:26:59 1993
***************
*** 55,62
};
/* Response messages */
! static char banner[] = "220- %s, KA9Q-NOS FTP version %s\n";
! static char banner1[] = "220 Ready on %s";
static char badcmd[] = "500 Unknown command\n";
static char binwarn[] = "100 Warning: type is ASCII and %s appears to be
binary\n";
static char unsupp[] = "500 Unsupported command or option\n";
--- 55,62 -----
};
/* Response messages */
! static char banner[] = "220 %s, KA9Q-NOS FTP version %s\n";
! static char banner1[] = "230 Ready on %s";
static char badcmd[] = "500 Unknown command\n";
static char binwarn[] = "100 Warning: type is ASCII and %s appears to be
binary\n";
static char unsupp[] = "500 Unsupported command or option\n";
***************
*** 173,179
long t;
int cnt,i;
struct sockaddr_in socket;
- FILE *fp;
sockmode(s,SOCK_ASCII);
memset((char *)&ftp,0,sizeof(ftp)); /* Start with clear slate */
--- 173,178 -----
long t;
int cnt,i;
struct sockaddr_in socket;
sockmode(s,SOCK_ASCII);
memset((char *)&ftp,0,sizeof(ftp)); /* Start with clear slate */
***************
*** 197,209
log(s,"open FTP");
usprintf(s,banner,Hostname,Version);
- if((fp = fopen(Ftpmotd,"r")) != NULL) {
- while(fgets(buf,128,fp)) {
- rip(buf);
- usprintf(s,"220- %s\n",buf);
- }
- fclose(fp);
- }
time(&t);
cp = ctime(&t);
--- 196,201 -----
log(s,"open FTP");
usprintf(s,banner,Hostname,Version);
time(&t);
cp = ctime(&t);
***************
*** 211,218
if((cp1 = strchr(cp,'\n')) != NULLCHAR)
*cp1 = '\0';
#endif
-
- usprintf(s,banner1,cp);
loop: if((cnt = recvline(s,buf,sizeof(buf))) == -1){
/* He closed on us */
--- 203,208 -----
if((cp1 = strchr(cp,'\n')) != NULLCHAR)
*cp1 = '\0';
#endif
loop: if((cnt = recvline(s,buf,sizeof(buf))) == -1){
/* He closed on us */
***************
*** 568,574
struct ftpserv *ftp;
char *pass;
{
! char *path;
char *p;
int anony = 0;
--- 558,564 -----
struct ftpserv *ftp;
char *pass;
{
! char *path,buf[128],*cp;
char *p;
long t;
FILE *fp;
***************
*** 570,575
{
char *path;
char *p;
int anony = 0;
path = mallocw(200);
--- 560,567 -----
{
char *path,buf[128],*cp;
char *p;
+ long t;
+ FILE *fp;
int anony = 0;
path = mallocw(200);
***************
*** 590,595
if((p = strchr(path,';')) != '\0')
*p = '\0'; /* delimit initial cd */
#endif
if(!anony){
usprintf(ftp->control,logged);
--- 582,598 -----
if((p = strchr(path,';')) != '\0')
*p = '\0'; /* delimit initial cd */
#endif
+ time(&t);
+ cp = ctime(&t);
+ usprintf(ftp->control,banner1,cp);
+
+ 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);
---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: Sat, 27 Mar 93 17:43:49 EST
From: Steve Urich <beyonet!steve@gvls1.VFL.Paramax.COM>
Subject: Ftpmotd in jnos v108d
To: TCP-Group@ucsd.edu
Hello, for those of you who are interested I have changed the
ftpmotd in jnos ftpserv to conform to internet standards. I
have put the motd in my version of net and also in a version
of pa0gri. It works with most of the original ka9q ftpcli
including net and most nos except the jnos client with has
a verbose default problem that somebody changed. I sent my
changes to Johan and explained the problem. Its due to the
client remaining quiet till a remote command is ordered
giving it a V_NORMAL verbose. Then the ftpmotd gets shown
when a data port is able to be read verbose. It works normal
with net and other versions of nos clients showing the motd
at 230 AFTER the login as it should be. I mainly changed the
motd routine and added it also to my server because of the
way it was sent out at 220 breaking my ka9q net client. Since
I don't have a dos box to compile jnos I can't fix the jnos
client myself without some debugging since the initial test
with wa3dsp Doug has proven to be ok with my client by a
slight difference in the jnos client because of its verbose.
Since I can't debug and compile jnos because I don't have
a dos box I had wa3dsp compile it for me. It worked ok for
me but the jnos client was coded differently then the vanilla
client code. It looks easy enough to debug if I had a dos
machine an compiler. Here are the diffs to the change from
220 to 230 for the motd.
73 - Steve
----Start `diff -c' ftpserv.c v1.08d----
*** ftpserv.old Wed Mar 24 18:20:45 1993
--- ftpserv.new Fri Mar 26 01:26:59 1993
***************
*** 55,62
};
/* Response messages */
! static char banner[] = "220- %s, KA9Q-NOS FTP version %s\n";
! static char banner1[] = "220 Ready on %s";
static char badcmd[] = "500 Unknown command\n";
static char binwarn[] = "100 Warning: type is ASCII and %s appears to be
binary\n";
static char unsupp[] = "500 Unsupported command or option\n";
--- 55,62 -----
};
/* Response messages */
! static char banner[] = "220 %s, KA9Q-NOS FTP version %s\n";
! static char banner1[] = "230 Ready on %s";
static char badcmd[] = "500 Unknown command\n";
static char binwarn[] = "100 Warning: type is ASCII and %s appears to be
binary\n";
static char unsupp[] = "500 Unsupported command or option\n";
***************
*** 173,179
long t;
int cnt,i;
struct sockaddr_in socket;
- FILE *fp;
sockmode(s,SOCK_ASCII);
memset((char *)&ftp,0,sizeof(ftp)); /* Start with clear slate */
--- 173,178 -----
long t;
int cnt,i;
struct sockaddr_in socket;
sockmode(s,SOCK_ASCII);
memset((char *)&ftp,0,sizeof(ftp)); /* Start with clear slate */
***************
*** 197,209
log(s,"open FTP");
usprintf(s,banner,Hostname,Version);
- if((fp = fopen(Ftpmotd,"r")) != NULL) {
- while(fgets(buf,128,fp)) {
- rip(buf);
- usprintf(s,"220- %s\n",buf);
- }
- fclose(fp);
- }
time(&t);
cp = ctime(&t);
--- 196,201 -----
log(s,"open FTP");
usprintf(s,banner,Hostname,Version);
time(&t);
cp = ctime(&t);
***************
*** 211,218
if((cp1 = strchr(cp,'\n')) != NULLCHAR)
*cp1 = '\0';
#endif
-
- usprintf(s,banner1,cp);
loop: if((cnt = recvline(s,buf,sizeof(buf))) == -1){
/* He closed on us */
--- 203,208 -----
if((cp1 = strchr(cp,'\n')) != NULLCHAR)
*cp1 = '\0';
#endif
loop: if((cnt = recvline(s,buf,sizeof(buf))) == -1){
/* He closed on us */
***************
*** 568,574
struct ftpserv *ftp;
char *pass;
{
! char *path;
char *p;
int anony = 0;
--- 558,564 -----
struct ftpserv *ftp;
char *pass;
{
! char *path,buf[128],*cp;
char *p;
long t;
FILE *fp;
***************
*** 570,575
{
char *path;
char *p;
int anony = 0;
path = mallocw(200);
--- 560,567 -----
{
char *path,buf[128],*cp;
char *p;
+ long t;
+ FILE *fp;
int anony = 0;
path = mallocw(200);
***************
*** 590,595
if((p = strchr(path,';')) != '\0')
*p = '\0'; /* delimit initial cd */
#endif
if(!anony){
usprintf(ftp->control,logged);
--- 582,598 -----
if((p = strchr(path,';')) != '\0')
*p = '\0'; /* delimit initial cd */
#endif
+ time(&t);
+ cp = ctime(&t);
+ usprintf(ftp->control,banner1,cp);
+
+ 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);
---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: Sun, 28 Mar 93 09:00:50 GMT
From: g4klx@g4klx.demon.co.uk (Jonathan Naylor)
Subject: G8BPQ with IP Router
To: TCP-Group@ucsd.edu
Hi All
I put BPQ406E.ZIP into the wrong incoming directory. It is now in
/hamradio/packet/tcpip/incoming.
Sorry
Jonathan
------------------------------
Date: Sat, 27 Mar 1993 11:41:17 -0600 (CST)
From: gerry@cs.tamu.edu (Gerald J Creager)
Subject: KA9Q NOS questions...
To: tcp-group@ucsd.edu
I recently shipped this to the group, but I've seen neither the question, nor
any responses, so I guess it went to a bit bucket in the sky... Let's try
again.
I recently downloaded Phil's latest from ucsd.edu. I tried to bring it up
initially with an autoexec.nos configured for jnos 107b. With the exception of
the attach asy statement, I have changed nothing, but I'm seeing some
interesting anomolies and NEED some help.
1. Hardware config:
'386DX/'387, 4 Mb memory, 130 Mb hard disk, 3 Mb free on NOS logical drive, 6
Mb free on a separate logical drive for /temp.
2. Software Config:
QEMM/386, ansi.sys, the world loaded high, 633k available.
3. TNC config:
PacComm Tiny-2 with "node" (higher speed) parts, port speed 9600 baud, radio
speed 1200 baud, ROM rev. 1.1.6b (PacComm)
4. Recent history:
Works "fine" with jnos, older karncode (tm) and g1emmCode (tm). Worked fine at
higher radio rates with DataEngine testing last year.
5. Symptoms:
A. When I issue *ANY* sort of transmission, with trace turned on, I see an
ax.25 "bad header" message in trace.
B. Occassionally, say, <10% of the time, I see what looks to the code
(appparently) like a good ax.25 packet but is gibberish.
C. Other systems see the packets I'm pumping out, and they look normal to
them. A connect request using either native ax.25 or tcp/ip results in the
other system thinking it can really talk to me, but I cannot make sense of the
replys.
I have used both the ax25ui and ax25i constructs in the attaach asy command
line, with similar results. Since I haven't pulled down the source yet, I have
no "documentation" to work with... I need more disk space, and I'm working oin
that issue.
Anyone got thoughts? I was wondering if KISS wasn't compiled into the code,
possibly... If that's the case, I guess I need to learn something about RCS
and grab a copy of Borland C++ 3.x...
Thanks,
Gerry n5jxs
gerry@cs.tamu.edu
------------------------------
Date: Sat, 27 Mar 93 17:01:07 EST
From: Mike Gallaher <mg@bds.bds.com>
Subject: KA9Q NOS questions...
To: gerry@cs.tamu.edu (Gerald J Creager)
Try using "kissui" or "kissi" instead of "ax25ui"/"ax25i".
If you use ax25 encapsulation, it just sends raw ax25 packets to the
serial port, assuming that whatever hears them will transmit them
literally (like an 8530 card). If you use kiss encapsulation, it
prepends a kiss "data follows" byte to the ax25 packet; this is
what the TNC expects, to distinguish data from parameter-setting commands,
for instance. At least, that's what I've been able to glean from
looking at the source, and playing with it for a few minutes.
I haven't seen any documentation either.
mg
------------------------------
Date: Sat, 27 Mar 93 15:05:15 EST
From: Postmaster@alis3.daytonoh.ncr.com
Subject: TCP-Group Digest V93 #79
To: tcp-group@ucsd.edu
Returned Mail: Could not find any To: or Cc: recipients.
*** Returned Mail Message Follows: ***
------------------------------
Date: Sat, 27 Mar 93 04:30:06 PST
From: Advanced Amateur Radio Networking Group <tcp-group@ucsd.edu>
Subject: TCP-Group Digest V93 #79
To: tcp-group-digest@ucsd.edu
TCP-Group Digest Sat, 27 Mar 93 Volume 93 : Issue 79
Today's Topics:
3COM Sniffer
Anyone seen this problem before ? (2 msgs)
any System V release 3 ports of NOS/NET (KA9q)/slip
AX25 and Linux (2 msgs)
LAPB bugs
Latest BPQ with IP Router
TCP-Group Digest V93 #78 (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: Fri, 26 Mar 93 11:28:05 EST
From: crompton@NADC.NADC.NAVY.MIL (D. Crompton)
Subject: 3COM Sniffer
To: tcp-group@ucsd.edu
I put the file eprobe.zip in the ucsd.edu incoming. It is a PUBLIC
DOMAIN ethernet monitor program from 3COM for any of there ethernet
board products. It is a nifty way to monitor ethernet traffic on a
PC. It has filtering modes and detailed viewing.
I thought this might be of interest to the ampr group. If it is not
appropriate to have it on here then take it off.
Doug
------------------------------
Date: Fri, 26 Mar 93 10:10:09 CST
From: andyw@aspen.cray.com (Andy Warner)
Subject: Anyone seen this problem before ?
To: tcp-group@ucsd.edu (TCP Group)
Has anyone seen NOS behave in the following way ?
An interface is set up to work in datagram mode, but sometimes
NOS decides to start talking in VC mode (to just one or two
stations, not everyone on that interface). If the remote
station in question has jumpstart on, there's a timewasting
round of "Huh?", "Huh?", "Huh?".... until one or other gets bored
and drops the ax25 connection.
Things I know as facts :-
1. I'm running a very recent version of KA9Q (not JNOS, PA0GRI etc),
with some local mods, they might be the culprit, but I thought
I'd ask.
2. This has been going on for a while now, so the problem existed
with earlier NOS versions I used (PA0GRI based, I believe).
3. It is definately my station that initiates the VC mode, (I send
the SABM).
Observations that may or may not be true :-
1. I run a name server on my ethernet, and accesses by other stations
to the nameserver seem to cause the problem to occur most readily.
From the traces I have noticed that sometimes I will get an "ICMP
code port unreachable" when I issue a DNS reply, could this be that
NOS got bored waiting for my answer, and closed the port ?
2. I've never seen this happen to a TCP connection, only to UDP traffic.
If this sounds familiar to anyone, or if you've got any ideas, send
mail & I'll summarise. I hope to dive into the code this weekend...
--
andyw. N0REN/G1XRL
andyw@aspen.cray.com Andy Warner, Cray Research, Inc. (612) 683-5835
------------------------------
Date: Fri, 26 Mar 1993 12:31:34 -0600 (CST)
From: lcz@dptspd.sat.datapoint.com (Lee Ziegenhals)
Subject: Anyone seen this problem before ?
To: tcp-group@ucsd.edu (tcp/ip networking group)
>
>Has anyone seen NOS behave in the following way ?
>
>An interface is set up to work in datagram mode, but sometimes
>NOS decides to start talking in VC mode (to just one or two
Andy,
One thing that would cause this is for someone to send a datagram
with the "reliability" flag set (0x04) in the IP TOS field. JNOS will
send such datagrams in VC mode, regardless of the default "ax25 mode"
setting.
------------------------------
Date: Fri, 26 Mar 93 16:34:58 CST
From: "Erach A. Irani" <irani@cs.umn.edu>
Subject: any System V release 3 ports of NOS/NET (KA9q)/slip
To: tcp-group@ucsd.edu
--- If this is a repeat, please excuse me. I still cannot locate a
working implementation, and that seems highly unlikely to me ---
Hi,
I read that you have agreed to help out by being the
coordinator for the UNIX ports. have you heard of a sys 5 release 3
port of nos/net ka9q slip WHICH can allow me to login to the
originating machine and do UNIX'ish work (rather than talk alone).
A limited number of logins is all I need.
Thanks,
erach
------------------------------
Date: Fri, 26 Mar 93 08:22:10 CST
From: Brian K. Teravskis <brian@smedley.telex.mn.org>
Subject: AX25 and Linux
To: tcp-group@ucsd.edu
Is anyone working on getting AX25 incorporated
into the Linux kernel or is KA9Q the only way
to go for now??
Thanks..
Brian
------------------------------------------------------------------------------
Brian K. Teravskis | Internet: brian@smedley.telex.mn.org
Telex Communications, Inc | brian@hercules.vware.mn.org
Bloomington, MN 55420 | AMPRNET: brian@hercules.wd0efl.tcman.ampr.org
------------------------------------------------------------------------------
------------------------------
Date: Fri, 26 Mar 1993 09:50:10 -0800 (PST)
From: Bruce Perens <bruce@pixar.com>
Subject: AX25 and Linux
To: "Brian K. Teravskis" <brian@smedley.telex.mn.org>
Right now, you must run a KA9Q variant such as WAMPES under Linux,
because the various people who have been hacking in AX.25 drivers
aren't ready to release them. We're waiting for the SLIP modifications
to the kernel (mostly STREAMS support) to stabilize, as we want to use
some of that to support AX.25. Also, the Linux TCP/IP implementation is
still being debugged - the original developer has left the effort in a
huff due to too much criticism, and others are now posting about one
bug-fix a day.
I find that running KA9Q under Linux is much more comfortable than
running KA9Q on DOS, simply because of the multi-tasking - I can do
something else with the computer while KA9Q is running, and if KA9Q
dies it doesn't crash the system.
It is going to be nice when we can abandon the monolithic structure of
NOS, and break the system into separate processes. I find it much easier
to modify and debug that way.
Bruce Perens KD6OTD
On Fri, 26 Mar 1993, Brian K. Teravskis wrote:
> Is anyone working on getting AX25 incorporated
> into the Linux kernel or is KA9Q the only way
> to go for now??
>
> Thanks..
>
> Brian
>
> ------------------------------------------------------------------------------
> Brian K. Teravskis | Internet: brian@smedley.telex.mn.org
> Telex Communications, Inc | brian@hercules.vware.mn.org
> Bloomington, MN 55420 | AMPRNET: brian@hercules.wd0efl.tcman.ampr.org
> ------------------------------------------------------------------------------
>
>
------------------------------
Date: Fri, 26 Mar 93 14:29:55 PST
From: psm%helios.nosc.mil@nosc.mil (Scot McIntosh)
Subject: LAPB bugs
To: tcp-group@ucsd.edu
Following are some bugs and deficiencies that I've found in the LAPB
code, which a couple of group members have requested that I post.
Excuse the extra-wide format. Hope it doesn't make this unreadable
for some.
------------------------------
Date: Fri, 26 Mar 93 19:04:03 GMT
From: g4klx@g4klx.demon.co.uk (Jonathan Naylor)
Subject: Latest BPQ with IP Router
To: TCP-Group@ucsd.edu
On incoming as ucsd.edu is the latest version of G8BPQs switch software,
BPQ406E.ZIP. In it is included the first release of his IP router software
that operates as an application above the switch. It has been in beta testing
for quite a while in our local packet area with good results. John has added
a protocol for auto routing between his switches.
Could somebody move it from incoming to the g8bpq directory please.
John G8BPQ can now be reached at g8bpq@g4klx.demon.co.uk
73's
Jonathan
------------------------------
Date: Fri, 26 Mar 93 11:02:08 EST
From: Postmaster@alis3.daytonoh.ncr.com
Subject: TCP-Group Digest V93 #78
To: tcp-group@ucsd.edu
Returned Mail: Could not find any To: or Cc: recipients.
*** Returned Mail Message Follows: ***
------------------------------
Date: Fri, 26 Mar 93 04:30:11 PST
From: Advanced Amateur Radio Networking Group <tcp-group@ucsd.edu>
Subject: TCP-Group Digest V93 #78
To: tcp-group-digest@ucsd.edu
TCP-Group Digest Fri, 26 Mar 93 Volume 93 : Issue 78
Today's Topics:
New nos version PA0GRI
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: Fri, 26 Mar 93 10:08:02 MET
From: gvdg@tophat.cdh.cdc.com
Subject: New nos version PA0GRI
To: tcp-group@ucsd.edu
Hello All,
Just before going i loaded my latest work on NOS onto ucsd.edu
Main work lately was on tcp and ip access code.
The c command help display now correctly displays the possible commands
for the various compile options of mailbox.c
Now i am all set to get "lost" in the big lands and have a good time.
>>>>>For all who wrote me a message: I took all notes with me and use them
as time and place comes by. Freq for simplex is 145.520 (i forgot the
30kc channel space.) Thanks all those responded , to nummerous to get back
to individualy (sorry).
Please have funn, i will.
Regards, Gerard.
--
Internet: gvdg@cdc.com | Gerard J van der Grinten
UUCP: gvdgpc!gvdg | Control Data Bv.
Telephone: 0(+31)-15-153123 | Olaf Palmestraat 20
| 2616 LS DELFT Netherlands
------------------------------
End of TCP-Group Digest V93 #78
******************************
------------------------------
Date: (null)
From: (null)
Start
File Line Function Description
lapb.c 168 lapb_input The following code fragment is part of
the processing for
the LAPB_CONNECTED state. 'control'
contains
the complete control field from an
incoming frame, which,
in the case of an RNR, has an N(R)
field. Therefore, the
control == RNR test fails when the N(R)
field of the RNR
contains nonzero. Change 'control' to
'type' to fix this.
case RR:
case RNR:
axp->flags.remotebusy = (control == RNR) ?
YES : NO;
if(poll)
enq_resp(axp);
ackours(axp,nr);
break;
lapb.c 371 ackours The ackours() function returns a -1
value to cause a
FRMR if an acknowledgement is received
for an unsent frame.
None of the routines calling ackours
pays any attention to
the return value. Suggest modifying
ackours to send the FRMR
itself:
static int
ackours(axp,n)
struct ax25_cb *axp;
int16 n;
{
struct mbuf *bp;
int acked = 0; /* Count of frames
acked by this ACK */
int16 oldest; /* Seq number of
oldest unacked I-frame */
int32 rtt,abserr;
/* Free up acknowledged frames by
purging frames from the I-frame
* transmit queue. Start at the
remote end's last reported V(r)
* and keep going until we reach the
new sequence number.
* If we try to free a null pointer,
* then we have a frame reject
condition.
*/
oldest = (axp->vs - axp->unack) &
MMASK;
while(axp->unack != 0 && oldest !=
n){
>> if((bp = dequeue(&axp->txq)) ==
NULLBUF){
>> /* Acking unsent frame */
>> sendfrmr(axp, axp->control,
LAPB_RESPONSE, axp->pf, Z);
>> return -1;
}
Remainder of routine is same. The
arguments to sendfrmr are
the offending packet's control and
pf fields, an indication
that this is a response, and the
reason for the FRMR.
Note: have to add 'control' and
'pf' fields to struct ax25_cb and
fill them with the control
and pf fields of the offending
incoming frame. Also, the X.25
standard specifies that after
sending an FRMR, the DCE enters into
a frame rejection condition and
waits for a SABM, DISC, or DM
from the DTE (this is an
abbreviated description of what the
standard really says). Suggest
adding the LAPB_REJECT state
and the processing for it in the
lapb_input function, and have
the sendfrmr function invoke the
LAPB_REJECT state. Also
suggest adding
sendfrmr(axp, axp->control,
LAPB_RESPONSE, axp->pf, W);
for the cases where an incoming
frame has a control field
containing an unknown type.
lapb.c various lapb_input The code decides whether the local
station is busy by the
enq_resp following means:
if(len_p(axp->rxq) >= axp->window){
/* Too bad he didn't
listen to us; he'll
* have to resend the
frame later. This
* drastic action is
necessary to avoid
* memory deadlock.
*/
sendctl(axp,LAPB_RESPONSE,RNR | pf);
_or_
tmp = len_p(axp->rxq) >=
axp->window ? RNR : RR;
The len_p routine only determines
the length of the
packet at the front of the receive
queue. If multiple
receive packets are queued, they
aren't taken into
account in calculating whether the
window has been
exceeded.
lapbtime.c 95 tx_enq The following code fragment is
from the tx_enq routine:
if(axp->txq != NULLBUF
&& (len_p(axp->txq) <
axp->pthresh || axp->proto == V1)){
/* Retransmit oldest unacked
I-frame */
dup_p(&bp,axp->txq,0,len_p(axp->txq));
ctl = PF | I | (((axp->vs -
axp->unack) & MMASK) << 1)
| (axp->vr << 5);
sendframe(axp,LAPB_COMMAND,ctl,bp);
} else {
ctl = len_p(axp->rxq) >=
axp->window ? RNR|PF : RR|PF;
sendctl(axp,LAPB_COMMAND,ctl);
}
A condition can arise wherein a
transmit packet has been put on
axp->txq, but transmission not
initiated because lapb_output()
found that axp->flags.remotebusy
indicated that the remote station
is busy. In this case, if
tx_enq() is called by recover() or
pollthem(), txq will be non-null,
and the I frame could be transmitted.
This is incorrect behavior when
the remote is busy. If by chance
the remote has become unbusy
between the time of the lapb_output()
failure and the call to tx_enq(),
the tx_enq() transmission of the
I frame doesn't increment
axp->vs, and axp->unack is zero, so an
acknowledgement by the remote
will not be processed properly by
ackours();
------------------------------
End of TCP-Group Digest V93 #79
******************************
------------------------------
End of TCP-Group Digest V93 #80
******************************
------------------------------
End of TCP-Group Digest V93 #82
******************************
------------------------------
Date: Tue, 30 Mar 93 10:32:16 PST
From: microme!mikeh@uunet.UU.NET (Michael L. Hasenfratz)
Subject: TCP-Group Digest V93 #82
To: uunet!UCSD.Edu!TCP-Group@uunet.UU.NET
Please STOP the recursive Digest.
Mike Hasenfratz - WA6FXT * mikeh@uMEM.COM or uunet!microme!mikeh
Micro Memory Inc.
Chatsworth, Ca. 91311
------------------------------
End of TCP-Group Digest V93 #83
******************************
------------------------------
End of TCP-Group Digest V93 #84
******************************
******************************