PenTest/nmap
1
0
Fork 0
mirror of https://github.com/nmap/nmap.git synced 2025-12-07 05:01:29 +00:00
Code Issues Projects Releases Wiki Activity

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

Browse Source
This commit is contained in:
dmiller
2020-05-11 17:20:11 +00:00
parent a41e8c8e58
commit 069af655eb
1 changed files with 5 additions and 2 deletions
Download Patch File Download Diff File Expand all files Collapse all files

7
scan_engine_raw.cc
View File

@@ -1571,7 +1571,7 @@ bool get_arp_result(UltraScanInfo *USI, struct timeval *stime) {
int rc; int rc;
u8 rcvdmac[6]; u8 rcvdmac[6];
struct in_addr rcvdIP; struct in_addr rcvdIP;
struct timeval rcvdtime; struct timeval rcvdtime, fudgedsenttime;
bool timedout = false; bool timedout = false;
struct sockaddr_in sin; struct sockaddr_in sin;
HostScanStats *hss = NULL; 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 /* Delay in libpcap could mean we sent another probe *after* this
* response was received. Search back for the last probe before rcvdtime. */ * response was received. Search back for the last probe before rcvdtime. */
probeI--; 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); ultrascan_host_probe_update(USI, hss, probeI, HOST_UP, &rcvdtime);
/* Now that we know the host is up, we can forget our other probes. */ /* Now that we know the host is up, we can forget our other probes. */
hss->destroyAllOutstandingProbes(); hss->destroyAllOutstandingProbes();