CC2540: Difference between revisions
No edit summary |
No edit summary |
||
| Line 40: | Line 40: | ||
* from the stick: raw sniffed BLE frames | * from the stick: raw sniffed BLE frames | ||
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 09:53, 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.
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:
- TODO
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
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.