Arch Linux

Please read this before reporting a bug:
https://wiki.archlinux.org/title/Bug_reporting_guidelines

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

FS#31014 - [libpcap] Network capture programs segfaulting in __opendirat () from /lib/libc.so

Attached to Project: Arch Linux
Opened by Derpy Hooves (mcd1992) - Sunday, 05 August 2012, 03:09 GMT
Last edited by Evangelos Foutras (foutrelis) - Sunday, 12 May 2013, 09:30 GMT
Task Type Bug Report
Category Packages: Core
Status Closed
Assigned To Thomas Bächler (brain0)
Architecture i686
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 1
Private No

Details

Description: (Testing on a Linode, kernel 3.4.2-linode44 i686) everything works fine on my Laptop with arch.

When attempting to run tshark/dumpcap/tcpdump with no interface specified all the programs will fail with gdb reporting it failing at __opendirat() in libc.so. If I specify the interface to use with -i eth0 then all the programs will succeed with their jobs, except ntop.

Running ntop with -i eth0 specified has the same effect as the above programs with no interface specified, so I'm at a loss as to whats causing the programs to segfault. Granted this might not be related to libc but maybe libpcap. Either was I will be watching this ticked for some assistance. I'm willing to provide any sort of gdb info needed.

Additional info: Ntop
Version : 4.1.0-2
Depends On : libevent libpcap gd glib libxml2 openssl rrdtool pcre geoip lua
Architecture : i686
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Additional info: glibc
Version : 2.16.0-2
Depends On : linux-api-headers>=3.4 tzdata
Architecture : i686
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Pastie of gdb output: http://pastie.org/4392531


Steps to reproduce:
Run ntop with glibc 2.16.0-2 i686 (on a linode?)
This task depends upon

Closed by  Evangelos Foutras (foutrelis)
Sunday, 12 May 2013, 09:30 GMT
Reason for closing:  Fixed
Additional comments about closing:  libpcap 1.4.0-1
Comment by Allan McRae (Allan) - Sunday, 05 August 2012, 06:30 GMT
I can not replicate.

Very similar backtrace here: https://bugs.launchpad.net/ubuntu/+source/colord/+bug/1026520 - perhaps this is a libusb issue.
Comment by Derpy Hooves (mcd1992) - Sunday, 05 August 2012, 18:42 GMT
Did you attempt on a Linode VPS?

The linode kernel I'm using has usb_device disabled (at least not showing up in /proc/devices) so maybe libpcap is trying to open the usb devices (not sure why)?
Comment by Evangelos Foutras (foutrelis) - Monday, 06 August 2012, 08:44 GMT
This is a bug in libpcap. It doesn't check the return value of libusb_init [1].

On a Linode VPS, libusb_init() will return -99:

$ LIBUSB_DEBUG=3 ./usb-test
libusbx: error [op_init] could not find usbfs
libusb_init() failed; ret = -99

Where usb-test is a simple test program (attached).

I have reported [2] the bug to upstream's tracker.

[1] https://github.com/mcr/libpcap/blob/master/pcap-canusb-linux.c#L96
[2] https://sourceforge.net/tracker/?func=detail&aid=3554749&group_id=53067&atid=469577
   usb-test.c (0.5 KiB)
Comment by Guy Harris (gharris) - Monday, 06 August 2012, 23:30 GMT
I've checked into the libpcap trunk and 1.3 branch a putative fix for

https://sourceforge.net/tracker/?func=detail&aid=3554749&group_id=53067&atid=469577

and attached to that bug a patch with the fix. You might want to pick up that fix for your version of libpcap, at least until a future libpcap release incorporates the fix.

Loading...