Date: Fri, 5 Nov 93 04:30:02 PST
From: Advanced Amateur Radio Networking Group <tcp-group@ucsd.edu>
Errors-To: TCP-Group-Errors@UCSD.Edu
Reply-To: TCP-Group@UCSD.Edu
Precedence: Bulk
Subject: TCP-Group Digest V93 #287
To: tcp-group-digest
TCP-Group Digest Fri, 5 Nov 93 Volume 93 : Issue 287
Today's Topics:
ka9q and campus net
NOS Boogers (4 msgs)
NOS Boogers (forgot something)
Recording of the telnet sessions
TCP-Group Digest V93 #286
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, 4 Nov 1993 13:25:39 -0600 (CST)
From: "Bill Walker" <uunet!uecok.ecok.edu!bw>
Subject: ka9q and campus net
To: tcp-group@ucsd.ecu
Apologies in advance for the semi-non-ham nature of this missive.
I run K5JB's version of KA9Q at home on my UNIX box, with great success.
As a UNIX type, I have always felt the fray of networked PC's to be
beneath my dignity, but no more!
Our administration at our small college has managed to find 1.5 megabucks
in a grant to provide "networking" to our campus. The folks in charge
are not technical types, but rather inclined to payroll processing.
They do know enough to think they know more than they do.
At any rate, the threat is that they may not adopt ethernet, or TCP/IP
standards at all, but instead get something off-the-wall, and make
US talk to THEM. That thought has already sent some of our systems people
screaming into the night.
In short, to stiffle the problem, we need to find moral equivalents
to telnet and ftp, in the public domain, for PC's, running on an ethernet.
It really needs to run in a "windows environment", whatever that is.
I assume that means it should "pop up" on demand. It is unclear if it
must also be actively connected to the network all the time. The question
did not occur to the powers-that-be.
It occurs to me that folks on this mailing list do this sort of thing
every day. Any suggestions? Has someone hacked KA9Q to provide
these services without the rest of the ham stuff (in particular, the
menu driven user interface)?
Save me! I have been seduced by UNIX! Seems like every time I need
a really slick solution to a technical communications problem I wind
up looking to ham radio for a solution. It's always worked before!
Tnx es 73 de Bill W5GFE [44.78.32.12]
bw@cs.ecok.edu
--
Bill Walker Ph.D.
Chairman, Dept. of Computer Science
East Central University
Ada, Oklahoma 74820-6899
e-mail: bw@cs.ecok.edu
phone: 405 332 8000 ext. 594
FAX: 405 332 1623
------------------------------
Date: Thu, 4 Nov 1993 07:29:43 -0600 (CST)
From: Steve Sampson <ssampson@sabea-oc.af.mil>
Subject: NOS Boogers
To: TCP-Group@UCSD.Edu
> I'm once more asking you to help me. I can't get working sources of original
> KA9Q's NOS.
That's because there is no such thing. Every copy of NOS I've ever compiled
has bugs in it. The biggest reason is that people select different options
in config.h and never try the others. Then when you turn them on and try a
compile, the compiler spews out a bunch of terminal errors.
If you're not proficient in C, you'll probably never be able to use NOS
unless it's the distributed binary with the sources. If you are proficient,
then you get the only documentation there is :-) I think the docs are circa
1987 and haven't been updated since, so reading source is the only way to
figure out how to make an autoexec.nos file. If you just want TCP/IP you
might try the k5jb version of net (on ucsd). At least this has docs and
can actually compile. The NOS's haven't leveled off in development enough for
people who just want to compile without errors.
My solution was to use a stripped down NOS on my junker 386sx (it's small and
doesn't have all that BBS bo-jive) and then I Ethernet to my 486.
On the 486 I'm running Super TCP (a commercial Windows package), thereby
bypassing most of the NOS boogers (it's just a gateway router to AX.25).
---
Steve
------------------------------
Date: 04 Nov 93 09:13:29 CST
From: Jack Snodgrass <kf5mg@vnet.IBM.COM>
Subject: NOS Boogers
To: <TCP-Group@UCSD.Edu>
>> I'm once more asking you to help me. I can't get working sources of
>> original KA9Q's NOS.
I can't figure out how to compile Phil's code either. I looked at RCS
once and decided I didn't like it so I erased it. Wish someone would
put out some plain, old .C and .H files for Phil's code.
> That's because there is no such thing. Every copy of NOS I've ever
>compiled has bugs in it. The biggest reason is that people select
>different options in config.h and never try the others. Then when you
>turn them on and try a compile, the compiler spews out a bunch of
>terminal errors.
I don't know.... the new, JNOS 1.10 stuff seems to compile without
errors as long as you stay with the main-stream code. If you start
using some of the non-standard drivers or CD-ROM stuff there might be
a couple of IFDEF problems but the main stuff compiles. Some stuff may
not work since it's eXperimental code, but at least it should compile.
Steve's right thought about docs and source. If you can't live without
up-to-date docs and you can't live with change, look at finding a now
router and use a commercial package.
73's de Jack
| (817) 962-4409 | VM Office Systems | 5 West Kirkwood Blvd | MS 06-05-60 |
| T/L 522-4409 | Performance Group | Westlake, Tx 76299 | Rm. 6569 |
vnet:jgrass@msnvm1 ibmmail:usib34cd@ibmmail internet:kf5mg@vnet.ibm.com
------------------------------
Date: Thu, 4 Nov 93 13:08:55 -0500
From: Jim De Arras <jmd@cube.handheld.com>
Subject: NOS Boogers
To: TCP-Group@UCSD.Edu
> >> I'm once more asking you to help me. I can't get working sources of
> >> original KA9Q's NOS.
> I can't figure out how to compile Phil's code either. I looked at RCS
> once and decided I didn't like it so I erased it. Wish someone would
> put out some plain, old .C and .H files for Phil's code.
I extracted it to plain, old. .c and .h files, from my unix paltform, but then
ran into the same problems of strange, missing, stuff. Kdebug, and the FAX
stuff, for starters. I think Phil has crossed over to the dark side (unix :-)
), and left DOS to rot.
Jim
------------------------------
Date: Fri, 5 Nov 93 00:43:54 GMT
From: ron@chaos.eng.wayne.edu (Ron Atkinson N8FOW)
Subject: NOS Boogers
To: kf5mg@vnet.IBM.COM
Try this with Phil's code. After you convert all the files over from RCS
(with the co program), rename all the .s files to .asm if that's
what they are called. In the main.c you can probably just comment out
the Kdebug that gives the error. I can now compile Phil's code just
fine. Works great too!
Ron
------------------------------
Date: Fri, 5 Nov 93 00:48:02 GMT
From: ron@chaos.eng.wayne.edu (Ron Atkinson N8FOW)
Subject: NOS Boogers (forgot something)
To: tcp-group@ucsd.edu
Almost forgot, grab the config.h and makefile from UCSD.EDU too. Or
just reove the references to things like fax, qtso, etc... in hte makefile.
Those modules aren't in the sources.
------------------------------
Date: Thu, 04 Nov 93 21:11:14 UTC
From: ve3mrm@bbs.ve3rpi.ampr.org
Subject: Recording of the telnet sessions
To: tcp-group@ucsd.edu
Hello to all,
I use KA9Q NOS 2.0p and the only problem I have is in recording of
telnet sessions (using the command "record <filename>"). The problem
appears any time the text is paginated by the system with "--More--".
Simply, the "--More--" terminates the recording without announcing it,
making the record files not longer than about 1052 bytes (one page). The
"session # flow on|off" command does not work (will not disable
pagination) despite what the "session # flow" says.
I posted the question previously but no-one has responded. I have been
reading the README.NOW file of JNOS [I am not using JNOS] and found such
a statement:
"VERSION 1.02 (920615)
- bugfix for recording of telnet session by Ron, vk6zjm added"
So, it might be a bug in my program. I have tried to contact Ron
[44.136.204.19] but till now I have no luck.
I am not sure if this message will be posted (I am in a process of
learning this mode - who isn't?) so please respond to me. I will
appreciate it.
73 de Andrew
------------------------------
Date: Thu, 04 Nov 93 15:59:12 -0800
From: karn@qualcomm.com (Phil Karn)
Subject: TCP-Group Digest V93 #286
To: William Ti Baggett <wbaggett@nmsu.edu>, Sbrown@charon.dseg.ti.com
Funny you should mention the San Francisco (actually Loma Prieta)
earthquake. The Internet stayed up the whole time, although a few hosts
went off due to power failures. And it carried quite a bit of traffic in
the "health and welfare" category that couldn't be carried on the
telephone because of call blocking.
Obviously, this won't necessarily hold in the future. Yet most
emergencies are local or regional in scope, so there's still no real
problem with building radio/wire/fiber hybrids. Consider a much more
severe earthquake that does take out the local phone networks. At some
distance from the disaster area, however, the phone networks will still
work. So an amateur/commercial hybrid that links local amateur
facilities in the disaster area with commercial long-haul facilities
outside makes a lot of sense to me.
Of course, it's rather rash to assume that amateur facilities will still
work even when commercial facilities have been knocked out by a
disaster. I've seen how PacTel builds cell sites in California, and
quite frankly I would sooner place my money on them staying operational
after a major earthquake than on the average ham repeater. And before
long, the same cellular companies will be selling access to the
Internet. What role will there be for amateur packet radio in
emergencies when that happens? If we stay connected to the Internet
ourselves, then at least we have a chance of doing something. We could
even interoperate with the cellular packet users.
Phil
------------------------------
End of TCP-Group Digest V93 #287
******************************
******************************