Package: libpcap0.8 Version: 1.1.1-2 Severity: normal 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. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
