Programmer 7500/MAX_PROGRAMMERS.iso/PROGRAMS/UTILS/HAMRADIO/TCP90138.ZIP/TCP90138.TXT

Text File | 1990-09-20 | 14.1 KB | 344 lines

TCP-Group Digest            Fri, 14 Sep 90       Volume 90 : Issue 138

Today's Topics:
         Anyone driving to the ARRL C.N.C from the Bay Area?
      Anyone driving to the ARRL C.N.C from the Bay Area? (fwd)
                            Ethernet <$100
                               failures
                            hp9000/800 NET
                    net write through screen bios?
                     NOS 900828 failure (3 msgs)
                             rspf status
                   RSPF Trials on LI not going well

Send Replies or notes for publication to: <[e-mail]>.
Subscription requests to <[e-mail]>.
Problems you can't solve otherwise to [e-mail].

Archives of past issues of the TCP-Group Digest are available
(by FTP only) from UCSD.Edu in directory "mailarchives".
----------------------------------------------------------------------

Date: Thu, 13 Sep 90 8:25:07 EDT
From: (null)
Subject: Anyone driving to the ARRL C.N.C from the Bay Area?
To: [e-mail]

My roomy has a small quantity of telephone parts waiting for him in
  San Francisco.  Is anyone from that area planning to drive to the
  C.N.C. next weekend, and would they be willing to pick up said junk
  and bring it to the C.N.C.?
--
-----------------
Marcus Leech, 4Y11             Bell-Northern Research  |opinions expressed
[e-mail]                  P.O. Box 3511, Stn. C   |are my own, and not
[e-mail]         Ottawa, ON, CANADA      |necessarily BNRs


--
-----------------
Marcus Leech, 4Y11             Bell-Northern Research  |opinions expressed
[e-mail]                  P.O. Box 3511, Stn. C   |are my own, and not
[e-mail]         Ottawa, ON, CANADA      |necessarily BNRs

------------------------------

Date: Thu, 13 Sep 90 08:26:00 EDT
From: Marcus (M.D.) Leech <[e-mail]>
Subject: Anyone driving to the ARRL C.N.C from the Bay Area? (fwd)
To: [e-mail]

Forwarded message:

------------------------------

Date: Thu, 13 Sep 90 12:34:05 EDT
From: [e-mail] (Jon Bloom)
Subject: Ethernet <$100
To: [e-mail]

In the search for low-cost networking, I've stumbled across an
8-bit Ethernet card for $99.  Since I haven't seen anything cheaper
(let me know if you have!) I thought I'd pass it along.

The board is advertised as an NE1000 "equivalent," and it works just
fine with the latest Clarkson NE1000 driver.  We bought a pair of
the boards from:  MCW Distribution, 800-638-9118 (Maryland).  They
also advertise an NE2000 (16-bit) equivalent which I have not tried.

Ethernet is getting _cheap_!

Jon

------------------------------

Date: Thu, 13 Sep 90 16:51:56 EDT
From: [e-mail] (D. Crompton)
Subject: failures
To: [e-mail]

I (and our local group) have found the late (since about May) versions
of NOS (G1EMM) to be very stable. We run it on a real mixture of machines
and machine enviroments. I have never seen a garbage collection message
from NOS nor after weeks of operation do I see any "Yellow" or "red"
alerts. For the most part we give NOS either full memory or a full DOS
window in DV. This would be around 510-580K of startup memory. I have
watched the Stack status (ps) and I have never found a stack to be more
than 50% of maximum. Even before the timer stack change. My particuliar
system is a V20 8MHZ with four 16550a's running  nrs/kiss ports. No
ethernet. The  addition of 'rspf' in G1EMM has been the only recent
blip. It seems to cause problems when it is turned on but not when it is
off. I handle a fairly heavy load of smtp and ftp on this system.

This is not to say that there are not some real problems that are being
experienced but it must be related to something (WHAT?) that is being
done differently than we are doing it. Since NOS uses alot or most of
memory in some cases maybe this really exercises the machine and it is
pointing to a flakey machine or memory that ordinarilly would not show
up?

Doug

------------------------------

Date: Thu, 13 Sep 90 10:16:51 mdt
From: Bdale Garbee <[e-mail]>
Subject: hp9000/800 NET
To: [e-mail]

Several people have asked me over time how to get NET running on an HP-PA
system.  I just received an account with considerable detail from someone
who has made the 890421.1 version work fine on a 9000/840.  If anyone needs
the details, email me and I'll forward them out.  It's a largish hunk of text,
so I won't post it here.

Bdale, [e-mail]

------------------------------

