On Oct 7, 2012, at 11:52 PM, Joerg Mayer <[email protected]> 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 <[email protected]>
Archives: http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:[email protected]?subject=unsubscribe
