On 03/10/2022 17:14, Paul Menzel wrote:
Dear Nicolas,
Thank you for the patch. Just a small suggestion to make the
summary/title shorter:
Work around SCO over USB HCI design defect
Am 03.10.22 um 16:25 schrieb Nicolas Cavallari:
The USB interface between the host and the bluetooth adapter used for
SCO packets uses an USB isochronous endpoint with a fragmentation scheme
that does not tolerate errors. Except USB isochronous transfers do
not provide a reliable stream with guaranteed delivery (There is no
retry on error, see USB spec v2.0 5.6 and 8.5.5).
I’d put the dot/period after delivery, and inside the brackets after 8.5.5.
To fragment a packet, the bluetooth HCI simply split it in parts and
split*s*
transfer them as-is. The receiver is expected to reconstruct the packet
by assuming the first fragment contains the header and parsing its size
field. There is no error detection either.
If a fragment is lost, the end result is that the kernel is no longer
synchronized and will pass malformed data to the upper layers, since it
has no way to tell if the first fragment is an actual first fragment or
a continuation fragment. Resynchronization can only happen by luck and
requires an unbounded amount of time.
The typical symptom for a HSP/HFP bluetooth headset is that the
microphone stops working and dmesg contains piles of rate-limited
"Bluetooth: hci0: SCO packet for unknown connection handle XXXX"
errors for an undeterminate amount of time, until the kernel accidently
indeterminate, accidentally
Thanks for the typos, will fix them in v2.
resynchronize.
A workaround is to ask the upper layer to prevalidate the first fragment
header. This is not possible with user channels so this workaround is
disabled in this case.
Please document your test setup.
My current worst case is a ath3k (AR3012) on an imx6 board (GW52xx)
running 5.19.8. The issue does not depend on the hfp/hsp headset.
It should be noted that the AR3012 is an USB1 device and it is plugged
into a USB2 root hub. This is already a special case for USB.
What happens when looking at the usbmon traces is that around every
~2s-3s, what should be a 9 byte fragment is replaced by a 0 byte
fragment, which is still reported as successfully transfered.
Please excuse my ignorance, but I have a few more questions:
1. Does that also happen with Android?
I haven't tested to run android on this platform, but is the android
kernel that different from a vanilla linux ?
2. Is it possible to reproduce in QEMU for example?
This platform is probably not powerful enough to run qemu.
