Discussion:
Wireshark-users Digest, Vol 98, Issue 5
Paul Raine
2014-07-14 14:27:26 UTC
Permalink
We haven't dropped support for it. If something doesn't work, it's
probably best to ask "I tried XXX, and it didn't work?", giving details,
rather than "is XXX still supported?", as the former makes fewer assumptions
as to the underlying problem.
(It's also best not to assume that somebody who answers an e-mail is the
only person with whom you should be discussing the problem; replying only to
them leaves out other people who ?might be able to help.)

OK, sorry, let me re-phase that... I tried Bluetooth Packet Capture in
Wireshark. But it didn't work. Can anyone help?
OK, so that version of libpcap (Libpcap-1.1.1-3.fc14.i686.rpm) supports
Bluetooth capturing with the BlueZ Bluetooth stack *if* it was configured to
include that support.

What is meant by "if it was configured to include that support."? Is there
something that I need to configure within Libpcap??
Is that the "Capture Interfaces" dialog that pops up if you click
"Interface List" on the Wireshark welcome screen or select "Interfaces" from
the "Capture" menu? If so, it's successfully capturing packets (the packet
counts it shows for the interfaces it shows, whether Bluetooth or not, are
counts of packets it captures and discards, as it's capturing them only to
count them).
What is the name of the Bluetooth interface on which you're capturing?
Yes I was referring to the "Capture Interfaces" dialog. The Bluetooth
Interface is called "bluetooth0 Bluetooth adapter number 0".
Or is it the main Wireshark window with the packet list, packet details,
and hex dump, and does "I get nothing in the capture window" mean that there
are no packets in the packet list?

There are no packets in the main Wireshark window. This is the one (on my
computer) that is labelled "Capturing from Bluetooth adapter number 0 -
Wireshark". (It has fields such as "No.", "Time", "Source", "Destination",
"Protocol" and has the Hex dump at the bottom. No packets are displayed and
this main Wireshark window remains black even though when Bluetooth data is
exchanged with my computer it increases the "bluetooth0 Bluetooth adapter
number 0" count in the "Capture Interfaces" dialog.


------------------------------

