When I connected my WH-1000XM3 for a webex meeting, it was no longer
working (and the internal microphone of my laptop wasn't working
either). The journalctl logs show:
Oct 19 16:56:11 qaa bluetoothd[1292]: profiles/audio/a2dp.c:load_remote_sep() Unable to load LastUsed: rseid 1 not found
Oct 19 16:56:12 qaa kernel: input: WH-1000XM3 (AVRCP) as /devices/virtual/input/input35
Oct 19 16:56:12 qaa systemd-logind[1310]: Watching system buttons on /dev/input/event24 (WH-1000XM3 (AVRCP))
Oct 19 16:56:29 qaa wireplumber[2492]: pw.node: (bluez_input.38_18_4C_4B_AC_93.0-77) running -> error (Received error event)
Oct 19 16:56:29 qaa wireplumber[2492]: pw.node: (bluez_output.38_18_4C_4B_AC_93.1-79) running -> error (Received error event)
Oct 19 16:56:29 qaa wireplumber[2492]: spa.bluez5: Failure in Bluetooth audio transport /org/bluez/hci0/dev_38_18_4C_4B_AC_93/fd64
Oct 19 16:56:29 qaa pipewire[2488]: pw.node: (bluez_input.38_18_4C_4B_AC_93.0-77) running -> error (Received error event)
Oct 19 16:56:29 qaa pipewire[2488]: pw.node: (bluez_output.38_18_4C_4B_AC_93.1-79) running -> error (Received error event)
Oct 19 16:56:29 qaa bluetoothd[1292]: /org/bluez/hci0/dev_38_18_4C_4B_AC_93/sep1/fd1: fd(34) ready
Oct 19 16:57:25 qaa kernel: Bluetooth: hci0: SCO packet for unknown connection handle 513
Oct 19 16:57:25 qaa kernel: kauditd_printk_skb: 54 callbacks suppressed
Oct 19 16:57:25 qaa kernel: audit: type=1400 audit(1792421845.592:568): apparmor="DENIED" operation="userns_create" class="namespace" profile="firejail-default" pid=256541 comm="firefox" requested="userns_create" denied="userns_create"
Oct 19 16:58:54 qaa wireplumber[2492]: pw.node: (bluez_output.38_18_4C_4B_AC_93.1-79) running -> error (Received error event)
Oct 19 16:58:54 qaa wireplumber[2492]: spa.bluez5: Failure in Bluetooth audio transport /org/bluez/hci0/dev_38_18_4C_4B_AC_93/sep1/fd1
Oct 19 16:58:54 qaa pipewire[2488]: pw.node: (bluez_output.38_18_4C_4B_AC_93.1-79) running -> error (Received error event)
Oct 19 16:58:55 qaa wireplumber[2492]: pw.node: (bluez_input.38_18_4C_4B_AC_93.0-94) suspended -> error (Received error event)
Oct 19 16:58:55 qaa wireplumber[2492]: pw.node: (bluez_output.38_18_4C_4B_AC_93.1-88) running -> error (Received error event)
Oct 19 16:58:55 qaa pipewire[2488]: pw.node: (bluez_input.38_18_4C_4B_AC_93.0-94) running -> error (Received error event)
Oct 19 16:58:55 qaa pipewire[2488]: pw.node: (bluez_output.38_18_4C_4B_AC_93.1-88) running -> error (Received error event)
Oct 19 16:58:55 qaa pipewire-pulse[2494]: mod.client-node: port (nil): set_param 4 0x563085381f80: Invalid argument
Oct 19 16:58:55 qaa pipewire[2488]: pw.core: 0x5594da794d40: error -22 for resource 74: port_set_param(Spa:Enum:ParamId:Format) failed: Invalid argument
Oct 19 16:58:55 qaa pipewire[2488]: mod.client-node: 0x5594dd02b340: error seq:10992 -22 (port_set_param(Spa:Enum:ParamId:Format) failed: Invalid argument)
Oct 19 16:58:55 qaa pipewire[2488]: pw.link: 0x5594dd039ae0: one of the nodes is in error out:suspended in:error
[...]
There was no such issue 2 weeks ago with bluez 5.87-4 (but perhaps
there's some randomness in the issue).
According to Mistral, this is an upstream bug, which is now fixed:
This looks like the known BlueZ 5.87 regression, not a config problem on your side.
## What's happening
- BlueZ 5.87 shipped commit `912f5efb0dd9` ("a2dp: Fix handling of codec capability storage"), which broke the loop that parses cached remote SEP capabilities: `i` starts at 0 but the loop requires `i >= 2`, so the body never runs and every cached endpoint is discarded — producing exactly your `load_remote_sep() Unable to load LastUsed: rseid 1 not found` message ([patch discussion](https://ratatoskr.run/linux-bluetooth/2026/07/17240553/t)).
- With no cached remote SEPs, AVDTP discovery on every reconnect races with the headset's own Set Configuration, so the stream never gets properly established, and PipeWire/WirePlumber's transport open fails — the `Failure in Bluetooth audio transport ... /sep1/fd1` and node `running -> error` lines you see. The same pattern is reported for Sony WH-1000XM5 and other A2DP devices on bluez 5.87-2 ([bluez#2575](https://github.com/bluez/bluez/issues/2575), [bluez#2321](https://github.com/bluez/bluez/issues/2321), [bluez#2553](https://github.com/bluez/bluez/issues/2553)).
- The `Unable to load LastUsed` line even appears on connections that work, so it's easy to dismiss — but it's the root-cause marker ([bluez#2321](https://github.com/bluez/bluez/issues/2321)).
The fix is upstream commit `b7d71e5` ("a2dp: Fix loading of remote SEP from cache"), merged on 2026-07-10 into BlueZ master ([fix commit](https://github.com/bluez/bluez/issues/2575)) — i.e. it should land in BlueZ 5.88.
[workaround snipped...]
The `SCO packet for unknown connection handle 513` kernel line is a side effect of the failed HFP/eSCO session teardown, and the firejail/firefox AppArmor denial is unrelated noise.
"Configuration"), pavucontrol switched the view to "Configuration". Switching the headset off and on did not solve the issue with webex (no issues with VLC, though).
Some of the obtained errors for the webex meeting actually seem to be harmless, as shown by microphone tests I've done with https://mozilla.github.io/webrtc-landing/gum_test.html (internal microphone, with audio back to my headset, so the same settings as yesterday). The journalctl logs show: Oct 20 10:45:19 qaa bluetoothd[1292]: profiles/audio/a2dp.c:load_remote_sep() Unable to load LastUsed: rseid 1 not found Oct 20 10:45:20 qaa kernel: Bluetooth: hci0: SCO packet for unknown connection handle 513 Oct 20 10:45:20 qaa kernel: input: WH-1000XM3 (AVRCP) as /devices/virtual/input/input42 Oct 20 10:45:20 qaa systemd-logind[1310]: Watching system buttons on /dev/input/event24 (WH-1000XM3 (AVRCP)) Oct 20 10:45:30 qaa wireplumber[2492]: pw.node: (bluez_input.38_18_4C_4B_AC_93.0-148) running -> error (Received error event) Oct 20 10:45:30 qaa wireplumber[2492]: pw.node: (bluez_output.38_18_4C_4B_AC_93.1-146) running -> error (Received error event) Oct 20 10:45:30 qaa wireplumber[2492]: spa.bluez5: Failure in Bluetooth audio transport /org/bluez/hci0/dev_38_18_4C_4B_AC_93/fd64 Oct 20 10:45:30 qaa pipewire[2488]: pw.node: (bluez_input.38_18_4C_4B_AC_93.0-148) running -> error (Received error event) Oct 20 10:45:30 qaa pipewire[2488]: pw.node: (bluez_output.38_18_4C_4B_AC_93.1-146) running -> error (Received error event) Oct 20 10:45:30 qaa bluetoothd[1292]: /org/bluez/hci0/dev_38_18_4C_4B_AC_93/sep1/fd1: fd(34) ready but here, everything is working correctly. Such errors are annoying because this means that it is impossible to know what could be the cause of issues like I had yesterday. Now, it is less clear that this is a bug in bluez rather than in pipewire (or wireplumber). It seems that the AI answer was focusing on the first error (which is what one should usually do), i.e. the "load_remote_sep() Unable to load LastUsed: rseid 1 not found" line above from bluez, but it actually seems to be harmless.
There is a lot of AI-generated text to read and this email seems to contradict the other emails. Could you summarize whether there is still anything that needs to be fixed in bluez? I also get a bit concerned about AI bugs because sometimes, the AI gives people suggestions on things to change in their system and it's unclear whether there are any AI-suggested changes that could cause additional bugs. Is this bug reproducible from a new Debian Testing (or Unstable) install? Thank you, Jeremy Bícha
The issue came from the fact that the AI chatbot did not have all
the context. To clarify:
* I intended to use the microphone of my laptop (as usual),
not the one of the headset.
* I was using webex from the web browser (not Cisco's webex
application).
* The default codec for the headset is MSBC (as shown by
pavucontrol), and with Mozilla's gum_test (microphone test),
pavucontrol shows that the codec is changed to SBC.
AI says that "mSBC is an HFP-only codec", so that WirePlumber
switches to A2DP/SBC when actual media playback starts. Indeed,
this is what I can see in pavucontrol.
AI also says that the log shows that during the Webex meeting,
WirePlumber was switching my headset into HFP, even though I
intended to use the laptop mic. I don't know why WirePlumber
did that, but this was apparently the cause of the failure,
due to some bugs (see below). AI says:
The "SCO packet for unknown connection handle 513" kernel errors
are the signature of a failed HFP SCO/eSCO audio connection —
the controller-level voice link that carries HFP audio never
established properly.
and
So the Oct 19 sequence was: Webex starts → stream with Communication
role → WirePlumber flips the XM3 to HFP → the SCO/mSBC voice link
fails on your adapter (the kernel errors) → nodes error out →
WirePlumber may flip back, Webex retriggers, flip-flop — the
repeated transport failures and the multiple node IDs (.1-79, .1-88,
.0-94) are successive profile switches, not a broken A2DP stream.
Then I asked about the mSBC/SCO failure. AI replied
The mSBC/SCO failure is actually a known, currently-active bug
cluster, and with a WH-1000XM3 + BlueZ 5.87 you're right in the
middle of it. Two distinct upstream defects match your logs:
1. BlueZ 5.87 + Sony headsets: the second profile switch breaks
[...]
2. PipeWire native HFP backend: AT+BCC during eSCO setup kills the transport
[...]
I don't know whether the analysis is correct, but at least there
are known bugs that need to be fixed (to entirely fix my problem,
or at least make things clearer).
Full conversation:
https://chat.mistral.ai/work/0c966ccb-1dd5-49c7-97b1-9a2460eeb235
https://github.com/bluez/bluez/issues/2575
A2DP: a2dp_resume() "SEP in bad state for resume" → Acquire
NotAuthorized after A2DP↔HFP profile switching, until reconnect
(Sony WH-1000XM5, 5.87)
Note: I have the WH-1000XM3, but there shouldn't be much difference.
This bug is still open, but AI says that it is partially mitigated by
https://github.com/bluez/bluez/commit/b7d71e5067856b0daf2f1f73b3fc95483236610e
(which will be in bluez ≥ 5.88).
About the second bug,
https://github.com/bluez/bluez/issues/2545
is mentioned, but the user "solved" it by removing the mSBC from
the codec list. But it is apparently a workaround for a kernel bug.
On the Pipewire side (second bug):
https://gitlab.freedesktop.org/pipewire/pipewire/-/work_items/5506
I do not want to do any change of my config (except for things
that clearly need to be changed for my own use, as I had to do
last year due to a change of behavior in WirePlumber). I was
more asking for information about known bugs.
no issues with the same webex meeting two weeks ago, while I
have not changed anything in my config. Yesterday, disconnecting
and reconnecting to the meeting did not solve the issue.
Compared to 2 weeks ago:
* bluez got upgraded from 5.87-4 to 5.87-5
* firefox got upgraded from 157.0-1 to 158.0-1
(no pipewire / wireplumber upgrades).
I think that a lot of bluetooth functionality is handled by the kernel, not bluez. To verify if this is a regression, you'll need to install older versions of the packages and reboot and see if the problem goes away. Thank you, Jeremy Bícha
For the meetings, I've been using the same old 6.7.12-amd64 kernel (which is the latest one that works correctly with Dell's dock) for months, and yesterday was the first time I had an issue. This is a bit difficult without a test webpage from which I could reproduce the issue (no issues with the ones I tried).