Re: [PATCH 1/2] Bluetooth: Fix legacy pairing with some devices

[Johan Hedberg <johan.hedberg@gmail.com>]

Hi Szymon,

On Thu, Jul 19, 2012, Szymon Janc wrote:
> 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.

Understood. I still think that we should do the necessary changes to the
disconnect timer. I've actually seen this kind of behavior quite often
at UnplugFests and I doubt all of the other parties have been running
BlueZ.

Johan