CC2540 - Revision history

Bertrik Sikken: /* Status */

2018-05-13T19:09:15Z

Status

← Older revision		Revision as of 19:09, 13 May 2018
Line 8:		Line 8:

	== Status ==		== Status ==
	At this point (2017-~~0509~~), the status is:		At this point (2017-05-09), the status is:
	* it is pretty clear which commands the default sniffer firmware understands		* it is pretty clear which commands the default sniffer firmware understands
	* ~~there is~~ a little test program to dump raw BLE frames		* I wrote a little test program to dump raw BLE frames
	* there is no plugin for WireShark yet		* there is no plugin for WireShark yet

2017-06-15T08:54:03Z

← Older revision		Revision as of 08:54, 15 June 2017
Line 145:		Line 145:

	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.

			Each frame starts with a byte indicating the type of frame, following by two bytes indicating the length of the rest of the frame (encoded as little endian).

	==== data frames ====		==== data frames ====
	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.

	~~Data frames start with 0x00, followed by the length of the rest of the frame.~~

	In the example image on the right:		In the example image on the right:
Line 166:		Line 166:
	* 01: 1 means this is a frame of type 1		* 01: 1 means this is a frame of type 1
	* 01 00: length of the rest of the frame encoded in little endian = 1 byte		* 01 00: length of the rest of the frame encoded in little endian = 1 byte
	* 40 or C0: unknown		* 40 or C0: unknown data byte

	== Software ==		== Software ==

2017-06-15T07:47:09Z

← Older revision		Revision as of 07:47, 15 June 2017
Line 151:		Line 151:
	Data frames start with 0x00, followed by the length of the rest of the frame.		Data frames start with 0x00, followed by the length of the rest of the frame.

			In the example image on the right:
			* 00: 0 means this is a data frame
			* 31 00: length of rest of frame encoded in little endian = 49 bytes decimal
			* 39 04 29 54: part of the time stamp
			* 2c d6 be ..: data frame contents

	==== unknown frames (tick or 'alive'?) ====		==== unknown frames (tick or 'alive'?) ====
Line 158:		Line 162:
	and		and
	<pre>01 01 00 C0</pre>		<pre>01 01 00 C0</pre>

			Interpretation:
			* 01: 1 means this is a frame of type 1
			* 01 00: length of the rest of the frame encoded in little endian = 1 byte
			* 40 or C0: unknown

	== Software ==		== Software ==

2017-06-15T07:39:36Z

← Older revision		Revision as of 07:39, 15 June 2017
Line 145:		Line 145:

	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.

			==== data frames ====
	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.

	Data frames start with 0x00, followed by the length of the rest of the frame.		Data frames start with 0x00, followed by the length of the rest of the frame.



			==== unknown frames (tick or 'alive'?) ====
	The stick also returns 4-byte frames, alternating between		The stick also returns 4-byte frames, alternating between
	<pre>01 01 00 40</pre>		<pre>01 01 00 40</pre>

2017-05-09T08:03:37Z

Update status

← Older revision		Revision as of 08:03, 9 May 2017
Line 6:		Line 6:
	\|Contact=bertrik		\|Contact=bertrik
	}}		}}

			== Status ==
			At this point (2017-0509), the status is:
			* it is pretty clear which commands the default sniffer firmware understands
			* there is a little test program to dump raw BLE frames
			* there is no plugin for WireShark yet

	== Introduction ==		== Introduction ==
	This page is about the CC2540 bluetooth low-energy sniffer dongle and getting it to work with Linux.		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.		A nice end result could be that it becomes possible to sniff directly in WireShark with this dongle.

	~~Status:~~
	* it works in raw mode
	* there is no plugin for WireShark yet

	I have such a "WeBee" dongle that can be found for about E15,- on websites like Aliexpress.		I have such a "WeBee" dongle that can be found for about E15,- on websites like Aliexpress.

2017-05-09T08:00:57Z

Update status

← Older revision		Revision as of 08:00, 9 May 2017
Line 3:		Line 3:
	\|Picture=cc2540_webee.png		\|Picture=cc2540_webee.png
	\|Omschrijving=Reverse engineering the CC2540 BLE sniffer dongle		\|Omschrijving=Reverse engineering the CC2540 BLE sniffer dongle
	\|Status=~~In progress~~		\|Status=Stalled
	\|Contact=bertrik		\|Contact=bertrik
	}}		}}
Line 10:		Line 10:
	This page is about the CC2540 bluetooth low-energy sniffer dongle and getting it to work with Linux.		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.		A nice end result could be that it becomes possible to sniff directly in WireShark with this dongle.

			Status:
			* it works in raw mode
			* there is no plugin for WireShark yet

	I have such a "WeBee" dongle that can be found for about E15,- on websites like Aliexpress.		I have such a "WeBee" dongle that can be found for about E15,- on websites like Aliexpress.

2016-11-19T15:59:35Z

← Older revision		Revision as of 15:59, 19 November 2016
Line 2:		Line 2:
	\|Name=CC2540		\|Name=CC2540
	\|Picture=cc2540_webee.png		\|Picture=cc2540_webee.png
	\|Omschrijving=~~Making~~ the CC2540 BLE dongle ~~work~~		\|Omschrijving=Reverse engineering the CC2540 BLE sniffer dongle
	\|Status=In progress		\|Status=In progress
	\|Contact=bertrik		\|Contact=bertrik
Line 74:		Line 74:
	(Bus Powered)		(Bus Powered)
	</pre>		</pre>

			Reading the identification from the stick with the 0xC0 command, results in the following 8-byte response
			<pre>40 25 40 05 03 00 01 00</pre>
			You can recognise the 2540 type number in there.

	=== USB logs from Windows ===		=== USB logs from Windows ===

2016-11-19T15:46:15Z

← Older revision		Revision as of 15:46, 19 November 2016
Line 136:		Line 136:
	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.

			Data frames start with 0x00, followed by the length of the rest of the frame.

			The stick also returns 4-byte frames, alternating between
			<pre>01 01 00 40</pre>
			and
			<pre>01 01 00 C0</pre>

	== Software ==		== Software ==

2016-11-18T15:12:07Z

fix status

← Older revision		Revision as of 15:12, 18 November 2016
Line 3:		Line 3:
	\|Picture=cc2540_webee.png		\|Picture=cc2540_webee.png
	\|Omschrijving=Making the CC2540 BLE dongle work		\|Omschrijving=Making the CC2540 BLE dongle work
	\|Status=In ~~Progress~~		\|Status=In progress
	\|Contact=bertrik		\|Contact=bertrik
	}}		}}

2016-11-18T12:02:54Z

← Older revision		Revision as of 12:02, 18 November 2016
Line 127:		Line 127:
	\| 0x40 \|\| 0xD0 \|\| 0 \|\| 0 \|\| - \|\| Start capture		\| 0x40 \|\| 0xD0 \|\| 0 \|\| 0 \|\| - \|\| Start capture
	\|}		\|}

			Request type 0x40 is a vendor-specific device request from host-to-device.
			Request type 0xC0 is a vendor-specific device request from device-to-host.

	=== Reading BLE frames ===		=== Reading BLE frames ===