Wireshark-dev: Re: [Wireshark-dev] [Wireshark-bugs] [Bug 7808] libnl3 compatibility
On Oct 7, 2012, at 11:52 PM, Joerg Mayer <jmayer@xxxxxxxxx> wrote:
> - Why do we do things in Wireshark that belong into libpcap?
Because, for better or worse, Wireshark releases happen faster than libpcap releases?
Because Wireshark supports versions of libpcap other than "what's on the trunk", so it has to cope with older versions of libpcap?
Because OSes may not have the latest shiniest version of libpcap?
Because putting stuff in libpcap requires that a reasonably future-proof API be provided for it?
I.e., there's a bunch of stuff that should be done in libpcap but that's
1) not done in libpcap yet, and we shouldn't hold up support in Wireshark waiting for that
or
2) is done in libpcap, but not all the platforms on which people might want to use the feature have the latest shiniest libpcap with support for it.
> Shouldn't the whole wireless low level stuff be in libpcap and
> Wireshark/dumpcap would only call libpcap for that?
Yes, ideally.
The main reason why Wireshark links with libnl is to support channel changing for 802.11 capture. Doing that in libpcap on Linux is probably not too painful (but would require that the current code be transplanted to libpcap - which means relicensing it with a BSD license - or reimplemented in BSD-licensed code), and doing it in *BSD is probably not too painful either.
Doing it on OS X is a bit more annoying, as there's no low-level C library that provides APIs for doing that; the choices are
1) using CoreWLAN, which is an Objective-C framework (which can be called from C; hopefully it only drags in the Objective-C runtime and the Foundation framework, without dragging in AppKit or something really bogus such as that), and which Apple hopefully won't balk at doing if that's required for updating OS X's libpcap to a version that supports changing channels
and
2) reverse-engineered low-level ioctls, the headers for which are, I think, available in older open-source releases of XNU but are licensed under the Apple Public Source License which has patent clauses that might keep other OSes from picking up that version of libpcap.
Designing a libpcap API for that also involves some level of future-proofing - an API that can't support 802.11ac or 802.11ad would not be ideal.
> - There's other stuff as well, as the still existing split between
> Winpcap and libpcap which causes lots of ugly #ifdefs
That's a combination of
1) libpcap not yet supporting remote capture (another item on my to-do list; I want to make sure it's Done Right, which means "works with pcap_create()/pcap_activate()" and "the API is extensible enough to handle authentication mechanisms other than username/password and capture mechanisms other than rpcap", which could include "running tcpdump or dumpcap over ssh" as well as "running rpcap over TLS")
and
2) WinPcap not being up-to-date with libpcap (which is why you can't read pcap-NG files with WinDump but you can with tcpdump on a number of UN*X platforms).
