Closed Bug 1120842 Opened 9 years ago Closed 9 years ago

[Bluetooth][API v2] Cannot receive pairing request event while pairing with some headset.

Categories

(Firefox OS Graveyard :: Bluetooth, defect)

x86
macOS
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED WORKSFORME

People

(Reporter: iliu, Assigned: jaliu)

References

Details

(Whiteboard: [webbt-api])

The WIP of bug 1119734 is working for phone device. But it cannot work for pairing with headset(like SONY Ericsson HBH-DS220, HBH-DS970).
Status: NEW → ASSIGNED
Whiteboard: [webbt-api]
STR: 
1. Click the headset device in found devices list.

Actual Result:
1. The paired property of headset device is changed to true.
2. And it's displayed in paired devices list.
3. No pairing event is received in Bluetooth app.

After the headset be paired, Gaia is able to receive the resolve of the pair() promise call. Then, we can start to connect with this 'audio-card' type headset. So that the actual result is also same with v1 code base. (i.e., we can pair/connect with these headset successfully.) I think the pairing protocol is different with other pairing events which is defined in 'pairingReqs'.

Jamin, I just want Gecko devs to make sure that the behaviour is our expected result. The issue is not blocking anything now. Thanks:)
Hi Ian,

I think the behaviour is expected when FxOS device pairs to some devices with old design. 
Most of modern devices use SSP (secure simple pairing) as pairing approach. 
The SSP process would trigger BluetoothService to send pairing event to ask for SSP response. (e.g. Display passkey, Set confirmation, Enter pincode, consent)

However, some devices with old design don't support SSP and use legacy pairing instead.
The this case, it's expected that BluetoothAdapter.pairingReqs doesn't receive pairing event.

I will check the behaviour of HBH-DS220 and HBH-DS970 to make sure it's using legacy pairing.
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
Resolution: --- → WORKSFORME
See Also: → 1168343
I've tested HBH-DS220 and HBH-DS970 with flame-kk.
Both device are using legacy pairing. Neither |PinRequestNotification| nor |SspRequestNotification| were triggered by Blutooth backend.

It's a expected behaviour that 'pairingReqs' doesn't receive any pairing request event if we are using legacy pairing.

Since the pair/connect procedure are successful, I would say this bug is WORKSFORME.
Thanks for Jamin's investigation here.
(In reply to Jamin Liu [:jaliu] from comment #3)
> I've tested HBH-DS220 and HBH-DS970 with flame-kk.
> Both device are using legacy pairing. Neither |PinRequestNotification| nor
> |SspRequestNotification| were triggered by Blutooth backend.
> 
> It's a expected behaviour that 'pairingReqs' doesn't receive any pairing
> request event if we are using legacy pairing.
> 
> Since the pair/connect procedure are successful, I would say this bug is
> WORKSFORME.

If the stack doesn't send neither |PinRequestNotification| nor
|SspRequestNotification|, i guess the stack goes auto-pair procedure. This is a feature of bluedroid stack for legacy pairing.

In btif/src/btif_dm.c |btif_dm_pin_req_evt(tBTA_DM_PIN_REQ *p_pin_req)|, bluedroid would send ascii 0000 to reply pin request.

However, not for all BT 2.0 devices, bluedroid stack handles /etc/bluetooth/auto_pair_devlist.conf blacklist to ignore auto-pair mechanism.

   if (pairing_cb.is_local_initiated)
    {
        if (check_cod(&bd_addr, COD_AV_HEADSETS) ||
            check_cod(&bd_addr, COD_AV_HANDSFREE) ||
            check_cod(&bd_addr, COD_AV_HEADPHONES) ||
            check_cod(&bd_addr, COD_AV_PORTABLE_AUDIO) ||
            check_cod(&bd_addr, COD_AV_HIFI_AUDIO) ||
            check_cod(&bd_addr, COD_HID_POINTING))
        {
            BTIF_TRACE_DEBUG("%s()cod matches for auto pair", __FUNCTION__);
            /*  Check if this device can be auto paired  */
            if ((btif_storage_is_device_autopair_blacklisted(&bd_addr) == FALSE) &&
                (pairing_cb.autopair_attempts == 0))
            {
                BTIF_TRACE_DEBUG("%s() Attempting auto pair", __FUNCTION__);
                pin_code.pin[0] = 0x30;
                pin_code.pin[1] = 0x30;
                pin_code.pin[2] = 0x30;
                pin_code.pin[3] = 0x30;

                pairing_cb.autopair_attempts++;
                BTA_DmPinReply( (UINT8*)bd_addr.address, TRUE, 4, pin_code.pin);
You need to log in before you can comment on or make changes to this bug.