Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Extended Advertising Events are missed when the message length is longer than 57 bytes #330

Open
turbinenreiter opened this issue Jul 28, 2023 · 2 comments
Labels
bug Something isn't working

Comments

@turbinenreiter
Copy link

turbinenreiter commented Jul 28, 2023

Describe the bug

I think I found an issue with Extended Advertising messages.
We are developing a BLE device that sends data via manufacturer data in advertising messages.
We confirmed that the messages are sent correctly from our BLE device using an app on a Mac.

But on the client I wrote, running on my Linux machine, I stop receiving advertising events once the message lengths exceed 57 bytes (not 57 bytes of manufacturer data, but 57 bytes of advertising).

This is going to be annoying to reproduce since none of you has our BLE device, but there is the client code anyway:

    #[ignore = "requires a BLE adapter"]
    #[tokio::test]
    async fn reproduce_error() -> Result<()> {
        let manager = Manager::new().await?;
        let adapters = manager.adapters().await?;
        let central = adapters
            .into_iter()
            .next()
            .ok_or(anyhow!("no adapters found"))?;
        central.start_scan(ScanFilter::default()).await?;
        let mut events = central.events().await?;

        while let Some(event) = events.next().await {
            match event {
                CentralEvent::ManufacturerDataAdvertisement {
                    id,
                    manufacturer_data,
                } => {
                    // 42069 is my device
                    //Once the message length exceeds 57 bytes (?), the advertising events stop happening
                    // same code on the microcontroller with less than 57 bytes does produce the events as expected
                    if manufacturer_data.contains_key(&42069) {
                        println!("42069: {:?}", manufacturer_data.get(&42069));
                    } else {
                        println!("{:?}", manufacturer_data.keys().collect::<Vec<&u16>>());
                    }
                }
                _ => {}
            }
        }

        Ok(())
    }

Expected behavior

I expect a CentralEvent::ManufacturerDataAdvertisement event with manufacturer data if a BLE device sends an "Extended Advertising".

Actual behavior

There is no event produced at all.

Additional context

Fedora 38 on Intel with Intel Bluetooth chip. The BLE device is an ESP32-C3 with our firmware.
The Bluetooth chip on my PC is an Intel AX210.

@turbinenreiter turbinenreiter added the bug Something isn't working label Jul 28, 2023
@qwandor
Copy link
Collaborator

qwandor commented Jul 28, 2023

Well that's a weird bug! But I suspect it's probably a bug in BlueZ (or maybe the Bluetooth adapter) rather than btleplug. Are you able to receive the manufacturer data you expect with the bluetoothctl command-line utility? Are there any interesting messages in the bluetoothd logs or syslog?

@turbinenreiter
Copy link
Author

turbinenreiter commented Jul 28, 2023

Does not look interesting imho

journalctl -fu bluetooth
Jul 28 15:32:12 worx bluetoothd[1665]: src/device.c:device_new() Unable to register device interface for 00:00:00:00:00:00
Jul 28 15:32:12 worx bluetoothd[1665]: Unable to create object for found device 00:00:00:00:00:00
Jul 28 15:32:18 worx bluetoothd[1665]: src/device.c:device_new() Unable to register device interface for 00:00:00:00:00

I used btmon tough -> and with that, I can see the longer messages. Example:

> HCI Event: LE Meta Event (0x3e) plen 255                   #8 [hci0] 0.741406
      LE Extended Advertising Report (0x0d)
        Num reports: 1
        Entry 0
          Event type: 0x0021
            Props: 0x0001
              Connectable
            Data status: �[0;33mIncomplete, more data to come�[0m
          Address type: Random (0x01)
          Address: 34:85:18:01:84:C8 (Non-Resolvable)
          Primary PHY: LE 1M
          Secondary PHY: LE 1M
          SID: 0x00
          TX power: 9 dBm
          RSSI: -57 dBm (0xc7)
          Periodic advertising interval: 0.00 msec (0x0000)
          Direct address type: Public (0x00)
          Direct address: 00:00:00:00:00:00 (OUI 00-00-00)
          Data length: 0xe5
        14 09 4c 61 70 70 2d 53 43 42 2d 50 72 65 41 6c  ..Katt-SCB-PreAl
        70 68 61 30 31 03 10 55 a4 cd ff 55 a4 b1 00 00  pha01..U...U....
        00 00 00 0d 0a 00 00 00 00 00 00 00 00 00 00 00  ................
        00 00 00 00 00 00 00 00 1c ba c9 3f 42 1b 05 42  ...........?B..B
        00 00 00 00 3c 00 00 00 70 e2 04 42 70 14 ca 3f  ....<...p..Bp..?
        33 20 00 00 38 00 00 00 74 14 ca 3f e0 e2 04 42  3 ..8...t..?...B
        00 00 00 00 00 00 00 00 bc 97 c9 3f c4 e3 04 42  ...........?...B
        86 ff 00 42 00 00 00 00 00 00 00 00 00 00 00 00  ...B............
        00 00 00 00 00 00 00 00 78 bb c9 3f 32 cb 00 42  ........x..?2..B
        00 00 00 00 00 34 85 18 01 84 c8 00 20 00 00 00  .....4...... ...
        20 00 00 00 07 00 00 00 01 00 00 00 00 00 00 00   ...............
        00 00 00 00 00 00 00 00 00 00 00 00 7f 01 00 01  ................
        00 00 00 00 00 00 00 00 00 00 00 00 00 ba 05 22  ..............."
        00 70 0b 3c 34 bb c9 3f a0 ba c9 3f 78 83 00 42  .p.<4..?...?x..B
        00 00 00 00 34                                   ....4           
        Name (complete): Katt-SCB-PreAlpha01
        SMP TK: 55a4
        cd ff 55 a4 b1 00 00 00 00 00 0d 0a 00 00 00 00  ..U.............
        00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1c  ................
        ba c9 3f 42 1b 05 42 00 00 00 00 3c 00 00 00 70  ..?B..B....<...p
        e2 04 42 70 14 ca 3f 33 20 00 00 38 00 00 00 74  ..Bp..?3 ..8...t
        14 ca 3f e0 e2 04 42 00 00 00 00 00 00 00 00 bc  ..?...B.........
        97 c9 3f c4 e3 04 42 86 ff 00 42 00 00 00 00 00  ..?...B...B.....
        00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 78  ...............x
        bb c9 3f 32 cb 00 42 00 00 00 00 00 34 85 18 01  ..?2..B.....4...
        84 c8 00 20 00 00 00 20 00 00 00 07 00 00 00 01  ... ... ........
        00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
        00 00 00 7f 01 00 01 00 00 00 00 00 00 00 00 00  ................
        00 00 00 00 ba 05 22 00 70 0b 3c 34 bb c9 3f a0  ......".p.<4..?.
        ba c9 3f 78 83 00 42 00 00 00 00 34              ..?x..B....4    

/edit:

BUT with bluetootctl, I can only see the short ones, and the long ones are missing:
Example short:

[CHG] Device 34:85:18:01:84:C8 ManufacturerData Key: 0xa455 (42069)
[CHG] Device 34:85:18:01:84:C8 ManufacturerData Value:
  01 00 01 00 00 00 69 08 00 00 00 00 00 00 00 00  ......i.........
  00 00 00 00 00 00 00 00 00 00                    .......... 

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants