[Bug 220564] New: Wrong indentification of Bluetooth in Lenovo Legion Pro 5 and 0489:e111 Foxconn / Hon Hai Wireless_Device

[Bug 220564] New: Wrong indentification of Bluetooth in Lenovo Legion Pro 5 and 0489:e111 Foxconn / Hon Hai Wireless_Device

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=220564

            Bug ID: 220564
           Summary: Wrong indentification of Bluetooth in Lenovo Legion
                    Pro 5 and 0489:e111 Foxconn / Hon Hai Wireless_Device
           Product: Drivers
           Version: 2.5
          Hardware: Intel
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P3
         Component: Bluetooth
          Assignee: linux-bluetooth@vger.kernel.org
          Reporter: jcubic@onet.pl
        Regression: No

I commented on https://bugzilla.kernel.org/show_bug.cgi?id=80791

But I think that this is something unrelated, since the error message:

hci0: ACL packet for unknown connection handle 3837

in my case it may be an error in the driver, I have a flood of errors in logs.
I have a new laptop from 2025 (Lenovo Legion Pro 5 16IAX10 Ultra 7 255HX) and
the system I have (fedora 42 xfce) with kernel 6.16.5-200.fc42.x86_64 detects
something as MTP Wireless Device. There is an icon on the desktop. I think that
this is because of wrong detected Bluetooth device in the Bluetooth driver. The
laptop don't have any MTP device.

gio mount -l shows:

Volume(0): Wireless Device
  Type: GProxyVolume (GProxyVolumeMonitorMTP)


mtp-detect returns:

libmtp version: 1.1.19
Listing raw device(s)
Device 0 (VID=0489 and PID=e111) is a Vizio (for Lenovo) LIFETAB S9714.
   Found 1 device(s):
   Vizio (for Lenovo): LIFETAB S9714 (0489:e111) @ bus 3, dev 6
Attempting to connect device(s)
PTP_ERROR_IO: failed to open session, trying again after resetting USB
interface
LIBMTP libusb: Attempt to reset device
LIBMTP PANIC: failed to open session on second attempt
Unable to open raw device 0
OK.

lsusb:
Bus 003 Device 006: ID 0489:e111 Foxconn / Hon Hai Wireless_Device


I've enabled debugging with /sys/kernel/debug/dynamic_debug/control

This is part of the logs from btmon:

> ACL Data RX: Handle 3837 flags 0x02 dlen 143         #26475 [hci0] 238.821952
      Channel: 259 len 139 [PSM 0 mode Basic (0x00)] {chan 65535}
        32 00 9f d2 95 00 01 00 e6 0a 03 00 00 00 00 00  2...............
        00 dd 9a 00 00 00 00 00 00 08 0a 00 00 00 00 00  ................
        00 d7 04 00 00 71 cc 00 00 e9 11 00 00 00 00 00  .....q..........
        00 fe 0e 01 00 00 00 00 00 9e d2 95 00 6a d2 95  .............j..
        00 07 d6 50 00 fc 07 00 00 00 00 c0 df ff 3f 00  ...P..........?.
        00 02 00 20 00 02 00 00 00 02 00 20 00 02 00 00  ... ....... ....
        00 02 00 20 00 02 00 00 00 02 00 20 00 02 00 09  ... ....... ....
        00 5c 01 00 00 02 00 09 00 00 00 00 00 02 00 20  .\............. 
        00 02 00 00 00 02 00 20 00 02 00                 ....... ...     
> HCI Event: Number of Completed Pack.. (0x13) plen 5  #26476 [hci0] 238.854712
        Num handles: 1
        Handle: 50
        Count: 1
bluetoothd[1539]: < ACL Data TX.. flags 0x02 dlen 850  #26477 [hci0] 238.854861
      Channel: 3778 len 846 [PSM 0 mode Basic (0x00)] {chan 65535}

This is output of journalctl -k

wrz 11 00:38:50 jcubic kernel: hdev 0000000021bf8090 len 147
wrz 11 00:38:50 jcubic kernel: hci0 ACL data packet
wrz 11 00:38:50 jcubic kernel: hci0: len 143 handle 0x0efd flags 0x0002
wrz 11 00:38:50 jcubic kernel: Bluetooth: hci0: ACL packet for unknown
connection handle 3837
wrz 11 00:38:50 jcubic kernel: hci0 Event packet
wrz 11 00:38:50 jcubic kernel: hci0: event 0x13
wrz 11 00:38:50 jcubic kernel: hci0: num 1

