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

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: [email protected]
Reporter: [email protected]
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:

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

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.

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

Jakub Jankiewicz ([email protected]) 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.

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

--- Comment #1 from Jakub Jankiewicz ([email protected]) --- 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.

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

--- Comment #2 from Jakub Jankiewicz ([email protected]) ---
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.

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

jeremy ([email protected]) changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |[email protected]

--- Comment #3 from jeremy ([email protected]) ---
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.

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

--- Comment #4 from Jakub Jankiewicz ([email protected]) --- 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.

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

--- Comment #5 from Jakub Jankiewicz ([email protected]) ---
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.

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

Jakub Jankiewicz ([email protected]) changed:

What |Removed |Added
----------------------------------------------------------------------------

             Status|NEW                         |RESOLVED
         Resolution|---                         |OBSOLETE

--- Comment #6 from Jakub Jankiewicz ([email protected]) ---
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.

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

Jakub Jankiewicz ([email protected]) 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.

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

--- Comment #7 from Jakub Jankiewicz ([email protected]) ---
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.

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

webcaptcha ([email protected]) changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |[email protected]

--- Comment #8 from webcaptcha ([email protected]) ---
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.

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

Rob Hogan ([email protected]) changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |[email protected]

--- Comment #9 from Rob Hogan ([email protected]) ---
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.

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

Paul Menzel ([email protected]) changed:

What |Removed |Added
----------------------------------------------------------------------------

                 CC|                            |pmenzel+bugzilla.kernel.org
                   |                            |@molgen.mpg.de

--- Comment #10 from Paul Menzel ([email protected]) --- 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.

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

Paul Menzel ([email protected]) changed:

What |Removed |Added
----------------------------------------------------------------------------

 Attachment #310408|0                           |1

is obsolete| |

--- Comment #11 from Paul Menzel ([email protected]) --- 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.

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

--- Comment #12 from Paul Menzel ([email protected]) ---
https://bugzilla.mozilla.org/show_bug.cgi?id=2048220(In reply to Rob Hogan from comment #9)

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

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

--- Comment #13 from Rob Hogan ([email protected]) --- 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:

      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.

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 [email protected]:

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

Hi Paul,

Thank you for pointing that out.

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

[To: [email protected] (bounced)]

Dear Chris,

Thank you for your instant reply.

Am 02.07.26 um 04:48 schrieb Chris Lu (陸稚泓):

[…]

Understood. Keep in mind, as the firmware sending the diag event has been published and you cannot expect everybody updating the Linux kernel also updating the firmware, the Linux kernel driver should also be “fixed” to deal with the older firmware.

Also, I believe the reporters/commenters are annoyed by the audio interruptions. Please feel free to comment in the Linux Kernel Bugzilla issue, what diagnostics you need, and if this should be handled separately, like via email lists or a separate bug report.

Kind regards,

Paul

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

--- Comment #14 from Paul Menzel ([email protected]) --- 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.

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

--- Comment #15 from Rob Hogan ([email protected]) ---
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.

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

--- Comment #16 from Rob Hogan ([email protected]) --- 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.

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

--- Comment #17 from Rob Hogan ([email protected]) ---
A factory reset on the speaker appears have to resolved the sound interruption issue for me. I think the 'handle 3837' messages have stopped now too - none in the past couple of hours. I suspect (although it doesn't make too much sense) that the issue with the speaker was that it lost its wifi connection due to a password change and this somehow started the audio interruptions.

You may reply to this email to add a comment.

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

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

--- Comment #18 from Jakub T. Jankiewicz ([email protected]) --- I didn't notice any sound interruption anymore. Right now I'm on kernel 7.0.13-100.fc43.x86_64

I still have many messages in the system log, but that is part of
https://bugzilla.kernel.org/show_bug.cgi?id=80791

You may reply to this email to add a comment.

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