I am debugging an android disconnection issue and have gathered bluetooth hci snoop logs and have browsed it via wireshark tool but i am not able to understand the datapackets being shown in the logs. Is there any official /non official documentation for understanding these hci snoop logs?
It's the Bluetooth HCI protocol. You can download the manual at https://www.bluetooth.com/specifications/adopted-specifications. Press "Core Version 5.0" to download the current version (5). If you check out Vol 2 Part E chapter 7, you will see all kind of packets. The ACL data packets depend on what kind of data it is (higher layer specification). For example GATT, you will find the documentation in Vol 3 Part G.
Related
The scenario:
I have one device (Android Phone) that I can control and I want to analyse the Bluetooth capabilities of a different device of which I have limited control/ information - I can only accept/ reject pairing, but I don't known what versions or features are supported (this is that I want to find out).
Question:
From the recorded HCI logs (in the Android Phone), can you determine what version/ technology was actually used in a successful pairing?
In other words, how can you tell whether Bluetooth low energy was used or the Classic Bluetooth (BR/EDR)?
Note: I am not looking for:
the LMP advertisement of the "remote host" as this will only tell
which Bluetooth version is supported (e.g. 4.1) but will not tell
which technology is actually used
also, not looking for the remote extended features telling what
technologies are supported (such as BR/EDR and LE) but without giving
details about which technology is actually used
Thanks :)
If the LE link is set up, HCI LE Meta Event 0x3E with sub event LE Connection Complete 0x01 will be seen in the logs. See core spec v5 Vol 2, part E.
If pairing occurs over the LE link, then SMP PDUs related to pairing will be seen in the HCI logs as pairing occurs on the host. See core spec Vol 3, Part H.
In LE, GATT is used to discover services of the remote device.
If the BR/EDR link is up, HCI Connection Complete event 0x03 will be seen in the logs. In BR/EDR, SDP is used to discover services of the remote device.
I have set up a Network where two devices are exchanging Bluetooth LE data.
The problem is when I use Wireshark I cannot see any HCI data packets. All I can see is HCI command packets and HCI event packets. When I use hcidump in Kali linux I get the same outcome.
I have seen examples online where HCI data packets appear when using hcidump. Can anyone suggest why I am not seeing any HCI data packets even though I am definitely sending data between the devices?
In order to see all HCI packets, including ACL data packets, you must run hcidump or btmon as root.
Try sudo hcidump
Is it possible to set a bluetooth le device into broadcast mode via command line (on Linux)? Is this available through hciconfig or hcitool commands?
I continue to read about broadcast mode, but can't find a way to enter into it in order to explore it.
I'm treating "broadcaster" as this article treats "broadcaster" http://rtcmagazine.com/articles/view/102266. And the wiki article states that "broadcast mode" is "little used" http://en.wikipedia.org/wiki/Bluetooth.
Thanks!
I didn't look at the wikipedia article, but the first article seems to be talking about "advertising broadcasts". You basically set up your system to periodically send out an advertising packet for other devices to "hear" to know that they can connect to it. That's completely all iBeacons are on the BLE side (as far as I can tell). And since it's the only way to find devices to connect to it's very very common.
The advertising packet has a data field so that you can broadcast information out without other devices needing to connect to get data. iBeacons use that to broadcast a GUID, but you could broadcast almost anything with the only restriction being the length
Radius Networks has published a how-to make an ibeacon from a raspberry pi and that gives you the linux commands to send advertising packets from the command line.
I'm trying to do something with this HCI module I got, which uses a CSR Bluecore6 chip. I'm very new to this, so I'd just want to make it perform inquiry scan only (i.e. make it discoverable). To do that, do I need to implement a bluetooth stack or do CSR chips already support that? The datasheet of the module isn't very helpful. Since it's a HCI module only, do I need to implement it inside an external MCU or within the chip?
Any other advise on what to expect will be much appreciated!
Thanks
If it is an HCI module then it will only support the standard bluetooth HCI interface and you must provide a stack on your MCU. CSR also provide a stack implementation (http://www.csr.com/products/19/csr-synergy) for most embedded devices.
you don't need a full stack just to perform inquiry / page scan, you can try to connect the module via its HCI interface to a PC or external MCU and send HCI commands to setup the scans, there are few PC tools lie the hciconfig tool on Linux
I know that one way to find this out is to have a look at the device specification. Most device specifications are reporting just that A2DP is supported. Is there another way to find which version of A2DP is used from a headset device?
I recommend using linux with either built in bluetooth or with a bluetooth dongle. Then you can use the bluez tool sdptool from the command line to get this information.
A protocol sniffer is not necessary as all a protocol sniffer does is decode the packets over the air (which is exactly what sdptool does already), and it is more difficult as you will need to find out the link key as well which, depending on the devices you are using, can be quite difficult.
Currently there are only 2 versions of A2DP - 1.0 and 1.2
The differences are only minor optimizations / adaptations. So from a user's point of view it really does not matter.
Both versions are compatible and will talk to each other.
Since the differences are minor technical documentation changes in the spec it is not marketed as different versions to the end user. (Its just A2DP)
To really know the versions you will have to hook up with a Protocol sniffer and look at the SDP (Service Discovery) Query which typically happens after pairing / initial connection.