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: <2e7025f4-e63c-070a-08e0-a1fb2469ee49@green-communications.fr>
Date:   Wed, 5 Oct 2022 11:25:01 +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: [PATCH] Bluetooth: Work around SCO over USB HCI design defect
To:     Luiz Augusto von Dentz <luiz.dentz@gmail.com>
Cc:     Marcel Holtmann <marcel@holtmann.org>,
        Johan Hedberg <johan.hedberg@gmail.com>,
        linux-bluetooth@vger.kernel.org
References: <20221004145351.13066-1-nicolas.cavallari@green-communications.fr>
 <CABBYNZJwti_jYq2ctGfgAeh3OS5ed7WqxwBhPhoxrL51Cciy2w@mail.gmail.com>
Content-Language: fr, en-US
From:   Nicolas Cavallari <nicolas.cavallari@green-communications.fr>
In-Reply-To: <CABBYNZJwti_jYq2ctGfgAeh3OS5ed7WqxwBhPhoxrL51Cciy2w@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk

On 05/10/2022 01:46, Luiz Augusto von Dentz wrote:
> Hi Nicolas,
> 
> On Tue, Oct 4, 2022 at 7:54 AM Nicolas Cavallari
> <nicolas.cavallari@green-communications.fr> wrote:
>>
>> 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.)
>>
>> To fragment a packet, the bluetooth HCI simply splits it in parts and
>> 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 indeterminate amount of time, until the kernel accidentally
>> 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.
>>
>> This problem is the most severe when using an ath3k adapter on an i.MX 6
>> board, where packet loss occur regularly, possibly because it is an USB1
>> device connected on an USB2 hub and this is a special case requiring
>> split transactions.
> 
> Interesting, but does this actually make it work if with the packet losses?

All userspace hsp/hfp implementations have packet loss concealment, I 
think, so they can tolerate losing one or two packets there and there. 
In any case it is much more usable than before. Without this patch, the 
number of packet lost is in the 10-1000 range and it is much harder to 
conceal that.

With this patch, given this sequence 01230123, if the first fragment (0) 
is lost, then only one packet is lost. If anything else than the first 
fragment, say (2) is lost, then 0130 is forwarded to the upper layer and 
  the remaining 123 is dropped.

With my ath3k I see that dropped fragments are replaced by zero-length 
fragments. I have a patch that treats zero-length fragments as an error 
and drops the current packet when it occurs, but I can't be certain that 
this won't cause any regression for other adapters, so didn't submit it.

>> [...]
>>
>> +static inline bool hci_conn_prevalidate_sco_hdr(struct hci_dev *hdev,
>> +                                               struct hci_sco_hdr *hdr)
>> +{
>> +       __u16 handle;
>> +
>> +       if (hci_dev_test_flag(hdev, HCI_USER_CHANNEL))
>> +               // Can't validate, userspace controls everything.
>> +               return true;
>> +
>> +       handle = hci_handle(__le16_to_cpu(hdr->handle));
>> +
>> +       switch (hci_conn_lookup_type(hdev, handle)) {
>> +       case SCO_LINK:
>> +       case ESCO_LINK:
>> +               return true;
>> +       default:
>> +               return false;
>> +       }
>> +}
> 
> Don't really like to have this in hci_core.h, it is sort of messy
> already beside this is probably too specific to USB so I'd go with
> something like btusb_validate_sco_handle and add a comment explaining
> why this is necessary.

Will move that into btusb.c then.