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 >>> >>> >>> >> >
