Hi Antti, > >>> It's easy to reproduce at least with these dongles: > >>> > >>> Alink BLUEUSB21 (BCM) > >>> Belkin BT2.1 F8T017 (BCM) > >>> DeLock 2.1 (CSR) > >>> PTS 2.1 (CSR) > >>> > >>> So most of our BT 2.1 dongles seem to be buggy. It would be nice to > >>> have a workaround since it happens with so many dongles. > >> > >> If there is so many buggy devices I think Gustavo and Marcel could consider to take this patch. > > > > The patch is too hackish, I don't wanna have such workaround in the tree. > > It is a good idea check the USB stack for possible causes for this bug. > > > > We checked this with USB sniffer. Data comes from USB in the same order > as shown in hcidump, so USB seems to work correctly. and this means that the Bluetooth controller is screwing this up. If you take a real Bluetooth air sniffer then you see that the packet is most likely encrypted. Problem is just that we do not know for sure. And the Bluetooth specification is pretty clear on what to do in these cases. There is even a special qualification test case for this. The real problem is that the HCI event packets and HCI data packets are on a different endpoint when you do this over USB. And there is no real guarantee of ordering in USB when you go over different endpoints. This is essentially the same problem when some controllers send the first data packet before we received the Connect Complete event with the connection handle. Fact is that the chip manufactures need to start testing for this. And BlueZ is faster with its event processing than other stacks. That is something they have to deal with. Regards Marcel -- To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
