Received-SPF: pass (google.com: domain of linux-bluetooth-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <4fc40766-6e8d-1683-b370-1417aeab1db7@green-communications.fr>
Date:   Tue, 4 Oct 2022 10:02:33 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.3.0
Subject: Re: [RFC PATCH] Bluetooth: Add a workaround for SCO over USB HCI
 design defect
To:     Paul Menzel <pmenzel@molgen.mpg.de>
Cc:     Marcel Holtmann <marcel@holtmann.org>,
        Johan Hedberg <johan.hedberg@gmail.com>,
        Luiz Augusto von Dentz <luiz.dentz@gmail.com>,
        linux-bluetooth@vger.kernel.org
References: <20221003142558.17914-1-nicolas.cavallari@green-communications.fr>
 <f083fce1-7ad3-0c5c-843a-3e14eb7ff4d6@molgen.mpg.de>
Content-Language: fr
From:   Nicolas Cavallari <nicolas.cavallari@green-communications.fr>
In-Reply-To: <f083fce1-7ad3-0c5c-843a-3e14eb7ff4d6@molgen.mpg.de>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Precedence: bulk

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.