Sun, 23 Feb 86 16:37:53 PST
Neat story. Thanks for sharing the info.
The Pup specs have always included a bit of important fine print about
sending back error Pups: don't send them in response to another error
Pup, and don't send them in response to a broadcast Pup. I think
"broadcast" should be extended to include the physical layer as well as
the logical layer to catch ARP type mixups.
I couldn't find the corresponding idea in the ICMP specs. Did I flip the
pages too fast?
We recently uncovered a similar glitch. We had a bug in our ARP like
code. It was returning an unitialized variable if the target machine
hadn't yet responded to the ARP request. That gives a 50% chance of the
multicast bit being on. Our gateways are willing to "forward" a Pup back
out the same interface it came in on. (That occasionally happens while
the routing tables are changing.) We have 6 or 8 gateways on that net
and they all include the same bug, so I'd expect a real explosion. All
we got was occasional "too many hops" errors. I guess the frames were
mostly reused in a lucky pattern.
BTW: Broadcasting an echo packet is a wonderful stress test for a
This archive was generated by hypermail 2.0b3 on Thu Mar 09 2000 - 14:35:40 GMT