Ticket Created
over 4 years ago

WERETECH-9123

Connect-IQ Ble advertising layer parsing bug, prevent many devices to function properly. (paired or not paired) Toybox::BluetoothLowEnergy::ScanResult:getRawData(), getServiceData , getServiceUuids are broken

Connect-IQ Ble advertising layer parsing bug, prevent many devices to function properly.
Reproduced on simulator, fenix 6x (9.0), fenix 6s.

Used bluetooth sniffer to confirm that the advertising bytes were correct, and different than what connect IQ returns.

When not paired :

Toybox::BluetoothLowEnergy::ScanResult:getRawData(), getServiceData , getServiceUuids
 are not receiving the proper data bytes from the network layer when **to be confirmed !!**the last advertising data type are :
 Complete List of 16-bit Service Class UUIDs

which is very common !
if the order is changed, and something else is set at the end, there is no problem at all.

In order to demonstrate this, I'm parsing the content of getRaw, using 2 stryd devices (ble indeed), one hardware v4 (last advertising data, is Shortened local name), which is working perfectly.

The parser, read all data, and decode them, now problem on this trace, it is complete, and perfectly good and valid.

devicename:Stryd kl
raw Adverting Data:[2, 1, 6, 7, 3, 24, 24, 20, 24, 10, 24, 9, 255, 170, 170, 210, 91, 0, 81, 82, 41, 9, 8, 83, 116, 114, 121, 100, 32, 107, 108]
--[AD Dump:
----[Record Dump:
    AD Len:2
    AD Type:Flags
    AD Type Integer:1
    AD Data Integer:[6]
    AD Data Hex:06
----[Record Dump:
    AD Len:7
    AD Type:Complete List of 16-bit Service Class UUIDs
    AD Type Integer:3
    AD Data Integer:[24, 24, 20, 24, 10, 24]
    AD Data Hex:181814180a18
    AD Data 16bits Service Class UUIDs:
        UUID: 0x1818
        UUID: 0x1418
        UUID: 0x0A18
----[Record Dump:
    AD Len:9
    AD Type:Manufacturer Specific Data
    AD Type Integer:255
    AD Data Integer:[170, 170, 210, 91, 0, 81, 82, 41]
    AD Data Hex:aaaad25b00515229
    AD Data String:ªªÒ[QR)
----[Record Dump:
    AD Len:9
    AD Type:Shortened Local Name
    AD Type Integer:8
    AD Data Integer:[83, 116, 114, 121, 100, 32, 107, 108]
    AD Data Hex:5374727964206b6c
    AD Data String:Stryd kl
--end of AD Dump]


Now, another generation of stryd (v3), where by lack of lack, advertising data last bytes are ...Complete List of 16-bit Service Class UUIDs

In this case, you can see that the raw data, is not correct, and stop before those advertising data.

If it was only the raw data, it won't be a problem, but getServiceUuids looks to use those bytes... so return none of those services.

devicename:Stryd
raw Adverting Data:[2, 1, 6, 9, 255, 170, 170, 115, 84, 0, 80, 82, 166, 6, 9, 83, 116, 114, 121, 100]
--[AD Dump:
----[Record Dump:
    AD Len:2
    AD Type:Flags
    AD Type Integer:1
    AD Data Integer:[6]
    AD Data Hex:06
----[Record Dump:
    AD Len:9
    AD Type:Manufacturer Specific Data
    AD Type Integer:255
    AD Data Integer:[170, 170, 115, 84, 0, 80, 82, 166]
    AD Data Hex:aaaa7354005052a6
    AD Data String:ªªsTPR¦
----[Record Dump:
    AD Len:6
    AD Type:Complete Local Name
    AD Type Integer:9
    AD Data Integer:[83, 116, 114, 121, 100]
    AD Data Hex:5374727964
    AD Data String:Stryd
--end of AD Dump]


When paired :

Class: Toybox::BluetoothLowEnergy::Device getService() and getServices()

are also affected !

This was confirmed with :
- nrf connect on android
- nrf connect desktop, with the nrf52 dongle I'm using for the simulator (confirmed into the simulator indeed)

Now, if it was only stryd, it would be okay, but my elliptical bike(FTMS profile), also adverstise services at the end... so they are not visible to the watch.

It is the same for many devices I checked, all that was availlable to me.

Is reporting to this forum enough to get it tracked by garmin ? anything else to do ?

Kind Regards.

Klick

Klick
  • over 4 years ago in reply to nilsbenson

    On some devices I see the advertised name and it matches the full name I can get later, but using one of my Raspberry Pi apps as an example, The name is advertised, but I can't see it in CIQ, but once connected, I see the name, but it's not the same as what's advertised (but still correct, and in fact more accurate).  

    So if you can get it with device.getName(), it could be different.

  • over 4 years ago in reply to jim_m_58

    Interesting - that would at least make me able to reliably detect the device. It would also mean that the bug is that CIQ is truncating the advertising data on the ScanResult, but does in fact have the full set of data somewhere in the stack.

    I'll give it a try this afternoon and report back here what I find. 

  • over 4 years ago in reply to jim_m_58

    What I'm thinking, is if you user the UUID to look for a device, then connect to it, you might be able to use device.getName() if you want to display it.

  • over 4 years ago in reply to nilsbenson

    So once you are paired, you don't get anything with device.getName()?

    In the case of the pi, the name advertised in my case is CIQGAR in the rRFConnect screen shot (and it's null in CIQ), but once I'm connected, device.getName() actually returns "hostname" of the pi.

  • over 4 years ago in reply to jim_m_58

    Jim,

    Yes, I've verified that your scanner shows the same thing as my code - NULL device name but DOES return a list of services which matches nrfConnect. 

    BleScan, and my verification in my app shows that the raw data array is 31 bytes. However, the device name marker in the advertising data starts at byte 32. It simply gets truncated. Since the order of these entries in the advertising is flexible - my guess is that the order of the entries in the advertising payload makes a differencec in whether or not you can see services, the device name, or both. Using BleScan I can properly discover all three of my wireless headsets, and my wireless BT -> aux adapter.

    Your app on my watch:

    nrfConnect mobile:

    wireshark dump:

    I am able to communicate with the device, I just can't ever see the name of it but I know it's being sent.

    For reference, here's my first pass at the bluetooth code for basic communication with it:

    https://github.com/nilsbenson/ciq-tenergy-solis-btle