[android] length 0 of device manufacturer data #28

mrquincle · 2017-04-09T11:03:49Z

Error with one of the properties regarding device manufacturer data.

04-09 12:47:29.517  3910  4310 D bt_btif_gattc: btif_gattc_update_properties BLE device name=Crown len=5 dev_type=2
04-09 12:47:29.517  3910  4310 E bt_btif : property type:241, len:0 is invalid
04-09 12:47:29.517  3910  4310 E bt_btif_dm: ### ASSERT : system/bt/main/../btif/src/btif_dm.c line 4655 failed to save remote device manufacturer (1) ###

Is the length properly set for the custom data that is sent?

The text was updated successfully, but these errors were encountered:

AlexDM0 · 2017-04-09T11:05:39Z

Isnt this an issue for bluenet lib android?

…

On 9 Apr 2017, at 13:03, Anne van Rossum ***@***.***> wrote: Error with one of the properties regarding device manufacturer data. 04-09 12:47:29.517 3910 4310 D bt_btif_gattc: btif_gattc_update_properties BLE device name=Crown len=5 dev_type=2 04-09 12:47:29.517 3910 4310 E bt_btif : property type:241, len:0 is invalid 04-09 12:47:29.517 3910 4310 E bt_btif_dm: ### ASSERT : system/bt/main/../btif/src/btif_dm.c line 4655 failed to save remote device manufacturer (1) ### Is the length properly set for the custom data that is sent? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

mrquincle · 2017-04-09T11:08:29Z

Feel free to move to appropriate location. If this is intended behavior on Android device it belongs here (I thought). If it reflects a bug in the firmware, it might be moved there.

mrquincle · 2017-04-09T11:28:43Z

In https://github.com/crownstone/bluenet/blob/master/src/ble/cs_Stack.cpp#L358

