linux-kernel - Re: [PATCH v1] Bluetooth: disable filter dup when scan for adv monitor

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 19 May 2021 22:47:20 +0200
From:   Marcel Holtmann <marcel@...tmann.org>
To:     Howard Chung <howardchung@...gle.com>
Cc:     "open list:BLUETOOTH SUBSYSTEM" <linux-bluetooth@...r.kernel.org>,
        CrosBT Upstreaming <chromeos-bluetooth-upstreaming@...omium.org>,
        Yun-Hao Chung <howardchung@...omium.org>,
        Archie Pusaka <apusaka@...omium.org>,
        "David S. Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>,
        Johan Hedberg <johan.hedberg@...il.com>,
        Luiz Augusto von Dentz <luiz.dentz@...il.com>,
        open list <linux-kernel@...r.kernel.org>,
        netdev@...r.kernel.org
Subject: Re: [PATCH v1] Bluetooth: disable filter dup when scan for adv
 monitor

Hi Howard,

> Disable duplicates filter when scanning for advertisement monitor for
> the following reasons. The scanning includes active scan and passive
> scan.
> 
> For HW pattern filtering (ex. MSFT), some controllers ignore
> RSSI_Sampling_Period when the duplicates filter is enabled.
> 
> For SW pattern filtering, when we're not doing interleaved scanning, it
> is necessary to disable duplicates filter, otherwise hosts can only
> receive one advertisement and it's impossible to know if a peer is still
> in range.

can we be a bit more specific on which controller does what. I am not inclined to always disable duplicate filtering unless your controller doesn’t do what you want it to do.

I also disagree with the last statement. If the device moved out of range (or comes back for that matter) you should get a HCI_VS_MSFT_LE_Monitor_Device_Event event that tells you if a device is in range or not.

Device leaving:

> HCI Event: LE Meta Event (0x3e) plen 43
      LE Advertising Report (0x02)
        Num reports: 1
        Event type: Non connectable undirected - ADV_NONCONN_IND (0x03)
        Address type: Random (0x01)
        Address: 01:9A:1F:C0:30:15 (Non-Resolvable)
        Data length: 31
        Flags: 0x1a
          LE General Discoverable Mode
          Simultaneous LE and BR/EDR (Controller)
          Simultaneous LE and BR/EDR (Host)
        16-bit Service UUIDs (complete): 1 entry
          Apple, Inc. (0xfd6f)
        Service Data (UUID 0xfd6f): f47698ff9243617d917ac521b5fcfd436afdb285
        RSSI: -86 dBm (0xaa)
> HCI Event: Vendor (0xff) plen 18
        23 79 54 33 77 88 97 68 02 01 15 30 c0 1f 9a 01  #yT3w..h...0....
        00 00                                            ..              

Device coming back:

> HCI Event: Vendor (0xff) plen 18
        23 79 54 33 77 88 97 68 02 01 95 b9 0b 32 22 2a  #yT3w..h.....2"*
        00 01                                            ..              
> HCI Event: LE Meta Event (0x3e) plen 43
      LE Advertising Report (0x02)
        Num reports: 1
        Event type: Non connectable undirected - ADV_NONCONN_IND (0x03)
        Address type: Random (0x01)
        Address: 2A:22:32:0B:B9:95 (Non-Resolvable)
        Data length: 31
        Flags: 0x1a
          LE General Discoverable Mode
          Simultaneous LE and BR/EDR (Controller)
          Simultaneous LE and BR/EDR (Host)
        16-bit Service UUIDs (complete): 1 entry
          Apple, Inc. (0xfd6f)
        Service Data (UUID 0xfd6f): 0b861791a0fb7adcf8b45f951f7d4b7c7fc8e3fd
        RSSI: -27 dBm (0xe5)

Regards

Marcel