Date: Thu, 13 Sep 90 17:28:13 EDT
From: [e-mail] (Bob Foxworth)
Subject: net write through screen bios?
To: [e-mail]

The following message appeared on the local AX25 networks on LI about
a week ago, and I am passing it on here. Text follows:

(rest of headers deleted)
R:900906/1615Z @:N2EYR [N.Y.C.,NY] F:441.00/145.030 #:11625 Z:10032

can anyone tell me if the tcpip program can write through the screen
bios? I need to know this because I am a sightless ham and my speech
synthesizer will not scroll properly if the software won't write
through bios. I appreciate any feedback from tcpip users on this point.
this will enable me to decide whether or not to get the program.
thanks for your help.
73
dan
n2fwq @ n2eyr.ny.usa.na

[end forwarded message]

ANy replies that may be posted here, pls indicate if they were also
sent direct to Dan. Pls reply direct to him if you are able. I do not
know this fellow, but thought this is a good medium to help him. 73 Bob

------------------------------

Date: Thu, 13 Sep 90 15:39 GMT
From: <[e-mail]>
Subject: NOS 900828 failure
To: [e-mail]

Aha! I'm so glad that someone has reported this! This looks very similar
to one of the ways in which NOS has been crashing off and on for me for
the past several months. I would ask you which compiler you used to
recompile NOS; I find that TC++ produces that warning message in a
seemingly spurious manner quite frequently. Every time I report this type
of problem other people come on and tell me how wonderfully stable
NOS is at their location. I've just been sitting back waiting for someone
else to get bit; I figured it would happen sooner or later. BTW, I tried
different hardware, TNC and versions of NOS. Seems to make no difference
here. Every now and then it will crash the way you said. Similarly, I
am convinced that there is a problem in the NETROM code because that
causes me crashes sometimes too (although I'm really confused about
that because testing it out with different people around here produce
reproducible problems on different people's systems -- but the problems
are different on different systems!).

Onward and upward...

73 -- Doc

------------------------------

Date: Thu, 13 Sep 90 10:57:51 MST
From: [e-mail] (Dave Fritsche)
Subject: NOS 900828 failure
To: [e-mail] (tcp-group)

> Aha! I'm so glad that someone has reported this! This looks very similar
> to one of the ways in which NOS has been crashing off and on for me for
> the past several months. I would ask you which compiler you used to
> recompile NOS; I find that TC++ produces that warning message in a
> seemingly spurious manner quite frequently.

