Return-Path: MIME-Version: 1.0 In-Reply-To: References: <6E6C1573-4744-486B-B2E6-2D3DC45D024B@warski.org> <407CD6A9-AFA8-4A8A-BA2C-882D7A64EF40@warski.org> <0BA8DEFD-9E73-4A6A-A9E6-1957634CABF8@warski.org> Date: Tue, 18 Mar 2014 10:07:23 -0400 Message-ID: Subject: Re: Passive scanning of iBeacons results in a "Data Buffer Overflow" From: Anderson Lizardo To: Adam Warski Cc: BlueZ development Content-Type: text/plain; charset=ISO-8859-1 Sender: linux-bluetooth-owner@vger.kernel.org List-ID: Hi Adam, On Sun, Mar 16, 2014 at 3:53 PM, Adam Warski wrote: > I didn't yet get to doing the wireshark investigations, but just for the record, I got another bluetooth dongle [1], and the --duplicates flag doesn't seem to have any effect, I always get all the packets. Actually, the default in hcitool is to filter duplicates, and "--duplicates" *disables* duplicate filtering. It's sometimes hard to tell from the host side whether duplicate filtering is working or not, as the logic is running inside the dongle. The only effect is to see *more* advertising packets coming to the host when using --duplicates. > 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... Best Regards, -- Anderson Lizardo http://www.indt.org/?lang=en INdT - Manaus - Brazil