>>> I'm having issues where hcidump seems to be losing packets. I'm >>> trying to collect traces of avtest running. Avtest properly prints >>> out that it sent a packet and received a reply, but I don't always see >>> it in hcidump. Seems if I run avtest a lot successively, it does show >>> up. I'm running a 2.6.33.20 kernel with hcidump-2.3. Let me know if >>> the kernel is just too ancient, but I'd like to know if others have >>> seen this type of issue. >> >> actually hcidump can not loose any packets. Write them into a file in >> BTSnoop format and double check with Wireshark or the Frontline Viewer. >> >> The kernel is always sending the exact copy to the hcidump sockets and >> thus there is no way you loose packets. The only explanation would be >> that L2CAP socket has a bug and swallows it. Have you checked that >> avtest actually reports L2CAP send errors. > > I was saving in btsnoop and looking at it in wireshark. And verified > that the other side got the command by enabling debug mode on > bluetoothd. But now I see the packet is sort of there, but it's > malformed! > > Bad: > < 02 01 20 07 00 03 00 40 00 00 06 04 >> 02 01 20 07 00 03 00 40 00 03 06 31 > > Good: > < 02 01 20 07 00 03 00 42 00 00 06 04 >> 02 01 20 07 00 03 00 42 00 03 06 31 > > Somehow one byte is wrong (40 bad, 42 good). Any ideas on that? Let > me know if you'd like the logs, but I verified the --raw output of > hcidump had the same issue. BTW, I would say the issue exists more when SDP is going on (as when I run the test a lot before a disconnect, it starts working -- no more SDP later on). And we can see that it classified the packet as SDP, not AVDTP. I'm tracking the hcidump code now, not entirely sure how data goes into one or the other. -- 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
