From: Marcel Holtmann <marcel@holtmann.org>
To: Mike <puffy.taco@gmail.com>
Cc: linux-bluetooth <linux-bluetooth@vger.kernel.org>
Subject: Re: hcidump / avtest issues
Date: Fri, 27 Apr 2012 22:51:48 +0200 [thread overview]
Message-ID: <1335559908.16897.481.camel@aeonflux> (raw)
In-Reply-To: <CAB7rCThDkFW+jRdw2Q9kJD3EROAGT=e6vmm5H0gaKq+J9q5A+A@mail.gmail.com>
Hi Mike,
> >>> 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.
the hcidump code is pure raw data. It is the same data that goes to the
driver. Trust me here, that is how the kernel works, it clones the skb
before sending to the driver and sends a copy back to hcidump. So you
will not find a bug in the hcidump raw data.
The only way something can go wrong if L2CAP has an issue. Are you using
L2CAP basic modem or enhanced retransmission?
Regards
Marcel
next prev parent reply other threads:[~2012-04-27 20:51 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-04-27 15:21 hcidump / avtest issues Mike
2012-04-27 18:51 ` Marcel Holtmann
2012-04-27 19:12 ` Mike
2012-04-27 20:13 ` Mike
2012-04-27 20:51 ` Marcel Holtmann [this message]
2012-04-27 20:57 ` Mike
2012-04-27 21:12 ` Mike
2012-04-28 15:15 ` Mike
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1335559908.16897.481.camel@aeonflux \
--to=marcel@holtmann.org \
--cc=linux-bluetooth@vger.kernel.org \
--cc=puffy.taco@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox