** Tags added: fixed-in-bluez-5.87 ** Description changed:
[ Impact ] - When a Bluetooth device running BlueZ acts as an OBEX server (OPP/FTP/PBAP - receiver), file transfer throughput is degraded by approximately 90% compared - to the Tx direction. + When a Bluetooth device running BlueZ acts as an OBEX server (OPP/FTP/PBAP + receiver), file transfer throughput is degraded by approximately 90% compared + to the Tx direction. - Root cause: bt_io_listen() in src/profile.c did not set BT_IO_OPT_IMTU for - OBEX profile listeners. This causes L2CAP_CONFIGURATION_RSP to advertise the - minimum MTU (672 bytes), limiting incoming OBEX packets to 669 bytes instead - of the expected ~8 KB+. + Root cause: bt_io_listen() in src/profile.c did not set BT_IO_OPT_IMTU for + OBEX profile listeners. This causes L2CAP_CONFIGURATION_RSP to advertise the + minimum MTU (672 bytes), limiting incoming OBEX packets to 669 bytes instead + of the expected ~8 KB+. - The fix adds an `imtu` field to profile default_settings and applies - BT_IO_OPT_IMTU = BT_RX_MTU (32767) for OPP, FTP, PSE, MAS and MNS profiles, - matching the value already used on the client (Tx) side. + The fix adds an `imtu` field to profile default_settings and applies + BT_IO_OPT_IMTU = BT_RX_MTU (32767) for OPP, FTP, PSE, MAS and MNS profiles, + matching the value already used on the client (Tx) side. - Upstream: https://github.com/bluez/bluez/commit/646014a6a - Merged in BlueZ 5.86. + Upstream: https://github.com/bluez/bluez/commit/646014a6a + Merged in BlueZ 5.87. - [ Test Plan ] + [ Test Plan ] - Prerequisites: - - An Qualcomm IQ-X device running Ubuntu as receiver - - A remote Bluetooth device (e.g. Android phone) as the sender + Prerequisites: + - An Qualcomm IQ-X device running Ubuntu as receiver + - A remote Bluetooth device (e.g. Android phone) as the sender - Steps to reproduce (before fix): - 1. On the IQ-X device, ensure bluetoothd and obexd are running - 2. On the Android phone, initiate an OPP file transfer sending a large file - (e.g. 10 MB) to the IQ-X device - 3. Observe transfer speed + Steps to reproduce (before fix): + 1. On the IQ-X device, ensure bluetoothd and obexd are running + 2. On the Android phone, initiate an OPP file transfer sending a large file + (e.g. 10 MB) to the IQ-X device + 3. Observe transfer speed - Expected with fix: > 500 KB/s (comparable to Tx direction) - Actual without fix: < 100 KB/s (limited by 669-byte OBEX packets) + Expected with fix: > 500 KB/s (comparable to Tx direction) + Actual without fix: < 100 KB/s (limited by 669-byte OBEX packets) - Verification after fix: - - Repeat the OPP transfer: speed should be comparable to Tx (~500 KB/s+) - - Optional: run obexd in debug mode and confirm recv_data() size ~8016 - $ systemctl stop obex - $ /usr/libexec/bluetooth/obexd -s -a -d - Before fix: recv_data() size=669 - After fix: recv_data() size=8016 depend on the remote device + Verification after fix: + - Repeat the OPP transfer: speed should be comparable to Tx (~500 KB/s+) + - Optional: run obexd in debug mode and confirm recv_data() size ~8016 + $ systemctl stop obex + $ /usr/libexec/bluetooth/obexd -s -a -d + Before fix: recv_data() size=669 + After fix: recv_data() size=8016 depend on the remote device - [ Where problems could occur ] + [ Where problems could occur ] - The change increases the advertised L2CAP IMTU for OBEX server sockets from - 672 to 32767. The remote peer still decides the actual packet size to send, so - a well-implemented BT stack will simply use its own MPS/MTU without issue. + The change increases the advertised L2CAP IMTU for OBEX server sockets from + 672 to 32767. The remote peer still decides the actual packet size to send, so + a well-implemented BT stack will simply use its own MPS/MTU without issue. - Possible regression scenarios: - - Remote BT stacks with bugs handling large-MTU L2CAP negotiation might fail - to connect or transfer. However, this is the same IMTU already used on - BlueZ's client (Tx) side and has worked reliably. - - Only OBEX profiles (OPP, FTP, PSE, MAS, MNS) are affected; all other - profiles using bt_io_listen() are unmodified. - - Slightly larger kernel socket buffers, negligible on any modern platform. + Possible regression scenarios: + - Remote BT stacks with bugs handling large-MTU L2CAP negotiation might fail + to connect or transfer. However, this is the same IMTU already used on + BlueZ's client (Tx) side and has worked reliably. + - Only OBEX profiles (OPP, FTP, PSE, MAS, MNS) are affected; all other + profiles using bt_io_listen() are unmodified. + - Slightly larger kernel socket buffers, negligible on any modern platform. - [ Other Info ] + [ Other Info ] - - Only src/profile.c is modified (19 lines changed). + - Only src/profile.c is modified (19 lines changed). ** Changed in: bluez (Ubuntu) Status: New => Fix Released ** Changed in: bluez (Ubuntu) Milestone: None => ubuntu-26.10 ** Also affects: bluez (Ubuntu Resolute) Importance: Undecided Status: New ** Also affects: bluez (Ubuntu Stonking) Importance: Undecided Status: Fix Released ** Changed in: bluez (Ubuntu Resolute) Milestone: None => resolute-updates ** Changed in: bluez (Ubuntu Resolute) Assignee: (unassigned) => Balachandra Bhat (bnbhat) -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2163625 Title: [SRU][Resolute] Set L2CAP IMTU for OBEX profile listeners to fix OPP Rx KPI To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/bluez/+bug/2163625/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