I listen to music almost non-stop with Bluetooth speakers, and the error happen
during short music interruption. I think that it started to happen after I've
upgraded to testing kernel in Fedora.

This is a related bug in Fedora:
https://bugzilla.redhat.com/show_bug.cgi?id=2392938

I hope that the provided info is enough, I used Grok (LLM) to help with
debugging.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are the assignee for the bug.

[Bug 220564] Wrong indentification of Bluetooth in Lenovo Legion Pro 5 16IAX10 and 0489:e111 Foxconn / Hon Hai Wireless_Device

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=220564

Jakub Jankiewicz (jcubic@onet.pl) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|Wrong indentification of    |Wrong indentification of
                   |Bluetooth in Lenovo Legion  |Bluetooth in Lenovo Legion
                   |Pro 5 and 0489:e111 Foxconn |Pro 5 16IAX10 and 0489:e111
                   |/ Hon Hai Wireless_Device   |Foxconn / Hon Hai
                   |                            |Wireless_Device

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are the assignee for the bug.

[Bug 220564] Wrong indentification of Bluetooth in Lenovo Legion Pro 5 16IAX10 and 0489:e111 Foxconn / Hon Hai Wireless_Device

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=220564

--- Comment #1 from Jakub Jankiewicz (jcubic@onet.pl) ---
The issue is solved in 6.16.7-200.fc42.x86_64 package.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are the assignee for the bug.

[Bug 220564] Wrong indentification of Bluetooth in Lenovo Legion Pro 5 16IAX10 and 0489:e111 Foxconn / Hon Hai Wireless_Device

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=220564

--- Comment #2 from Jakub Jankiewicz (jcubic@onet.pl) ---
I was mistaken it's still happening but less often. The logs are not flooded
anymore.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are the assignee for the bug.

[Bug 220564] Wrong indentification of Bluetooth in Lenovo Legion Pro 5 16IAX10 and 0489:e111 Foxconn / Hon Hai Wireless_Device

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=220564

jeremy (jeremy53561@gmail.com) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jeremy53561@gmail.com

--- Comment #3 from jeremy (jeremy53561@gmail.com) ---
https://github.com/LuanAdemi/mediatek7925e-bluetooth-fix/tree/main?tab=readme-ov-file#quick-install
See if that fixes this issue

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are the assignee for the bug.

[Bug 220564] Wrong indentification of Bluetooth in Lenovo Legion Pro 5 16IAX10 and 0489:e111 Foxconn / Hon Hai Wireless_Device

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=220564

--- Comment #4 from Jakub Jankiewicz (jcubic@onet.pl) ---
Running:

