Nmap Development mailing list archives
Re: libpcap regression since 1.5.3
From: Daniel Miller <bonsaiviking () gmail com>
Date: Thu, 21 May 2015 06:59:02 -0500
For anyone affected by this issue (i.e. using libpcap 1.5 and later on Linux 3.2 - 3.18), I've written a report of my findings on the issue page on Github (http://issues.nmap.org/34) which I will copy here: <https://github.com/nmap/nmap/issues/34#issuecomment-104241752>
A few final notes on this issue: - The most relevant bug report on libpcap for this issue is the-tcpdump-group/libpcap#380 <https://github.com/the-tcpdump-group/libpcap/issues/380>. The suggested workaround there is using a very short timeout on select(). I can confirm that this works to avoid packet loss if we add a short-timeout select before the primary one in readip_pcap, but I can't figure out how to make this a general solution that doesn't alter the timing too much or just become a busy wait. Example patch: --- a/tcpip.cc+++ b/tcpip.cc@@ -1710,6 +1710,9 @@ char *readip_pcap(pcap_t *pd, unsigned int *len, long to_usec, if (p == NULL) { /* Nonblocking pcap_next didn't get anything. */+ if (to_usec < 200000 && pcap_select(pd, to_usec) > 0)+ p = (char *) pcap_next(pd, &head);+ else if (pcap_select(pd, to_usec) == 0) timedout = 1; else - As noted in that libpcap issue, the underlying problem is a bug in Linux TPACKET_V3 mmapped packet capture. This bug was fixed in Linux 3.19, and I can confirm that Nmap has no further issues on Linux 4.0. Please file bug reports with your distros to backport the patch if possible: torvalds/linux@da413ee <https://github.com/torvalds/linux/commit/da413ee> - As a workaround, you can configure Nmap --disable-packet-ring --with-libpcap=included (an option that is passed along to libpcap's configure script). This disables the packet ring mmapped packet capture, which could slow down Nmap in very-high-packet-rate cases, but will be *far* less troublesome than this particular bug. Alternatively, you could try to muck around in libpcap/pcap-linux.c to try to downgrade to TPACKET_V2 which does not have this problem, but I have not tried that. Given that we have these workarounds, and the bug is demonstrated to be in the Linux kernel code, not in Nmap or libpcap, I am removing the release milestone. I will leave the bug open until either several major distros backport the kernel fix or we find a suitable workaround.
Dan On Mon, Mar 30, 2015 at 12:59 PM, Daniel Miller <bonsaiviking () gmail com> wrote:
Dario, Thank you for the bug report. We've seen this behavior as well, and are tracking it on our Issues page (http://issues.nmap.org/34). Previous reporters have noted that using the included libpcap 1.5.3 (./configure --with-libpcap=included) fixes the issue. Dan On Mon, Mar 30, 2015 at 9:18 AM, Dario Bertini <berdario () gmail com> wrote:When running a SYN scan, a lot of probes are dropped, and this slows down the scan terribly: https://gist.github.com/berdario/9e2eecba0d35f9255f29 If I wait for the scan to finish, subsequent scans are faster (probably until the network interface is torn down or anyhow until the next reboot) I reproduced the problem on Nixos, Ubuntu, Kali... and I recompiled nmap with different versions of libpcap 1.5.3 and 1.7.2 (the latest) are affected 1.3.0 and 1.4.0 aren't I can reproduce the problem while connecting to a machine on my network, I haven't been able to reproduce the problem by scanning localhost _______________________________________________ Sent through the dev mailing list https://nmap.org/mailman/listinfo/dev Archived at http://seclists.org/nmap-dev/
_______________________________________________ Sent through the dev mailing list https://nmap.org/mailman/listinfo/dev Archived at http://seclists.org/nmap-dev/
Current thread:
- Re: libpcap regression since 1.5.3 Daniel Miller (May 21)