Bug 142921

Description of problem:
netdump causes logging of "martian destination 0.0.0.0 from a.b.c.d, 
dev eth0" on systems on the same network as a system which has 
crashed and has netdump configured with only SYSLOGADDR set (not 
NETDUMPADDR or any other netdump config variables)

Version-Release number of selected component (if applicable):
netdump-0.6.11-3

How reproducible:
Start netdump on a server with only SYSLOGADDR set (pointing to a 
server on a different network--though I don't know if that's required 
or not), crash that server, and check the syslog output on other 
servers on the same network as the crashed/crashing server.

Additional info:
On the system that was running netdump with only SYSLOGADDR and which 
later crashed (host1), this was the sequence of netdump startup 
messages:

kernel: netlog: using network device <eth0>
kernel: netlog: using source IP a.b.c.d
kernel: netlog: using source UDP port: 6666
kernel: netlog: using syslog target IP w.x.y.z, port: 514
kernel: netlog: using broadcast ethernet frames to send netdump 
packets.
kernel: netlog: using broadcast ethernet frames to send netdump 
packets.
kernel: netlog: using syslog target ethernet address 
00:e0:b6:00:e9:ac.
kernel: netlog: network logging started up successfully!

Note that it says "using broadcast ethernet frames to send netdump 
packets," despite the fact that netdump should only be logging to 
syslog.  Then here's the sequence of events in the centralized syslog 
file when this system eventually crashed:

Dec 14 12:57:29 host1 [...various kernel oops messages, omitted...]
Dec 14 12:57:32 host1 < netdump activated - performing handshake with 
the client. >
Dec 14 12:57:32 host2 martian destination 0.0.0.0 from a.b.c.d, dev 
eth0
Dec 14 12:57:32 host3 martian destination 0.0.0.0 from a.b.c.d, dev 
eth0
Dec 14 12:57:32 host4 martian destination 0.0.0.0 from a.b.c.d, dev 
eth0

Note that host2/3/4 (the other hosts on the same network as host1) 
immediately start logging the "martian" messages after host1 starts 
trying to do its netdump.  These martian log messages then start 
being generated very rapidly; we had thousands within a few minutes.  
Also, host1 doesn't ever go down...it just hangs in netdump, 
apparently, sending out its broadcasts and generating these martian 
messages on its neighbors.

So the bug may be that netdump shouldn't be sending broadcast packets 
when it's only been configured to send to syslog (with a specific 
SYSLOGADDR set), or that netdump should eventually give up and let 
the machine finish crashing and rebooting, or possibly even that 
RHEL3 systems  shouldn't generate martian messages for these netdump 
broadcasts...or some combination of all of these.  But whatever it 
is, things shouldn't work this way.