linux-bluetooth.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Ville Tervo <ville.tervo@nokia.com>
To: "ext Gustavo F. Padovan" <padovan@profusion.mobi>
Cc: Vinicius Gomes <vinicius.gomes@openbossa.org>,
	ext Anderson Briglia <anderson.briglia@openbossa.org>,
	"linux-bluetooth@vger.kernel.org"
	<linux-bluetooth@vger.kernel.org>
Subject: Re: [PATCH 2/6] Bluetooth: fix receiving L2CAP packets over LE
Date: Mon, 1 Nov 2010 10:51:49 +0200	[thread overview]
Message-ID: <20101101085149.GA10917@null> (raw)
In-Reply-To: <20101029205033.GB14961@vigoh>

Hi,

On Fri, Oct 29, 2010 at 10:50:33PM +0200, ext Gustavo F. Padovan wrote:
> Hi,
> 
> * Vinicius Gomes <vinicius.gomes@openbossa.org> [2010-10-29 09:41:55 -0400]:
> 
> > Hi Ville,
> > 
> > On Fri, Oct 29, 2010 at 6:44 AM, Ville Tervo <ville.tervo@nokia.com> wrote:
> > > Hi Anderson,
> > >
> > > On Sat, Oct 23, 2010 at 01:56:56AM +0200, ext Anderson Briglia wrote:
> > >> From: Vinicius Costa Gomes <vinicius.gomes@openbossa.org>
> > >>
> > >> As L2CAP packets coming over LE don't have any more encapsulation,
> > >> other than L2CAP, we are able to process them as soon as they arrive.
> > >
> > > Why is this change needed? Was something broken without this patch?
> > >
> > 
> > This change is needed because without it the receiving side would
> > always think that it was receiving continuation frames.
> > 
> > As the flags parameter is zero, it would fall into the "} else {"
> > condition, and because no frame was received before, conn->rx_len
> > would be zero and the frame would be discarded. Without this patch I
> > was seeing those "Unexpected continuation frame ..." messages on the
> > receiving side.
> 
> From what I understood the flags are only for ACL connections and LE
> links doesn't have fragmentation, right? So we don't need to check flags
> here, actually it seems we don't have flags for LE like ACL.

Yes it has. See spec. Vol 2 Part E 5.4.2.

It seems that controller should not be sending 0 PB flag in any situation
(except loopback). Vinicius that controller are you using?

I haven't seen this ever in my testing.

-- 
Ville

      parent reply	other threads:[~2010-11-01  8:51 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-10-22 23:56 [PATCH 2/6] Bluetooth: fix receiving L2CAP packets over LE Anderson Briglia
2010-10-29 10:44 ` Ville Tervo
2010-10-29 13:41   ` Vinicius Gomes
2010-10-29 20:50     ` Gustavo F. Padovan
2010-10-30  3:31       ` Vinicius Gomes
2010-11-01  8:51       ` Ville Tervo [this message]

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=20101101085149.GA10917@null \
    --to=ville.tervo@nokia.com \
    --cc=anderson.briglia@openbossa.org \
    --cc=linux-bluetooth@vger.kernel.org \
    --cc=padovan@profusion.mobi \
    --cc=vinicius.gomes@openbossa.org \
    /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;
as well as URLs for NNTP newsgroup(s).