From: Szymon Janc <szymon.janc@tieto.com>
To: Johan Hedberg <johan.hedberg@gmail.com>
Cc: Gustavo Padovan <gustavo@padovan.org>,
"linux-bluetooth@vger.kernel.org"
<linux-bluetooth@vger.kernel.org>
Subject: Re: Re: [PATCH 1/2] Bluetooth: Fix legacy pairing with some devices
Date: Thu, 19 Jul 2012 12:17:13 +0200 [thread overview]
Message-ID: <1709298.ayJY9Nu1WY@uw000953> (raw)
In-Reply-To: <20120719093452.GC7612@x220>
On Thursday 19 of July 2012 12:34:52 Johan Hedberg wrote:
> > > > > Maybe we could set timeout back to HCI_DICONN_TIMEOUT when l2cap is
> > > > > connected (or disconnected)? That should cover SDP search case..
> > > >
> > > > What happened to getting this patch upstream? To me it looks like a
> > > > definitely needed fix. After adding the fix to restore a sensible value
> > > > for disc_timeout after an L2CAP connect request either way and adding a
> > > > better explanation to the commit message (that we only get the PIN
> > > > request after user has entered one on the remote side, including a
> > > > hcidump of this) I think this should go upstream. If this had been
> > > > processed in a timely manner it could have made it to 3.5 but now it
> > > > seems too late for that (as it's not strictly speaking a regression from
> > > > 3.4).
> > >
> > > Could you re-do this patch as Johan says so we can try push it to 3.5?
> >
> > Sorry for late reply, been on rather long holiday..
> >
> > I now feel that this is a bug in bluez not in kernel - bluez should not cancel
> > PIN request for agent if acl is disconnected but just reconnect when PIN is
> > provided.
> >
> > So, if you still like to have this workaround in kernel for devices which are
> > highly unlikely to have this fixed I can send new version.
>
> I don't agree with your categorization of the kernel change as a
> workaround. Since it was the remote side the initiated the initial ACL I
> don't think it's right for us to have any kind of automation of creating
> a second ACL in the opposite direction. So please do the improvements to
> your patch as discussed and resend. Thanks.
I guess I wasn't clear enough.. I meant that the bug is in bluez which is also
running on remote device and is unlikely to get updated. No connection in
opposite direction is taking place. It is bluez on initiator side that should
reconnect when it received PIN from user if acl was disconnected. Most agents
do service search in the meantime so l2cap exists and acl is not disconnected.
This can be easily reproduced with simple-agent which is not doing service
search.
--
BR
Szymon Janc
next prev parent reply other threads:[~2012-07-19 10:17 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-05-28 9:47 [PATCH 1/2] Bluetooth: Fix legacy pairing with some devices Szymon Janc
2012-05-28 9:47 ` [PATCH 2/2] Bluetooth: Remove unused HCI timeouts definitions Szymon Janc
2012-05-29 17:39 ` Gustavo Padovan
2012-05-29 17:37 ` [PATCH 1/2] Bluetooth: Fix legacy pairing with some devices Gustavo Padovan
2012-05-30 7:41 ` Szymon Janc
2012-06-29 10:56 ` Johan Hedberg
2012-07-04 7:56 ` Gustavo Padovan
2012-07-19 9:13 ` Szymon Janc
2012-07-19 9:34 ` Johan Hedberg
2012-07-19 10:17 ` Szymon Janc [this message]
2012-07-19 10:25 ` Johan Hedberg
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=1709298.ayJY9Nu1WY@uw000953 \
--to=szymon.janc@tieto.com \
--cc=gustavo@padovan.org \
--cc=johan.hedberg@gmail.com \
--cc=linux-bluetooth@vger.kernel.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