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 -- To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