Forgot to mention, I used the TC 2.0 compiler (haven't ordered TC++ yet).
Only thing i did was edit the config header file to "turn on" the SCC
driver.  I also modified version.c to change the "900828" to "900828+SCC".
I like to be know what executables are no longer "stock".

As soon as I power cycled the machine, and re-booted, NOS came up fine, as
usual.  About the time the SMTP timer kicked in for the first time (and
tried to start sending the mail that had been in progress before the
crash), I started getting a bunch of messages scrolling across the screen
saying something I think about a stack pointer out of its valid range.
This was an unending stream of messages that was scrolling as fast as they
could be printed (the address in the message was decrementing I believe).
I was parinoid that I may have bumped the squelch control on the Kantronics
DVR2-2 radio, and had the squelch running open, and that maybe the PC-100
was causing problems.  (I've found that the DVR2-2 has quite a few intermod
problems in use around Pheonix here, and with potentially open squelch, I
don't know what all might have been going on.)  Since there's no speaker on
the radio, I just tweaked the squelch control up a bit, rebooted, started
NOS, and haven't had a problem in the last 12 hours.  Again, until last
night, I'd never experienced a problem of this sort (activity in AZ isn't
the most vigorous, since there's only 2 of us that are very active with
TCP/IP).

73 . . . Dave Fritsche (wb8zxu)
         [e-mail]

------------------------------

Date: Thu, 13 Sep 90 18:42:09 UTC
From: [e-mail] (Phil Karn)
Subject: NOS 900828 failure
To: [e-mail], [e-mail]

My experience has been that spectacular crashes of this type are now almost
always caused by a process that overflows its stack. Choosing stack sizes in
NOS is a trial-and-error process; there doesn't seem to be a better way (if
somebody can come up with one, I'd be very grateful).

So the next time things start going crazy, try running the "ps" command
(if the system is still capable of doing so) and look for any tasks that
have exceeded their stack allocations. The stack high water marks should
always be well below the stack size figures to give an adequate safety
margin.

Sometimes it takes a while for the system to start dying after a stack
overflows, so if you can run ps regularly even when things seem OK,
you might find the first evidence of a stack overflow.

Phil

------------------------------

Date: Thu, 13 Sep 90 17:06:15 GMT
From: [e-mail]
Subject: rspf status
To: [e-mail]

All,
  I have incorporated Anders fix to rspf (the route deletion problem) and
have uploaded the new g1emm version to thumper. The files are emm82812.*
in /pub/ka9q/incoming.
  I have to say however, that it still doesn't work and in fact causes
severe (power-off only) system crashes when it's been running for a while.
In view of this, I cannot recommend using rsfp until Fred, Anders and any
other brave souls who feel like debugging the code have come up with some
fixes. The symptom seems to be corrupted memory pointers leading to either
a total hang or garbage pointers detected in free(). If rspf is NOT invoked
the problems go away. best of luck!
     All the best,
               Kelvin.
+-------------------------------------------------+
| Kelvin J.Hill - BULL HN Ltd, Hounslow, England. |
| Internet - kelvin.uk22.bull.com  [128.35.110.6] |
| Amprnet  - g1emm.ampr.org        [44.131.7.6]   |
+-------------------------------------------------+

------------------------------

Date: Thu, 13 Sep 90 15:49:45 EDT
From: [e-mail] (Bob Foxworth)
Subject: RSPF Trials on LI not going well
To: [e-mail]

Several locals tried running rspf in the central LI (NY) subnet, n2pl,
wb2dvk, and a day later, k2euh and kc2ky. N2pl sent me mail via amprnet
saying his routing table entries disappeared, and I believe he stopped
running rspf. I am not sure of the details, not even what version of
NOS Paul is running. I am using emm82811, I set the rspf parameters
according to Anders' note in the 18 August tcp-digest, set preferred
mode to datagram.

I believe Ron, dvk had emm82810 running Tuesday night and I saw his
RSPF protocol IP QST's to 44.255.255.255 and caught one QST from him as:

RSPF: type Routing Update  nodes 0 id 1
      Reporting Router: 44.68.8.34 Seq 3 Subseq 0 links 1
      horizon 32 ERP factor 0 cost 8 adjacencies 4
            44.68.8.35/32
            44.68.8.58/32
            44.68.8.25/32
            44.68.8.22/32

At that point I did a status on my system:

net> rspf status
Addr            Cost     Seq     Heard          Time       TOS   State
44.68.8.34         8     262         0      0:00:50:18      16   OK
44.68.8.41         8       0         0      0:00:45:19       0   OK
44.68.8.58         8       0         0      0:00:42:51       0   OK
44.68.8.82         8       0         0      0:00:00:00       0   Suspect

34, 41 and 58 are all active and well heard. 82 is probably a result
of a manual entry in my autoexec "arp add". I probably should delete it.
Note that I restarted NOS about 55 minutes before taking this data.
About 5 or 7 minutes after this, my station 44.68.8.35 broadcast a
reporting router update. I caught most of it to screen, but not before
a couple lines scrolled off. I sent my data, then apparently rebroadcast
then the report from wb2dvk (44.68.8.34) as so:

(top 2 lines not copied to printer - these were my heard stations:)
     horizon 32 ERP factor 0 cost 8 adjacencies 3
           44.68.8.58/32
           44.68.8.41/32
           44.68.8.34/32
     Reporting Router: 44.68.8.34 Seq 3 Subseq 0 links 1
     horizon 31 ERP factor 0 cost 8 adjacencies 4
           44.68.8.35/32
           44.68.8.58/32
           44.68.8.25/32
           44.68.8.22/32

At this point everything appeared to be working normally.Time 0420Z on
12 Sept. I checked next at about 2230Z that date and found no mail had
arrived, NOS basically appeared to be running OK but I was unable to
send a ping to anyone except kc2ky (44.68.8.58) and he was the *sole*
station appearing in my net>rspf status listing. Any other station
pinged would not resolve and would not even transmit. The other 2
known heards (41) (nq2d) and 34 (wb2dvk) were still up. I think dvk
had discontinued rspf; nq2d I am sure has not yet tried it.

I saw the reference to a bug fix a day or two ago. I believe this refers
to the problem. I was running emm82811 which I ftp'ed from thumper and
took home, and wb2dvk (34) and kc2ky (58) had ftp'ed it from me over the
air.

I know this is lengthy. I hope there is a clue for Anders or someone
else in here. I know we are interested in continuing to play with it,
and await further developments/versions of code. I think a brief list
of what parameters to check if there appears to be a problem would help
too. We have copies of the k1io documentation by the way.

73 Bob k2euh

------------------------------

End of TCP-Group Digest
******************************