Difference between revisions of "CC2540"

From RevSpace
Jump to navigation Jump to search
Line 45: Line 45:
 
* 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
 
* from the stick: raw sniffed BLE frames
 
* 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.
 
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 21:01, 16 November 2016

Project CC2540
Cc2540 webee.png
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:

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

Cc2540 settings.png
Cc2540 packet details.png
Cc2540 wireshark.png

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.