1

I have a remote control that advertises BLE raw data:

nRF Connect screenshot

I need to make the exact advertisement (0x18f90...) using my raspberry pi or esp32 microcontroller. The problem is I can't find a way to advertise that exact raw data. Every library like espressif or sample code I use, kind of generates the raw data. Like this esp32 Arduino BLE iBeacon snippet:

BLEBeacon oBeacon = BLEBeacon();
oBeacon.setManufacturerId(0x5558); // fake Apple 0x004C LSB (ENDIAN_CHANGE_U16!)
oBeacon.setProximityUUID(BLEUUID(BEACON_UUID));
oBeacon.setMajor((bootcount & 0xFFFF0000) >> 16);
oBeacon.setMinor(bootcount&0xFFFF);
BLEAdvertisementData oAdvertisementData = BLEAdvertisementData();
BLEAdvertisementData oScanResponseData = BLEAdvertisementData();

Can anyone suggest a way to exactly clone a BLE advertiser?

The nRF Connect app has a feature to clone the advertiser, but no exporting is provided.

Zeke Lu
  • 6,349
  • 1
  • 17
  • 23
Rman
  • 19
  • 1
  • 3

1 Answers1

2

You can use BlueZ command line utilities on a Raspberry Pi to get pretty close to total control of recording and replaying a Bluetooth LE packet, but it still must have a valid BLE header. (See my related answer here that talks about the header.)

The Raspberry Pi BlueZ library also lets you record advertisements sent over the air, but there are no CLI tools pre-installed on Raspberry Pi that do this -- only C APIs. So I made a command line tool called scan that makes it easy. You can download and install it here.

Here's how that tool works:

./scanner

B8:27:EB:1F:93:4D -68 02 01 06 11 06 82 75 25 D9 37 9D D7 8F 5F 4A F4 20 00 00 75 30
71:5C:23:9D:BC:7F -68 02 01 1A 02 0A 0C 0B FF 4C 00 10 06 03 1A 3B D4 B2 EB
B8:27:EB:1F:93:4D -68 02 01 06 11 06 82 75 25 D9 37 9D D7 8F 5F 4A F4 20 00 00 75 30

In the above, the header is the MAC address of the BLE advertiser (e.g. B8:27:EB:1F:93:4D) followed by the RSSI (eg. -68) then the data bytes.

If you then want to replay the first data packed on a Raspberry Pi (e.g. the bytes 02 01 06 11 06 82 75 25 D9 37 9D D7 8F 5F 4A F4 20 00 00 75 30) you can do so with this command on the Raspberry Pi:

sudo hcitool -i hci0 cmd 0x08 0x0008 02 01 06 11 06 82 75 25 D9 37 9D D7 8F 5F 4A F4 20 00 00 75 30

Note in the above, the bytes after 0x0008 are just cut and pasted from the output of the ./scanner tool.

BTW, I am skeptical of the data shown in your Nordic NRF Connect screenshot -- that is normally a very good tool, but it is showing an advertisement that is longer than is usually supported for BLE 4.1. I would retry scanning it on a Raspberry Pi with the scanner tool mentioned above then you can try playing it back as shown.

davidgyoung
  • 63,876
  • 14
  • 121
  • 204
  • Why are you skeptical of the data shown by nRF Connect? This seems to be the data advertised: "`1e ff 58 55 18 f9 08 49 b2 ce 2c 5a 7a d4 d1 49 4b 75 7c db 7f 10 11 12 13 14 15 16 17 18 19`", it is 31 bytes long which fits precisely in a normal ADV_IND. – Emil May 09 '23 at 08:26
  • Thanks. I did the scan and fetched the raw data. However, when I `sudo hcitool -i hci0 cmd 0x08 0x0008 1E FF 58 55 18 48 46 4B 4A E1 6D 31 8D 85 F2 1C B2 42 EA CF BC B1 17 17 D5 10 11 12 13 14 15` I can't see the advertisement on my nrf app. But with different data, like `sudo hcitool -i hci0 cmd 0x08 0x0008 1e 02 01 1a 1a ff 4c 00 02 15 aa aa aa aa bb bb cc cc dd dd ee ee ee ee ee ee 01 00 01 00 c5` it works well. I don't know where is the problem in my raw data. – Rman May 09 '23 at 11:40
  • Two things make me suspicious about the bytes shown by Nordic (1) it shows the manufacturer data length to be 30 bytes, and on BLE4 I believe this is limited to 27 bytes (but perhaps that is a only a limitation when additional flag header bytes are present in the packet.) (2) the packet does not show flag header bytes, which are sometimes required by scanning devices so they are detected. I am not sure if NordicNRF connect is filtering these out before showing them to the user. – davidgyoung May 09 '23 at 16:40
  • @Rman maybe try two things: (1) As a test, cut off the last three bytes of the advertisement to see if it goes out: `sudo hcitool -i hci0 cmd 0x08 0x0008 1B FF 58 55 18 48 46 4B 4A E1 6D 31 8D 85 F2 1C B2 42 EA CF BC B1 17 17 D5 10 11 12`. (2) Next try adding a flags header to see if that helps with detections: `sudo hcitool -i hci0 cmd 0x08 0x0008 1E 02 01 1a 1B FF 58 55 18 48 46 4B 4A E1 6D 31 8D 85 F2 1C B2 42 EA CF BC B1 17 17 D5 10 11 12`. – davidgyoung May 09 '23 at 16:49
  • 1
    To clarify my reasoning on the above tests: (1) Perhaps the BLE chip on your Raspberry Pi will fail to transmit successfully if the packet is too long (whereas other chips on other devices may allow this.) (2)The device you are using to scan (Android? iOS?) may have a limitation were it won't detect or show an advertisement unless it meets certain criteria like the header. – davidgyoung May 09 '23 at 16:53
  • 1
    @Rman did you find that one of these adjustments worked for you? If so, please share the details so that it might help others. – davidgyoung May 09 '23 at 20:41