On Jul 17, 2014, at 11:04 AM, "Paul Raine" <praine@xxxxxxxxxxxxxxxxx> wrote:
> On July 17, 2014, at 12:44 PM, Guy Harris <guy@xxxxxxxxxxxx> 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.