CC2540: Difference between revisions
No edit summary |
No edit summary |
||
Line 38: | Line 38: | ||
== Protocol == | == Protocol == | ||
In the windows sniffer software, it seems there are only two things communicated: | In the windows sniffer software, it seems there are only two things communicated: | ||
* towards the stick: which radio channel to sniff, and some other radio settings | * towards the stick: which radio channel to sniff, and some other radio settings | ||
Line 47: | Line 43: | ||
=== Configuring the radio === | === Configuring the radio === | ||
[[File:cc2540_settings.png|right|thumb]] | |||
This appears to be done using USB control transfers. | This appears to be done using USB control transfers. | ||
Line 92: | Line 89: | ||
=== Reading BLE frames === | === Reading BLE frames === | ||
[[File:cc2540_packet_details.png|thumb]] | |||
[[File:cc2540_wireshark.png|thumb]] | |||
This appears to be done using USB bulk input transfers. | This appears to be done using USB bulk input transfers. | ||
I can see a lot of similarities between the USB log and the BLE sniffer log. | I can see a lot of similarities between the USB log and the BLE sniffer log. | ||
The bulk USB data starts off with two bytes indicating the length of the rest of the data. | The bulk USB data starts off with two bytes indicating the length of the rest of the data. |
Revision as of 20:03, 16 November 2016
Project CC2540 | |
---|---|
Making the CC2540 BLE dongle work | |
Status | Initializing |
Contact | bertrik |
Last Update | 2016-11-16 |
Introduction
This page is about the CC2540 bluetooth low-energy sniffer dongle and getting it to work with Linux. A nice end result could be that it becomes possible to sniff directly in WireShark with this dongle.
I have such a "WeBee" dongle that can be found for about E15,- on websites like Aliexpress.
It's supposedly a CC2540 (or compatible) dongle, the USB id is 0451:16b3.
Interesting links:
- https://lacklustre.net/bluetooth/wireshark.html
- http://processors.wiki.ti.com/index.php/BLE_sniffer_guide
- https://github.com/andrewdodd/ccsniffpiper
Analysis
USB descriptor
When plugging this stick into a Linux machine, you can see it uses only one bulk endpoint.
XXX
USB logs from Windows
This USB device does actually work with Windows:
I've captured a log of the communication over USB while the BLE is capturing bluetooth traffic from some iBeacon, using USB pcap.
In the logs, I cannot see any firmware blobs being downloaded to the stick. Probably the stick comes with a pre-loaded firmware of itself to do the BLE sniffing.
Protocol
In the windows sniffer software, it seems there are only two things communicated:
- towards the stick: which radio channel to sniff, and some other radio settings
- from the stick: raw sniffed BLE frames
Configuring the radio
This appears to be done using USB control transfers.
Control transfer OUT:
- request type 0x40
- request 197 (0xC5)
- value/index/length 0/4/0
- no data
Control transfer IN:
- request type 0xC0
- request 198 (0xC6)
- value/index 0/0
- data: 0x00
Control transfer IN:
- request type 0xC0
- request 198 (0xC6)
- value/index 0/0
- data: 0x04
Control transfer OUT:
- request type 0x40
- request 201 (0xC9)
- value/index 0/0
- data: -
Control transfer OUT: to set the radio channel to sniff
- request type 0x40
- request 210 (0xD2)
- value/index 0/0
- data: 0x27
Control transfer OUT: ???
- request type 0x40
- request 210 (0xD2)
- value/index 0/1
- data: 0x00
Control transfer OUT: ???
- request type 0x40
- request 208 (0xD0)
- value/index 0/0
- data: -
Reading BLE frames
This appears to be done using USB bulk input transfers.
I can see a lot of similarities between the USB log and the BLE sniffer log. The bulk USB data starts off with two bytes indicating the length of the rest of the data.