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