This actually works correctly with the default bletiny sysconfig.
After a bit more digging, this is the config that makes it fail:
(simon/mynewt-1_2_0_rc1) ~>
$ newt target show bletiny
targets/bletiny
app=@apache-mynewt-core/apps/bletiny
bsp=@apache-mynewt-core/hw/bsp/rb-nano2
build_profile=optimized
syscfg=BLE_MAX_CONNECTIONS=32:MSYS_1_BLOCK_COUNT=96:MSYS_1_BLOCK_SIZE=80
Note that MSYS_1_BLOCK_SIZE=80 by itself is not sufficient to trigger the
problem, the other two values are needed as well. Not sure what's going on.
On Wed, Sep 6, 2017 at 10:24 AM, Simon Ratner <[email protected]> wrote:
> Not an off-by-one: for a 29-byte adv packet, the last byte is corrupted,
> for a 31-byte adv packet, the last 3 bytes are corrupted, so it seems to be
> capping the adv data at 28 bytes regardless of actual length.
>
> Confirmed with bletiny:
>
> 011335 received advertisement; event_type=3 rssi=-92 addr_type=1
> addr=3a:7b:80:88:44:77 length_data=31 data=0x1e:0xff:0x06:0x00:0x01:
> 0x09:0x20:0x00:0xd5:0x27:0x09:0x02:0xe2:0x4b:0x7d:0xf0:0xd8:
> 0xa6:0x95:0xa1:0x46:0xde:0x09:0xde:0x71:0x94:0x38:0xe9:0x04:0x1a:0x00
>
> 011348 received advertisement; event_type=3 rssi=-93 addr_type=1
> addr=3a:7b:80:88:44:77 length_data=31 data=0x1e:0xff:0x06:0x00:0x01:
> 0x09:0x20:0x00:0xd5:0x27:0x09:0x02:0xe2:0x4b:0x7d:0xf0:0xd8:
> 0xa6:0x95:0xa1:0x46:0xde:0x09:0xde:0x71:0x94:0x38:0xe9:0x74:0x19:0x00
>
> The last three bytes of that packet should be "2a a7 30":
>
> [image: Inline image 1]
>
>
> On Wed, Sep 6, 2017 at 9:55 AM, Simon Ratner <[email protected]> wrote:
>
>> Eliminated one more variable -- it isn't the fault of
>> ble_hs_adv_parse_fields, event->disc->data itself seems to be wrong. Given
>> that this is the last byte, perhaps an off-by-one in calculating the size
>> of the hci packet?
>>
>> scan: event_type=0 addr=6a:be:ca:d3:09:68 data=02 01 02 04 ff 04 03 03 02
>> 0a f9 11 07 bd 7e 63 a8 e9 03 62 ad 26 4d ae 2a 00 01 04 5c
>> scan: event_type=0 addr=6a:be:ca:d3:09:68 data=02 01 02 04 ff 04 03 03 02
>> 0a f9 11 07 bd 7e 63 a8 e9 03 62 ad 26 4d ae 2a 00 01 04 9b
>> scan: event_type=0 addr=6a:be:ca:d3:09:68 data=02 01 02 04 ff 04 03 03 02
>> 0a f9 11 07 bd 7e 63 a8 e9 03 62 ad 26 4d ae 2a 00 01 04 0c
>>
>>
>> On Wed, Sep 6, 2017 at 9:24 AM, Simon Ratner <[email protected]> wrote:
>>
>>> Found the culprit, and it is something else - the adv packet data itself.
>>>
>>> scan: event_type=0 addr_type=1 addr=4b:41:99:63:b4:e4 uuids128=1
>>> (cc040100-2aae-4d26-ad62-03e9a8637ebd) mfg_data_len=3
>>> scan: event_type=0 addr_type=1 addr=4b:41:99:63:b4:e4 uuids128=1
>>> (6c040100-2aae-4d26-ad62-03e9a8637ebd) mfg_data_len=3
>>> scan: event_type=4 addr_type=1 addr=4b:41:99:63:b4:e4 uuids128=0 ()
>>> mfg_data_len=10
>>>
>>> I see both types of reports, but note the uuid128: the first byte of it
>>> appears to be corrupted (should be 0x03).
>>>
>>>
>>> On Wed, Sep 6, 2017 at 8:43 AM, Simon Ratner <[email protected]> wrote:
>>>
>>>> Interesting, I will investigate more today and let you know.
>>>>
>>>> Maybe something to do with how the reports are prioritized onto HCI? We
>>>> have iOS apps advertising in the foreground which can be very aggressive
>>>> (sub-100ms) so a change in how the reports are ordered or stored may have
>>>> resulted in unfair starving of other advertisers when it comes to grabbing
>>>> an HCI event?
>>>>
>>>>
>>>> On 5 Sep. 2017 23:57, "Andrzej Kaczmarek" <
>>>> [email protected]> wrote:
>>>>
>>>> Hi Simon,
>>>>
>>>> On Wed, Sep 6, 2017 at 5:06 AM, Simon Ratner <[email protected]> wrote:
>>>> >
>>>> > Hi devs,
>>>> >
>>>> > I am seeing a change in behaviour when performing active scan,
>>>> compared to
>>>> > pre-1.1. Previously, BLE_GAP_EVENT_DISC event would be reported for
>>>> both
>>>> > the original advertising packet (BLE_HCI_ADV_RPT_EVTYPE_ADV_IND),
>>>> and the
>>>> > scan response (BLE_HCI_ADV_RPT_EVTYPE_SCAN_RSP), in close succession.
>>>> >
>>>> > With 1_2_0_dev, I no longer see the advertising packet data, only the
>>>> scan
>>>> > responses.
>>>> >
>>>> > This is my scan parameters:
>>>> >
>>>> > const struct ble_gap_disc_params scan_params_dflt = {
>>>> > .itvl = 0, /* use default */
>>>> > .window = 0, /* use default */
>>>> > .filter_policy = BLE_HCI_SCAN_FILT_NO_WL,
>>>> > .filter_duplicates = 0,
>>>> > .limited = 0,
>>>> > .passive = 0,
>>>> > };
>>>> >
>>>> > Is this an intentional change, and if so, any way to get at the
>>>> actual adv
>>>> > packet data?
>>>>
>>>> I'm not aware of any change in this code, but I've just done a quick
>>>> test using bletiny and for me it works just fine:
>>>>
>>>> [08:50:23:504] 093668 received advertisement; event_type=0 <cut> fields:
>>>> [08:50:23:600] 093672 flags=0x1a:
>>>> [08:50:23:600] 093672 General discoverable mode
>>>> [08:50:23:600] 093673 tx_pwr_lvl=-7
>>>> [08:50:23:600] 093674
>>>> [08:50:23:600] 093674 received advertisement; event_type=4 <cut> fields:
>>>> [08:50:23:600] 093680 uuids16(complete)=0x180d
>>>> [08:50:23:600] 093681 name(complete)=andk xperia z5
>>>>
>>>> I used 'b scan' which uses default parameters so the same as you quoted.
>>>>
>>>> Can you see the advertising reports in HCI trace? If so, can you show
>>>> them perhaps to check if they are correct?
>>>>
>>>> Best regards,
>>>> Andrzej
>>>>
>>>>
>>>>
>>>
>>
>
