Discussion:
building libpcap without usb support
Michael Richardson
2014-07-06 00:02:34 UTC
Permalink
It appears that on Linux there is no way to build libpcap without USB
support. There is no --disable-usb that I can see in ./configure, and
it appears that if you don't have the right headers, you just fail.
(Or did I miss something?)

Ubuntu 12.04 (which is what Travis runs), can not install both the amd64
and i386 versions of libusb-dev. We don't attempt to build both in .travis,
but I have another application that I build for -m32 as well, and it depends
upon libpcap.

--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works | network architect [
] ***@sandelman.ca http://www.sandelman.ca/ | ruby on rails [
Guy Harris
2014-07-06 00:39:54 UTC
Permalink
Post by Michael Richardson
It appears that on Linux there is no way to build libpcap without USB
support. There is no --disable-usb that I can see in ./configure, and
it appears that if you don't have the right headers, you just fail.
(Or did I miss something?)
The configure script should probably check for the necessary headers, and build the USB printer only if they're present.
Guy Harris
2014-07-06 02:21:02 UTC
Permalink
Post by Guy Harris
Post by Michael Richardson
It appears that on Linux there is no way to build libpcap without USB
support. There is no --disable-usb that I can see in ./configure, and
it appears that if you don't have the right headers, you just fail.
(Or did I miss something?)
The configure script should probably check for the necessary headers, and build the USB printer only if they're present.
s/printer/pcap module/ - I was thinking tcpdump, not libpcap.

pcap-usb-linux.c includes what should be standard Linux headers, plus including some headers under #ifdefs set by configure.

However, it assumes that, for example, struct usbdevfs_ctrltransfer will always be defined, even if <linux/usbdevice_fs.h> doesn't exist. That probably needs to be fixed; I'll look at that.

For other structures and #defines, pcap-usb-linux.c has its own versions; this makes me a little nervous - I'll have to see whether the authors of the code had a reason why 1) they had to do that and 2) it was safe to do that.
Guy Harris
2014-07-06 10:41:00 UTC
Permalink
Post by Guy Harris
However, it assumes that, for example, struct usbdevfs_ctrltransfer will always be defined, even if <linux/usbdevice_fs.h> doesn't exist. That probably needs to be fixed; I'll look at that.
Done. If that header isn't present, the USB probing code isn't built or called, so you don't get information about attached USB devices as the first items in the trace unless they happen for some other reason.
Guy Harris
2014-07-06 10:45:44 UTC
Permalink
Post by Guy Harris
Post by Guy Harris
However, it assumes that, for example, struct usbdevfs_ctrltransfer will always be defined, even if <linux/usbdevice_fs.h> doesn't exist. That probably needs to be fixed; I'll look at that.
Done. If that header isn't present, the USB probing code isn't built or called, so you don't get information about attached USB devices as the first items in the trace unless they happen for some other reason.
I've cherry-picked that to the 1.6 branch.

BTW, I don't see a 4.6 branch for tcpdump; will that be created soon as well?
Michael Richardson
2014-07-06 21:23:58 UTC
Permalink
Post by Guy Harris
Post by Guy Harris
Done. If that header isn't present, the USB probing code isn't built
or called, so you don't get information about attached USB devices as
the first items in the trace unless they happen for some other reason.
I've cherry-picked that to the 1.6 branch.
BTW, I don't see a 4.6 branch for tcpdump; will that be created soon as well?
Should be there.
Weird, it wasn't on bpf. Maybe cause it was down when I first made the
branches. It is there now....

There should be a branch:
tcpdump-4.6
libpcap-1.6

there should be tags:
tcpdump-4.6.0
libpcap-1.6.0
tcpdump-4.6.0-bp
libpcap-1.6.0-bp

I could add "X-Y.Z" tags to libpcap to augment the "X_Y_Z" tags and the
"X_Y.Z" tags that are a relic from using CVS which can't handle - and .
in tag names (which seeps into brains).

--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works | network architect [
] ***@sandelman.ca http://www.sandelman.ca/ | ruby on rails [
Michael Richardson
2014-07-06 21:17:15 UTC
Permalink
Post by Guy Harris
Post by Michael Richardson
It appears that on Linux there is no way to build libpcap without USB
support. There is no --disable-usb that I can see in ./configure, and
it appears that if you don't have the right headers, you just fail.
(Or did I miss something?)
The configure script should probably check for the necessary headers,
and build the USB printer only if they're present.
The headers are there, so it gets detected and configured, it's just that on
some slightly older distros (such as ubuntu 12.04, which is what's in
Travis-CI), you can't install the libusb-dev libraries for both :i386 and
:amd64 at the same time.

So if you build something, tcpdump, my uml_netjig, etc. that needs -lpcap,
you can't build it for both -m32 and -m64 without rejigging libraries.

Since I don't need pcap-usb support, and I'm building libpcap from source
anyway as I need the latest one, I'm happy to simply turn off usb support.

--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works | network architect [
] ***@sandelman.ca http://www.sandelman.ca/ | ruby on rails [
Guy Harris
2014-07-06 10:19:19 UTC
Permalink
Post by Michael Richardson
Ubuntu 12.04 (which is what Travis runs), can not install both the amd64
and i386 versions of libusb-dev. We don't attempt to build both in .travis,
but I have another application that I build for -m32 as well, and it depends
upon libpcap.
<linux/usbdevice_fs.h> is a kernel header; does USB sniffing require libusb-dev at all?
Romain Francoise
2014-07-06 10:28:40 UTC
Permalink
Post by Guy Harris
<linux/usbdevice_fs.h> is a kernel header; does USB sniffing require libusb-dev at all?
Nope. libusb is only required for canusb support.
Michael Richardson
2014-07-06 21:25:44 UTC
Permalink
Post by Romain Francoise
Post by Guy Harris
<linux/usbdevice_fs.h> is a kernel header; does USB sniffing require libusb-dev at all?
Nope. libusb is only required for canusb support.
Ah, that's a bit confusing.

There is a --disable-canusb, I think, so I'll try building libpcap
with that option, which ought to eliminate needing to link with -lusb.
I wonder if canusb sniffing is sufficiently rare, and forcing people
to have libusb-dev around is sufficiently annoying that we should
turn that off by default.

--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works | network architect [
] ***@sandelman.ca http://www.sandelman.ca/ | ruby on rails [
Guy Harris
2014-07-08 00:51:41 UTC
Permalink
Post by Michael Richardson
Post by Romain Francoise
Post by Guy Harris
<linux/usbdevice_fs.h> is a kernel header; does USB sniffing require libusb-dev at all?
Nope. libusb is only required for canusb support.
Ah, that's a bit confusing.
There is a --disable-canusb, I think, so I'll try building libpcap
with that option, which ought to eliminate needing to link with -lusb.
I wonder if canusb sniffing is sufficiently rare, and forcing people
to have libusb-dev around is sufficiently annoying that we should
turn that off by default.
I've changed the configure script in the trunk and the 1.6 branch so that, instead of looking for the header, it checks whether it can build, with -lusb-1.0, a program that calls libusb_init().

See if that fixes the problem.

Loading...