Hello List,
On Sun, Oct 07, 2012 at 05:06:27PM -0700, bugzilla-daemon@xxxxxxxxxxxxx wrote:
> https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=7808
>
> --- Comment #3 from Guy Harris <guy@xxxxxxxxxxxx> 2012-10-07 17:06:26 PDT ---
> (In reply to comment #2)
> > % ldd /usr/lib64/libpcap.so.1
>
> ...
>
> > libnl.so.1 => /usr/lib64/libnl.so.1 (0x00007f8d31eec000)
>
> ...
>
> Exactly.
>
> There's not much Wireshark can do about this; it *does* support libnl1, so I
> guess whatever Wireshark package you're using could be configured to use libnl1
> rather than libnl3 and not get collisions of that sort, or the distribution
> could stop configuring libpcap to use libnl (with the loss of some convenience
> in capturing in monitor mode).
>
> The best way to deal with this is probably to change libpcap to avoid using
> libnl to do things such as adding monitor-mode VIFs - perhaps just doing Full
> Frontal Netlink (it can't incorporate any GPLed code into the library, so
> merging in a GPLed or LGPLed netlink library isn't possible here) - which would
> also mean that more distributions will support libpcap's monitor-mode APIs
> (some avoid linking libpcap with libnl so as not having to deal with "which
> version of libnl should it use?" issues).
This leads to a question I have been asking myself for years now:
- Why do we do things in Wireshark that belong into libpcap?
Shouldn't the whole wireless low level stuff be in libpcap and
Wireshark/dumpcap would only call libpcap for that?
- There's other stuff as well, as the still existing split between
Winpcap and libpcap which causes lots of ugly #ifdefs
- Or, as an alternative: Include libpcap (well, the core enging) into
wireshark. That would allow for a unified capture and display syntax
(of course the display filters can filter for stuff that cannot be
done with libpcap).
Ciao
Jörg
--
Joerg Mayer <jmayer@xxxxxxxxx>
We are stuck with technology when what we really want is just stuff that
works. Some say that should read Microsoft instead of technology.
