Hi Luiz, On Mon, Mar 26, 2012 at 11:40 AM, Luiz Augusto von Dentz <luiz.dentz@xxxxxxxxx> wrote: > Hi Mike, > > On Mon, Mar 26, 2012 at 12:44 PM, Mike <puffy.taco@xxxxxxxxx> wrote: >> True, but I'm testing all the possible user experiences and that's not >> an acceptable solution. The particular case I'm testing is that the >> user deleted the pairing on one end but not the other. I can't >> control what the software on my phone does; I'm only reporting how it >> interacts with BlueZ running on my device. It's true that the next >> time the connection occurs (provided we eventually figure out a SEP >> lock fix), everything will work just fine. I'm just trying to figure >> out what goes wrong the first time. So any pointers you have would be >> great. > > So you are deleting the link key on your phone and still initiating > the connection from it, that doesn't sound like a practical case since > by removing the key the phone should no longer remember your device. > Anyway, that seems that something else is broke because the connection > should be authenticated before accepted by userspace, in other words > the signalling channel connection should not be established before the > pairing completes. I'm probably not being clear on the specifics (they are clear in my head!). My phone is an old Motorola KRZR K1. I do not delete the link key here -- it assumes we're still paired and is attempting to open the A2DP. The device it is connecting to uses BlueZ in an HFP HF role. It is on this device (BlueZ) that I have deleted the link key. So, the phone does remember the past pairing and is attempting at connect as if the two are still paired -- making this a practical case. So I agree that something is broken here as to why the process continues while pairing is occurring. >>>> What exactly is this timeout waiting for? I haven't figured that out >>>> yet. I assume it's waiting on something from my phone (the a2dp >>>> source) and not D-Bus? >>> >>> The client is would be waiting the reply of Acquire, so if you setup >>> something over D-Bus timeout there is a chance the device respond >>> correctly but the client will ignored because the method call already >>> timed out. >> >> Well, this case helps out in a time where I didn't call Acquire (the >> phone initiated the connection). So it seems like there should be a >> check for pairing before initiating the timer. I'm not sure how that >> would work or what would be needed to make that foolproof. For my >> situation, a much higher timeout was sufficient (I'm not saying that >> it should be set to 60 in bluez.git -- just that for me it works). The timeout of 2 seconds is just fine when the two devices are paired. I only run into this issue of crashing my phone when the BlueZ device deletes the pairing. I'm sure it's my phone's fault for crashing, but fixing the upper issue will fix this as well. Mike -- 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
