mailing list archives
Re: Wireshark Bluetooth
From: Guy Harris <guy () alum mit edu>
Date: Thu, 17 Jul 2014 11:55:12 -0700
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
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
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>
mailto:wireshark-users-request () wireshark org?subject=unsubscribe
- Re: Wireshark Bluetooth, (continued)