Date: Fri, 10 Sep 93 04:30:02 PDT
From: Advanced Amateur Radio Networking Group <tcp-group@ucsd.edu>
Errors-To: TCP-Group-Errors@UCSD.Edu
Reply-To: TCP-Group@UCSD.Edu
Precedence: Bulk
Subject: TCP-Group Digest V93 #233
To: tcp-group-digest
TCP-Group Digest Fri, 10 Sep 93 Volume 93 : Issue 233
Today's Topics:
AXIP making memory go away...
NOS in NT VDM
nos version 29th Dec 91, where?
SUBSCRIBE
TCP-Group Digest V93 #232 (2 msgs)
Send Replies or notes for publication to: <TCP-Group@UCSD.Edu>.
Subscription requests to <TCP-Group-REQUEST@UCSD.Edu>.
Problems you can't solve otherwise to brian@ucsd.edu.
Archives of past issues of the TCP-Group Digest are available
(by FTP only) from UCSD.Edu in directory "mailarchives".
We trust that readers are intelligent enough to realize that all text
herein consists of personal comments and does not represent the official
policies or positions of any party. Your mileage may vary. So there.
----------------------------------------------------------------------
Date: Thu, 09 Sep 93 17:25:23 mdt
From: ka7oei@uugate.wa7slg.ampr.org
Subject: AXIP making memory go away...
To: tcp-group@ucsd.edu
For better or for worse (the latter mostly) UUGATE is running AXIP.
We are doing this because the majority of local packet users are still
running ax.25 (and they will, until NOS becomes less incomprehensible to
them...) and we don't wish to alienate them...
The problem sees to be that when someone AXIP's (NetWrongs, maybe...)
to uugate, and then accesses a faster system (most of them are!) via the
gateway (i.e. callsign server, telnet to another system, etc.) memory
disappears extremely rapidly... This sends the gateway into oblivion.
Is there any known fix/patch to improve the backoff? (like the "ICMP QUENCH
OFF" equivalent for this situation...)
I already know that one solution (using the term loosely) would be to have
different machines handling the mbox and the gateway routing. That is not
going to happen extremely soon.
Also, DOES ANYONE KNOW HOW TO SET UP AN IP-IP DAEMON FOR WAMPES? (To allow
it to run encap!) If so, PLEASE tell 'JR@upl.com' how it is done!!!
Thanks
<Clint>
[sysop]
------------------------------
Date: Fri, 10 Sep 93 00:41:31 CST
From: jimh@kd4ldo.ampr.org (Jim Henderson)
Subject: NOS in NT VDM
To: tcp-group@ucsd.edu
In message <9308290112.AA02545@hoccny.ho.att.com>, djt@hoccny.ho.att.com (David J.Trulli) 746608280 writes:
>I tried to run JNOS107b under NT in a DOS VDM.
>I tried this with an empty autoexec.nos file and
>find that NT reports an illegal instruction at
>CS:0000 IP:00A8 OP:f004b5cbb8
>
>This occurs before any output to the screen. I think is occurs
>when NOS set up a new proc but I am not sure yet.
>Before I start debugging this has anyone tired this yet ?
According to Microsoft, several direct hardware interrupt calls are not
supported under NT - presumably for security reasons. I've got the list
at work - I'll bring it home and pass it along.
Jim
----
Jim Henderson, KD4LDO/W0 [44.94.249.38] on 144.99 MHz
Crystal, MN Internet: jimh@kd4ldo.ampr.org
CIS: 71321,1461 Alt. Internet: hendersj@alpha.db.erau.edu
"And now some news from some of the outlying regions of the Galaxy. A
report out today from the western spiral arm says that the wheel is
commercially unviable. . ."
- Sub-ether news report
------------------------------
Date: Thu, 9 Sep 93 21:40:23 +0200
From: jt@fuw.edu.pl
Subject: nos version 29th Dec 91, where?
To: J.R.Jagger@sheffield-hallam.ac.uk (Jon Jagger)
> Message-Id: <MAILQUEUE-101.930728080709.384@oak.shu.ac.uk>
> Date: 28 Jul 93 08:07:09 GMT
> I'm looking for a copy of the above (with full sources).
Is it still actual? More than month passed, but I didn't see any
answer, since I put it (I didn't read mail almost 2 months...).
I'm not sure if I have binary (if you really need it, I can look
for it on my floppies), but source is available on my site
zfja-gate.fuw.edu.pl (148.81.6.100) as nos/ka9q/src1229.zip
by anonymous ftp (don't use my mini-listserv to get it, please,
the file is 620kB and mail would be about 850kB). Let me know
when you don't need it - I plan to remove it from the disk.
Anyway, I suppose RCS allows to get any old version... 73's
------------------------------
Date: Fri, 10 Sep 93 01:03:37 UTC
From: barry@hs.ve3nav.ampr.org
Subject: SUBSCRIBE
To: tcp-group@ucsd.edu
SUBSCRIBE
------------------------------
Date: Thu, 09 Sep 93 09:42:03 -0600
From: Bdale Garbee <bdale@col.hp.com>
Subject: TCP-Group Digest V93 #232
To: Advanced Amateur Radio Networking Group <tcp-group@UCSD.EDU>
> NetBSD (free) has this stuff already done, and OS/2 looks like it
> has also. I wouldn't waste too much time on creating this. NOS
> has pretty much outgrown MS-DOS and needs to be redesigned to
> work with Unix.
:-) Brilliant minds do think alike, sort of...
What I and others have done is to combine 386/486 machines running a mix of
BSDI and NetBSD bits, all slip'ed to Gracilis standalone switches that are
handling all the AX.25 and RF work. I understand and appreciate the desire to
do AX.25 on the BSD systems, but frankly... I'm pleased to be able to leave
all the RF pieces on the air full time, and take the UX box up and down as the
development mood hits me. Sort of the non-pc-NOS way of doing what Phil has
suggested to Unix users all along...
One of these days I'll get around to writing a driver for the pc-plug-in
version of the Gracilis PackeTen switch for NetBSD/BSDI...
Others have done work on AX.25 in the kernel, but I haven't seen any bits yet.
Will be fun to play with, particularly on my BSDI/Toshiba 4500C combination
when travelling...
Bdale
------------------------------
Date: Thu, 9 Sep 93 18:05:48 +0100
From: Alan Cox <iiitac@pyr.swan.ac.uk>
Subject: TCP-Group Digest V93 #232
To: bdale@col.hp.com, tcp-group@UCSD.EDU
It shouldn't be hard to do AX.25 in a BSD based kernel, apart from the
arp problem, which at least with source you can fix. Getting UI
frame AX.25 KISS support into a Linux kernel took me 40 minutes
of attacking the slip driver. Now adding a real SOCK_AX25 layer
will be more fun.
Alan
------------------------------
End of TCP-Group Digest V93 #233
******************************
******************************