Suggestion for a more precise message for packets that are received after a timeout. about arp-scan HOT 5 CLOSED

Looks like the issue is fixed.

To reproduce I put a Linux bridge between the scanning system and target, and added a 1 second delay with tc qdisc add dev ens36 root netem delay 1000ms. Network is 10.0.0.0/24 containing one host 10.0.0.1.

Old behavior:

---     Removing host 10.0.0.250 - Timeout
---     Received packet #1 from 10.0.0.1
10.0.0.1        00:0c:29:80:62:81       VMware, Inc. (DUP: 1)   RTT=999.444 ms
---     Removing host 10.0.0.1 - Received 60 bytes
***     remove_host called on non-live host: SHOULDN'T HAPPEN
---     Removing host 10.0.0.251 - Timeout

New behavior:

---     Removing host 10.0.0.251 - Timeout
---     Received packet #1 from 10.0.0.1
10.0.0.1        00:0c:29:80:62:81       VMware, Inc.    RTT=1002.372 ms
---     Removing host 10.0.0.1 - Received 60 bytes
---     Removing host 10.0.0.252 - Timeout

from arp-scan.

I think this is a long-standing bug that only occurs in certain situations and is difficult to reproduce.

A host is marked as "not live" when it's either responded or when it has timed out, and the code assumes that any responses to a non-live host must be duplicates. But that is not strictly true because a hosts' first response can occur shortly after the host has been marked as non-live due to timeout. Note that marking a host as non-live only means that no more packets will be sent to that host, but received packets will still be displayed.

Edit: this code in the pcap callback fundtion is also problematic because it assumes that any responding host that isn't marked as "live" when the response is received must be a duplicate and thus shouldn't increment responders.

if (temp_cursor->live)
   responders++;

When a response is received after the host has been marked as non-live due to timeout, it should be displayed in the normal way - no need to add "Received after timeout" because that's an internal implementation matter that the use shouldn't care about. We shouldn't be displaying the "SHOULDN'T HAPPEN" error message in this case either because it's normal (if unusual) behaviour.

from arp-scan.

Hopefully fixed by commit 167b4c5

Not fully tested yet though.

from arp-scan.

Just "anecdotally", this fixes it on my network. I've run it with and without patch and voila, works! Thanks!

from arp-scan.

Thanks for the confirmation. I'm closing this issue now as it appears to be resolved.

from arp-scan.