Re: Wireshark Bluetooth

[Guy Harris <guy () alum mit edu>]

On Jul 17, 2014, at 11:04 AM, "Paul Raine" <praine () solutions-eng com> wrote:

> On July 17, 2014, at 12:44 PM, Guy Harris <guy () alum mit edu> wrote:
>
> > And, under the *same* circumstances, tcpdump reports nothing?
>
> Correct. I'm guessing there is some kind of filter in the tcpdump version.

Unless Red Hat/the Fedora project have *added* a filter, as you specified no filter on the command line, the only 
filter in the tcpdump version would be one inadvertently introduced by libpcap doing something different from what 
hcidump does.

> And that's why I see:
>
> 0 packets captured
> 157 packets received by filter
> 0 packets dropped by kernel

The statistics that the Bluetooth code in libpcap provides are a bit misleading.  For regular network interfaces, either

        1) the filtering is done in the kernel, and the number of packets handed to the capture mechanism are counted, 
and that count is returned when a program asks for statistics

or

        2) the filtering is done in userland (because the kernel doesn't support filtering or because it can't handle 
the filter supplied), and the number of packets read from the kernel in libpcap is counted, and that count is returned 
when a program asks for statistics.

This can result in somewhat misleading results, as, especially with filtering done in the kernel, packets may pass the 
filter but not be read by the program, as the capture may have stopped before they were read, so the "packets captured" 
value might be less than the "packets received by filter" message even with no filter.

However, for Bluetooth, the filtering is done in userland (and not much in the way of filter expressions is supported), 
but, instead of counting the number of packets read from the kernel, it gets a raw "packets received" count from the 
kernel, so any filtering done by the kernel, *including, for example, any filtering done inadvertently as a result of 
libpcap not setting up whatever fields the Bluetooth people decided to add in the latest version of BlueZ, binary 
compatibility be damned* (yes, they *have* broken binary compatibility in the past...), affects the difference between 
"received by filter" and "captured", and that's *very* misleading.

I consider this a bug, and will change libpcap *not* to fetch raw packet count statistics from the kernel, but to 
report as packets "received by filter" only the packets that make it to userland from the socket.

However, there appears to be another problem with libpcap, wherein it's not seeing the packets that hcidump is.  I'll 
see whether I can reproduce this on one of my Linux virtual machines.
___________________________________________________________________________
Sent via:    Wireshark-users mailing list <wireshark-users () wireshark org>
Archives:    http://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
             mailto:wireshark-users-request () wireshark org?subject=unsubscribe