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. >>> 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). As I said the use case you are trying does not seem very practical, and in any case to pass a file descriptor you will need a method call which inevitably will have a timeout associated. -- Luiz Augusto von Dentz -- 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
