(I'm doing "Reply all", as I think sending to "651...@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.)
On Dec 12, 2011, at 2:34 PM, Romain Francoise wrote:
> Hi Guy,
>
> Guy Harris <g...@alum.mit.edu> writes:
>
>> 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.
>
> Can you provide more information about the problems the libnl mode fixes?
> How exactly does it work better?
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.)
> 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).
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.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