Message: 5
Date: Fri, 11 Jul 2014 15:23:08 -0700
From: Guy Harris <guy-FrUbXkNCsVf2fBVCVOL8/***@public.gmane.org>
To: Paul Raine <praine-Cb7RZHV19h45hkZm/HhNrQC/***@public.gmane.org>
Cc: Community support list for Wireshark
<wireshark-users-IZ8446WsY0/***@public.gmane.org>
Subject: Re: [Wireshark-users] Wireshark Bluetooth
Message-ID: <5E2667EA-D773-407D-A857-3DA0E55C8F93-FrUbXkNCsVf2fBVCVOL8/***@public.gmane.org>
Content-Type: text/plain; charset=us-ascii
In answer to your question I just meant "capturing traffic sent by and
received by the machine running Wireshark"
I have a version of Wireshark running on Linux Fedora 14, which I had
been using in the past to analyze Bluetooth protocol packets sent to
and from the computer.
However, it has been a long time since I used it and I can't seem to
capture any Bluetooth packets any more. (It works fine for other
interfaces).
Because I've had it working before, I feel like I am either missing
something simple that I have just forgotten to do, or that Bluetooth
capture is no longer supported by Wireshark.
We haven't dropped support for it. If something doesn't work, it's probably
best to ask "I tried XXX, and it didn't work?", giving details, rather than
"is XXX still supported?", as the former makes fewer assumptions as to the
underlying problem.

(It's also best not to assume that somebody who answers an e-mail is the
only person with whom you should be discussing the problem; replying only to
them leaves out other people who might be able to help.)
Libpcap-1.1.1-3.fc14.i686.rpm
OK, so that version of libpcap supports Bluetooth capturing with the BlueZ
Bluetooth stack *if* it was configured to include that support.
Wireshark-1.4.10-1.fc14.i686.rpm
And that version supports dissecting Bluetooth packets.
Wireshark-gnome-1.4.10-1.fc14.i686.rpm
...which just adds the GUI.
And I am running Linux Kernel 2.6.35.6-45.fc14.i686 with Gnome 2.32.0
...and that kernel should include the BlueZ stack.
If I bring up the Wireshark dialog box that lists the number of
Bluetooth packets per interface I can see the Bluetooth packets
increase when I send and receive Bluetooth information.
Is that the "Capture Interfaces" dialog that pops up if you click "Interface
List" on the Wireshark welcome screen or select "Interfaces" from the
"Capture" menu? If so, it's successfully capturing packets (the packet
counts it shows for the interfaces it shows, whether Bluetooth or not, are
counts of packets it captures and discards, as it's capturing them only to
count them).

What is the name of the Bluetooth interface on which you're capturing?
But I get nothing in the capture window.
Is the capture window the small "packet count" window that can be popped up
during a capture, showing "Captured Packets", with a "Total" row and rows
for things such as SCTP, TCP, UDP, etc., and "Other"? If so, does "I get
nothing in the capture window" mean that all the counts are stuck at zero?

Or is it the main Wireshark window with the packet list, packet details, and
hex dump, and does "I get nothing in the capture window" mean that there are
no packets in the packet list?



------------------------------
Guy Harris
2014-07-14 21:03:22 UTC
Permalink
Post by Paul Raine
OK, so that version of libpcap (Libpcap-1.1.1-3.fc14.i686.rpm) supports Bluetooth capturing with the BlueZ Bluetooth stack *if* it was configured to include that support.
What is meant by "if it was configured to include that support."?
Libpcap is distributed by the developers (tcpdump.org) as a package of source code. Like a number of other open-source projects, that package includes a "configure script" generated by autoconf, which

1) attempts to figure out characteristics of the OS and OS version on which you're trying to build and for which you're trying to build, and arrange to make the build work there

and

2) for some optional features, lets you configure them in or out.

Bluetooth sniffing is one of those features. It's not currently available on any OS other than Linux, so the configure script configures it out if the OS for which libpcap is being built isn't Linux; it also configures it out if it can't find a necessary "include file" for the code that does Bluetooth capturing.

There's also a flag that can be passed to explicitly request it (which means the configure script will fail if it can't be configured in) or explicitly request its *absence* (which means that configure script won't configure it in even if it could).

The Fedora people take the source, may make changes to it, and, in the process of building a Fedora release, may run the configure script, or may use some other mechanism when building it.
Post by Paul Raine
From a quick look at the Fedora 14 source RPM for libpcap, they do make some changes, but none that would affect the Bluetooth configuration, *and* the spec file says it depends on bluez-libs-devel, so it appears that the intention is to include Bluetooth sniffing support.
Is there something that I need to configure within Libpcap??
If there is, it'd have to be done by getting the source RPM, making sure it doesn't configure with --disable-bluetooth, and building and installing libpcap from it:

http://www.rpm.org/max-rpm/s1-rpm-miscellania-srpms.html

But I'm not sure that's the problem.
Post by Paul Raine
Is that the "Capture Interfaces" dialog that pops up if you click "Interface List" on the Wireshark welcome screen or select "Interfaces" from the "Capture" menu? If so, it's successfully capturing packets (the packet counts it shows for the interfaces it shows, whether Bluetooth or not, are counts of packets it captures and discards, as it's capturing them only to count them).
What is the name of the Bluetooth interface on which you're capturing?
Yes I was referring to the "Capture Interfaces" dialog. The Bluetooth Interface is called "bluetooth0 Bluetooth adapter number 0".
OK, so that means that Wireshark sees that interface and can open it and capture on it, and therefore that libpcap *does* have Bluetooth support on your system, so rebuilding libpcap is not necessary and will not make a difference.
Post by Paul Raine
Or is it the main Wireshark window with the packet list, packet details, and hex dump, and does "I get nothing in the capture window" mean that there are no packets in the packet list?
There are no packets in the main Wireshark window. This is the one (on my computer) that is labelled "Capturing from Bluetooth adapter number 0 - Wireshark". (It has fields such as "No.", "Time", "Source", "Destination", "Protocol" and has the Hex dump at the bottom. No packets are displayed and this main Wireshark window remains black even though when Bluetooth data is exchanged with my computer it increases the "bluetooth0 Bluetooth adapter number 0" count in the "Capture Interfaces" dialog.
Black, or blank?

If you're doing a live capture and "Update list of packets in real time" is enabled, the main window will show (unless you've reconfigured Wireshark to do something differently):

the packet list, with the columns you mention;

the packet detail pane;

the hex dump pane;

and they should, if there are no packets, be white, not black.

If you're doing a live capture and "Update list of packets in real time" is *not* enabled, the main window will show a grey area where the packet panes are, and only when you stop the capture will Wireshark read in the packets and display them.
___________________________________________________________________________
Sent via: Wireshark-users mailing list <wireshark-users-IZ8446WsY0/***@public.gmane.org>
Archives: http://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
mailto:wireshark-users-request-IZ8446WsY0/***@public.gmane.org?subject=unsubscribe
Paul Raine
2014-07-14 21:24:48 UTC
Permalink
Post by Paul Raine
Post by Guy Harris
Black, or blank?
If you're doing a live capture and "Update list of packets in real time"
is enabled, the main window will show (unless you've reconfigured Wireshark
Post by Paul Raine
Post by Guy Harris
the packet list, with the columns you mention;
the packet detail pane;
the hex dump pane;
and they should, if there are no packets, be white, not black.
If you're doing a live capture and "Update list of packets in real time"
is *not* enabled, the main window will show a grey area where the packet
panes are, and only when you stop the >>capture will Wireshark read in the
packets and display them.


Thanks for your email Guy,

Yes, I do have "Update list of packets in real time" enabled.
And I meant the main window is "Blank" not black.

Attached is a screenshot showing the main window is blank even though the
number Bluetooth packets are increasing in "Capture Interfaces"
When I stop the capture the main window also stays blank.

Are there any other wireshark settings/rules that I need to be able to
display the packets from Bluetooth?
It works fine if I monitor eth0 or some other interface!

Regards,
PR


-----Original Message-----
From: Guy Harris [mailto:guy-FrUbXkNCsVf2fBVCVOL8/***@public.gmane.org]
Sent: Monday, July 14, 2014 4:03 PM
To: Paul Raine
Cc: wireshark-users-IZ8446WsY0/***@public.gmane.org
Subject: Re: [Wireshark-users] Wireshark Bluetooth
Post by Paul Raine
Post by Guy Harris
OK, so that version of libpcap (Libpcap-1.1.1-3.fc14.i686.rpm) supports
Bluetooth capturing with the BlueZ Bluetooth stack *if* it was configured to
include that support.
Post by Paul Raine
What is meant by "if it was configured to include that support."?
Libpcap is distributed by the developers (tcpdump.org) as a package of
source code. Like a number of other open-source projects, that package
includes a "configure script" generated by autoconf, which

1) attempts to figure out characteristics of the OS and OS version
on which you're trying to build and for which you're trying to build, and
arrange to make the build work there

and

2) for some optional features, lets you configure them in or out.

Bluetooth sniffing is one of those features. It's not currently available
on any OS other than Linux, so the configure script configures it out if the
OS for which libpcap is being built isn't Linux; it also configures it out
if it can't find a necessary "include file" for the code that does Bluetooth
capturing.

There's also a flag that can be passed to explicitly request it (which means
the configure script will fail if it can't be configured in) or explicitly
request its *absence* (which means that configure script won't configure it
in even if it could).

The Fedora people take the source, may make changes to it, and, in the
process of building a Fedora release, may run the configure script, or may
use some other mechanism when building it.
Post by Paul Raine
From a quick look at the Fedora 14 source RPM for libpcap, they do make some
changes, but none that would affect the Bluetooth configuration, *and* the
spec file says it depends on bluez-libs-devel, so it appears that the
intention is to include Bluetooth sniffing support.
Post by Paul Raine
Is there something that I need to configure within Libpcap??
If there is, it'd have to be done by getting the source RPM, making sure it
doesn't configure with --disable-bluetooth, and building and installing
libpcap from it:

http://www.rpm.org/max-rpm/s1-rpm-miscellania-srpms.html

But I'm not sure that's the problem.
Post by Paul Raine
Post by Guy Harris
Is that the "Capture Interfaces" dialog that pops up if you click
"Interface List" on the Wireshark welcome screen or select "Interfaces" from
the "Capture" menu? If so, it's successfully capturing packets (the packet
counts it shows for the interfaces it shows, whether Bluetooth or not, are
counts of packets it captures and discards, as it's capturing them only to
count them).
Post by Paul Raine
Post by Guy Harris
What is the name of the Bluetooth interface on which you're capturing?
Yes I was referring to the "Capture Interfaces" dialog. The Bluetooth
Interface is called "bluetooth0 Bluetooth adapter number 0".

OK, so that means that Wireshark sees that interface and can open it and
capture on it, and therefore that libpcap *does* have Bluetooth support on
your system, so rebuilding libpcap is not necessary and will not make a
difference.
Post by Paul Raine
Post by Guy Harris
Or is it the main Wireshark window with the packet list, packet details,
and hex dump, and does "I get nothing in the capture window" mean that there
are no packets in the packet list?
Post by Paul Raine
There are no packets in the main Wireshark window. This is the one (on my
computer) that is labelled "Capturing from Bluetooth adapter number 0 -
Wireshark". (It has fields such as "No.", "Time", "Source", "Destination",
"Protocol" and has the Hex dump at the bottom. No packets are displayed and
this main Wireshark window remains black even though when Bluetooth data is
exchanged with my computer it increases the "bluetooth0 Bluetooth adapter
number 0" count in the "Capture Interfaces" dialog.

Black, or blank?

If you're doing a live capture and "Update list of packets in real time" is
enabled, the main window will show (unless you've reconfigured Wireshark to
do something differently):

the packet list, with the columns you mention;

the packet detail pane;

the hex dump pane;

and they should, if there are no packets, be white, not black.

If you're doing a live capture and "Update list of packets in real time" is
*not* enabled, the main window will show a grey area where the packet panes
are, and only when you stop the capture will Wireshark read in the packets
and display them.
Guy Harris
2014-07-14 21:39:31 UTC
Permalink
Post by Paul Raine
Attached is a screenshot showing the main window is blank even though the
number Bluetooth packets are increasing in "Capture Interfaces"
When I stop the capture the main window also stays blank.
That is *extraordinarily* odd.
Post by Paul Raine
It works fine if I monitor eth0 or some other interface!
So it's not a generic bug in the Wireshark capture code path.

What happens if you don't open the Capture Interfaces window, but just select "bluetooth0" from the main window and start a capture?
___________________________________________________________________________
Sent via: Wireshark-users mailing list <wireshark-users-IZ8446WsY0/***@public.gmane.org>
Archives: http://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
mailto:wireshark-users-request-IZ8446WsY0/***@public.gmane.org?subject=unsubscribe
Paul Raine
2014-07-14 21:50:12 UTC
Permalink
Post by Paul Raine
Post by Guy Harris
What happens if you don't open the Capture Interfaces window, but just
select "bluetooth0" from the main window and start a capture?

Same thing - blank main window during and after capture.



-----Original Message-----
From: Guy Harris [mailto:guy-FrUbXkNCsVf2fBVCVOL8/***@public.gmane.org]
Sent: Monday, July 14, 2014 4:40 PM
To: Paul Raine
Cc: wireshark-users-IZ8446WsY0/***@public.gmane.org
Subject: Re: [Wireshark-users] Wireshark Bluetooth
Post by Paul Raine
Attached is a screenshot showing the main window is blank even though
the number Bluetooth packets are increasing in "Capture Interfaces"
When I stop the capture the main window also stays blank.
That is *extraordinarily* odd.
Post by Paul Raine
It works fine if I monitor eth0 or some other interface!
So it's not a generic bug in the Wireshark capture code path.

What happens if you don't open the Capture Interfaces window, but just
select "bluetooth0" from the main window and start a capture?

___________________________________________________________________________
Sent via: Wireshark-users mailing list <wireshark-users-IZ8446WsY0/***@public.gmane.org>
Archives: http://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
mailto:wireshark-users-request-IZ8446WsY0/***@public.gmane.org?subject=unsubscribe
Guy Harris
2014-07-14 22:54:26 UTC
Permalink
Post by Paul Raine
Post by Guy Harris
What happens if you don't open the Capture Interfaces window, but just select "bluetooth0" from the main window and start a capture?
Same thing - blank main window during and after capture.
So what happens if you run:

sudo tcpdump -D

sudo tcpdump -i bluetooth0

from the command line?
___________________________________________________________________________
Sent via: Wireshark-users mailing list <wireshark-users-IZ8446WsY0/***@public.gmane.org>
Archives: http://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
mailto:wireshark-users-request-IZ8446WsY0/***@public.gmane.org?subject=unsubscribe
Paul Raine
2014-07-16 13:28:43 UTC
Permalink
Post by Paul Raine
Post by Guy Harris
sudo tcpdump -D
sudo tcpdump -i bluetooth0
from the command line?
<user> is not in the sudoers file. This incident will be reported.


-----Original Message-----
From: Guy Harris [mailto:guy-FrUbXkNCsVf2fBVCVOL8/***@public.gmane.org]
Sent: Monday, July 14, 2014 5:54 PM
To: Paul Raine
Cc: wireshark-users-IZ8446WsY0/***@public.gmane.org
Subject: Re: [Wireshark-users] Wireshark Bluetooth
Post by Paul Raine
Post by Guy Harris
What happens if you don't open the Capture Interfaces window, but just
select "bluetooth0" from the main window and start a capture?
Post by Paul Raine
Same thing - blank main window during and after capture.
So what happens if you run:

sudo tcpdump -D

sudo tcpdump -i bluetooth0

from the command line?

___________________________________________________________________________
Sent via: Wireshark-users mailing list <wireshark-users-IZ8446WsY0/***@public.gmane.org>
Archives: http://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
mailto:wireshark-users-request-IZ8446WsY0/***@public.gmane.org?subject=unsubscribe
Paul Raine
2014-07-16 13:35:23 UTC
Permalink
Post by Paul Raine
Post by Guy Harris
sudo tcpdump -D
sudo tcpdump -i bluetooth0
from the command line?
[***@FoxForce5 rainey]# sudo tcpdump -D
1.eth0
2.bluetooth0 (Bluetooth adapter number 0)
3.eth1
4.usbmon1 (USB bus number 1)
5.usbmon2 (USB bus number 2)
6.usbmon3 (USB bus number 3)
7.usbmon4 (USB bus number 4)
8.any (Pseudo-device that captures on all interfaces)
9.lo
[***@FoxForce5 rainey]# 2
bash: 2: command not found...
[***@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
[***@FoxForce5 rainey]# sudo tcpdump -i bluetooth0 -v
tcpdump: 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
269 packets received by filter
0 packets dropped by kernel



-----Original Message-----
From: Paul Raine [mailto:praine-Cb7RZHV19h45hkZm/HhNrQC/***@public.gmane.org]
Sent: Wednesday, July 16, 2014 8:29 AM
To: 'Guy Harris'
Cc: 'wireshark-users-IZ8446WsY0/***@public.gmane.org'
Subject: RE: [Wireshark-users] Wireshark Bluetooth
Post by Paul Raine
Post by Guy Harris
sudo tcpdump -D
sudo tcpdump -i bluetooth0
from the command line?
<user> is not in the sudoers file. This incident will be reported.


-----Original Message-----
From: Guy Harris [mailto:guy-FrUbXkNCsVf2fBVCVOL8/***@public.gmane.org]
Sent: Monday, July 14, 2014 5:54 PM
To: Paul Raine
Cc: wireshark-users-IZ8446WsY0/***@public.gmane.org
Subject: Re: [Wireshark-users] Wireshark Bluetooth
Post by Paul Raine
Post by Guy Harris
What happens if you don't open the Capture Interfaces window, but just
select "bluetooth0" from the main window and start a capture?
Post by Paul Raine
Same thing - blank main window during and after capture.
So what happens if you run:

sudo tcpdump -D

sudo tcpdump -i bluetooth0

from the command line?

___________________________________________________________________________
Sent via: Wireshark-users mailing list <wireshark-users-IZ8446WsY0/***@public.gmane.org>
Archives: http://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
mailto:wireshark-users-request-IZ8446WsY0/***@public.gmane.org?subject=unsubscribe
Guy Harris
2014-07-16 17:57:14 UTC
Permalink
Post by Paul Raine
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?

___________________________________________________________________________
Sent via: Wireshark-users mailing list <wireshark-users-IZ8446WsY0/***@public.gmane.org>
Archives: http://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
mailto:wireshark-users-request-IZ8446WsY0/***@public.gmane.org?subject=unsubscribe
Paul Raine
2014-07-17 01:12:49 UTC
Permalink
Post by Paul Raine
Post by Guy Harris
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-FrUbXkNCsVf2fBVCVOL8/***@public.gmane.org]
Sent: Wednesday, July 16, 2014 12:57 PM
To: Paul Raine
Cc: wireshark-users-IZ8446WsY0/***@public.gmane.org
Subject: Re: [Wireshark-users] Wireshark Bluetooth
Post by Paul Raine
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?


___________________________________________________________________________
Sent via: Wireshark-users mailing list <wireshark-users-IZ8446WsY0/***@public.gmane.org>
Archives: http://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
mailto:wireshark-users-request-IZ8446WsY0/***@public.gmane.org?subject=unsubscribe
Guy Harris
2014-07-17 01:27:51 UTC
Permalink
Post by Paul Raine
Post by Guy Harris
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".
See whether there's a "bluez-hcidump" package available for your system and, if so, install it (and give me the full name of the package you installed).
___________________________________________________________________________
Sent via: Wireshark-users mailing list <wireshark-users-IZ8446WsY0/***@public.gmane.org>
Archives: http://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
mailto:wireshark-users-request-IZ8446WsY0/***@public.gmane.org?subject=unsubscribe
Paul Raine
2014-07-17 13:48:37 UTC
Permalink
Post by Guy Harris
See whether there's a "bluez-hcidump" package available for your system
and, if so, install it (and give me the full name of the package you
installed).

I found and installed "/usr/share/doc/bluez-hcidump-1.42"
Running this when there is some bluetooth activity gives me packet info....
as shown below....


[***@FoxForce5 rainey]# hcidump
HCI sniffer - Bluetooth packet analyzer ver 1.42
device: hci0 snap_len: 1028 filter: 0xffffffff
< HCI Command: Periodic Inquiry Mode (0x01|0x0003) plen 9
HCI Event: Command Complete (0x0e) plen 4
HCI Event: Inquiry Result (0x02) plen 15
< HCI Command: Exit Periodic Inquiry Mode (0x01|0x0004) plen 0
HCI Event: Command Complete (0x0e) plen 4
< HCI Command: Create Connection (0x01|0x0005) plen 13
HCI Event: Command Status (0x0f) plen 4
HCI Event: Role Change (0x12) plen 8
HCI Event: Connect Complete (0x03) plen 11
< HCI Command: Read Remote Supported Features (0x01|0x001b) plen 2
HCI Event: Page Scan Repetition Mode Change (0x20) plen 7
HCI Event: Command Status (0x0f) plen 4
HCI Event: Max Slots Change (0x1b) plen 3
HCI Event: Command Status (0x0f) plen 4
< HCI Command: Remote Name Request (0x01|0x0019) plen 10
HCI Event: Command Status (0x0f) plen 4
HCI Event: Read Remote Supported Features (0x0b) plen 11
< ACL data: handle 41 flags 0x02 dlen 10
L2CAP(s): Info req: type 2
HCI Event: Number of Completed Packets (0x13) plen 5
ACL data: handle 41 flags 0x02 dlen 16
L2CAP(s): Info rsp: type 2 result 0
Extended feature mask 0x01a8
< ACL data: handle 41 flags 0x02 dlen 10
L2CAP(s): Info req: type 3
HCI Event: Number of Completed Packets (0x13) plen 5
ACL data: handle 41 flags 0x02 dlen 20
L2CAP(s): Info rsp: type 3 result 0
Unknown (len 8)
< ACL data: handle 41 flags 0x02 dlen 12
L2CAP(s): Connect req: psm 1 scid 0x0040
HCI Event: Number of Completed Packets (0x13) plen 5
ACL data: handle 41 flags 0x02 dlen 16
L2CAP(s): Connect rsp: dcid 0x0180 scid 0x0040 result 1 status 2
Connection pending - Authorization pending
ACL data: handle 41 flags 0x02 dlen 16
L2CAP(s): Connect rsp: dcid 0x0180 scid 0x0040 result 0 status 0
Connection successful
< ACL data: handle 41 flags 0x02 dlen 12
L2CAP(s): Config req: dcid 0x0180 flags 0x00 clen 0
ACL data: handle 41 flags 0x02 dlen 16
L2CAP(s): Config req: dcid 0x0040 flags 0x00 clen 4
MTU 672
< ACL data: handle 41 flags 0x02 dlen 18
L2CAP(s): Config rsp: scid 0x0180 flags 0x00 result 0 clen 4
MTU 672
ACL data: handle 41 flags 0x02 dlen 14
L2CAP(s): Config rsp: scid 0x0040 flags 0x00 result 0 clen 0
Success
< ACL data: handle 41 flags 0x02 dlen 24
L2CAP(d): cid 0x0180 len 20 [psm 1]
SDP SSA Req: tid 0x0 len 0xf
pat uuid-16 0x1105 (OBEXObjPush)
max 65535
aid(s) 0x0000 - 0xffff
cont 00
ACL data: handle 41 flags 0x02 dlen 110
L2CAP(d): cid 0x0040 len 106 [psm 1]
SDP SSA Rsp: tid 0x0 len 0x65
count 98
record #0
aid 0x0000 (SrvRecHndl)
uint 0x10004
aid 0x0001 (SrvClassIDList)
< uuid-16 0x1105 (OBEXObjPush) >
aid 0x0004 (ProtocolDescList)
< < uuid-16 0x0100 (L2CAP) > <
uuid-16 0x0003 (RFCOMM) uint 0x11 > <
uuid-16 0x0008 (OBEX) > >
aid 0x0005 (BrwGrpList)
< uuid-16 0x1002 (PubBrwsGrp) >
aid 0x0009 (BTProfileDescList)
< < uuid-16 0x1105 (OBEXObjPush) uint 0x102 > >
aid 0x0100 (SrvName)
str "OPP"
aid 0x0200 (VersionNumList)
uint 0xfef7
aid 0x0303 (SuppFormatsList)
< uint 0x1 uint 0x2 uint 0x3 uint 0x4 uint 0x5 uint 0x6
uint 0xff >
cont 00
< ACL data: handle 41 flags 0x02 dlen 12
L2CAP(s): Connect req: psm 3 scid 0x0041
< ACL data: handle 41 flags 0x02 dlen 12
L2CAP(s): Disconn req: dcid 0x0180 scid 0x0040
HCI Event: Remote Name Req Complete (0x07) plen 255
HCI Event: Number of Completed Packets (0x13) plen 5
ACL data: handle 41 flags 0x02 dlen 16
L2CAP(s): Connect rsp: dcid 0x01c1 scid 0x0041 result 1 status 2
Connection pending - Authorization pending
HCI Event: Number of Completed Packets (0x13) plen 5
ACL data: handle 41 flags 0x02 dlen 16
L2CAP(s): Connect rsp: dcid 0x01c1 scid 0x0041 result 0 status 0
Connection successful
< ACL data: handle 41 flags 0x02 dlen 16
L2CAP(s): Config req: dcid 0x01c1 flags 0x00 clen 4
MTU 1013
HCI Event: Number of Completed Packets (0x13) plen 5
ACL data: handle 41 flags 0x02 dlen 16
L2CAP(s): Config req: dcid 0x0041 flags 0x00 clen 4
MTU 65520
< ACL data: handle 41 flags 0x02 dlen 18
L2CAP(s): Config rsp: scid 0x01c1 flags 0x00 result 0 clen 4
MTU 65520
ACL data: handle 41 flags 0x02 dlen 12
L2CAP(s): Disconn rsp: dcid 0x0180 scid 0x0040
HCI Event: Number of Completed Packets (0x13) plen 5
HCI Event: Number of Completed Packets (0x13) plen 5
HCI Event: Number of Completed Packets (0x13) plen 5
ACL data: handle 41 flags 0x02 dlen 18
L2CAP(s): Config rsp: scid 0x0041 flags 0x00 result 0 clen 4
MTU 1013
< ACL data: handle 41 flags 0x02 dlen 8
L2CAP(d): cid 0x01c1 len 4 [psm 3]
RFCOMM(s): SABM: cr 1 dlci 0 pf 1 ilen 0 fcs 0x1c
HCI Event: Number of Completed Packets (0x13) plen 5
HCI Event: Number of Completed Packets (0x13) plen 5
ACL data: handle 41 flags 0x02 dlen 8
L2CAP(d): cid 0x0041 len 4 [psm 3]
RFCOMM(s): UA: cr 1 dlci 0 pf 1 ilen 0 fcs 0xd7
< ACL data: handle 41 flags 0x02 dlen 18
L2CAP(d): cid 0x01c1 len 14 [psm 3]
RFCOMM(s): PN CMD: cr 1 dlci 0 pf 0 ilen 10 fcs 0x70 mcc_len 8
dlci 34 frame_type 0 credit_flow 15 pri 7 ack_timer 0
frame_size 1008 max_retrans 0 credits 7
HCI Event: Number of Completed Packets (0x13) plen 5
ACL data: handle 41 flags 0x02 dlen 18
L2CAP(d): cid 0x0041 len 14 [psm 3]
RFCOMM(s): PN RSP: cr 0 dlci 0 pf 0 ilen 10 fcs 0xaa mcc_len 8
dlci 34 frame_type 0 credit_flow 14 pri 7 ack_timer 0
frame_size 662 max_retrans 0 credits 7
< ACL data: handle 41 flags 0x02 dlen 8
L2CAP(d): cid 0x01c1 len 4 [psm 3]
RFCOMM(s): SABM: cr 1 dlci 34 pf 1 ilen 0 fcs 0x8f
HCI Event: Number of Completed Packets (0x13) plen 5
ACL data: handle 41 flags 0x02 dlen 8
L2CAP(d): cid 0x0041 len 4 [psm 3]
RFCOMM(s): UA: cr 1 dlci 34 pf 1 ilen 0 fcs 0x44
< ACL data: handle 41 flags 0x02 dlen 12
L2CAP(d): cid 0x01c1 len 8 [psm 3]
RFCOMM(s): MSC CMD: cr 1 dlci 0 pf 0 ilen 4 fcs 0x70 mcc_len 2
dlci 34 fc 0 rtc 1 rtr 1 ic 0 dv 1 b1 1 b2 1 b3 0 len 0
ACL data: handle 41 flags 0x02 dlen 12
L2CAP(d): cid 0x0041 len 8 [psm 3]
RFCOMM(s): MSC CMD: cr 0 dlci 0 pf 0 ilen 4 fcs 0xaa mcc_len 2
dlci 34 fc 0 rtc 1 rtr 1 ic 0 dv 0 b1 1 b2 1 b3 0 len 0
< ACL data: handle 41 flags 0x02 dlen 12
L2CAP(d): cid 0x01c1 len 8 [psm 3]
RFCOMM(s): MSC RSP: cr 1 dlci 0 pf 0 ilen 4 fcs 0x70 mcc_len 2
dlci 34 fc 0 rtc 1 rtr 1 ic 0 dv 0 b1 1 b2 1 b3 0 len 0
HCI Event: Number of Completed Packets (0x13) plen 5
HCI Event: Number of Completed Packets (0x13) plen 5
ACL data: handle 41 flags 0x02 dlen 12
L2CAP(d): cid 0x0041 len 8 [psm 3]
RFCOMM(s): MSC RSP: cr 0 dlci 0 pf 0 ilen 4 fcs 0xaa mcc_len 2
dlci 34 fc 0 rtc 1 rtr 1 ic 0 dv 1 b1 1 b2 1 b3 0 len 0
< ACL data: handle 41 flags 0x02 dlen 9
L2CAP(d): cid 0x01c1 len 5 [psm 3]
RFCOMM(d): UIH: cr 1 dlci 34 pf 1 ilen 0 fcs 0x2e credits 33
< ACL data: handle 41 flags 0x02 dlen 15
L2CAP(d): cid 0x01c1 len 11 [psm 3]
RFCOMM(d): UIH: cr 1 dlci 34 pf 0 ilen 7 fcs 0x32
OBEX: Connect cmd(f): len 7 version 1.0 flags 0 mtu 4096
HCI Event: Number of Completed Packets (0x13) plen 5
HCI Event: Number of Completed Packets (0x13) plen 5
ACL data: handle 41 flags 0x02 dlen 9
L2CAP(d): cid 0x0041 len 5 [psm 3]
RFCOMM(d): UIH: cr 0 dlci 34 pf 1 ilen 0 fcs 0xf4 credits 18
ACL data: handle 41 flags 0x02 dlen 16
L2CAP(d): cid 0x0041 len 12 [psm 3]
RFCOMM(d): UIH: cr 0 dlci 34 pf 1 ilen 7 fcs 0xf4 credits 1
OBEX: Connect rsp(f): status 200 len 7 version 1.0 flags 0 mtu 65280
< ACL data: handle 41 flags 0x02 dlen 192
< ACL data: handle 41 flags 0x01 dlen 192
< ACL data: handle 41 flags 0x01 dlen 192
< ACL data: handle 41 flags 0x01 dlen 95
L2CAP(d): cid 0x01c1 len 667 [psm 3]
RFCOMM(d): UIH: cr 1 dlci 34 pf 0 ilen 662 fcs 0x32
< ACL data: handle 41 flags 0x02 dlen 192
< ACL data: handle 41 flags 0x01 dlen 192
< ACL data: handle 41 flags 0x01 dlen 192
< ACL data: handle 41 flags 0x01 dlen 95
L2CAP(d): cid 0x01c1 len 667 [psm 3]
RFCOMM(d): UIH: cr 1 dlci 34 pf 0 ilen 662 fcs 0x32
HCI Event: Number of Completed Packets (0x13) plen 5
< ACL data: handle 41 flags 0x02 dlen 192
HCI Event: Number of Completed Packets (0x13) plen 5
< ACL data: handle 41 flags 0x01 dlen 192
HCI Event: Number of Completed Packets (0x13) plen 5
< ACL data: handle 41 flags 0x01 dlen 192
HCI Event: Number of Completed Packets (0x13) plen 5
< ACL data: handle 41 flags 0x01 dlen 95
L2CAP(d): cid 0x01c1 len 667 [psm 3]
RFCOMM(d): UIH: cr 1 dlci 34 pf 0 ilen 662 fcs 0x32
HCI Event: Number of Completed Packets (0x13) plen 5
< ACL data: handle 41 flags 0x02 dlen 192
HCI Event: Number of Completed Packets (0x13) plen 5
< ACL data: handle 41 flags 0x01 dlen 192
HCI Event: Number of Completed Packets (0x13) plen 5
< ACL data: handle 41 flags 0x01 dlen 192
< ACL data: handle 41 flags 0x01 dlen 8
L2CAP(d): cid 0x01c1 len 580 [psm 3]
RFCOMM(d): UIH: cr 1 dlci 34 pf 0 ilen 575 fcs 0x32
OBEX: Put cmd(c): len 2561
Name (0x01) = Unicode length 18
Length (0xc3) = 2529
Body (0x48) = Sequence length 2529
HCI Event: Number of Completed Packets (0x13) plen 5
HCI Event: Number of Completed Packets (0x13) plen 5
HCI Event: Number of Completed Packets (0x13) plen 5
HCI Event: Number of Completed Packets (0x13) plen 5
HCI Event: Number of Completed Packets (0x13) plen 5
HCI Event: Number of Completed Packets (0x13) plen 5
ACL data: handle 41 flags 0x02 dlen 12
L2CAP(d): cid 0x0041 len 8 [psm 3]
RFCOMM(d): UIH: cr 0 dlci 34 pf 1 ilen 3 fcs 0xf4 credits 4
OBEX: Put rsp(f): status 100 len 3
< ACL data: handle 41 flags 0x02 dlen 14
L2CAP(d): cid 0x01c1 len 10 [psm 3]
RFCOMM(d): UIH: cr 1 dlci 34 pf 0 ilen 6 fcs 0x32
OBEX: Put cmd(f): len 6 (continue)
End of Body (0x49) = Sequence length 0
HCI Event: Number of Completed Packets (0x13) plen 5
ACL data: handle 41 flags 0x02 dlen 12
L2CAP(d): cid 0x0041 len 8 [psm 3]
RFCOMM(d): UIH: cr 0 dlci 34 pf 1 ilen 3 fcs 0xf4 credits 1
OBEX: Put rsp(f): status 200 len 3
< ACL data: handle 41 flags 0x02 dlen 11
L2CAP(d): cid 0x01c1 len 7 [psm 3]
RFCOMM(d): UIH: cr 1 dlci 34 pf 0 ilen 3 fcs 0x32
OBEX: Disconnect cmd(f): len 3
HCI Event: Number of Completed Packets (0x13) plen 5
ACL data: handle 41 flags 0x02 dlen 12
L2CAP(d): cid 0x0041 len 8 [psm 3]
RFCOMM(d): UIH: cr 0 dlci 34 pf 1 ilen 3 fcs 0xf4 credits 1
OBEX: Disconnect rsp(f): status 200 len 3
< ACL data: handle 41 flags 0x02 dlen 8
L2CAP(d): cid 0x01c1 len 4 [psm 3]
RFCOMM(s): DISC: cr 1 dlci 34 pf 1 ilen 0 fcs 0x6e
HCI Event: Number of Completed Packets (0x13) plen 5
ACL data: handle 41 flags 0x02 dlen 8
L2CAP(d): cid 0x0041 len 4 [psm 3]
RFCOMM(s): UA: cr 1 dlci 34 pf 1 ilen 0 fcs 0x44
< ACL data: handle 41 flags 0x02 dlen 8
L2CAP(d): cid 0x01c1 len 4 [psm 3]
RFCOMM(s): DISC: cr 1 dlci 0 pf 1 ilen 0 fcs 0xfd
HCI Event: Number of Completed Packets (0x13) plen 5
ACL data: handle 41 flags 0x02 dlen 8
L2CAP(d): cid 0x0041 len 4 [psm 3]
RFCOMM(s): UA: cr 1 dlci 0 pf 1 ilen 0 fcs 0xd7
< ACL data: handle 41 flags 0x02 dlen 12
L2CAP(s): Disconn req: dcid 0x01c1 scid 0x0041
ACL data: handle 41 flags 0x02 dlen 12
L2CAP(s): Disconn req: dcid 0x0041 scid 0x01c1
< ACL data: handle 41 flags 0x02 dlen 12
L2CAP(s): Disconn rsp: dcid 0x0041 scid 0x01c1
HCI Event: Number of Completed Packets (0x13) plen 5
HCI Event: Number of Completed Packets (0x13) plen 5
ACL data: handle 41 flags 0x02 dlen 12
L2CAP(s): Disconn rsp: dcid 0x01c1 scid 0x0041
< HCI Command: Disconnect (0x01|0x0006) plen 3
HCI Event: Command Status (0x0f) plen 4
HCI Event: Disconn Complete (0x05) plen 4
^C
[***@FoxForce5 rainey]#

___________________________________________________________________________
Sent via: Wireshark-users mailing list <wireshark-users-IZ8446WsY0/***@public.gmane.org>
Archives: http://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
mailto:wireshark-users-request-IZ8446WsY0/***@public.gmane.org?subject=unsubscribe
Guy Harris
2014-07-17 17:44:19 UTC
Permalink
Post by Paul Raine
I found and installed "/usr/share/doc/bluez-hcidump-1.42"
Running this when there is some bluetooth activity gives me packet info....
as shown below....
And, under the *same* circumstances, tcpdump reports nothing?

That's *REALLY* strange - as far as I can tell, the code paths in hcidump and libpcap for opening a Bluetooth socket to capture traffic do the same thing.

___________________________________________________________________________
Sent via: Wireshark-users mailing list <wireshark-users-IZ8446WsY0/***@public.gmane.org>
Archives: http://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
mailto:wireshark-users-request-IZ8446WsY0/***@public.gmane.org?subject=unsubscribe
Paul Raine
2014-07-17 18:04:30 UTC
Permalink
-----Original Message-----
From: Guy Harris [mailto:guy-FrUbXkNCsVf2fBVCVOL8/***@public.gmane.org]
Sent: Thursday, July 17, 2014 12:44 PM
To: Paul Raine
Cc: wireshark-users-IZ8446WsY0/***@public.gmane.org
Subject: Re: [Wireshark-users] Wireshark Bluetooth
Post by Guy Harris
And, under the *same* circumstances, tcpdump reports nothing?
Correct. I'm guessing there is some kind of filter in the tcpdump version.
And that's why I see:

0 packets captured
157 packets received by filter
0 packets dropped by kernel




___________________________________________________________________________
Sent via: Wireshark-users mailing list <wireshark-users-IZ8446WsY0/***@public.gmane.org>
Archives: http://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
mailto:wireshark-users-request-IZ8446WsY0/***@public.gmane.org?subject=unsubscribe
Guy Harris
2014-07-17 18:55:12 UTC
Permalink
Post by Paul Raine
Post by Guy Harris
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.
Post by Paul Raine
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-IZ8446WsY0/***@public.gmane.org>
Archives: http://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
mailto:wireshark-users-request-IZ8446WsY0/***@public.gmane.org?subject=unsubscribe
Guy Harris
2014-07-17 19:28:39 UTC
Permalink
Post by Guy Harris
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.
Unfortunately, I was unable to see any Bluetooth traffic - even on the (Mac) host (using Apple's PacketLogger) for the virtual machines - so I was unable to reproduce the problem.

You can try reporting this to tcpdump-workers-YE1jQ5a0g24KACXWX4p+q9i2O/***@public.gmane.org, to see if the people who actually *developed* the Bluetooth support in libpcap can help.

___________________________________________________________________________
Sent via: Wireshark-users mailing list <wireshark-users-IZ8446WsY0/***@public.gmane.org>
Archives: http://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
mailto:wireshark-users-request-IZ8446WsY0/***@public.gmane.org?subject=unsubscribe
Loading...