Re: [Bug 220564] hci0: ACL packet for unknown connection handle 3837 and sound interruption

["Chris Lu (陸稚泓)" <Chris.Lu@mediatek.com>]

Hi Paul,

Thank you for pointing that out.

On Wed, 2026-07-01 at 18:32 +0200, Paul Menzel wrote:
> 
> External email : Please do not click links or open attachments until
> you have verified the sender or the content.
> 
> 
> Dear Sean, dear Chris, dear Mark,
> 
> 
> Unfortunately, you do not have an account in the Linux Kernel
> Bugzilla,
> so I am replying to this notification.
> 
> Am 01.07.26 um 17:09 schrieb bugzilla-daemon@kernel.org:
> > https://urldefense.com/v3/__https://bugzilla.kernel.org/show_bug.cgi?id=220564__;!!CTRNKA9wMg0ARbw!lP0PNdDR4CSngVJTB_m7P0TD0fp2aNst4ZfqjZDvuCE19YkcpmDERWSYSQa1jr64CwTeCcrgd2p4BOvQwBX4gg$
> > 
> > --- Comment #13 from Rob Hogan (robhogan@gmail.com) ---
> > I'm pretty sure it's the same issue. Extract from syslog below:
> > 
> > Jul  1 16:01:49 mwenge kernel: [439779.598878] Bluetooth: hci0: ACL
> > packet for unknown connection handle 3837
> > Jul  1 16:02:08 mwenge bluetoothd[760091]:
> > src/adapter.c:dev_disconnected() Device F0:EF:86:C3:50:D8
> > disconnected, reason 1
> > Jul  1 16:02:08 mwenge bluetoothd[760091]:
> > src/adapter.c:adapter_remove_connection()
> > Jul  1 16:02:08 mwenge bluetoothd[760091]:
> > plugins/policy.c:disconnect_cb() reason 1
> > Jul  1 16:02:08 mwenge bluetoothd[760091]:
> > plugins/policy.c:disconnect_cb() Device
> > /org/bluez/hci0/dev_F0_EF_86_C3_50_D8 identified for auto-
> > reconnection
> > Jul  1 16:02:08 mwenge bluetoothd[760091]:
> > plugins/policy.c:reconnect_set_timer() attempt 1/7 1 seconds
> > Jul  1 16:02:08 mwenge bluetoothd[760091]:
> > src/adapter.c:bonding_attempt_complete() hci0 bdaddr
> > F0:EF:86:C3:50:D8 type 0 status 0xe
> > Jul  1 16:02:08 mwenge bluetoothd[760091]:
> > src/device.c:device_bonding_complete() bonding (nil) status 0x0e
> > Jul  1 16:02:08 mwenge bluetoothd[760091]:
> > src/device.c:device_bonding_failed() status 14
> > Jul  1 16:02:08 mwenge bluetoothd[760091]:
> > src/adapter.c:resume_discovery()
> > Jul  1 16:02:08 mwenge bluetoothd[760091]:
> > profiles/audio/avdtp.c:session_cb()
> > Jul  1 16:02:08 mwenge bluetoothd[760091]:
> > profiles/audio/avdtp.c:avdtp_ref() 0x5c5568690930: ref=3
> > Jul  1 16:02:08 mwenge bluetoothd[760091]:
> > profiles/audio/avdtp.c:connection_lost() Disconnected from
> > F0:EF:86:C3:50:D8
> > Jul  1 16:02:08 mwenge bluetoothd[760091]:
> > profiles/audio/a2dp.c:abort_cfm() Source 0x5c5568671120: Abort_Cfm
> > Jul  1 16:02:08 mwenge bluetoothd[760091]:
> > profiles/audio/avdtp.c:avdtp_sep_set_state() stream state changed:
> > STREAMING -> IDLE
> > Jul  1 16:02:08 mwenge bluetoothd[760091]:
> > profiles/audio/transport.c:media_transport_remove_owner() Transport
> > /org/bluez/hci0/dev_F0_EF_86_C3_50_D8/sep1/fd3 Owner :1.79
> > 
> > 
> > And here is the relevant handle entry in btmon:
> > 
> > > ACL Data RX: Handle 3837 flags 0x02 dlen 143         #33540
> > > [hci0] 390.036978
> >        Channel: 515 len 139 [PSM 0 mode Basic (0x00)] {chan 65535}
> >          33 00 cb db 90 00 01 00 58 17 02 00 00 00 00 00 
> > 3.......X.......
> >          00 0e 81 00 00 00 00 00 00 01 00 00 00 00 00 00 
> > ................
> >          00 2a 25 00 00 03 14 01 00 42 27 00 00 00 00 00 
> > .*%......B'.....
> >          00 00 00 00 00 00 00 00 00 ca db 90 00 4a da 90 
> > .............J..
> >          00 07 c4 50 00 00 00 20 00 00 40 f8 05 e1 7f 00  ...P...
> > ..@.....
> >          00 3f 00 09 00 0d 00 00 00 3d 00 09 00 b6 00 00 
> > .?.......=......
> >          00 02 00 20 00 05 00 00 00 01 00 09 00 00 00 09  ...
> > ............
> >          00 0d 00 00 00 3b 00 09 00 1a 00 00 00 30 00 09 
> > .....;.......0..
> >          00 0f 00 00 00 3b 00 09 00 0d 00                
> > .....;.....
> > 
> > The full btmon log is too large to attach I think. Let me know if
> > there's
> > something else I should be turning on to help debug.
> Claude Opus 4.8 analyzed:
> 
> The decisive detail: the handle is byte-for-byte 3837 across three
> unrelated reporters — different laptop, different speaker
> (F0:EF:86:C3:50:D8 here vs. the Lenovo in comment #1), different
> kernel.
> Random corruption wouldn't land on the same handle every time. A
> fixed
> value is a firmware sentinel. This is the ACL twin of the ISO
> misbehaviour Pauli Virtanen already documented ("MT7925 continuously
> sends invalid ISO packets")—related [1][2]—, and it's the same shape
> as
> the handles the MediaTek driver already intercepts:
> 
>      // drivers/bluetooth/btmtk.c  btmtk_usb_recv_acl()
>      case 0xfc6f: /* Firmware dump from device */ ...
>      case 0x05ff: /* Firmware debug logging 1 */
>      case 0x05fe: /* Firmware debug logging 2 */
>          return hci_recv_diag(hdev, skb);   // routed to diag, NOT
> into
> L2CAP
> 
> 0x2EFD isn't in that list, so it falls through to hci_recv_frame() →
> hci_acldata_packet() → no matching connection → the error. So the
> disconnect in Rob's syslog is likely a coincident A2DP timeout, not
> caused by the log line — the spurious packet just shares the
> timeline.
> 
> Should the kernel ignore handle 3837?
> 
> Two different places, two different answers:
> 
> - In generic hci_core.c — no. HCI_CONN_HANDLE_MAX = 0x0eff, and 3837
> =
> 0x0EFD is inside the spec-valid range (just below the max). A
> non-MediaTek controller could legitimately assign it. Dropping it
> generically would silently break other hardware. So my rate-limit
> patch
> is the right vendor-neutral change: it stops the flood without
> dropping
> anyone's data.
> 
> - In btmtk_usb_recv_acl() — probably yes, and that's the real fix,
> routing these to hci_recv_diag() exactly like 0x05fe/0x05ff. That
> both
> kills the spam and stops feeding garbage into L2CAP.
> 
> But I won't add that magic number on inference alone, and here's the
> honest gap:
> 
> 1. I have no MediaTek doc confirming 0x2EFD/0x0EFD is a firmware-log
> handle. The existing constants came from the vendor.
> 2. The existing cases match the raw 16-bit value with a non-flag high
> nibble (0x05ff, 0xfc6f). Ours has high nibble 0x2, which looks like a
> real PB=start flag — so matching semantics (raw 0x2EFD? masked
> 0x0EFD?
> do fragments arrive as 0x1EFD?) aren't obvious, and a wrong mask
> could
> drop real ACL fragments.
> 
> To close that gap before touching the driver, the bug needs the full
> btmon (Rob offered it), to confirm:
> 
> - no HCI Connection Complete / LE Enhanced Connection Complete ever
> assigns handle 0x0EFD, and
> - the 0x?EFD packets always carry this same non-L2CAP payload and
> never
> a real ACL fragment.
> 
> @Mediatek, can you please confirm, that this handle should be
> ignored.
> 
> 
> Kind regards,
> 
> Paul
> 
> 
> [1]:
> https://urldefense.com/v3/__https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=6dc22ab9f085ae165e4ce89d61fb426f94e8a969__;!!CTRNKA9wMg0ARbw!lP0PNdDR4CSngVJTB_m7P0TD0fp2aNst4ZfqjZDvuCE19YkcpmDERWSYSQa1jr64CwTeCcrgd2p4BOvAFpoZmA$
> [2]:
> https://urldefense.com/v3/__https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=edef6576853e51faa11bb286884c362ff7fc83a0__;!!CTRNKA9wMg0ARbw!lP0PNdDR4CSngVJTB_m7P0TD0fp2aNst4ZfqjZDvuCE19YkcpmDERWSYSQa1jr64CwTeCcrgd2p4BOvIQVb0Tg$


From my initial look, ACL data with 0x2EFD is a diag event sent from
Firmware layer. The reason why the data is being reported still needs
further investigation. At least, I don't think it should be appearing.

Regarding your suggestion, adding it to the recv_acl function is one
solution, but I'll bring this back for internal discussion to see
whether disabling it from firmware would be more appropriate. If that
turns out to be difficult, we'll then consider addressing it from
driver side.

Thanks,
Chris Lu