Date: Sat, 3 Apr 93 04:30:18 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 #86
To: tcp-group-digest
TCP-Group Digest Sat, 3 Apr 93 Volume 93 : Issue 86
Today's Topics:
BPQ IP router
Difference between asy modes kissi and kissui? (2 msgs)
DOS 6.0 (2 msgs)
gangrenous NOS bits
Help with asy ports
JNOS/KA9Q merge
New WAMPES version (2 msgs)
Re: NOS Prototypes.. more ..
User Applications
Whither tcp-group
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, 03 Apr 93 03:27:16 UTC
From: willie@wj3g.ampr.org
Subject: BPQ IP router
To: tcp@wj3g.ampr.org
Is anyone using the IP router that was released with BPQ406E? If so what did
you do to get it working? Are there any command line options? Thank you,
Willie, WJ3G
------------------------------
Date: 02 Apr 1993 09:06:51 -0600 (CST)
From: Jeffrey Austen <JRA1854@tntech.edu>
Subject: Difference between asy modes kissi and kissui?
To: tcp-group@ucsd.edu
Could somebody explain the difference between the modes kissi and kissui
in the attach asy ... command? I could not find them in the documentation
that I have and a trace command on the port shows no obvious difference
in the operation. The software version is ka9q 9301xx.
Jeff, k9ja
Internet: jra1854@tntech.edu
------------------------------
Date: Fri, 02 Apr 93 13:37:40 -0800
From: karn@qualcomm.com (Phil Karn)
Subject: Difference between asy modes kissi and kissui?
To: Jeffrey Austen <JRA1854@tntech.edu>, tcp-group@ucsd.edu
At 09:06 AM 4/2/93, Jeffrey Austen wrote:
>Could somebody explain the difference between the modes kissi and kissui
>in the attach asy ... command?
In the kissi mode, connected-mode AX.25 connections are used by default
('i' = I-frame). In kissui mode, unconnected mode AX.25 is used by default
('ui' = unnumbered information). These defaults can be overridden by type
of service bits in the IP header.
These distinct encapsulation modes replace the old "mode vc/dgram" settings,
which were much less clean.
Phil
------------------------------
Date: Fri, 2 Apr 93 10:02:42 EST
From: crompton@NADC.NADC.NAVY.MIL (D. Crompton)
Subject: DOS 6.0
To: tcp-group@ucsd.edu
Just a note to say that NOS seems to be working very well with DOS6.0
I guess this would be expeceted. What was not expected for me, because
I have not used any overall disk compression SW, was the increase in
disk size. I had figured it backwards and was very surprised at the
results.
I.E. - I had a 203 meg total capacity drive with 200 Megs of data -
3 megs remaining after installing DOS 6.0. After running dblspace I
had 159 megs available - 203*1.8-200-some overhead - I had thought
of it as 203-(200/1.8) which of course leads to a different result.
The 1.8 factor can vary - all the way down to 1.0 if all of the files
on your drive were already compressed. Therefore on a NOS file server
with many zip files the results will not be nearly as good.
It does require some shuffling around with the optimization. I was using
QEMM and had to reoptimize as well as do some manual optimization.
dblspace takes 44K and when loaded high you need to make room for it
in the nooks and crannies. I was able to load everything high though and
end up with 636K of DOS space.
Doug
------------------------------
Date: Fri, 2 Apr 93 17:43:21 EST
From: crompton@NADC.NADC.NAVY.MIL (D. Crompton)
Subject: DOS 6.0
To: tcp-group@ucsd.edu
You need to add a 'case 6:' at approx. line 1460 in main.c to allow
viewing of open files. This is right after the current 'case 5:'
Be sure to make a boot floppy of DOS 6.0 with dblspace.sys on it. If
you lose you hard drive config file you will NOT be able to get to
any files on the drive unless you boot and load the bdlspace driver.
Compiles are faster running from a drive with dblspace installed here.
The above reference in main.c is for WG7J108d - just search for a 'case 5:'
Doug
------------------------------
Date: Fri, 2 Apr 93 8:17:28 EST
From: Mike Gallaher <mg@bds.bds.com>
Subject: gangrenous NOS bits
To: tcp-group.;@bds.bds.com
As long as we're talking about obsolete baggage in NOS:
How about removing ec.c, eccmd.c, and other things associated with the
wired 3c501 card. Does anyone really use the 3c501, and isn't using
the packet driver for it?
Also, where did the interrupt buffer pool in JNOS come from? (I
believe it's from pa0gri, but I'm not sure.) Although JNOS 108
maintains these buffers, nothing ever seems to use them. Unless I'm
missing something, the PI driver (for which the pool seems intended)
doesn't even use them.
My vote is for using ANSI prototypes everywhere. Specifically what
compilers are people using that don't support them?
I've linted JNOS (using CodeCenter), though I haven't given it the
full treatment lately. It turned up a few egregious bugs (like a
write through a wild pointer in the converse "invite" code), but the
last few times haven't turned up anything interesting. (Johan has
already fixed those problems.) I agree with Doug that we should pay
more attention to BCC's warnings, and try to eliminate them; even if
they are harmless, habitually ignoring compiler messages is asking for
trouble.
Here's a couple of such pieces of lint:
Calls to qsort should cast its func arg to avoid type mismatch:
arpcmd.c if (Arp_Sort) qsort(temp,(size_t)j,80,(int (*) ())strcmp);
ipcmd.c if (Route_Sort) qsort(temp,(size_t)j,80,(int (*)())strcmp);
nrcmd.c qsort(temp,(size_t)j,17,(int (*) ())strcmp);
tcpcmd.c qsort(buf,(size_t)i,80,(int (*) ())strcmp);
In config.c, cast clrscr:
"cls", (int (*) ()) clrscr, 0, 0, NULLCHAR,
Finally, a couple of random inconsistencies:
The receiver process for ppp interface is "<iface> receive",
whereas that of all other async interfaces is "<iface> rx".
ppp_recv should be called ppp_rx
nrs_recv should be called nrs_rx
And to file off a burr in ka9q:
Eliminate pk_send in pktdrvr.c (and pktdrvr.h).
Nothing calls pk_send, except that it's used as the sendfunc for the
SLFP interface (iftype in config.c), which could just as well use
nu_send.
------------------------------
Date: Fri, 02 Apr 1993 14:19:37
From: ccmcgone@mtu.edu (Charles McGonegal - N8OKM)
Subject: Help with asy ports
To: tcp-group@ucsd.edu
I'm am using JNOS 1.08c on a 286 and have run into this problem:
I'm trying to using the system with 3 asy ports - 2 TNCs and an internal
modem. All are using different addresses and interupts. The problem lies
with the TNC ports. Outgoing data seems to work fine, but incoming data
is only recieved on ONE of the ports, no matter which of the TNCs actually
recieved it. One TNC is an MFJ1270, the other is a KAM. The computer
only seems to recieve from the MFJ. The KAM alone doesn't work (sends,
but incoming data doesn't reach the computer unless the MFJ is turned on,
then the data is recieved on the port that the MFJ is connected two)
Does anybody have any clues as to what the trouble is???
Charles McGonegal
ccmcgone@mtu.edu
------------------------------
Date: Fri, 2 Apr 93 8:13:13 EST
From: Mike Gallaher <mg@bds.bds.com>
Subject: JNOS/KA9Q merge
To: tcp-group.;@bds.bds.com
I have put on wg7j.ece.orst.edu a zip file of the files that have
changed in replacing the network protocol code in JNOS 108d with the
code from ka9q. I just included the files themselves, not the RCS
files, because I'm not sure everyone is using RCS. (I highly
recommend RCS. You can get a DOS version via ftp from tandem.com,
rcs56.zip, I believe. That package also contains diff.)
This code IS NOT FINISHED YET. I'm making it available so others
can help test it and shake out bugs, and I'm hoping that others can
help with their specialties, like the PI driver (help, Dave!). It
does MOSTLY work. I still haven't tracked down why the system hangs
when there is lots of activity on more than one interface.
[The reason I did all this is that I wanted the demand-dialer code
from ka9q, and one thing led to another...]
Included is a detailed commentary on what changed and why. I took
great pains to incorporate changes that had been added to JNOS, such
as buffered sockets and fixes to the ax.25 code. This doesn't mean I
didn't do anything wrong, though -- please help find my mistakes!
I also included my notes on NOS internals that I took as I went over
the code. I haven't seen a NOS internals document, so unless there is
one already, these are about as close to one as we've got now, as
unpolished as they are.
Here's a list of the things that need to be checked:
16550 FIFO support
LZW support
AXIP
settable per-socket EOL sequence
noblock code (socket.c)
buffered socket code (sockuser.c)
multi-port kiss (kiss.c)
The PI and Gracilis drivers still need to be worked over. Along with
a few other things, they should use the new interrupt wrapper, and
should call net_route instead of enqueue. The driver should prepend
an iface pointer instead of a phdr. The PI driver accounts for the
size of the phdr in many places; I don't know that this is necessary
anymore.
Mike Gallaher wa2hee@wa2hee.ampr.org mg@bds.com
------------------------------
Date: Fri, 2 Apr 93 15:12:57 MST
From: Dieter Deyke <deyke@mdddhd.fc.hp.com>
Subject: New WAMPES version
To: tcp-group@ucsd.edu
I have uploaded a new version of WAMPES (wampes-930402.tar.Z) to
UCSD.EDU. This version should solve some of the problems with 386BSD.
Please keep this distribution for reference, my plans are to distribute
new versions of WAMPES as patches to this 930402 base code.
This is the README file:
------------------------------------------------------------------------
wampes-xxxxxx.tar.Z is a compressed tar archive of WAMPES, which is a
NET/NOS port to HP-UX. It currently supports HP 9000 series 300, 400,
700, and 800 computers, running HP-UX 08.xx or HP-UX 09.xx.
I also ported the software to SunOS 4.1.2, and it compiles there, but I
do not have enough time to really test it. Feedback is welcome.
This version of WAMPES was also ported to 386BSD 0.1.34. It compiles
fine, but because of lacking support for file locking in the 386BSD
kernel the BBS and the pop2 daemon will not work. There is still much
more work to do to fully support inbound logins. But, for outbound
connections, this port should be usable. Again, feedback is welcome.
WAMPES was also ported to Linux running on a 386 by Olaf Erb, dc1ik.
Comments and questions about the Linux port of WAMPES please to Olaf
Erb, <erb@insu1.etec.uni-karlsruhe.de>
To unpack this archive you should create the directory /tcp and cd to
it. After unpacking please read the file /tcp/doc/intro.txt.
wampes-xxxxxx.tar.Z and all followups should go into
/hamradio/packet/tcpip/wampes on UCSD.EDU.
73,
Dieter Deyke, DK5SG / N0PRA, <deyke@fc.hp.com>
------------------------------
Date: Fri, 2 Apr 93 19:07:44 MST
From: Dieter Deyke <deyke@mdddhd.fc.hp.com>
Subject: New WAMPES version
To: tcp-group@ucsd.edu
I forgot:
if you are on 386BSD, you will need the uname command. Create the file
/usr/bin/uname and put the following line into it, then make it
executable:
echo 386BSD
73,
Dieter
------------------------------
Date: Fri, 2 Apr 93 5:02:41 HST
From: Antonio Querubin <tony@mpg.phys.hawaii.edu>
Subject: Re: NOS Prototypes.. more ..
To: jbj@USDesign.COM (Jeff Johnson)
> 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));
Already being done. But in NOS it's called ARGS instead of P.
Tony
------------------------------
Date: Fri, 02 Apr 93 12:54:40 -0800
From: karn@qualcomm.com (Phil Karn)
Subject: User Applications
To: jsteinhu@nyx.cs.du.edu (Josh Steinhurst), tcp-group@ucsd.edu
> 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.. :(
A much better solution is to avoid wheel reinvention. There are now two
different freeware versions of Unix that run on 386-class machines
(386BSD and Linux). Not only are these real operating systems designed
to support these sorts of applications, but many of the applications
already exist!
There is no reason to turn NOS into another UNIX. NOS should continue to
do what it has always done best - act as a router between LANs and
packet radio channels using low-end PC hardware. Big applications and
servers should go on platforms that are better suited to the task.
Phil
------------------------------
Date: Fri, 2 Apr 93 09:34:28 -0800
From: brian (Brian Kantor)
Subject: Whither tcp-group
To: tcp-group
It think it's time to disband tcp-group - it's lost its focus.
I propose to create
1) NOS-HACKS mailing list for people who are primarily engaged in
chroming Phil's code and its derivatives. That would also be the place
for people to ask questions about setting up nos and such.
2) PAC-FAST for high speed radio data transmission discussions - for
now, 9600 bps is fast, but as that becomes mature technology, we'll
slide the bottom limit up to like 56kb or somewhere. Emphasis is on
people DOING things!
3) PAC-HITECH for discussions of high-tech packet applications - what
next, beyond BBSs.
Most of the miscellaneous traffic (there's not much of that) can go to
the packet-radio mailing list (which is the mail mirror of the
rec.radio.amateur.packet Usenet newsgroup).
Are these enough? Are they appropriate divisions? Do they reflect the
moods of the existing group?
- Brian
------------------------------
End of TCP-Group Digest V93 #86
******************************
******************************