1
0
mirror of https://github.com/nmap/nmap.git synced 2025-12-06 12:41:29 +00:00

ARP: Look for an earlier probe if response seems too fast. See #92

This commit is contained in:
dmiller
2020-05-11 17:20:11 +00:00
parent a41e8c8e58
commit 069af655eb

View File

@@ -1571,7 +1571,7 @@ bool get_arp_result(UltraScanInfo *USI, struct timeval *stime) {
int rc;
u8 rcvdmac[6];
struct in_addr rcvdIP;
struct timeval rcvdtime;
struct timeval rcvdtime, fudgedsenttime;
bool timedout = false;
struct sockaddr_in sin;
HostScanStats *hss = NULL;
@@ -1628,7 +1628,10 @@ bool get_arp_result(UltraScanInfo *USI, struct timeval *stime) {
/* Delay in libpcap could mean we sent another probe *after* this
* response was received. Search back for the last probe before rcvdtime. */
probeI--;
} while (TIMEVAL_AFTER((*probeI)->sent, rcvdtime) && probeI != hss->probes_outstanding.begin());
/* If the response came just a hair (<10ms) after the probe was sent, it's
* probably a response to an earlier probe instead. Keep looking. */
TIMEVAL_MSEC_ADD(fudgedsenttime, (*probeI)->sent, INITIAL_ARP_RTT_TIMEOUT / 20);
} while (TIMEVAL_AFTER(fudgedsenttime, rcvdtime) && probeI != hss->probes_outstanding.begin());
ultrascan_host_probe_update(USI, hss, probeI, HOST_UP, &rcvdtime);
/* Now that we know the host is up, we can forget our other probes. */
hss->destroyAllOutstandingProbes();