libpcap version ? about arp-scan HOT 13 CLOSED

To downgrade temporarily libcap in Arch
pacman -U (http://dl.free.fr/r1JznEuHs)

from arp-scan.

Might be related to pcap_lookupdev() being depreciated in libpcap 1.9.0

On Fedora 30 with libpcap 1.9.0-PRE-GIT (with TPACKET_V3), arp-scan works OK but gives compiler warnings:

arp-scan.c:148:10: warning: ‘pcap_lookupdev’ is deprecated: use 'pcap_findalldevs' and use the first device [-Wdeprecated-declarations]
148 | if (!(if_name=pcap_lookupdev(errbuf))) {
| ^~
In file included from /usr/include/pcap.h:43,
from arp-scan.h:112,
from arp-scan.c:37:
/usr/include/pcap/pcap.h:326:16: note: declared here
326 | PCAP_API char *pcap_lookupdev(char *)
| ^~~~~~~~~~~~~~

Need to test on Arch Linux to check libpcap 1.9.1

from arp-scan.

Problem reproduced on Arch Linux 2019.10.01 x64:

rsh@arch:~/arp-scan$ uname -a
Linux arch 5.3.5-arch1-1-ARCH #1 SMP PREEMPT Mon Oct 7 19:03:08 UTC 2019 x86_64 GNU/Linux

rsh@arch:~/arp-scan$ sudo ./arp-scan --localnet
DEBUG: pcap_lookupdev returned interface ens33
Interface: ens33, type: EN10MB, MAC: 00:0c:29:8f:1a:6e, IPv4: 192.168.159.182
Starting arp-scan 1.9.5 with 256 hosts (https://github.com/royhills/arp-scan)

11 packets received by filter, 0 packets dropped by kernel
Ending arp-scan 1.9.5: 256 hosts scanned in 2.234 seconds (114.59 hosts/sec). 0 responded

from arp-scan.

The problem seems to be due to the following select() call always returning zero:
n = select(sock_fd+1, &readset, NULL, NULL, &to);
This indicates there is nothing ready to read on the file descriptor, so pcap_dispatch() never gets called.

Not sure why this is happening though. This code has been working on various Linux and BSD versions with many diffrerent libpcap versions for a long time.

from arp-scan.

Compiling arp-scan on arch 2019.10.01 x64 with libpcap 1.9.1 and running the binary on Fedora 30 x64 with libpcap 1.9.0 works fine and displays the expected output. This implies it's a shared library issue, and probably libpcap - as suggested by @cleoo

I think it's either a regression in libpcap between 1.9.0 and 1.9.1 or the arp-scan code breaking the libpcap api rules somewhere.

from arp-scan.

Problem reproduced on latest libpcap git revision:
ac945a40156ecbbd759528bb147b800cf9dd37dd
1.10.0-PRE-GIT (with TPACKET_V3)

arp-scan built on Debian buster after setting CPPFLAGS and LDFLAGS to force use of local lpcap headers and libs:
CPPFLAGS="-I/usr/local/include" LDFLAGS="-L/usr/local/lib" ./configure

from arp-scan.

Running git bisect to find possible regression point in libpcap:

rsh@buster:~/libpcap$ git bisect log
git bisect start
# good: [0ff834006347cc131e1256804d4f8d55301b27f3] set version to release
git bisect good 0ff834006347cc131e1256804d4f8d55301b27f3
# bad: [d396f255cf7b96a09cf91d0e8cc94d23777d6986] bump version
git bisect bad d396f255cf7b96a09cf91d0e8cc94d23777d6986
# skip: [9046eead54730fd0b0f9a00ea8fe283fe35b3808] Get rid of extra blank line.
git bisect skip 9046eead54730fd0b0f9a00ea8fe283fe35b3808
# good: [41abf587e7f386be4b67ad3ab720afe55d3579c1] No, you don't use commas there.
git bisect good 41abf587e7f386be4b67ad3ab720afe55d3579c1
# good: [16970a4a176cd262743007bf53aea16321ec060b] Removing null check before free
git bisect good 16970a4a176cd262743007bf53aea16321ec060b
# bad: [2ade7676101366983bd4f86bc039ffd25da8c126] With a timeout of zero, specify a maximum-size retire timeout.
git bisect bad 2ade7676101366983bd4f86bc039ffd25da8c126
# good: [dab5b0ea6f0a2a4024ec5eafa21d12db2c659b0c] Make the 7 used when rounding up a size unsigned.
git bisect good dab5b0ea6f0a2a4024ec5eafa21d12db2c659b0c
# good: [2c615752fe71085a82c93e5cc2e5c758a6195d52] Clean up the code to parse /proc/net/dev.
git bisect good 2c615752fe71085a82c93e5cc2e5c758a6195d52
# good: [7732ed7a5fa325d951df3b8b1f1b121d7890e60a] Just point to the big "kludge" comment in gen_vlan().
git bisect good 7732ed7a5fa325d951df3b8b1f1b121d7890e60a
# good: [5211a3f3aa72ea1b43e2e81e8101c8b269e2f076] Fix missing underscore in pcap man page.
git bisect good 5211a3f3aa72ea1b43e2e81e8101c8b269e2f076
# first bad commit: [2ade7676101366983bd4f86bc039ffd25da8c126] With a timeout of zero, specify a maximum-size retire timeout.

from arp-scan.

Opened libpcap issue the-tcpdump-group/libpcap#860

from arp-scan.

I think it's either a regression in libpcap between 1.9.0 and 1.9.1 or the arp-scan code breaking the libpcap api rules somewhere.

It's the second of those. You're setting the timeout to 0, which means "don't deliver packets until the kernel's packet buffer fills up" - to quote pcap(3PCAP):

   packet buffer timeout
          If,  when  capturing,  packets  are  delivered  as  soon as they
          arrive, the application capturing the packets will be  woken  up
          for  each  packet  as  it arrives, and might have to make one or
          more calls to the operating system to fetch each packet.

          If, instead, packets are not delivered as soon as  they  arrive,
          but  are  delivered after a short delay (called a "packet buffer
          timeout"), more than one packet can be  accumulated  before  the
          packets are delivered, so that a single wakeup would be done for
          multiple packets, and each set of calls made  to  the  operating
          system  would  supply  multiple  packets,  rather  than a single
          packet.  This reduces the per‐packet CPU overhead if packets are
          arriving  at  a  high rate, increasing the number of packets per
          second that can be captured.

          The packet buffer timeout is required  so  that  an  application
          won’t  wait for the operating system’s capture buffer to fill up
          before packets are delivered; if packets  are  arriving  slowly,
          that wait could take an arbitrarily long period of time.

          Not  all platforms support a packet buffer timeout; on platforms
          that don’t, the packet buffer timeout is ignored.  A zero  value
          for the timeout, on platforms that support a packet buffer time‐
          out, will cause a read to wait forever to allow  enough  packets
          to  arrive,  with  no timeout.  A negative value is invalid; the
          result of setting the timeout to  a  negative  value  is  unpre‐
          dictable.

That was buggy on Linux before 1.9.1; 1.9.1 fixed that.

You're setting immediate mode after the pcap_activate() on some platforms, but, if libpcap has pcap_set_immediate_mode(), you should, instead, call that between pcap_create() and pcap_activate(), which will set immediate mode appropriately for the platform.

from arp-scan.

@guyharris Thanks for the detailed explanation. That makes sense, and will simplify the arp-scan code by removing the need for DLPI and BPF ioctl workarounds.

As the old arp-scan code had been working on Linux with zero timeout for a long time (since libpcap 0.9.5 IIRC), there may be other projects making the same assumption. So a note about the change in behaviour in the libpcap changelong or another suitable place might be useful.

from arp-scan.

Changes suggested by @guyharris implemented in arp-scan commit 8513a18

Not fully tested yet, but appears to work on Debian 10 "buster" x64 with latest git version of libpcap. Further testing required.

from arp-scan.

Appears to work on Arch with lastest libcpap
Thanks

from arp-scan.

Looks like it's working on FreeBSD 12 and Solaris 10 as well, so I think this issue can be closed now.

from arp-scan.