RE: MGMT_OP_SET_DISCOVERABLE is queued for a long time if Pairing is in progress

RE: MGMT_OP_SET_DISCOVERABLE is queued for a long time if Pairing is in progress

[Biman Paul]

If the device has initiated pairing and after that it tries to change
discovery mode, discovery mode change request is queued until the pairing
operation is completed(be it successful, failed, timeout).

Steps to Reproduce:
1. Initiate Pairing from Instrument Under Test
2. Accept in Instrument under Test but do not accept in remote device
3. Try to change the Visibility from off to on or on to off.
Visibility change does not happen until pairing operation is
completed(Pairing is accepted, rejected or timeout in remote).

Please suggest the best way we can handle this.


Thanks and Regards

Biman Paul
Samsung R&D Institute India - Bangalore

Re: MGMT_OP_SET_DISCOVERABLE is queued for a long time if Pairing is in progress

[Johan Hedberg]

Hi,

On Wed, Dec 17, 2014, Biman Paul wrote:
> If the device has initiated pairing and after that it tries to change
> discovery mode, discovery mode change request is queued until the pairing
> operation is completed(be it successful, failed, timeout).
> 
> Steps to Reproduce:
> 1. Initiate Pairing from Instrument Under Test
> 2. Accept in Instrument under Test but do not accept in remote device
> 3. Try to change the Visibility from off to on or on to off.
> Visibility change does not happen until pairing operation is
> completed(Pairing is accepted, rejected or timeout in remote).
> 
> Please suggest the best way we can handle this.

Can't you just enable discoverable mode *before* initiating pairing? :)

On a more serious note, we do have the appropriate API for such
situations: mgmt_reply (instead of mgmt_send) which skips the queue of
mgmt commands. This is how canceling pairing works as well as responding
to PIN or passkey requests (as otherwise these commands would only get
sent when the pair command completes).

So far we haven't extended the use of mgmt_reply anywhere else, but we
could consider using it more extensively when pairing is active if we
have good use cases for it.

Johan