Date: Fri, 14 May 93 04:30:13 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 #124
To: tcp-group-digest
TCP-Group Digest Fri, 14 May 93 Volume 93 : Issue 124
Today's Topics:
Bug in BPQ ? (2 msgs)
Watchdog Timer question (2 msgs)
your LISTSERV request "list tcp-group"
your LISTSERV request "list tcp-group@ucsd.edu"
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, 13 May 93 19:03:55 GMT
From: g4klx@g4klx.demon.co.uk (Jonathan Naylor)
Subject: Bug in BPQ ?
To: TCP-Group@UCSD.EDU
Alan mentions an incompatibility between WAMPES and G8BPQs code. I too use
WAMPES under LINUX and have had no problems using NET/ROM between the two
systems and using G8BPQs IP router. I am lucky enough to be in range of Johns
machine from where I live.
Johns NET/ROM code was based on the documentation in the Software 2000 manual
and is not buggy. I would suggest that any bug exists in WAMPES. John does use
extra bytes on the Connect Request and Connect Acknowledgement packets in order
to perform additional parameter negotiation, but he correctly identifies non
BPQ nodes and does not use these additional bytes with them.
As far as I am aware the NET/ROM code in NET/NOS/WNOS/WAMPES lost its support
many years ago, at least by the original author, and represents a pretty
minimalist implementation to enable inter-operability with the newly appearing
NET/ROM nodes of that time.
I'm sorry if this sounds like a flame but Johns code is not buggy. He can be
contacted via my node as g8bpq@g4klx.demon.co.uk if you wish to discuss it with
him in detail.
The only potential conflict occurred when a NOS system would segment its data
and use the special PID to identify a segment. Since it was never documented
anywhere that I know of, John didn't implement it until I read the source code
and documented it for him. I needed to know what the rules were for my Acorn
Archimedes port of NET. So much for "open systems".
Jonathan
------------------------------
Date: Thu, 13 May 93 20:52:26 MDT
From: Dieter Deyke <deyke@mdddhd.fc.hp.com>
Subject: Bug in BPQ ?
To: tcp-group@UCSD.EDU
> Alan mentions an incompatibility between WAMPES and G8BPQs code. I too use
> WAMPES under LINUX and have had no problems using NET/ROM between the two
> systems and using G8BPQs IP router. I am lucky enough to be in range of Johns
> machine from where I live.
>
> Johns NET/ROM code was based on the documentation in the Software 2000 manual
> and is not buggy. I would suggest that any bug exists in WAMPES. John does use
> extra bytes on the Connect Request and Connect Acknowledgement packets in order
> to perform additional parameter negotiation, but he correctly identifies non
> BPQ nodes and does not use these additional bytes with them.
I sure would like to hear more about this bug. Last time I used the
NET/ROM features of WAMPES it worked, but these days all NET/ROM nodes
within my reach are replaced by FlexNet nodes, so there is no easy way
for me to test it.
> As far as I am aware the NET/ROM code in NET/NOS/WNOS/WAMPES lost its support
> many years ago, at least by the original author, and represents a pretty
> minimalist implementation to enable inter-operability with the newly appearing
> NET/ROM nodes of that time.
The NET/ROM code in WAMPES was completely written by me, and is not
based on the work of others. (Later I adopted some declarations from
the NET/ROM files in KA9Q to minimize the diffs). I am supporting it,
but will need help in finding compatibility problems with other
implementations.
Dieter, DK5SG / N0PRA
------------------------------
Date: Thu, 13 May 93 07:57:19 cst
From: kf5mg@vnet.IBM.COM
Subject: Watchdog Timer question
To: TCP-Group@UCSD.Edu
Does the watchdog timer function still work? If so, how and under
what conditions? It seems to me that if the system is really hosed, a
software controlled reset may be impossible.
I was discussing different ways to trigger the a reset. Someone
suggested that I use a 555 timer chip that is connected to the reset
pins on the motherboard. NOS would reset the countdown timer every
minute or so. If the timer was not reset in a 5 minute period, it would
reset the machine.
Can I rely on the built in watchdog function, or should I look at
wiring up a external reset device like the 555 timer? I'd probably plug
it into a gameport and program it that way. Thanks.
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
-------------------------------------------------------------------
| "I am Homer, of Borg...prepare to be assim -- ooo, donuts." |
-------------------------------------------------------------------
------------------------------
Date: Thu, 13 May 1993 15:33:48 -0400 (EDT)
From: MIKEBW@ids.net (Mike Bilow, <MIKEBW@ids.net>)
Subject: Watchdog Timer question
To: kf5mg@vnet.IBM.COM, tcp-group@ucsd.edu
The watchdog timer is not foolproof. If NOS does something that disables
interrupts, for example, then the watchdog timer cannot trip off, since
it is connected to the system timer tick.
A 555 timer would probably make a decent hardware watchdog, although the
effects of rebooting a computer abruptly are similar those to pulling the
plug on it suddenly. In other words, disk corruption and such are real
possibilities.
Forcing the machine to reset is not difficult. The reset switches on
machines are usually easily available. Even on motherboards which do
not have formal reset switch junction points, there are any number of
places to tie onto.
The tough part is figuring out how to keep the watchdog happy when the
machine is running correctly. W1EO, sysop at the WA1PHY system, has a
hardware watchdog wired to his transmitter PTT; if he doesn't transmit
at least once every 30 minutes, the machine and the TNCs all get their
power cycled. With RSPF or some other type of beacon, this is probably
a good approach. Another idea that I have never actually tried would
be sensing the hard drive activity light, the main advantage of which
is that you would never reboot the machine in the middle of a write to
disk, as the watchdog would trip only if no disk operations occurred
for some period of time. Barring efficient caches and such, NOS will
scan the hard drive every time the "smtp timer" kicks, and will write
a log entry if logging in enabled.
-- Mike Bilow, <mikebw@ids.net> (Internet)
N1BEE @ WA1PHY.#EMA.MA.USA.NA (AX.25)
------------------------------
Date: Thu, 13 May 93 20:25:28 -0700
From: Listserv@UCSD.EDU (Mailing List Processor)
Subject: your LISTSERV request "list tcp-group"
To: healy@moriah.ee.unr.edu
Per request by healy@moriah.ee.unr.edu
"list tcp-group"
'tcp-group' is not subscribed to any mailing lists.
------------------------------
Date: Thu, 13 May 93 20:00:32 -0700
From: Listserv@UCSD.EDU (Mailing List Processor)
Subject: your LISTSERV request "list tcp-group@ucsd.edu"
To: healy@moriah.ee.unr.edu
Per request by healy@moriah.ee.unr.edu
"list tcp-group@ucsd.edu"
'tcp-group@ucsd.edu' is not subscribed to any mailing lists.
------------------------------
End of TCP-Group Digest V93 #124
******************************
******************************