Suggestion for a more precise message for packets that are received after a timeout.

[mrquincle]

I'm scanning the local network.

sudo arp-scan --interface wlp3s0 -l -vvvv -L -N -r1

It seems that I get DUP: 1 entries when packets are received after the timeout.

---	Removing host 192.168.50.245 - Timeout
---	Removing host 192.168.50.246 - Timeout
---	Received packet #1 from 192.168.50.238
192.168.50.238	88:57:1d:87:7c:37	Some company (DUP: 1)
---	Removing host 192.168.50.238 - Received 42 bytes
***	remove_host called on non-live host: SHOULDN'T HAPPEN
---	Received packet #1 from 192.168.50.222
192.168.50.222	4c:17:44:22:fe:84	Some company (DUP: 1)
---	Removing host 192.168.50.222 - Received 42 bytes
***	remove_host called on non-live host: SHOULDN'T HAPPEN

Most logical to me would be to adjust the message. If he->num_recv is equal to one, it's not a duplicate message, but a message that is received after the timeout.

      if (!he->live) {
         cp = msg;
         msg = make_message("%s (DUP: %u)", cp, he->num_recv);
         free(cp);
      }

This is just using arp-scan-1.9.7 the default on Ubuntu, but the precise version doesn't matter here I think. It would be great if the console log would be more precise here.

Now:

192.168.50.83	ec:e5:12:12:60:36	Some company (DUP: 1)

Towards something like this:

192.168.50.83	ec:e5:12:12:60:36	Some company (Received after timeout)

[royhills]

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.

[royhills]

Hopefully fixed by commit 167b4c5

Not fully tested yet though.

[royhills]

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

[mrquincle]

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

[royhills]

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