On Sunday 19 Oct 2014 14:14:03 Alec Ten Harmsel wrote: > On 10/19/2014 06:31 AM, Mick wrote: > > On Saturday 18 Oct 2014 19:13:23 Alec Ten Harmsel wrote: > >> arpscanning the entire subnet results in 3 responses, with 2 being > >> displayed and 1 being dropped by the kernel. > > > > Oh! I wonder if this is your problem. I can't answer why 1 response is > > being dropped by the kernel. Have you set up some fancy tcp wrappers or > > firewall rules at the desktop? > > Nope, running vanilla-sources, no tcp wrappers or firewall. In fact, > iptables wasn't installed until arp-scan or wireshark or another network > tool pulled it in as a dependency. > > If you're really interested as to why this happens and can tell me how I > can even log something like this, I'd be more than willing to play > around with it.
The information that thegeezer suggested will offer some quick comparisons between the three machines. In addition, for capturing packets: Router - I think that DD-WRT offers netflow to monitor interfaces. That should show what comes in - goes out, but there may be other network diagnostic tools that DD-WRT offers. On desktop, laptop (for comparison) and server you could use something like: tcpdump -i eth0 -e -l -p -U -vvv -w tcpdump_cap.txt -XX to record and replace the -w with -r to read the captured file, or use wireshark to study the captured file. Run tcpdump while using arping from each machine at a time: arping -I eth0 -c 2 192.168.0.10 You can filter for arp packets and see which machine is the culprit, because so far we do not know for sure whether the server refuses to return arp responses, or the desktop drops them for some reason (e.g. malformed ARP packets), or the router routes them differently. -- Regards, Mick
signature.asc
Description: This is a digitally signed message part.
