[android] length 0 of device manufacturer data

[mrquincle]

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?

[AlexDM0]

Isnt this an issue for bluenet lib android?

On 9 Apr 2017, at 13:03, Anne van Rossum notifications@github.com 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]

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]

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]

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]

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

[AlexDM0]

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 notifications@github.com 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 https://github.com/crownstone/CrownstoneApp/issues/28#issuecomment-292782342, or mute the thread https://github.com/notifications/unsubscribe-auth/AFHWTd0DqlWUXTvsgMXdI_3LqsewNF5dks5ruMw1gaJpZM4M3_l3 .

[mrquincle]

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]

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]

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]

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 notifications@github.com 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]

Is this still an issue?