udevadm info --query=all --name=/dev/bus/usb/*/$(lsusb | grep 0489:e111 | awk
'{print $4}' | sed 's/://') 2>/dev/null | grep -E "GPHOTO2|MTP|MEDIA_PLAYER"

gives no output in my case. But will test the udev config anyway. Even that I
already tested different things with udev. I've created this report after I've
found about udev system and was asking Grok how to disable the MTP device.

I also tried to edit:

/usr/lib/udev/rules.d/69-libmtp.rules

file, to ignore my device, with no effect.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are the assignee for the bug.

[Bug 220564] Wrong indentification of Bluetooth in Lenovo Legion Pro 5 16IAX10 and 0489:e111 Foxconn / Hon Hai Wireless_Device

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=220564

--- Comment #5 from Jakub Jankiewicz (jcubic@onet.pl) ---
The fix solved the issue with MTP device, but there are still interruption
during playing music over Bluetooth. And this still shows up in logs:

Bluetooth: hci0: ACL packet for unknown connection handle 3837

It seems that interruption was not related to MTP device.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are the assignee for the bug.

[Bug 220564] Wrong indentification of Bluetooth in Lenovo Legion Pro 5 16IAX10 and 0489:e111 Foxconn / Hon Hai Wireless_Device

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=220564

Jakub Jankiewicz (jcubic@onet.pl) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |OBSOLETE

--- Comment #6 from Jakub Jankiewicz (jcubic@onet.pl) ---
I think that this can be closed now. I don't see any issues with the sound from
Bluetooth, the logs are clean, and the MTP device was fixed by a hack on udev
level.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are the assignee for the bug.

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

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=220564

Jakub Jankiewicz (jcubic@onet.pl) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|OBSOLETE                    |---
            Summary|Wrong indentification of    |hci0: ACL packet for
                   |Bluetooth in Lenovo Legion  |unknown connection handle
                   |Pro 5 16IAX10 and 0489:e111 |3837 and sound interruption
                   |Foxconn / Hon Hai           |
                   |Wireless_Device             |

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are the assignee for the bug.

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

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=220564

--- Comment #7 from Jakub Jankiewicz (jcubic@onet.pl) ---
The issue is still present. The identification of the Bluetooth device is fixed
but there are still messages in logs:

Bluetooth: hci0: ACL packet for unknown connection handle 3837

And there are still sound interruptions.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are the assignee for the bug.

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

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=220564

webcaptcha (webcapcha@gmail.com) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |webcapcha@gmail.com

--- Comment #8 from webcaptcha (webcapcha@gmail.com) ---
I have the same constantly error messages in logs. I would say every 20-60
seconds the same error

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are the assignee for the bug.

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

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=220564

Rob Hogan (robhogan@gmail.com) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |robhogan@gmail.com

--- Comment #9 from Rob Hogan (robhogan@gmail.com) ---
I also have this issue. Error appears every few minutes and the bluetooth
speaker disconnects and reconnects.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are the assignee for the bug.

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

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=220564

Paul Menzel (pmenzel+bugzilla.kernel.org@molgen.mpg.de) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |pmenzel+bugzilla.kernel.org
                   |                            |@molgen.mpg.de

--- Comment #10 from Paul Menzel (pmenzel+bugzilla.kernel.org@molgen.mpg.de) ---
Created attachment 310408
  --> https://bugzilla.kernel.org/attachment.cgi?id=310408&action=edit
Output of `about:support` (Debian’s Firefox 152.0.4) (Copy text to clipboard)

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are the assignee for the bug.

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

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=220564

Paul Menzel (pmenzel+bugzilla.kernel.org@molgen.mpg.de) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
 Attachment #310408|0                           |1
        is obsolete|                            |

--- Comment #11 from Paul Menzel (pmenzel+bugzilla.kernel.org@molgen.mpg.de) ---
Comment on attachment 310408
  --> https://bugzilla.kernel.org/attachment.cgi?id=310408
Output of `about:support` (Debian’s Firefox 152.0.4) (Copy text to clipboard)

Sorry, wrong tab. :(

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are the assignee for the bug.

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

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=220564

--- Comment #12 from Paul Menzel (pmenzel+bugzilla.kernel.org@molgen.mpg.de) ---
https://bugzilla.mozilla.org/show_bug.cgi?id=2048220(In reply to Rob Hogan from
comment #9)
> I also have this issue. Error appears every few minutes and the bluetooth
> speaker disconnects and reconnects.

@Rob, might this be a different problem? It be great if you create a new issue
with output of `dmesg` and btmon trace attached.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are the assignee for the bug.

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

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=220564

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

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are the assignee for the bug.

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

[Paul Menzel]

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://bugzilla.kernel.org/show_bug.cgi?id=220564
> 
> --- 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://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=6dc22ab9f085ae165e4ce89d61fb426f94e8a969
[2]: 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=edef6576853e51faa11bb286884c362ff7fc83a0

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

[Chris Lu (陸稚泓)]

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

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

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=220564

--- Comment #14 from Paul Menzel (pmenzel+bugzilla.kernel.org@molgen.mpg.de) ---
Thank you! Which Linux kernel is it? Full output of `dmesg` would be nice to
have.

Did it work flawlessly in the past for you?

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are the assignee for the bug.

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

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=220564

--- Comment #15 from Rob Hogan (robhogan@gmail.com) ---
Yes, it worked fine until the last few days when the interruptions to sound
became nearly constant - almost every ten or twenty minutes.

Linux mwenge 6.8.0-124-generic #124~22.04.1-Ubuntu SMP PREEMPT_DYNAMIC Tue May
26 21:05:19 UTC  x86_64 x86_64 x86_64 GNU/Linux

dmesg output attached.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are the assignee for the bug.

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

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=220564

--- Comment #16 from Rob Hogan (robhogan@gmail.com) ---
Created attachment 310410
  --> https://bugzilla.kernel.org/attachment.cgi?id=310410&action=edit
dmesg output

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are the assignee for the bug.