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. 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 :) Adam [1] http://www.adafruit.com/products/1327, which identifies itself as: Bus 001 Device 004: ID 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode) [2] http://pastie.org/8936306 On 10 Mar 2014, at 14:09, Anderson Lizardo <anderson.lizardo@xxxxxxxxxxxxx> wrote: > Hi Adam, > > Duplicate filtering is done inside the controller. If you disable > filtering, the controller will receive a lot more packets (the > quantity will depend on device's advertising parameters, but it is > several times more packets). > > Even if your Gimbal device changes address on every packet (which is > unusual, usually address changes are time based), what you actually > see without using --duplicate is still a small fraction of what the > controller receives over the air. Try comparing Gimbal on using > --duplicates versus not using (instead of comparing different devices > with different firmware and adv. parameters). Try counting number of > adv. reports on both situations. I expect to see a lot more when > --duplicate is enabled... > > Regarding the logs, it seems your dmesg.txt seems only to show the > last lines of debugging... maybe the dmesg buffer is too short. Can > you check if there is a more complete log generated in one of the > /var/log/kern.log.* files ? > > Fortunately, It contains one snippet showing problems with HCI > reassembly from USB packets: > > [ 878.184532] btusb_intr_complete: hci0 urb d9a8d300 status 0 count 16 > [ 878.185499] btusb_intr_complete: hci0 urb d9a8d300 status 0 count 16 > [ 878.186498] btusb_intr_complete: hci0 urb d9a8d300 status 0 count 12 > [ 878.386548] btusb_intr_complete: hci0 urb d9a8d300 status 0 count 16 > [ 878.387530] btusb_intr_complete: hci0 urb d9a8d300 status 0 count 16 > [ 878.387664] hci_rx_work: hci0 > [ 878.387693] hci_send_to_monitor: hdev d9a4e000 len 64 > [ 878.387783] hci_send_to_sock: hdev d9a4e000 len 64 > [ 878.387803] hci_rx_work: hci0 Event packet > [ 878.387822] hci_event_packet: hci0 event 0xbc > [ 878.387847] hci_send_to_monitor: hdev d9a4e000 len 4 > [ 878.387896] hci_send_to_sock: hdev d9a4e000 len 4 > [ 878.387913] hci_rx_work: hci0 Event packet > [ 878.387930] hci_req_cmd_complete: opcode 0x200c status 0x00 > [ 878.387945] hci_sent_cmd_data: hci0 opcode 0x200c > [ 878.387959] hci_event_packet: hci0 event 0x00 > [ 878.388058] hci_sock_recvmsg: sock da567840, sk daa9c800 > > It contains 3 bogus events: > >> HCI Event: Unknown (0xbc) plen 62 >> HCI Event: Unknown (0x00) plen 2 >> HCI Event: Physical Link Complete (0x40) plen 127 > > For me, it still points out to corrupted/truncated USB packets. > Unfortunately, it is just indirect evidence as the logs don't show raw > USB packets. But you can definitively confirm by using a USB sniffer > tool. I recommend using tshark (wireshark's command line interface). > It works just fine on raspberry. See this post for instructions: > http://nagaraj-embedded.blogspot.com.br/2012/03/capturing-usb-data-through-wireshark.html > > Note that on raspberry there is just "usbmon1" (i.e. Bus 1), and > everything is attached to it. So the logs will get other unrelated > traffic (like ethernet packets), but wireshark GUI is powerful enough > to filter only traffic related to a specific device. > > Best Regards, > -- > Anderson Lizardo > http://www.indt.org/?lang=en > INdT - Manaus - Brazil > -- > 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 -- Adam Warski http://twitter.com/#!/adamwarski http://www.softwaremill.com http://www.warski.org -- 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
