Re: libpcap regression since 1.5.3

[Daniel Miller <bonsaiviking () gmail com>]

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/