Re: Passive scanning of iBeacons results in a "Data Buffer Overflow"

[Terry Hardie <terryh@orcas.net>]

On 2014-03-18 07:07, Anderson Lizardo wrote:
>> And the same as before, after a short amount of time I start getting 
>> similar (not exactly the same [2]) errors. So it's not the dongle :)
> 
> The logs seem to show the same behaviour as the other dongle:
> seemingly "random" packets with nonsense parameters (simply because
> the HCI packet was assembled incorrectly).
> 
> I still blame the USB controller in RPi/Beaglebone for not feeding all
> USB fragments to the bluetooth subsystem... at least is my
> interpretation from Terry's logs (which are from USB sniffing).
> 
> What I have no clue is why this is happenning: both of you tried
> powered USB hubs, and this was my only guess (insufficient power on
> the bus). If you could find a kernel version for your boards that are
> not causing any problems, then we can rule out HW related issues...

I agree that it looks like the USB controller's fault. It seems highly 
unlikely, though. A few reasons why I think so:

1. The 2 boards use completely different USB controllers.
2. Both those platforms talk to other USB devices pushing much higher 
data rates without any issue.
3. The problem doesn't show up when the bus is forced to USB 1.1 (Full 
speed instead of high speed)
4. The problem doesn't only show up during non-duplicate-filtered scans. 
I can reproduce it (although it takes a lot longer) with LE 
Advertisement packets only coming in once per second.

Let me ask another question:

Are there any other USB devices that ever send a bunch of data with no 
polling from the host? IE, if the host has no buffer space to accept an 
INT transaction, it will just be lost, and all other USB devices wait 
for the INT to be processed by getting an acknowledgement before 
generating another INT? Apologies for my lack of in-depth knowledge for 
the workings of USB bus transactions.

My suspicion is that if you follow the Bluetooth spec for HCI over USB 
(which all of these vendors making these USB devices should) then if the 
host USB controller is not fast enough, it can be overwhelmed. Forcing 
the bus to full-speed mode, means the bluetooth receiver is forced to 
buffer on its end, since it simply cannot transfer data to the host fast 
enough to overwhelm it. If my suspicion is true, then that means any 
packets of this type could overflow a host if it is busy enough, 
although much less likely to happen if the host is more powerful (in 
terms of processing power).

Regards,

Terry