void Nrf51822BluetoothStack::configureIBeaconAdvData(IBeacon* beacon) {

The getArray() function from cs_iBeacon.h is used, which is hardcoded to 23. So that can't go wrong...

In https://github.com/crownstone/bluenet/blob/master/src/ble/cs_Stack.cpp#L411

void Nrf51822BluetoothStack::configureBleDeviceAdvData() {

The struct _advdata.p_manuf_specific_data is not set, neither the size of that struct.

This function seems not to be used? In a case CONFIG_IBEACON_ENABLED in cs_main_crownstone.cpp:

bool enabled = *(bool*)p_data;

This needs a low-level check to see how the packets actually look.

mrquincle · 2017-04-09T12:12:06Z

In wireshark I see the following:

Device d6:cc:73:b4:9c:be:

Bluetooth HCI Event - LE Meta
    Event Code: LE Meta (0x3e)
    Parameter Total Length: 40
    Sub Event: LE Advertising Report (0x02)
    Num Reports: 1
    Event Type: Scan Response (0x04)
    Peer Address Type: Random Device Address (0x01)
    BD_ADDR: d6:cc:73:b4:9c:be (d6:cc:73:b4:9c:be)
    Data Length: 28
    Advertising Data
        Service Data - 16 bit UUID
            Length: 20
            Type: Service Data - 16 bit UUID (0x16)
            UUID 16: Unknown (0xc001)
            Service Data: 0170f842830d8f9aae0b540d4ddf25faa6
        Device Name (shortened): Crown
            Length: 6
            Type: Device Name (shortened) (0x08)
            Device Name: Crown
    RSSI (dB): -88

Device cb:69:b8:69:14:6e:

Bluetooth HCI Event - LE Meta
    Event Code: LE Meta (0x3e)
    Parameter Total Length: 40
    Sub Event: LE Advertising Report (0x02)
    Num Reports: 1
    Event Type: Scan Response (0x04)
    Peer Address Type: Random Device Address (0x01)
    BD_ADDR: cb:69:b8:69:14:6e (cb:69:b8:69:14:6e)
    Data Length: 28
    Advertising Data
        Service Data - 16 bit UUID
            Length: 20
            Type: Service Data - 16 bit UUID (0x16)
            UUID 16: Unknown (0xc001)
            Service Data: 01181fba5e9422fc47a8951a348dacd26f
        Device Name (shortened): Crown
            Length: 6
            Type: Device Name (shortened) (0x08)
            Device Name: Crown
    RSSI (dB): -92

There are no differences that I can spot at first sight.

Then the same devices again, but for their iBeacon advertisements:

Device d6:cc:73:b4:9c:be:

See: Event Type: Connectable Undirected Advertising (0x00)

Bluetooth HCI Event - LE Meta
    Event Code: LE Meta (0x3e)
    Parameter Total Length: 42
    Sub Event: LE Advertising Report (0x02)
    Num Reports: 1
    Event Type: Connectable Undirected Advertising (0x00)
    Peer Address Type: Random Device Address (0x01)
    BD_ADDR: d6:cc:73:b4:9c:be (d6:cc:73:b4:9c:be)
    Data Length: 30
    Advertising Data
        Flags
            Length: 2
            Type: Flags (0x01)
            000. .... = Reserved: 0x0
            ...0 .... = Simultaneous LE and BR/EDR to Same Device Capable (Host): false (0x0)
            .... 0... = Simultaneous LE and BR/EDR to Same Device Capable (Controller): false (0x0)
            .... .1.. = BR/EDR Not Supported: true (0x1)
            .... ..1. = LE General Discoverable Mode: true (0x1)
            .... ...0 = LE Limited Discoverable Mode: false (0x0)
        Manufacturer Specific
            Length: 26
            Type: Manufacturer Specific (0xff)
            Company ID: Apple, Inc. (0x004c)
            Data: 021521719e9ddbb9434a9d9085e335fcccba778527dbc4
    RSSI (dB): -89

Device cb:69:b8:69:14:6e:

See: Event Type: Non-Connectable Undirected Advertising (0x03)

Bluetooth HCI Event - LE Meta
    Event Code: LE Meta (0x3e)
    Parameter Total Length: 42
    Sub Event: LE Advertising Report (0x02)
    Num Reports: 1
    Event Type: Non-Connectable Undirected Advertising (0x03)
    Peer Address Type: Random Device Address (0x01)
    BD_ADDR: cb:69:b8:69:14:6e (cb:69:b8:69:14:6e)
    Data Length: 30
    Advertising Data
        Flags
            Length: 2
            Type: Flags (0x01)
            000. .... = Reserved: 0x0
            ...0 .... = Simultaneous LE and BR/EDR to Same Device Capable (Host): false (0x0)
            .... 0... = Simultaneous LE and BR/EDR to Same Device Capable (Controller): false (0x0)
            .... .1.. = BR/EDR Not Supported: true (0x1)
            .... ..1. = LE General Discoverable Mode: true (0x1)
            .... ...0 = LE Limited Discoverable Mode: false (0x0)
        Manufacturer Specific
            Length: 26
            Type: Manufacturer Specific (0xff)
            Company ID: Apple, Inc. (0x004c)
            Data: 021521719e9ddbb9434a9d9085e335fcccbaf93a43fec4
    RSSI (dB): -92

Do I have an old version for one of the Crownstone's firmware? Where can I check that?

mrquincle · 2017-04-09T12:16:53Z

Correction. They both send out connectable and non-connectable iBeacon advertisements.

AlexDM0 · 2017-04-09T12:25:50Z

That is by design. Alternating these adheres to the iBeacon spec enough for the phones to keep alive :)

…

On Sun, Apr 9, 2017 at 2:16 PM, Anne van Rossum ***@***.***> wrote: Correction. They both send out connectable and non-connectable advertisements. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#28 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AFHWTd0DqlWUXTvsgMXdI_3LqsewNF5dks5ruMw1gaJpZM4M3_l3> .

mrquincle · 2017-04-09T14:09:16Z

This probably stems from not using a UUID from SIG yet as 16-bit Service Data UUID.

The question is... Do we need it? Do we actually use the Shortened Local Name (0x08) type in the scan response, see https://github.com/crownstone/bluenet/blob/master/docs/PROTOCOL.md?

I think we can get rid of these 10 bytes and use a 128 bit UUID that does not need registering.

Another road would be to not use scan responses at all. Just use our own advertisement type. We already have a company UUID. So it makes sense to use Manufacturer Specific (Data GAP 11.1.4) with the 16 bit company identifier.

vliedel · 2017-04-10T08:05:15Z

If we use the 128bit UUID, we don't have enough bytes left for the data. 1B AD len + 1B ad type + 16B UUID + 17B data = 35B, while we only have 31B. We only made the name as long as possible, and would drop it if it wouldn't fit.

vliedel · 2017-04-10T08:08:46Z

For the other road: we could indeed interleave iBeacon messages with the data messages, and not use a scan response at all. However, I think IPhones may not be able to recognize which IBeacon messages belongs to which data messages (as you don't get the MAC address), @AlexDM0 should know.

AlexDM0 · 2017-04-10T08:19:04Z

iPhones do not get mac adresses. The app database knows which major minor should match to which crownstone but I can't tell it to connect to one of them. The uuids I get instead of mac addresses are not provided when I get the iBeacon information. Those are only available for scan responses. I listen to the uid of the Crownstone (cloud short I'd of stone) and store their handles so I can look for them in the future.

…

On 10 Apr 2017, at 10:08, vliedel ***@***.***> wrote: For the other road: we could indeed interleave iBeacon messages with the data messages, and not use a scan response at all. However, I think IPhones may not be able to recognize which IBeacon messages belongs to which data messages (as you don't get the MAC address), @AlexDM0 should know. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

AlexDM0 · 2021-10-26T11:30:52Z

Is this still an issue?

mrquincle added the Android label Apr 9, 2017

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[android] length 0 of device manufacturer data #28

[android] length 0 of device manufacturer data #28

mrquincle commented Apr 9, 2017

AlexDM0 commented Apr 9, 2017 via email

mrquincle commented Apr 9, 2017 •

edited

Loading

mrquincle commented Apr 9, 2017 •

edited

Loading

mrquincle commented Apr 9, 2017 •

edited

Loading

mrquincle commented Apr 9, 2017 •

edited

Loading

AlexDM0 commented Apr 9, 2017 via email

mrquincle commented Apr 9, 2017

vliedel commented Apr 10, 2017

vliedel commented Apr 10, 2017

AlexDM0 commented Apr 10, 2017 via email

AlexDM0 commented Oct 26, 2021

[android] length 0 of device manufacturer data #28

[android] length 0 of device manufacturer data #28

Comments

mrquincle commented Apr 9, 2017

AlexDM0 commented Apr 9, 2017 via email

mrquincle commented Apr 9, 2017 • edited Loading

mrquincle commented Apr 9, 2017 • edited Loading

mrquincle commented Apr 9, 2017 • edited Loading

mrquincle commented Apr 9, 2017 • edited Loading

AlexDM0 commented Apr 9, 2017 via email

mrquincle commented Apr 9, 2017

vliedel commented Apr 10, 2017

vliedel commented Apr 10, 2017

AlexDM0 commented Apr 10, 2017 via email

AlexDM0 commented Oct 26, 2021

mrquincle commented Apr 9, 2017 •

edited

Loading

mrquincle commented Apr 9, 2017 •

edited

Loading

mrquincle commented Apr 9, 2017 •

edited

Loading

mrquincle commented Apr 9, 2017 •

edited

Loading