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: Windows password security audit tool. GUI, reports in PDF.

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

Date:   Thu, 20 May 2021 11:23:07 +0800
From:   Yun-hao Chung <howardchung@...gle.com>
To:     Marcel Holtmann <marcel@...tmann.org>
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 <netdev@...r.kernel.org>
Subject: Re: [PATCH v1] Bluetooth: disable filter dup when scan for adv monitor

Hi Marcel,
Thanks for the comments.

On Thu, May 20, 2021 at 4:47 AM Marcel Holtmann <marcel@...tmann.org> wrote:
>
> 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.

Will update the commit message and submit again.

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

The last statement is about software filtering, which is used when
MSFT is not supported. Software filtering in the kernel is basically
doing an LE passive scan. When the duplicate filter is enabled, some
controllers consider packets with the same address but different RSSIs
as duplicate thus not reporting to the host, which makes userspace not
able to tell if a peer 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
>