Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Wireshark-users: Re: [Wireshark-users] Wireshark Bluetooth

From: "Paul Raine" <praine@xxxxxxxxxxxxxxxxx>
Date: Wed, 16 Jul 2014 20:12:49 -0500
>>What happens if you run the command "hcidump" while there's Bluetooth
traffic going to or from your machine?

Don't think I have that on my system...
I get " bash: hcidump: command not found".



-----Original Message-----
From: Guy Harris [mailto:guy@xxxxxxxxxxxx] 
Sent: Wednesday, July 16, 2014 12:57 PM
To: Paul Raine
Cc: wireshark-users@xxxxxxxxxxxxx
Subject: Re: [Wireshark-users] Wireshark Bluetooth


On Jul 16, 2014, at 6:35 AM, "Paul Raine" <praine@xxxxxxxxxxxxxxxxx> wrote:

> [root@FoxForce5 rainey]# sudo tcpdump -i bluetooth0
> tcpdump: verbose output suppressed, use -v or -vv for full protocol 
> decode listening on bluetooth0, link-type BLUETOOTH_HCI_H4_WITH_PHDR 
> (Bluetooth HCI UART transport layer plus pseudo-header), capture size 
> 65535 bytes
> 
> ^C
> 0 packets captured
> 157 packets received by filter
> 0 packets dropped by kernel

OK, so "packets received by filter" is actually "packets the kernel claims
have arrived over Bluetooth", and there is no filter, so, apparently, the
kernel, for whatever reason, isn't delivering packets to the Bluetooth
socket libpcap is using.

The Capture Interfaces dialog uses the same libpcap call that tcpdump uses
to get the "received by filter" (and "dropped by kernel") numbers, so it'll
report packets even if they're not getting delivered to the socket.

So tcpdump is showing the same problem that Wireshark is showing, meaning
this is either a libpcap problem or a kernel problem.

What happens if you run the command "hcidump" while there's Bluetooth
traffic going to or from your machine?