Date: Mon, 26 Apr 93 04:30:09 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 #109
To: tcp-group-digest
TCP-Group Digest Mon, 26 Apr 93 Volume 93 : Issue 109
Today's Topics:
Ethernet board going to sleep.... (2 msgs)
Gracilis bug
LA/Chicago wormhole info needed (3 msgs)
NOS and PC's turbo switch.....
RSPF troubles
Undeliverable Mail
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, 26 Apr 1993 3:37:05 -0400 (EDT)
From: MIKEBW@ids.net (Mike Bilow, <MIKEBW@ids.net>)
Subject: Ethernet board going to sleep....
To: kf5mg@vnet.IBM.COM, tcp-group@ucsd.edu
This sounds agonizingly familiar. Issue the "mem stat" command after your
Ethernet card goes deaf. I expect that you will see "Iminfree" at zero
and "Ibuffail" non-zero? I believe that someone, at some point, decided
that NOS should pinch interrupt buffers when it needed more memory.
-- Mike Bilow, <mikebw@ids.net> (Internet)
------------------------------
Date: 26 Apr 93 05:33:36 CDT
From: Jack Snodgrass <kf5mg@vnet.IBM.COM>
Subject: Ethernet board going to sleep....
To: <MIKEBW@ids.net>
Mike,
Thanks. Actually, I've still got lots (10 - 20) of Iminfree and
Ibuffail is zero. I think that I've narrowed the problem down to
running tcp time exponential or tcp irtt 10000. I changed these to
tcp time lin and tcp irtt 30000. This seed to fix the problem a bit.
It took 6 - 8 hours before the ethernet card went deaf. If I connect
via the radio and use the card, it start working again. I changed
the irtt value to 45000 and a couple of other things, and now the
box is dead. It's a remote box, so I need to have someone look at it
and see what shape it's in.
Still hoping to have dfwgate.ampr.org on the air by 05/01/93. We'll
have to see.
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@dalhqic2 ibmmail:usib34cd@ibmmail internet:kf5mg@vnet.ibm.com
------------------------------
Date: Sun, 25 Apr 1993 15:03:41 -0500 (CDT)
From: S. R. Sampson <ssampson@sabea-oc.af.mil>
Subject: Gracilis bug
To: TCP-Group@UCSD.Edu
I've been running a Gracilis PackeTwin on its B port for quite awhile now, but
still am having problems with the card locking up in the DEFER state. I've
gone through the code several times to try and find why it can't get out of
this state, but haven't succeeded in breaking the code yet. I've sent
megabyte files using this card and then the very last byte will lock it up.
Or maybe it'll get half-way through and lock up. Usually when this happens
I must manually change the route to a 1200 path to finish up, or kill NOS and
start over.
I just started using the JNOS version and was hoping this one was working, but
it has the same symptoms. Are other Gracilis users experiancing this also?
Seems like the PackeTwin has lost software support to the PackeTen thing, which
is probably just as well, but I'm still waiting for the window software from
Dayton 2 years ago. I'm satisfied the JNOS will do what I need, but this card
is a hair puller for sure.
---
Steve N5OWK
------------------------------
Date: 25 Apr 93 09:48:33 CDT
From: Jack Snodgrass <kf5mg@vnet.IBM.COM>
Subject: LA/Chicago wormhole info needed
To: <TCP-Group@UCSD.Edu>
Does anyone have any info on the setup of the LA/Chicago wormhole?
I'm pretty sure that it's NETROM. I'm trying to get some idea of what
hardware is needed on each end of the wormhole. Can you use a TheNet X1G
TNC, can you use JNOS, etc. I'm assuming that the connection looks like
an RS-232 cable connected to another NETROM node.
73's de Jack - kf5mg
AMPRnet - kf5mg@kf5mg.ampr.org - 44.28.0.14
AX25net - kf5mg@kf5mg.#dfw.tx.usa.na - work (817) 962-4409
Internet - kf5mg@vnet.ibm.com - home (817) 488-4386
------------------------------
Date: Sun, 25 Apr 93 13:54:04 PDT
From: Bill Healy <healy@moriah.ee.unr.edu>
Subject: LA/Chicago wormhole info needed
To: tcp-group@ucsd.edu (tcp-group)
> From: Jack Snodgrass <kf5mg@vnet.IBM.COM>
> Does anyone have any info on the setup of the LA/Chicago wormhole?
> I'm pretty sure that it's NETROM. I'm trying to get some idea of what
> hardware is needed on each end of the wormhole. Can you use a TheNet X1G
> TNC, can you use JNOS, etc. I'm assuming that the connection looks like
> an RS-232 cable connected to another NETROM node.
The setup is the same as you would hook up 2 netrom tncs except that the
wire between them is over a dedicated data line. Both ends of the link are
at branches of the same company, can't remember which, the Internet is not
being used. Yes you could use X1G or JNOS, all you need is someway to pass
data between the 2 machines.
Bill N8KHN
------------------------------
Date: Sun, 25 Apr 93 18:50:51 MST
From: w6swe@tapr.org (Bob Nielsen)
Subject: LA/Chicago wormhole info needed
To: tcp-group@ucsd.edu
Bill Healy <noao!healy@moriah.ee.unr.edu> writes:
> The setup is the same as you would hook up 2 netrom tncs except that the
> wire between them is over a dedicated data line. Both ends of the link are
> at branches of the same company, can't remember which, the Internet is not
> being used. Yes you could use X1G or JNOS, all you need is someway to pass
> data between the 2 machines.
The name of the company is MICOM.
-----
Bob Nielsen W6SWE Internet: w6swe@tapr.org
Tucson, Arizona ax.25: w6swe@kc7cg.az.usa.na
------------------------------
Date: Mon, 26 Apr 1993 3:15:03 -0400 (EDT)
From: MIKEBW@ids.net (Mike Bilow, <MIKEBW@ids.net>)
Subject: NOS and PC's turbo switch.....
To: karn@qualcomm.com, tcp-group@ucsd.edu
Some motherboard chipsets switch into and out of "turbo" mode using writes
to certain I/O ports. In fact, all systems I know about do this, although
the exact port and bit pattern is chipset and manufacturer specific. A
very popular port for this is the one which also handles the A20 gate (on
another bit), and this is trapped by protected mode software (such as QEMM).
I strongly doubt that the system timer itself is being reprogrammed. My
suspicion is that a spurious write to an I/O port is responsible. The
fact that the problem disappears (according to the original report) when
NOS is loaded with no AUTOEXEC file tends to confirm this. Isolating the
offending line in AUTOEXEC would probably lead toa quick solution.
-- Mike Bilow, <mikebw@ids.net> (Internet)
N1BEE @ WA1PHY.#EMA.MA.USA.NA (AX.25)
------------------------------
Date: Mon, 26 Apr 1993 4:06:44 -0400 (EDT)
From: MIKEBW@ids.net (Mike Bilow, <MIKEBW@ids.net>)
Subject: RSPF troubles
To: moerner@almaden.ibm.com, tcp-group@ucsd.edu
I fixed POP a few versions ago, and Johan incorporated my fixes into his
releases months ago. Certainly Johan's stuff works now for POP.
Some of the POP server problems relate to the compiler. As of BC++ 3.1,
the library stat() function calls realloc(). Since realloc() is not
implemented in the custom NOS memory allocator, big time crashes result.
I worked around this by using Bdale's old fsize() call from the SMTP code
instead of stat(). Properly, stat() or even realloc() should be replaced.
There is presently no such thing as a working version of RSPF. Without
opening the subject again, there are chicken-and-egg type problems with
getting RSPF to work within NOS. In the meantime, RSPF can be used for
a network which is tightly controlled and which scrupulously uses agreed
upon parameters. It is inevitable that a routing protocol can be messed
up by any one host that makes a serious enough mistake, and RSPF is no
exception. Do you have a copy of the rough guide to RSPF operation I
wrote a few years ago describing how we have RSPF set up here? It was
called the "Rhode Island Standard for RSPF."
Subnet routes do not simply appear from nowhere, however. You can
override a specific troublesome route by adding it manually to your
IP routing table with a lower metric than can be acquired through RSPF.
This is why a key idea of the Rhode Island Standard is to use link costs
always greater than 1 across RSPF interfaces.
There have been several attempts to work on RSPF over the last couple of
years, so I am not sure which code you are using. At least one of these
attempts was something I strongly disagreed with, and which I thought
violated the protocol specification in potentially harmful ways.
-- Mike Bilow, <mikebw@ids.net> (Internet)
N1BEE @ WA1PHY.#EMA.MA.USA.NA (AX.25)
------------------------------
Date: 25 Apr 93 08:44:00 EST
From: TCP-Group@UCSD.Edu
Subject: Undeliverable Mail
To: "TCP-Group" <TCP-Group@UCSD.Edu>
---- Microsoft Mail "Status" message ----
Your Message: TCP-Group Digest V93 #108
Sent: Sun, Apr 25, 1993 8:43 AM
To: ROSS JR CHARLIE
Date: Sun, Apr 25, 1993 8:43 AM
Reason: Address(es) rejected by Microsoft Mail: Unknown or ambiguous user names
------------------------------
Date: Sun, 25 Apr 93 10:46:48 PDT
From: "W. E. Moerner (MOERNER@ALMADEN.IBM.COM)" <moerner@almaden.ibm.com>
To: tcp-group@ucsd.edu
Message-Id: <042593.104648.moerner@ibm.com>
Subject: Stable gri version needed
I need a stable working version of nos with a reliable rspf and pop,
capable of running unattended for weeks at the sanjose switch site.
No netrom support needed, just async ports.
I tried rspf on wg7j 1.05 approx. 6-10 months ago and had to stop
using it, because even simple direct routes to users normally
handled by my route addprivate default ax0 command were
losing connection to the network. Using rspf status, I learned that
another station running
rspf (the Stanford switch) was broadcasting that he had routes
to 44.4.0.0./24, i.e., a 24 bit match that overrode my local
default route to line-of-sight stations! The Stanford sysop
did not have an entry like this; it was generated by some bug
in the code, I presume. So I went back to gri 1.7J, and this has been
running pretty well, but it is an old version.
Now, after waiting a few months, I am
ready to try rspf again, if someone can assure me that it is
working better.
I am willing to run a GRI version (since I don't need the
expanded mailbox of wgj7), or a wg7j version, whichever has the
features and lasts longer.
Note - slow machine, AT-class with 8 MHz clock, 2M memory.
If there is a good reason to upgrade to a 386sx, I'll do this
if it buys me something useful.
Many thanks and 73, Weo WN6I
------------------------------
End of TCP-Group Digest V93 #109
******************************
******************************