Jon Radel wrote:
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....
On FreeBSD 7.0 box on other side of OpenBSD 4.2 router did a arpdig 216.143.151.1/28 On FreeBSD 6.2 box tcpdump said:22:45:06.707002 00:08:02:cc:b1:60 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: arp who-has 216.143.151.11 tell 0.0.0.0 22:45:06.707020 00:16:76:cf:e4:b3 > 00:08:02:cc:b1:60, ethertype ARP (0x0806), length 42: arp reply 216.143.151.11 is-at 00:16:76:cf:e4:b3
with resulting message in debug.log:May 14 22:45:06 left kernel: arplookup 0.0.0.0 failed: host is not on local netw
ork May 14 22:45:07 left last message repeated 2 timesSo I'm actually going to update my hypothesis a bit; I suspect that any incoming packet that triggers an ARP lookup for 0.0.0.0 will result in this message. Try
tcpdump -vvv -n -l -e -s 128 arp or ip | grep 0.0.0.0 to see what you can catch. --Jon Radel
smime.p7s
Description: S/MIME Cryptographic Signature
