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.
In RHEL 3, this is not a supported configuration.
What specifically is not supported about this configuration? There's nothing in the netdump docs to indicate that it's non-standard.
(I'm asking just so that I'll know what it is we're supposed to be avoiding, since it's not clear from your response....)
Oh, sorry my response was so vague. In RHEL 3, if you load the netdump module it will try to take a network crash dump. It also uses the netdump address information for netlog, which cannot be configured separately. And so, if you only configure syslog, then it is expected that netlog and netdump will send packets to the broadcast address. In RHEL 4, all three options (syslog, netlog, and netdump) can be configured independently. I'm guessing the crashing system never takes a netdump because there is no netdump server on the network.