)]}'
{
  "commit": "56ed6b127a27c418dc2daa3fd076539d8fe69c4c",
  "tree": "3e85245256db11c4ca667e9b7177f4bfd8d60cd1",
  "parents": [
    "737139f4157d302292a6b937d96922879ecabfa3"
  ],
  "author": {
    "name": "Valentin Kindschi",
    "email": "valentin.kindschi@fiveco.ch",
    "time": "Tue Oct 20 12:51:50 2026 +0200"
  },
  "committer": {
    "name": "Luiz Augusto von Dentz",
    "email": "luiz.von.dentz@intel.com",
    "time": "Mon Nov 02 17:09:01 2026 -0500"
  },
  "message": "Bluetooth: hci_sync: pause advertising for the scan address update\n\nhci_active_scan_sync() programs a non-resolvable private address with LE\nSet Random Address on every active scan start.\n\nBLUETOOTH CORE SPECIFICATION Vol 4, Part E, 7.8.4 says the controller\nshall return Command Disallowed (0x0C) for that command while legacy\nadvertising or scanning is enabled. hci_pause_addr_resolution(), called\njust above, only stops advertising when LL privacy is in use, so on a\ncontroller without it the command is issued while advertising is still\non:\n\n  Bluetooth: hci0: Opcode 0x2005 failed: -16\n\nIt does not converge either. hdev-\u003erandom_addr is only set on a\nsuccessful command complete, so it stays BDADDR_ANY, and the deferral\nadded by commit c2994b008492 (\"Bluetooth: hci_sync: Fix not setting\nRandom Address when required\") requires it to be set. Unlike the\nresolvable address a few lines above, which is reused while rpa_valid(),\nthe non-resolvable one is regenerated and rewritten on every call, so a\ncontroller that refuses the write is asked again at the scan restart\nperiod of about 10 s, for as long as discovery keeps restarting.\nObserved on a BCM43455, which has no LL privacy and no extended\nadvertising, 190 rejections in one capture, every one retrying the same\naddress:\n\n  \u003c LE Set Random Address  Address: 02:16:91:90:F1:D4 (Non-Resolvable)\n  \u003e Command Complete       LE Set Random Address, Command Disallowed\n  \u003c LE Set Random Address  Address: 26:90:57:96:9A:3E (Non-Resolvable)\n  \u003e Command Complete       LE Set Random Address, Command Disallowed\n\nPause advertising for the address update, and resume it once the update\nis done and before the scan is started. The pause does not outlive the\nfunction: it is taken only when nothing else holds it, and every exit\nresumes advertising, which also releases the pause taken by\nhci_pause_addr_resolution(). A failed pause returns before marking\nanything paused, so the error path is a no-op.\n\nThe resume in the error path is no longer guarded by ll_privacy_capable().\nThat guard matched a pause taken only under LL privacy; the pause added\nhere is unconditional, and hci_resume_advertising_sync() returns early\nwhen nothing was paused.\n\nOne caveat this widens, raised on the previous posting. When\nHCI_ADVERTISING is set, hci_pause_advertising_sync() also clears\nHCI_DISCOVERABLE and HCI_LIMITED_DISCOVERABLE and zeroes discov_timeout,\nand hci_resume_advertising_sync() restores only HCI_ADVERTISING, so the\ndiscoverable state is lost. It reproduces today on an LL privacy\ncontroller through hci_pause_addr_resolution(); the unconditional pause\nmakes it reachable without LL privacy as well. hci_suspend_sync() also\npauses unconditionally, so a device that suspends loses the same state\non any controller today. That asymmetry is pre-existing and is left\nalone here rather than folded into a scan path fix.\n\nLegacy controllers have one random address register, shared by the\nscanner and the advertiser. Restoring the advertiser here can reprogram\nit when the advertiser is non-connectable, so the scan then uses that\naddress rather than the one generated for it. Both are non-resolvable\nand neither is linkable to the identity address. With privacy enabled\nboth roles already share one resolvable address the same way.\n\nWith the patch, on the same hardware:\n\n  \u003c LE Set Advertising Enable    Enable: 0x00              Success\n  \u003c LE Set Random Address                                  Success\n  \u003c LE Set Advertising Parameters                          Success\n  \u003c LE Set Advertising Enable    Enable: 0x01              Success\n  \u003c LE Set Scan Parameters                                 Success\n  \u003c LE Set Scan Enable           Enable: 0x01              Success\n\nThe address write is accepted, and advertising is restored before the\nscan is started.\n\nOver 119369 btmon records and about 12 minutes of the normal workload of\nthat device, alternating active and passive scanning with ten outgoing\nconnection attempts, every LE Set Random Address succeeded and there were\nno Command Disallowed responses of any opcode, against one per scan\nrestart before.\n\nPatch 1 is required: without it the resume added here returns -EPERM on\nthe controllers this fixes and leaves advertising disabled.\n\nFixes: 3c44a431d62b (\"Bluetooth: hci_sync: Resume adv with no RPA when active scan\")\nCc: stable@vger.kernel.org\nAssisted-by: Claude:claude-opus-5.5 btmon\nSigned-off-by: Valentin Kindschi \u003cvalentin.kindschi@fiveco.ch\u003e\nSigned-off-by: Luiz Augusto von Dentz \u003cluiz.von.dentz@intel.com\u003e\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "c2f2a0c0e73d9d51e3796bbdcfbc90404dec7355",
      "old_mode": 33188,
      "old_path": "net/bluetooth/hci_sync.c",
      "new_id": "c9e80b957455186f40b1cfedd87184384bb49388",
      "new_mode": 33188,
      "new_path": "net/bluetooth/hci_sync.c"
    }
  ]
}
