Wireshark-dev: Re: [Wireshark-dev] wireshark and usb
From: Paolo Abeni <[email protected]>
Date: Mon, 04 Dec 2006 10:46:36 +0100
On Mon, 2006-12-04 at 01:15 -0800, Guy Harris wrote:
> > 1) capture -> Interfaces, gives me :
> > 
> >  	        Can't get list of interfaces: can't open raw by socket 97:
> >  		Rodzina adresw nie obsugiwana przez protok
> 
> That's actually an error in the code to enumerate *Bluetooth* 
> interfaces.  Does your machine have any Bluetooth interfaces?  That 
> error (97) is "Address family not supported by protocol", and is 
> returned by a
> 
> 	socket(AF_BLUETOOTH, SOCK_RAW, BTPROTO_HCI)
> 
> call - Paolo, would you get that error if, for example, Bluetooth 
> support weren't configured into the kernel, or if you have no Bluetooth 
> devices?  If so, libpcap should probably treat EAFNOSUPPORT as an 
> indication that there aren't any Bluetooth devices, rather than an error.

This describe exactly what is happening and the correct solution :-)

> >          Once I press OK, windows disappears and I get no list
> >          However, it works to do :
> > 
> >          Capture -> Options -> enter "USB4" -> Start
> 
> That probably means that the libpcap code to enumerate USB interfaces 
> isn't finding your interface.  What are the contents of the 
> /sys/kernel/debug/usbmon directory on your machine?

This is quite strange, because when enumeration the usb buses and
opening the usb interface for sniffing the pcap code is looking for the
same files...

> > 2) stop of capture, I get this error :
> > 
> >          	Can't get packet-drop statistics:
> >  		Can't parse stat line 'nreaders 1 events 7614 text_lost 1918'
> >  		expected 2 token got 1
> > 
> >  	        Please report this to the Wireshark developers.
> >  		(This is not a crash; please do not report it as such.)
> 
> The libpcap code that gets the statistics is looking for a line of the form
> 
> 	nreaders {N} text_lost {M}
> 
> and can't handle the "events {N}" in there.  It might need to do the 
> parsing directly, rather than using sscanf(), in case different versions 
> of the kernel code put different information in there.

Again, this describe exactly what is happening and the correct
solution :-). The text string produced by the kernel has changed
switching from fedora 5 to fedora 6.

Best Regards 

Paolo

p.s. the usb sniffing code is currently under heavy refactoring, so
things are going to change...