Copy of personal note to Gerard

["Mike Bilow, mikebw@ids.jvnc.net" <mikebw@IDS.JVNC.NET>]

Antonio Querubin <tony@mpg.phys.hawaii.edu>,
in Message-ID: <CMM.0.90.2.694927530.tony@mpg.phys.hawaii.edu>, writes:

>Your summary of the three causes of memory failure mirrors our experiences
>here also.  We've also noticed that whenever SMTP tries to deliver mail to
>a system with either multiple IP addresses or no IP address but has an MX
>record, timers start to fail all over the place (this is with smtp usemx on).

No one in New England ever turns "smtp usemx" on, since there are no MX
records in the current DOMAIN.TXT file.  However, I would say that any
real network is eventually going to want to make use of MX records, so
this is a very serious problem.  More important, however, is that this
is a fantastic clue.  The hunch is that the problem is in killproc() or
killself(), similar to RSPF.

>Currently, we have disabled RSPF on the gateway here to prevent crashes and
>run it on the end-user systems.  So far it tends to cause OTHER machines
>running RSPF to crash whenever an update is sent out.

This is completely unprecedented, since we have been running RSPF here
for months without seeing this.  Yes, machines will freeze for a few
seconds when rebuilding the routing table, but this ranges from a few
seconds on a 386 to as much as 30 seconds on a 4.77 MHz PC.  Yes, this
should be fixed in RSPF, and table building should not be done at such a
high priority level.

The only thing even close to this is that some machines running RSPF
seem to send ARP requests for [0.0.0.0]; I don't know why.  Since it
is not a protocol violation to do this, although it is foolish in the
bigger scheme of things, any host hearing such a frame should just be
able to ignore it.  Unfortunately, PA0GRI NOS as of v1.7h froze up
when such an ARP request was even monitored, and I sent the source
diff to fix this out to the group in late September.  Gerard cycled
this change back into his release as of his v1.7j.

-- Mike