Re: [Wireshark-bugs] [Bug 7808] libnl3 compatibility

[Guy Harris <guy () alum mit edu>]

On Oct 7, 2012, at 11:52 PM, Joerg Mayer <jmayer () loplof de> 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).

___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request () wireshark org?subject=unsubscribe