libpcap's configure script, when run on Linux, checks to see whether libnl is present and usable and, if so, uses it to create monN interfaces when monitor mode is requested for 802.11 adapters.  This is used by tcpdump, and by TShark and dumpcap from the Wireshark distribution, to support a "-I" flag (capital-"i") to support capturing in monitor mode, and is used by Wireshark to support a "capture in monitor mode" checkbox.

Using libnl to create a monN interface works better than using Wireless Extension ioctls to turn on monitor mode, which is what libpcap does if *not* linked with libnl.

Depending on how the Debian build process works, this might be the result of libnl not being given in the Build-Depends section of libpcap's "control" file - if the build process runs the configure script, and libnl *and* libnl-devel aren't present when the configure script is run, the configure script won't find libnl and will build without it.

This shouldn't break binary compatibility with programs built with the libpcap shared library - libpcap is explicitly linked with libnl, so the run-time linker will pull in libnl automatically.  (I just tested this on my Ubuntu 10.10 virtual machine.)  It may cause issues when *statically* linking with libpcap, but programs that use autoconf and use "pcap-config --static --libs" to find out what libraries are needed when linking statically with libpcap should work.

Hi Guy,

Guy Harris <guy@alum.mit.edu> writes:

Can you provide more information about the problems the libnl mode fixes?
How exactly does it work better?

I've never received any bug reports about this before so I'm trying to
evaluate if tying libpcap to libnl is worth the cost, especially since
libnl in Debian looks somewhat messy--we have three different versions
maintained by two different people. If the wext mode is good enough for
most users, I'd rather not add a binary dependency to libpcap0.8
(especially since so far it had a minimal set, only libc6).

Yes, packages are built in a clean environment with only their listed
build dependencies installed.

Thanks,

(I'm doing "Reply all", as I think sending to "651783@bugs.debian.org" will get this reply into the bug log.  If the right thing to do is to reply *only* to that address, so you don't get your own copy, let me know.)

Well, I configured and built libpcap without libnl, and configured and built tcpdump with it, and ran it on a (virtual) machine with a Wi-Fi adapter connected to our local Wi-Fi network, capturing on wlan0, with -I specified to capture in monitor mode.  After a while, I get disconnected from the network; I have the impression that this is the result of NetworkManager seeing that wlan0 is in monitor mode and "helpfully" disconnecting from the network.  When I ^C tcpdump, the connection is reestablished, perhaps because NetworkManager sees that monitor mode is off and reconnects.

I then configured and built libpcap with libnl, and configured and rebuilt tcpdump with it, and ran it again capturing on wlan0 with -I.  The connection is *not* dropped, probably because wlan0 is not in monitor mode - the mon0 interface created by libpcap is in monitor mode, and that's the interface to which libpcap binds the PF_PACKET socket.

I don't know if there are other advantages to creating a separate monN adapter rather than just putting wlanN into monitor mode, but I do have the impression that it's the "right thing to do" in order to capture in monitor mode.  One advantage I could think of is that it provides some level of reference-counting for monitor mode, by creating separate monitorm-mode interfaces for each program requesting monitor mode, so that as long as *somebody* wants monitor mode, the adapter stays in monitor mode, rather than, for example, having:

	program A requests monitor mode, so it's turned on, and libpcap remembers that it was off beforehand;

	program B requests monitor mode, but it's already on, and libpcap remembers that;

	program A exits, and libpcap attempts to restore the old monitor-mode setting, and turns it off out from under program B.

(I wish the "right thing to do" involved turning on monitor mode in a way that counted all the PF_PACKET sockets that had requested monitor mode, so that when the last such socket is closed, the hardware can be taken out of monitor mode, rather than requiring libpcap to set an atexit routine and manually undo monitor mode, whether by turning it back off or by destroying a monitor-mode interface.  I wish that were true on *BSD as well; Mac OS X does that because the way you request monitor mode is to ask for an 802.11-style header, but that has the disadvantage that you can't capture with 802.11 headers out of monitor mode, which you *can* do on *BSD.)

Another possibility might be to add support to libpcap to use libmnl for this, so libpcap can just use that.  I already had to cope with API differences between libnl 1.x and libnl 2.x, and I just discovered libnl 3.x when I noticed the three different versions.  I'll still have to do that, as not all distributions have libmnl (Fedora doesn't - it builds libpcap with some version of libnl, I don't remember which), but if the "m" in "libmnl" means it's simpler and doesn't keep changing its API from major release to major release, it might be a useful alternative, especially if more distributions start picking it up.

If that makes sense, let me know, and I can look at updating libpcap so that it can work with libmnl.

Hi Guy,

Sorry for the delay in responding to this, and thanks for providing your
use case for this bug.

Guy Harris <guy@alum.mit.edu> writes:

Yes, that would definitely be interesting. But I was thinking that it
would be even better if libpcap used the netlink interface directly
instead of relying on libnl. It already does so for the new nflog
interface, and it's tied to the kernel in other ways so the abstraction
level offered by libnl isn't so valuable than for other programs.

I don't know how much new code that would require, though.

Yes, I was thinking along those lines.

I'll add that to my list of things to do in my Copious Free Time(TM) (along with adding support for TPACKET_V3 and FreeBSD 9's new USB-capture mechanism and making a better mechanism into which to plug support for new capture device types and adding support for getting lists of available 802.11 channels and setting the channel and...)

Hi Romain,

It has been a "few" years since this bug has seen much action, and I
would like to inquire about the possibility of enabling this now that
libnl-1 and libnl-2 seem to be gone.

There is a project called Nzyme (http://nzyme.org) and it depends on
libpcap being able to put a device into monitor mode.  This doesn't
happen if libpcap is not built against libnl, and there's no indication
of why, unfortunately.  You can test this without having to go through
setting up nzyme with the very simple "tcpdump -I -i wlan0" - it simply
spits out that the device does not support monitor mode.

I did a test here locally, and it seems like libnl is an automagic dep,
so simply having the libnl-genl-3-dev package installed at the time of
building causes it to link against it.  I have tested that it works and
does what is expected of it; both "tcpdump -I -i wlan0" work properly as
well as nzyme.

One thing I didn't look into, is whether libnl is available on the other
architectures - in Kali we only support amd64/i386/arm{el,hf}/arm64 so
I'm not sure how it affects hurd or kfreebsd.

Hi Steev,

While the libnl landscape indeed seems to have simplified since the
last time I took a look at it, I don't think we are in a good place
right now. The last upload of libnl3 was in 2018. The packaging Git
repository has disappeared. Upstream-wise, there's a 3.5.0 release on
GitHub (picked up by Fedora), but it's not listed on the project
homepage... Not very encouraging.

There's also a known issue with the integration related to tcpdump
which now drops privileges by default and cannot delete the mon
interface it creates, leaking interfaces at each invocation.

So I won't be enabling this. I'm still of the opinion that libpcap
should do the work by itself and not require libnl.

Thanks.