From: Gustavo Padovan <padovan@profusion.mobi>
To: David Fries <david@fries.net>
Cc: linux-bluetooth@vger.kernel.org, linux-kernel@vger.kernel.org,
Arek Lichwa <arkadiusz.lichwa@tieto.com>,
iliak@ti.com, ulrik.lauren@stericsson.com,
peter@hurleysoftware.com
Subject: Re: [REGRESSION] 3.2.0-rc3 Bluetooth L2CAP Linux to Linux rfcomm fails
Date: Sun, 18 Dec 2011 22:36:52 -0200 [thread overview]
Message-ID: <20111219003652.GN2621@joana> (raw)
In-Reply-To: <20111211051624.GA12050@spacedout.fries.net>
Hi David,
* David Fries <david@fries.net> [2011-12-10 23:16:24 -0600]:
> On Mon, Oct 31, 2011 at 05:01:29PM -0200, Gustavo Padovan wrote:
> > Hi Arek,
> >
> > * Arek Lichwa <arkadiusz.lichwa@tieto.com> [2011-10-26 11:23:21 +0200]:
> >
> > > Hi
> > >
> > > We found during testing problem when setting rfcomm (SPP) channel between
> > > two 2.1 devices.
> > > The test case always failed mostly saying security block on l2cap level
> > > but sometimes the fail root cause was 'Command not understood' on l2cap
> > > as well.
> > > Analyzing security block issue, I found that there's unencrypted link when
> > > l2cap command 'connection request' is sent to remote.
> > > The second issue with 'command not understood' has turn out to be related to
> > > expiration of l2cap timer and its implications.
> > >
> > > Solution that I found to fix the problem seems to be related to old commit
> > > 330605423ca6eafafb8dcc27502bce1c585d1b06 made by Ilia Kolomisnky. When there's
> > > authentication ongoing, 'encryption pending' should be turn on, otherwise
> > > there're situations when link stays unencrypted.
> > > The issue with timer expiration is related to Andrzej Kaczmarek's patch
> > > sent to community a couple days ago (~ 2011/10/20).
> > > This patch actually recalculates (repairs) timer values on l2cap which were
> > > wrongly converted before.
> > > With this patch the expiration issue disappears during the test case
> > > I've made, otherwise just reverting 330605423ca6eafafb8dcc27502bce1c585d1b06
> > > is not enough, since timer issue blocks very often passing the test case.
> >
> > Are you saying that Andrzej's patch together with revert of 330605423 fixes
> > the problem? and are you sure that we are not creating any new regression?
> >
> > Gustavo
>
> I just found that I can't connect rfcomm any more from Linux (desktop)
> to Linux (N900) with bluetooth. On the desktop side, 3.2.0-rc2 works,
> but 3.2.0-rc3 (and on) fails, I even merged in
> git://git.kernel.org/pub/scm/linux/kernel/git/padovan/bluetooth-next
> master 5a13b09531420d230616bd524b68a5b0c23cd487 without any change.
> Fortunately there were only three bluetooth patches between rc2 and rc3.
> Reverting 4dff523a913197e3314c7b0d08734ab037709093 fixed the issue and
> I can connect again.
I wen ahead and reverted this one.
Gustavo
next prev parent reply other threads:[~2011-12-19 0:36 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-10-26 9:23 [PATCH cover letter] Bluetooth: Revert: Fix L2CAP connection Arek Lichwa
2011-10-26 9:23 ` [PATCH] Bluetooth: Revert: Fix L2CAP connection establishment Arek Lichwa
2011-10-31 16:00 ` Arkadiusz.Lichwa
2011-11-01 8:58 ` Ilia, Kolominsky
2011-11-02 7:44 ` Arkadiusz.Lichwa
2011-11-02 13:19 ` Ilia, Kolominsky
2011-10-31 19:01 ` [PATCH cover letter] Bluetooth: Revert: Fix L2CAP connection Gustavo Padovan
2011-11-02 7:53 ` Arkadiusz.Lichwa
2011-11-04 17:18 ` Gustavo Padovan
2011-11-07 10:06 ` Arkadiusz.Lichwa
2011-11-07 18:54 ` Gustavo Padovan
2011-11-22 13:27 ` Arkadiusz.Lichwa
2011-12-02 12:53 ` Gustavo Padovan
2011-12-11 5:16 ` [REGRESSION] 3.2.0-rc3 Bluetooth L2CAP Linux to Linux rfcomm fails David Fries
2011-12-19 0:36 ` Gustavo Padovan [this message]
2011-12-20 2:58 ` David Fries
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=20111219003652.GN2621@joana \
--to=padovan@profusion.mobi \
--cc=arkadiusz.lichwa@tieto.com \
--cc=david@fries.net \
--cc=iliak@ti.com \
--cc=linux-bluetooth@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=peter@hurleysoftware.com \
--cc=ulrik.lauren@stericsson.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.