Hi Arkadiusz, On Mon, Aug 25, 2025 at 2:49 PM Arkadiusz Bokowy <arkadiusz.bokowy@xxxxxxxxx> wrote: > > > This issue above seem to be something different though, it looks like > > there is some fragmentation of the response but then in the meantime > > we send another command (HCI_OP_READ_BUFFER_SIZE 0x1005) and that > > times out, so the description and the code changes don't really seem > > to match. > > This extra byte tripps wireshark as well. I have exactly the same > dissection in my case, and also I thought that the problem is with > fragmentation (which kind of is). If you look at raw bytes in > wireshark (not the reassembled packet), then you will see that the > 0x1005 command response is correct on its own, however, it is > reassembled with this extra byte from 0x1004 command and then > everything goes sideways.... Yeah, but that is just working around the extra byte, but it seems there is some way to detect that not all data has been read, which is why wireshard is only considering the Read Local Extended Features as received on frame 127 not on frame 123, so Im afraid we are not checking something in urb that tells there are more bytes, then we must read that and only then call btusb_recv_event with the entire response, then we can have a quirk to ignore the extra byte. -- Luiz Augusto von Dentz
