Christer Solskogen wrote:

Derek Ragona wrote:

I would do a traceroute from all your hosts there. When you do keep an eye out for the arp error message. This should help find the host causing these errors and then look at that systems configuration.

Also do you have more than one ethernet interface in the system showing the arp errors? If you do, make sure the interfaces are on different subnets.



traceroute dont show anything(no response). Only ping responds, and ping respodns with "192.168.0.1" - which is my router. My router on the other hand do not have this arp problem. Only the other machines.

Every machine, except my router, have only one interface. (my router has two, butthey are on to different subnets)


OK, this problem amused me enough to play around. Unfortunately, while I was able to, somehow, replicate the log entries on a FreeBSD 6.2 box, I don't know how, as it was a box that I wasn't using for my experiments (though on the same LAN segment as those I was using) and it was only the next day that I realized that it had taken offense at something I'd done. By then I'd forgotten what I'd tried in which order....

In any case, what I can tell you:

On FreeBSD (various versions from 4.9 to 7.0) and MacOS X 10.4, ping 0.0.0.0 appears to be the equivalent of pinging the ipv4 default gateway (if you use tcpdump you can actually see the packets with a destination address of 0.0.0.0 go out and the replies come in). OpenBSD 4.2 and Windows XP basically tell you can't do such a foolish thing. I think this is a red herring.

I doubt you have an interface with a 0.0.0.0 address. What I suspect you have is some software, somewhere on the same segment as the machine logging the complaints, that is triggering an ARP query for 0.0.0.0.

If you really want to track this down, what I'd strongly urge you to start with is to, on a machine where the log entries happen, run the command

tcpdump -vvv -n -l -e arp

and see if you can catch ARP traffic mentioning 0.0.0.0. If you catch one, this will give you the MAC address of the source of the traffic. I would hope that this would help narrow it down.

Meanwhile, I'll see if I can replicate this when I'm paying a bit more attention. :-)

--Jon Radel

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

Reply via email to