Message ID | 20230214145609.kernel.v1.1.Ibe4d3a42683381c1e78b8c3aa67b53fc74437ae9@changeid |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:adf:eb09:0:0:0:0:0 with SMTP id s9csp3244560wrn; Tue, 14 Feb 2023 15:00:41 -0800 (PST) X-Google-Smtp-Source: AK7set8j26oV7O1M22e1S/37cCxcRWADUaeRfnotFh3pb8Ub6FUh1BECAtplujjdsOFEPerhJmc6 X-Received: by 2002:aa7:8a0b:0:b0:5a8:1866:7cfe with SMTP id m11-20020aa78a0b000000b005a818667cfemr908022pfa.17.1676415641487; Tue, 14 Feb 2023 15:00:41 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1676415641; cv=none; d=google.com; s=arc-20160816; b=vP5gRM9l1MwU43hJ1yiRxDHVvAzySTF2QWwqbMY24dLNSOPIhDFgRLb1W+YDChFcES Kpd/bMLuTKCEZwFR8YwVOlwM7zVftPeuKnfFugmPw0xucBep/ySzrzgXMMh5JsjDRAgp RWBjAXJIPpMm0OR2znTtL2dj4BxwZebSs866d3gLJcYpFkOxnTS5oXCM7i8L358QDp66 AQrI1gfg8LYQqh6/TdC0b51/9SQedv9SSPrLeu0qV1TyYCmSRlKL36B/YNmJwmV+vNFI ECA0eqy4PpT4cpEDR53n8SrvK5MVT0Sqbu/B6K5UI3YhZOGssZ67kvTwR8jWz0lheyXm E0Aw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:from:subject:message-id:mime-version:date :dkim-signature; bh=d2LKeVjdglgBPLcsM7WUahFxxZMsBH+ZUt0TnFuwIo8=; b=oRM0SmHXltlavY3kxJeXs2FQppy86rYx9SMisOtSc1rSElsTyiDAIi84LuRsYmU3/V 6SyvQFrImji17B+EjFx+frZUyYp8ZjMG2tOqG/AusDvGGOgnbT3QFXM7qwPtVFw7iI3U zNqk8sxzuqVGhwCXDTzLbqnlTVbzCzX0xRZsubQ37oRP5C8qWc5J8gr1GDV+T/boJxHI jJFIiij9IbWOnxJB/g4GjfcdiXQQVJ6jZ9v8qsnee8jOOr4kmhbPjPL8HPI3sGDNT4kw k053Ipos5hD6DW8iPq1jM7/aRHxNsO7btIqAhRpqnEl0R1my01srfZINS0wHt4cCRcaZ e2Gw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=CVHEhPyp; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id 80-20020a621753000000b00594472eb4fesi16117896pfx.228.2023.02.14.15.00.27; Tue, 14 Feb 2023 15:00:41 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=CVHEhPyp; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231934AbjBNW4Z (ORCPT <rfc822;tebrre53rla2o@gmail.com> + 99 others); Tue, 14 Feb 2023 17:56:25 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58134 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229454AbjBNW4Y (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Tue, 14 Feb 2023 17:56:24 -0500 Received: from mail-pl1-x649.google.com (mail-pl1-x649.google.com [IPv6:2607:f8b0:4864:20::649]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3C1BE28D00 for <linux-kernel@vger.kernel.org>; Tue, 14 Feb 2023 14:56:23 -0800 (PST) Received: by mail-pl1-x649.google.com with SMTP id y15-20020a1709029b8f00b00198e0564d73so9920276plp.22 for <linux-kernel@vger.kernel.org>; Tue, 14 Feb 2023 14:56:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=cc:to:from:subject:message-id:mime-version:date:from:to:cc:subject :date:message-id:reply-to; bh=d2LKeVjdglgBPLcsM7WUahFxxZMsBH+ZUt0TnFuwIo8=; b=CVHEhPypiO5omY1RQfCswgvy4wUi+AoBlXqVxDRnbUcIhGVJiOOHBXKcru3HvsWzGA 9DaP4h84gZoYw5os8S4tTM9f0UNBmFHVp1QDoWTXJ5Yyhk8G6CvtB1V/D0di6gj+g9W0 AkVdGdp2QHl5oeuvyUa0Yg83Uq3k3hNTX2qm8k0aYLCdKPQPKzd6ippLYk93gJ80JjkQ T++lUE4ddbnBTgRG1tTREEXeUtwTMbAimm+/r9TEfhnf6ORXo2zPSjYm37xrMEQ8leU8 h1ofBTWzu9nFKqhMudA8JVcbY4x81IuB+XRzNOLWsoWZr5dmjQ5UvHCkWq+yg9zWTUgl K3UA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:from:subject:message-id:mime-version:date:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=d2LKeVjdglgBPLcsM7WUahFxxZMsBH+ZUt0TnFuwIo8=; b=e+SDBXbEmfPVe1ftX3hZgfim1ESVkGsIJpHPygNJL0k8/pyv3L05dVwnQQgr7I/rO6 f6nC8gSWYL3kYXLz9FRPHJfBOaeboOdq3K0B/00kxH9i9tW4nS695NQjxS1R4F+rAxVH yEdFF/bB5KMQ4Fgq/xRHfaqf2we1HElDXZ97eEDWhNI86m+QgdBxZq2yVBE16Nuz5uRg cNR6w0U2RTEpaR5DoPNHG76X+69A/k0ylo9Oa6SesgP3Mcv4KS9vbEupjqgfjxJzJRtO nf/HqdjabDjqnHgYp9aPlGD7+ZyxW9xgMp/ZVQr5ivj51yESn4zlVI12u0xYVuNSjCb2 okVw== X-Gm-Message-State: AO0yUKWvioMYheXPXXZM1Xgw2mCIUBnkV+xzxX/fNkGLQxNdBjEnP0zf Xysh2MtXjZ7Rc5m+W6o/9pm85g0Ulkp8 X-Received: from jiangzp-glinux-dev.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:4c52]) (user=jiangzp job=sendgmr) by 2002:a63:3dc4:0:b0:4ce:e113:5e32 with SMTP id k187-20020a633dc4000000b004cee1135e32mr10817pga.10.1676415382678; Tue, 14 Feb 2023 14:56:22 -0800 (PST) Date: Tue, 14 Feb 2023 14:56:15 -0800 Mime-Version: 1.0 X-Mailer: git-send-email 2.39.1.581.gbfd45094c4-goog Message-ID: <20230214145609.kernel.v1.1.Ibe4d3a42683381c1e78b8c3aa67b53fc74437ae9@changeid> Subject: [kernel PATCH v1] Bluetooth: hci_sync: Resume adv with no RPA when active scan From: Zhengping Jiang <jiangzp@google.com> To: linux-bluetooth@vger.kernel.org, marcel@holtmann.org, luiz.dentz@gmail.com Cc: chromeos-bluetooth-upstreaming@chromium.org, Zhengping Jiang <jiangzp@google.com>, "David S. Miller" <davem@davemloft.net>, Eric Dumazet <edumazet@google.com>, Jakub Kicinski <kuba@kernel.org>, Johan Hedberg <johan.hedberg@gmail.com>, Paolo Abeni <pabeni@redhat.com>, linux-kernel@vger.kernel.org, netdev@vger.kernel.org Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-9.6 required=5.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE,SPF_PASS,USER_IN_DEF_DKIM_WL autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1757849207544120602?= X-GMAIL-MSGID: =?utf-8?q?1757849207544120602?= |
Series |
[kernel,v1] Bluetooth: hci_sync: Resume adv with no RPA when active scan
|
|
Commit Message
Zhengping Jiang
Feb. 14, 2023, 10:56 p.m. UTC
The address resolution should be disabled during the active scan,
so all the advertisements can reach the host. The advertising
has to be paused before disabling the address resolution,
because the advertising will prevent any changes to the resolving
list and the address resolution status. Skipping this will cause
the hci error and the discovery failure.
If the host is using RPA, the controller needs to generate RPA for
the advertising, so the advertising must remain paused during the
active scan.
If the host is not using RPA, the advertising can be resumed after
disabling the address resolution.
Fixes: 9afc675edeeb ("Bluetooth: hci_sync: allow advertise when scan without RPA")
Signed-off-by: Zhengping Jiang <jiangzp@google.com>
---
Changes in v1:
- Always pause advertising when active scan, but resume the advertising if the host is not using RPA
net/bluetooth/hci_sync.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
Comments
Hi Zhengping, On Tue, Feb 14, 2023 at 2:56 PM Zhengping Jiang <jiangzp@google.com> wrote: > > The address resolution should be disabled during the active scan, > so all the advertisements can reach the host. The advertising > has to be paused before disabling the address resolution, > because the advertising will prevent any changes to the resolving > list and the address resolution status. Skipping this will cause > the hci error and the discovery failure. It is probably a good idea to quote the spec saying: 7.8.44 LE Set Address Resolution Enable command This command shall not be used when: • Advertising (other than periodic advertising) is enabled, > If the host is using RPA, the controller needs to generate RPA for > the advertising, so the advertising must remain paused during the > active scan. > > If the host is not using RPA, the advertising can be resumed after > disabling the address resolution. > > Fixes: 9afc675edeeb ("Bluetooth: hci_sync: allow advertise when scan without RPA") > Signed-off-by: Zhengping Jiang <jiangzp@google.com> > --- > > Changes in v1: > - Always pause advertising when active scan, but resume the advertising if the host is not using RPA > > net/bluetooth/hci_sync.c | 8 ++++++-- > 1 file changed, 6 insertions(+), 2 deletions(-) > > diff --git a/net/bluetooth/hci_sync.c b/net/bluetooth/hci_sync.c > index 117eedb6f709..edbf9faf7fa1 100644 > --- a/net/bluetooth/hci_sync.c > +++ b/net/bluetooth/hci_sync.c > @@ -2402,7 +2402,7 @@ static u8 hci_update_accept_list_sync(struct hci_dev *hdev) > u8 filter_policy; > int err; > > - /* Pause advertising if resolving list can be used as controllers are > + /* Pause advertising if resolving list can be used as controllers > * cannot accept resolving list modifications while advertising. > */ > if (use_ll_privacy(hdev)) { > @@ -5397,7 +5397,7 @@ static int hci_active_scan_sync(struct hci_dev *hdev, uint16_t interval) > /* Pause advertising since active scanning disables address resolution > * which advertising depend on in order to generate its RPAs. > */ > - if (use_ll_privacy(hdev) && hci_dev_test_flag(hdev, HCI_PRIVACY)) { > + if (use_ll_privacy(hdev)) { > err = hci_pause_advertising_sync(hdev); > if (err) { > bt_dev_err(hdev, "pause advertising failed: %d", err); > @@ -5416,6 +5416,10 @@ static int hci_active_scan_sync(struct hci_dev *hdev, uint16_t interval) > goto failed; > } > > + // Resume paused advertising if the host is not using RPA > + if (use_ll_privacy(hdev) && !hci_dev_test_flag(hdev, HCI_PRIVACY)) > + hci_resume_advertising_sync(hdev); > + > /* All active scans will be done with either a resolvable private > * address (when privacy feature has been enabled) or non-resolvable > * private address. > -- > 2.39.1.581.gbfd45094c4-goog I think it is better that we add something like hci_pause_addr_resolution so we can make it check all the conditions, such as pausing advertising and resuming if needed. Btw, we do seem to have proper checks for these conditions on the emulator: https://git.kernel.org/pub/scm/bluetooth/bluez.git/tree/emulator/btdev.c#n4090 But perhaps there is no test which attempts to enable LL Privacy without enabling Local Privacy, so it would be great if you could update mgmt-tester adding a test that emulates such behavior.
Hi Luiz, Thanks for the comment. I will submit a new patch to address that. I notice in the spec, it is mentioned > Note: This command does not affect the generation of Resolvable Private Addresses. How should I understand this note? Does it mean even if the address resolution is disabled, the controller can still generate RPA for advertising? Does it mean the advertising can always be resumed during active scan? Thanks, Zhengping On Tue, Feb 14, 2023 at 4:09 PM Luiz Augusto von Dentz <luiz.dentz@gmail.com> wrote: > > Hi Zhengping, > > On Tue, Feb 14, 2023 at 2:56 PM Zhengping Jiang <jiangzp@google.com> wrote: > > > > The address resolution should be disabled during the active scan, > > so all the advertisements can reach the host. The advertising > > has to be paused before disabling the address resolution, > > because the advertising will prevent any changes to the resolving > > list and the address resolution status. Skipping this will cause > > the hci error and the discovery failure. > > It is probably a good idea to quote the spec saying: > > 7.8.44 LE Set Address Resolution Enable command > > This command shall not be used when: > • Advertising (other than periodic advertising) is enabled, > > > If the host is using RPA, the controller needs to generate RPA for > > the advertising, so the advertising must remain paused during the > > active scan. > > > > If the host is not using RPA, the advertising can be resumed after > > disabling the address resolution. > > > > Fixes: 9afc675edeeb ("Bluetooth: hci_sync: allow advertise when scan without RPA") > > Signed-off-by: Zhengping Jiang <jiangzp@google.com> > > --- > > > > Changes in v1: > > - Always pause advertising when active scan, but resume the advertising if the host is not using RPA > > > > net/bluetooth/hci_sync.c | 8 ++++++-- > > 1 file changed, 6 insertions(+), 2 deletions(-) > > > > diff --git a/net/bluetooth/hci_sync.c b/net/bluetooth/hci_sync.c > > index 117eedb6f709..edbf9faf7fa1 100644 > > --- a/net/bluetooth/hci_sync.c > > +++ b/net/bluetooth/hci_sync.c > > @@ -2402,7 +2402,7 @@ static u8 hci_update_accept_list_sync(struct hci_dev *hdev) > > u8 filter_policy; > > int err; > > > > - /* Pause advertising if resolving list can be used as controllers are > > + /* Pause advertising if resolving list can be used as controllers > > * cannot accept resolving list modifications while advertising. > > */ > > if (use_ll_privacy(hdev)) { > > @@ -5397,7 +5397,7 @@ static int hci_active_scan_sync(struct hci_dev *hdev, uint16_t interval) > > /* Pause advertising since active scanning disables address resolution > > * which advertising depend on in order to generate its RPAs. > > */ > > - if (use_ll_privacy(hdev) && hci_dev_test_flag(hdev, HCI_PRIVACY)) { > > + if (use_ll_privacy(hdev)) { > > err = hci_pause_advertising_sync(hdev); > > if (err) { > > bt_dev_err(hdev, "pause advertising failed: %d", err); > > @@ -5416,6 +5416,10 @@ static int hci_active_scan_sync(struct hci_dev *hdev, uint16_t interval) > > goto failed; > > } > > > > + // Resume paused advertising if the host is not using RPA > > + if (use_ll_privacy(hdev) && !hci_dev_test_flag(hdev, HCI_PRIVACY)) > > + hci_resume_advertising_sync(hdev); > > + > > /* All active scans will be done with either a resolvable private > > * address (when privacy feature has been enabled) or non-resolvable > > * private address. > > -- > > 2.39.1.581.gbfd45094c4-goog > > I think it is better that we add something like > hci_pause_addr_resolution so we can make it check all the conditions, > such as pausing advertising and resuming if needed. Btw, we do seem to > have proper checks for these conditions on the emulator: > > https://git.kernel.org/pub/scm/bluetooth/bluez.git/tree/emulator/btdev.c#n4090 > > But perhaps there is no test which attempts to enable LL Privacy > without enabling Local Privacy, so it would be great if you could > update mgmt-tester adding a test that emulates such behavior. > > -- > Luiz Augusto von Dentz
Hi Zhengping, On Tue, Feb 14, 2023 at 4:28 PM Zhengping Jiang <jiangzp@google.com> wrote: > > Hi Luiz, > > Thanks for the comment. I will submit a new patch to address that. > > I notice in the spec, it is mentioned > > Note: This command does not affect the generation of Resolvable Private Addresses. Where is that mentioned? > How should I understand this note? Does it mean even if the address > resolution is disabled, the controller can still generate RPA for > advertising? Does it mean the advertising can always be resumed > during active scan? I think it may be related to the fact that it only affects the addr resolution of remote devices, that said if you are active scanning that probably means the user wants to setup a new device thus why we don't enable any filtering like accept list, etc, so it is not really useful to keep address resolution active either way. > Thanks, > Zhengping > > On Tue, Feb 14, 2023 at 4:09 PM Luiz Augusto von Dentz > <luiz.dentz@gmail.com> wrote: > > > > Hi Zhengping, > > > > On Tue, Feb 14, 2023 at 2:56 PM Zhengping Jiang <jiangzp@google.com> wrote: > > > > > > The address resolution should be disabled during the active scan, > > > so all the advertisements can reach the host. The advertising > > > has to be paused before disabling the address resolution, > > > because the advertising will prevent any changes to the resolving > > > list and the address resolution status. Skipping this will cause > > > the hci error and the discovery failure. > > > > It is probably a good idea to quote the spec saying: > > > > 7.8.44 LE Set Address Resolution Enable command > > > > This command shall not be used when: > > • Advertising (other than periodic advertising) is enabled, > > > > > If the host is using RPA, the controller needs to generate RPA for > > > the advertising, so the advertising must remain paused during the > > > active scan. > > > > > > If the host is not using RPA, the advertising can be resumed after > > > disabling the address resolution. > > > > > > Fixes: 9afc675edeeb ("Bluetooth: hci_sync: allow advertise when scan without RPA") > > > Signed-off-by: Zhengping Jiang <jiangzp@google.com> > > > --- > > > > > > Changes in v1: > > > - Always pause advertising when active scan, but resume the advertising if the host is not using RPA > > > > > > net/bluetooth/hci_sync.c | 8 ++++++-- > > > 1 file changed, 6 insertions(+), 2 deletions(-) > > > > > > diff --git a/net/bluetooth/hci_sync.c b/net/bluetooth/hci_sync.c > > > index 117eedb6f709..edbf9faf7fa1 100644 > > > --- a/net/bluetooth/hci_sync.c > > > +++ b/net/bluetooth/hci_sync.c > > > @@ -2402,7 +2402,7 @@ static u8 hci_update_accept_list_sync(struct hci_dev *hdev) > > > u8 filter_policy; > > > int err; > > > > > > - /* Pause advertising if resolving list can be used as controllers are > > > + /* Pause advertising if resolving list can be used as controllers > > > * cannot accept resolving list modifications while advertising. > > > */ > > > if (use_ll_privacy(hdev)) { > > > @@ -5397,7 +5397,7 @@ static int hci_active_scan_sync(struct hci_dev *hdev, uint16_t interval) > > > /* Pause advertising since active scanning disables address resolution > > > * which advertising depend on in order to generate its RPAs. > > > */ > > > - if (use_ll_privacy(hdev) && hci_dev_test_flag(hdev, HCI_PRIVACY)) { > > > + if (use_ll_privacy(hdev)) { > > > err = hci_pause_advertising_sync(hdev); > > > if (err) { > > > bt_dev_err(hdev, "pause advertising failed: %d", err); > > > @@ -5416,6 +5416,10 @@ static int hci_active_scan_sync(struct hci_dev *hdev, uint16_t interval) > > > goto failed; > > > } > > > > > > + // Resume paused advertising if the host is not using RPA > > > + if (use_ll_privacy(hdev) && !hci_dev_test_flag(hdev, HCI_PRIVACY)) > > > + hci_resume_advertising_sync(hdev); > > > + > > > /* All active scans will be done with either a resolvable private > > > * address (when privacy feature has been enabled) or non-resolvable > > > * private address. > > > -- > > > 2.39.1.581.gbfd45094c4-goog > > > > I think it is better that we add something like > > hci_pause_addr_resolution so we can make it check all the conditions, > > such as pausing advertising and resuming if needed. Btw, we do seem to > > have proper checks for these conditions on the emulator: > > > > https://git.kernel.org/pub/scm/bluetooth/bluez.git/tree/emulator/btdev.c#n4090 > > > > But perhaps there is no test which attempts to enable LL Privacy > > without enabling Local Privacy, so it would be great if you could > > update mgmt-tester adding a test that emulates such behavior. > > > > -- > > Luiz Augusto von Dentz
Hi Luiz, > Where is that mentioned? It is just below the command on "7.8.44 LE Set Address Resolution Enable command". On "4.7 RESOLVING LIST", there is another note: > Note: The Controller may generate Resolvable Private Addresses even when address resolution is disabled. If this is the case, then the comment in the kernel (hci_active_scan_sync) is not accurate. > /* Pause advertising since active scanning disables address resolution > * which advertising depend on in order to generate its RPAs. > */ > I think it may be related to the fact that it only affects the addr > resolution of remote devices, that said if you are active scanning > that probably means the user wants to setup a new device thus why we > don't enable any filtering like accept list, etc, so it is not really > useful to keep address resolution active either way. That makes sense. When the local privacy is enabled, I assume the host RPA will change when advertising. I haven't tested that scenario, but if RPA generation is not related to disable/enable address resolution, why should the advertising be paused when active scan? Thanks, Zhengping > > > Thanks, > > Zhengping > > > > On Tue, Feb 14, 2023 at 4:09 PM Luiz Augusto von Dentz > > <luiz.dentz@gmail.com> wrote: > > > > > > Hi Zhengping, > > > > > > On Tue, Feb 14, 2023 at 2:56 PM Zhengping Jiang <jiangzp@google.com> wrote: > > > > > > > > The address resolution should be disabled during the active scan, > > > > so all the advertisements can reach the host. The advertising > > > > has to be paused before disabling the address resolution, > > > > because the advertising will prevent any changes to the resolving > > > > list and the address resolution status. Skipping this will cause > > > > the hci error and the discovery failure. > > > > > > It is probably a good idea to quote the spec saying: > > > > > > 7.8.44 LE Set Address Resolution Enable command > > > > > > This command shall not be used when: > > > • Advertising (other than periodic advertising) is enabled, > > > > > > > If the host is using RPA, the controller needs to generate RPA for > > > > the advertising, so the advertising must remain paused during the > > > > active scan. > > > > > > > > If the host is not using RPA, the advertising can be resumed after > > > > disabling the address resolution. > > > > > > > > Fixes: 9afc675edeeb ("Bluetooth: hci_sync: allow advertise when scan without RPA") > > > > Signed-off-by: Zhengping Jiang <jiangzp@google.com> > > > > --- > > > > > > > > Changes in v1: > > > > - Always pause advertising when active scan, but resume the advertising if the host is not using RPA > > > > > > > > net/bluetooth/hci_sync.c | 8 ++++++-- > > > > 1 file changed, 6 insertions(+), 2 deletions(-) > > > > > > > > diff --git a/net/bluetooth/hci_sync.c b/net/bluetooth/hci_sync.c > > > > index 117eedb6f709..edbf9faf7fa1 100644 > > > > --- a/net/bluetooth/hci_sync.c > > > > +++ b/net/bluetooth/hci_sync.c > > > > @@ -2402,7 +2402,7 @@ static u8 hci_update_accept_list_sync(struct hci_dev *hdev) > > > > u8 filter_policy; > > > > int err; > > > > > > > > - /* Pause advertising if resolving list can be used as controllers are > > > > + /* Pause advertising if resolving list can be used as controllers > > > > * cannot accept resolving list modifications while advertising. > > > > */ > > > > if (use_ll_privacy(hdev)) { > > > > @@ -5397,7 +5397,7 @@ static int hci_active_scan_sync(struct hci_dev *hdev, uint16_t interval) > > > > /* Pause advertising since active scanning disables address resolution > > > > * which advertising depend on in order to generate its RPAs. > > > > */ > > > > - if (use_ll_privacy(hdev) && hci_dev_test_flag(hdev, HCI_PRIVACY)) { > > > > + if (use_ll_privacy(hdev)) { > > > > err = hci_pause_advertising_sync(hdev); > > > > if (err) { > > > > bt_dev_err(hdev, "pause advertising failed: %d", err); > > > > @@ -5416,6 +5416,10 @@ static int hci_active_scan_sync(struct hci_dev *hdev, uint16_t interval) > > > > goto failed; > > > > } > > > > > > > > + // Resume paused advertising if the host is not using RPA > > > > + if (use_ll_privacy(hdev) && !hci_dev_test_flag(hdev, HCI_PRIVACY)) > > > > + hci_resume_advertising_sync(hdev); > > > > + > > > > /* All active scans will be done with either a resolvable private > > > > * address (when privacy feature has been enabled) or non-resolvable > > > > * private address. > > > > -- > > > > 2.39.1.581.gbfd45094c4-goog > > > > > > I think it is better that we add something like > > > hci_pause_addr_resolution so we can make it check all the conditions, > > > such as pausing advertising and resuming if needed. Btw, we do seem to > > > have proper checks for these conditions on the emulator: > > > > > > https://git.kernel.org/pub/scm/bluetooth/bluez.git/tree/emulator/btdev.c#n4090 > > > > > > But perhaps there is no test which attempts to enable LL Privacy > > > without enabling Local Privacy, so it would be great if you could > > > update mgmt-tester adding a test that emulates such behavior. > > > > > > -- > > > Luiz Augusto von Dentz > > > > -- > Luiz Augusto von Dentz
Hi Zhengping, On Tue, Feb 14, 2023 at 5:20 PM Zhengping Jiang <jiangzp@google.com> wrote: > > Hi Luiz, > > > Where is that mentioned? > It is just below the command on "7.8.44 LE Set Address Resolution > Enable command". > > On "4.7 RESOLVING LIST", there is another note: > > Note: The Controller may generate Resolvable Private Addresses even when address resolution is disabled. Note that the term used here is 'may' not 'shall' so I don't think we can take for granted that the controller will keep generating a new RPA while address resolution is disabled, in fact I think this is sort of a bad idea since as part of the resolving list is the actual IRK and the procedures to update those entries requires address resolution to be stopped, in fact I think the spec is sort of responsible for creating this confusion when it mixed up remote IRK with local IRK in the same list. > If this is the case, then the comment in the kernel > (hci_active_scan_sync) is not accurate. > > /* Pause advertising since active scanning disables address resolution > > * which advertising depend on in order to generate its RPAs. > > */ > > > I think it may be related to the fact that it only affects the addr > > resolution of remote devices, that said if you are active scanning > > that probably means the user wants to setup a new device thus why we > > don't enable any filtering like accept list, etc, so it is not really > > useful to keep address resolution active either way. > That makes sense. When the local privacy is enabled, I assume the host > RPA will change > when advertising. I haven't tested that scenario, but if RPA > generation is not related to disable/enable > address resolution, why should the advertising be paused when active scan? Initially it was because we wanted to disable address resolution which requires both scan and advertising to be disabled to begin with, then there is the fact that there is no fine control over how the controller would priority the scanning and advertising states, and there is also the situation where a incoming connection may come in when advertising is enabled then we have a connection competing with scanning which creates even more problems, not to mention not all controllers do support scanning and advertising simultaneously. > Thanks, > Zhengping > > > > > > Thanks, > > > Zhengping > > > > > > On Tue, Feb 14, 2023 at 4:09 PM Luiz Augusto von Dentz > > > <luiz.dentz@gmail.com> wrote: > > > > > > > > Hi Zhengping, > > > > > > > > On Tue, Feb 14, 2023 at 2:56 PM Zhengping Jiang <jiangzp@google.com> wrote: > > > > > > > > > > The address resolution should be disabled during the active scan, > > > > > so all the advertisements can reach the host. The advertising > > > > > has to be paused before disabling the address resolution, > > > > > because the advertising will prevent any changes to the resolving > > > > > list and the address resolution status. Skipping this will cause > > > > > the hci error and the discovery failure. > > > > > > > > It is probably a good idea to quote the spec saying: > > > > > > > > 7.8.44 LE Set Address Resolution Enable command > > > > > > > > This command shall not be used when: > > > > • Advertising (other than periodic advertising) is enabled, > > > > > > > > > If the host is using RPA, the controller needs to generate RPA for > > > > > the advertising, so the advertising must remain paused during the > > > > > active scan. > > > > > > > > > > If the host is not using RPA, the advertising can be resumed after > > > > > disabling the address resolution. > > > > > > > > > > Fixes: 9afc675edeeb ("Bluetooth: hci_sync: allow advertise when scan without RPA") > > > > > Signed-off-by: Zhengping Jiang <jiangzp@google.com> > > > > > --- > > > > > > > > > > Changes in v1: > > > > > - Always pause advertising when active scan, but resume the advertising if the host is not using RPA > > > > > > > > > > net/bluetooth/hci_sync.c | 8 ++++++-- > > > > > 1 file changed, 6 insertions(+), 2 deletions(-) > > > > > > > > > > diff --git a/net/bluetooth/hci_sync.c b/net/bluetooth/hci_sync.c > > > > > index 117eedb6f709..edbf9faf7fa1 100644 > > > > > --- a/net/bluetooth/hci_sync.c > > > > > +++ b/net/bluetooth/hci_sync.c > > > > > @@ -2402,7 +2402,7 @@ static u8 hci_update_accept_list_sync(struct hci_dev *hdev) > > > > > u8 filter_policy; > > > > > int err; > > > > > > > > > > - /* Pause advertising if resolving list can be used as controllers are > > > > > + /* Pause advertising if resolving list can be used as controllers > > > > > * cannot accept resolving list modifications while advertising. > > > > > */ > > > > > if (use_ll_privacy(hdev)) { > > > > > @@ -5397,7 +5397,7 @@ static int hci_active_scan_sync(struct hci_dev *hdev, uint16_t interval) > > > > > /* Pause advertising since active scanning disables address resolution > > > > > * which advertising depend on in order to generate its RPAs. > > > > > */ > > > > > - if (use_ll_privacy(hdev) && hci_dev_test_flag(hdev, HCI_PRIVACY)) { > > > > > + if (use_ll_privacy(hdev)) { > > > > > err = hci_pause_advertising_sync(hdev); > > > > > if (err) { > > > > > bt_dev_err(hdev, "pause advertising failed: %d", err); > > > > > @@ -5416,6 +5416,10 @@ static int hci_active_scan_sync(struct hci_dev *hdev, uint16_t interval) > > > > > goto failed; > > > > > } > > > > > > > > > > + // Resume paused advertising if the host is not using RPA > > > > > + if (use_ll_privacy(hdev) && !hci_dev_test_flag(hdev, HCI_PRIVACY)) > > > > > + hci_resume_advertising_sync(hdev); > > > > > + > > > > > /* All active scans will be done with either a resolvable private > > > > > * address (when privacy feature has been enabled) or non-resolvable > > > > > * private address. > > > > > -- > > > > > 2.39.1.581.gbfd45094c4-goog > > > > > > > > I think it is better that we add something like > > > > hci_pause_addr_resolution so we can make it check all the conditions, > > > > such as pausing advertising and resuming if needed. Btw, we do seem to > > > > have proper checks for these conditions on the emulator: > > > > > > > > https://git.kernel.org/pub/scm/bluetooth/bluez.git/tree/emulator/btdev.c#n4090 > > > > > > > > But perhaps there is no test which attempts to enable LL Privacy > > > > without enabling Local Privacy, so it would be great if you could > > > > update mgmt-tester adding a test that emulates such behavior. > > > > > > > > -- > > > > Luiz Augusto von Dentz > > > > > > > > -- > > Luiz Augusto von Dentz
diff --git a/net/bluetooth/hci_sync.c b/net/bluetooth/hci_sync.c index 117eedb6f709..edbf9faf7fa1 100644 --- a/net/bluetooth/hci_sync.c +++ b/net/bluetooth/hci_sync.c @@ -2402,7 +2402,7 @@ static u8 hci_update_accept_list_sync(struct hci_dev *hdev) u8 filter_policy; int err; - /* Pause advertising if resolving list can be used as controllers are + /* Pause advertising if resolving list can be used as controllers * cannot accept resolving list modifications while advertising. */ if (use_ll_privacy(hdev)) { @@ -5397,7 +5397,7 @@ static int hci_active_scan_sync(struct hci_dev *hdev, uint16_t interval) /* Pause advertising since active scanning disables address resolution * which advertising depend on in order to generate its RPAs. */ - if (use_ll_privacy(hdev) && hci_dev_test_flag(hdev, HCI_PRIVACY)) { + if (use_ll_privacy(hdev)) { err = hci_pause_advertising_sync(hdev); if (err) { bt_dev_err(hdev, "pause advertising failed: %d", err); @@ -5416,6 +5416,10 @@ static int hci_active_scan_sync(struct hci_dev *hdev, uint16_t interval) goto failed; } + // Resume paused advertising if the host is not using RPA + if (use_ll_privacy(hdev) && !hci_dev_test_flag(hdev, HCI_PRIVACY)) + hci_resume_advertising_sync(hdev); + /* All active scans will be done with either a resolvable private * address (when privacy feature has been enabled) or non-resolvable * private address.