938003 - [tarako][fugu]Can not pair some specific bluetooth headset

Status: RESOLVED WORKSFORME

(Firefox OS Graveyard :: Bluetooth, defect)

Description

[Xinhe Yan]

Attachment: log for fugu can not connect BH105

User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/535.19 (KHTML, like Gecko) Ubuntu/11.04 Chromium/18.0.1025.151 Chrome/18.0.1025.151 Safari/535.19

Comment 1

[Xinhe Yan]

I add more log and find this 
BluetoothHfpManager::OnSocketConnectError mSocket ConnectError

But can not find root cause. Fire this bug to trace compatibility of fugu headset

Comment 2

[Xinhe Yan]

I found device_bonding_complete status is 0x06 which call device_remove_bonding and re-authentication,but our corresponding android phone got status 0.

device_bonding_complete
{
if (status == 0x06 && auth == NULL) {
		device_remove_bonding(device);
		device_get_address(device, &bdaddr);
		btd_adapter_retry_authentication(device->adapter, &bdaddr);
		return;
	} 
}

Hi Shawn, do you have any suggestion? Does gecko invole in blue authentication,or authentication just releated with bluez/kernel?

Comment 3

[Shawn Huang [:shawnjohnjr][:shuang] (as a happy gecko contributor)]

Gecko is not related to bluez kernel but bluez userspace might. And this is bluez stack code.
Have you checked air sniffer log why HCI_PIN_OR_KEY_MISSING returns?
Sorry, I don't have the whole picture why it leads connection error.

Comment 4

[Shawn Huang [:shawnjohnjr][:shuang] (as a happy gecko contributor)]

(In reply to Xinhe Yan from comment #2)
> Hi Shawn, do you have any suggestion? Does gecko invole in blue
> authentication,or authentication just releated with bluez/kernel?
You should check air trace log or hcidump snoop file for more information, adding log in stack might not be able to point out problems.

Comment 5

[Xinhe Yan]

I found some log in fugu android
Bluetooth HSHFP(  408): Trying to connect to rfcomm socket again after 1 sec

But I can not sure about the root cause. I have other bug to fix, I will check this next week.

Comment 6

[James Zhang (Spreadtrum)]

It's not block issue, Xinhe will check it next week.

Comment 7

[Xinhe Yan]

Attachment: fugu and android log(kernel log & hcidump)

Comment 8

[viral [:viralwang]]

Attachment: hcidump.txt

add hcidump log

Comment 9

[Xinhe Yan]

hcidump log
2013-12-09 13:45:29.962207 > ACL data: handle 50 flags 0x02 dlen 14
    L2CAP(d): cid 0x0040 len 10 [psm 1]
        SDP SSA Rsp: tid 0xa len 0x5 
          count 2
          cont 00
2013-12-09 13:45:32.000443 < ACL data: handle 50 flags 0x00 dlen 12
    L2CAP(s): Disconn req: dcid 0x0046 scid 0x0040
2013-12-09 13:45:32.003319 > HCI Event: Number of Completed Packets (0x13) plen 5
    handle 50 packets 1
2013-12-09 13:45:32.013479 > ACL data: handle 50 flags 0x02 dlen 12
    L2CAP(s): Disconn rsp: dcid 0x0046 scid 0x0040
2013-12-09 13:45:33.011101 < HCI Command: Disconnect (0x01|0x0006) plen 3                                                                                    
    handle 50 reason 0x13
    Reason: Remote User Terminated Connection


kernel log
<3>0[ 2493.840612] hci_conn_timeout: conn c2243400 state 1
<3>0[ 2493.840636] l2cap_disconn_ind: hcon c2243400
<3>0[ 2493.840648] hci_acl_disconn: c2243400
<3>0[ 2493.840661] hci_send_cmd: hci0 opcode 0x406 plen 3

12-09 13:45:29.349 E/GeckoBlue(  118): linux/BluetoothDBusService.cpp DBUS_DEVICE_IFACE PropertyChanged name Paired
12-09 13:45:34.470 E/GeckoBluetooth(  118): Start: [HFP/HSP] 
12-09 13:45:34.470 E/GeckoBlueHFP(  118): BluetoothHfpManager::Connect entry

It took 5 seconds to connect HFP. But hci connect already timeout.

Comment 10

[viral [:viralwang]]

Attachment: another hcidump log

Comment 11

[Shawn Huang [:shawnjohnjr][:shuang] (as a happy gecko contributor)]

I really think this is related to a temporary link key problem. Does your Android device kernel bluez as the same as fugu kernel?
You can check /data/misc/bluetoothd/[bdaddress]/linkkeys, see if Nokia BH-105 had stored link key after the first auth complete.

Comment 12

[Xinhe Yan]

(In reply to Shawn Huang [:shuang] [:shawnjohnjr] from comment #11)
> I really think this is related to a temporary link key problem. Does your
> Android device kernel bluez as the same as fugu kernel?
Yes, they use same bluez and kernel.
> You can check /data/misc/bluetoothd/[bdaddress]/linkkeys, see if Nokia
> BH-105 had stored link key after the first auth complete.
no linkkeys store in /data/misc/bluetoothd.
I also checked hamachi and fugu android.
They also not store any thing in /data/misc/bluetoothd.
No file exist in /data/misc/bluetoothd.

Comment 13

[Xinhe Yan]

Attachment: patch to fix fugu ssp

This patch can fix fugu simple pair bug.

Comment 14

[Shawn Huang [:shawnjohnjr][:shuang] (as a happy gecko contributor)]

Based on comment 13, is it also fix for Nokia-BH105? Or just enable secure simple pairing mode only?

Comment 15

[Xinhe Yan]

(In reply to Shawn Huang [:shuang] [:shawnjohnjr] from comment #14)
> Based on comment 13, is it also fix for Nokia-BH105? Or just enable secure
> simple pairing mode only?
Only for simple pairing mode.

Comment 16

[Xinhe Yan]

(In reply to Xinhe Yan from comment #9)
> It took 5 seconds to connect HFP. But hci connect already timeout.
I found gaia bluetooth.js will take 5 seconds to connect HFP.

// if the device has to be connected when it just paired
// wait for a while so they can have time to communicate
// their connection protocol
if (device.address === connectingAddress &&
  device.icon === 'audio-card') {
var small = aItem.querySelector('small');
l10n.localize(small, 'device-status-connecting');
setTimeout(function() {
setDeviceConnect(device);
}, 5000);
}

After change 5000 to 1000, BH105 can connect HFP.
Maybe we need to decrease wait time.

Comment 17

[Xinhe Yan]

12-10 18:57:23.730 D/BluetoothEventLoop(  236): Device property changed: F0:65:DD:40:36:93 property: Paired value: true
12-10 18:57:24.370 V/BluetoothEventManager(  457): Received android.bluetooth.device.action.UUID
12-10 18:57:24.390 D/BluetoothBondState(  236): setBondState address 12reason: 0
12-10 18:57:24.400 I/BluetoothDeviceProfileState(  236): Entering ACL Connected state with: -2
12-10 18:57:24.430 D/BluetoothBondState(  236): F0:65:DD:40:36:93 bond state 11 -> 12 (0)
12-10 18:57:24.450 V/BluetoothEventManager(  457): Received android.bluetooth.device.action.BOND_STATE_CHANGED
12-10 18:57:24.510 D/CachedBluetoothDevice(  457): Command sent successfully:CONNECT Address:F0:65:DD:40:36:93 Profile:HEADSET
 android.bluetooth.headset.profile.action.CONNECTION_STATE_CHANGED
12-10 18:57:24.600 D/CachedBluetoothDevice(  457): onProfileStateChanged: profile HEADSET newProfileState 1
12-10 18:57:24.660 D/Bluetooth HSHFP(  395): RFCOMM connection attempt took 139 ms
12-10 18:57:24.660 D/Bluetooth HSHFP(  395): Rfcomm connected
12-10 18:57:24.660 D/Bluetooth HSHFP(  395): Device: F0:65:DD:40:36:93 Headset  state1 -> 2
12-10 18:57:24.670 I/BluetoothProfileState(  236): Message:Entering Stable State
12-10 18:57:24.680 D/Bluetooth HSHFP(  395): Saved priority F0:65:DD:40:36:93 = 1000
12-10 18:57:24.690 D/BluetoothService(  236): CONNECTION_STATE_CHANGE: F0:65:DD:40:36:93: 1 -> 2
12-10 18:57:24.720 V/BluetoothEventManager(  457): Received android.bluetooth.headset.profile.action.CONNECTION_STATE_CHANGED
12-10 18:57:24.730 D/CachedBluetoothDevice(  457): onProfileStateChanged: profile HEADSET newProfileState 2
12-10 18:57:24.770 I/BluetoothDeviceProfileState(  236): Entering ACL Connected state with: 102

Android only take 1 second to finish RFCOMM connection after receive Paired.

Comment 18

[Eric Chou [:ericchou] [:echou]]

(In reply to Xinhe Yan from comment #16)
> (In reply to Xinhe Yan from comment #9)
> > It took 5 seconds to connect HFP. But hci connect already timeout.
> I found gaia bluetooth.js will take 5 seconds to connect HFP.
> 
> // if the device has to be connected when it just paired
> // wait for a while so they can have time to communicate
> // their connection protocol
> if (device.address === connectingAddress &&
>   device.icon === 'audio-card') {
> var small = aItem.querySelector('small');
> l10n.localize(small, 'device-status-connecting');
> setTimeout(function() {
> setDeviceConnect(device);
> }, 5000);
> }
> 
> After change 5000 to 1000, BH105 can connect HFP.
> Maybe we need to decrease wait time.

This shouldn't be the root cause. According to what you mentioned in comment 9 and comment 16, it seems that the bluetooth stack or kernel used on your device would stop the connecting process after a short period of time for some reason.

In the log Viral attached, the remote device (Nokia BH105) responded to our authentication request with "Error: PIN or Key Missing" even after link key was just created. Even though, I think Gecko/Gaia are able to deal with this situation without any problem. Xinhe, could you assist with confirming that there is no restrictions such as "cannot create link key again few seconds after the previous one just created" in the bt stack you're using?

Comment 19

[Xinhe Yan]

(In reply to Eric Chou [:ericchou] [:echou] from comment #18)
> In the log Viral attached, the remote device (Nokia BH105) responded to our
> authentication request with "Error: PIN or Key Missing" even after link key
> was just created. Even though, I think Gecko/Gaia are able to deal with this
> situation without any problem. Xinhe, could you assist with confirming that
> there is no restrictions such as "cannot create link key again few seconds
> after the previous one just created" in the bt stack you're using?
Broadcom has sames bug. So I think there was no such restriction. 
I already ask our PS engineer to check this. I will get feedback in one or two days.

Comment 20

[Xinhe Yan]

(In reply to Eric Chou [:ericchou] [:echou] from comment #18)
> In the log Viral attached, the remote device (Nokia BH105) responded to our
> authentication request with "Error: PIN or Key Missing" even after link key
> was just created. Even though, I think Gecko/Gaia are able to deal with this
> situation without any problem. Xinhe, could you assist with confirming that
> there is no restrictions such as "cannot create link key again few seconds
> after the previous one just created" in the bt stack you're using?
This is feedback from beken.
When pair with one device, on link key will generate. After that, pair with this device will delete stored link key and regenerate. If pair with other device, another link key will be generate.

Comment 21

[Eric Chou [:ericchou] [:echou]]

(In reply to Xinhe Yan from comment #20)
> (In reply to Eric Chou [:ericchou] [:echou] from comment #18)
> > In the log Viral attached, the remote device (Nokia BH105) responded to our
> > authentication request with "Error: PIN or Key Missing" even after link key
> > was just created. Even though, I think Gecko/Gaia are able to deal with this
> > situation without any problem. Xinhe, could you assist with confirming that
> > there is no restrictions such as "cannot create link key again few seconds
> > after the previous one just created" in the bt stack you're using?
> This is feedback from beken.
> When pair with one device, on link key will generate. After that, pair with
> this device will delete stored link key and regenerate. If pair with other
> device, another link key will be generate.

Yes, I think we all knew that. The problem still can't be explained by this feedback. Please note that the hcidump log told us that PIN code request was firing through HCI at the end of log - then no other hci commands or events afterwards. However, your observation told us that the connect session was terminated for unknown reason, and that's the problem.

Since this could be fixed by decreasing the time of waiting-to-connect period after a device is paired, I'd recommend landing that solution on gaia 1.2f branch. Meanwhile, we should still take time to figure out the root cause.

Comment 22

[Xinhe Yan]

(In reply to Eric Chou [:ericchou] [:echou] from comment #21)
> Since this could be fixed by decreasing the time of waiting-to-connect
> period after a device is paired, I'd recommend landing that solution on gaia
> 1.2f branch. Meanwhile, we should still take time to figure out the root
> cause.
It is not block bug now. We can wait few weeks to find out root cause.

Our PS engineer gave some hints.

fugu
2013-12-10 06:24:36.966158 < HCI Command: IO Capability Request Reply (0x01|0x002b) plen 9
    bdaddr F0:65:DD:40:36:93 capability 0x01 oob 0x00 auth 0x03
    Capability: DisplayYesNo (OOB data not present)
    Authentication: Dedicated Bonding (MITM Protection)
2013-12-10 06:24:36.967351 > HCI Event: Command Complete (0x0e) plen 10
    IO Capability Request Reply (0x01|0x002b) ncmd 1
    status 0x00 bdaddr F0:65:DD:40:36:93
2013-12-10 06:24:37.021148 > HCI Event: IO Capability Response (0x32) plen 9
    bdaddr F0:65:DD:40:36:93 capability 0x03 oob 0x00 auth 0x02
    Capability: NoInputNoOutput (OOB data not present)
    Authentication: Dedicated Bonding (No MITM Protection)

2013-12-10 06:24:45.981426 < HCI Command: IO Capability Request Reply (0x01|0x002b) plen 9
    bdaddr F0:65:DD:40:36:93 capability 0x01 oob 0x00 auth 0x04
    Capability: DisplayYesNo (OOB data not present)
    Authentication: General Bonding (No MITM Protection)
2013-12-10 06:24:45.982666 > HCI Event: Command Complete (0x0e) plen 10
    IO Capability Request Reply (0x01|0x002b) ncmd 1
    status 0x00 bdaddr F0:65:DD:40:36:93
    2013-12-10 06:24:46.011040 > HCI Event: IO Capability Response (0x32) plen 9
    bdaddr F0:65:DD:40:36:93 capability 0x03 oob 0x00 auth 0x04
    Capability: NoInputNoOutput (OOB data not present)
    Authentication: General Bonding (No MITM Protection)

hamachi
2013-06-05 06:05:44.176009 < HCI Command: IO Capability Request Reply (0x01|0x002b) plen 9
    bdaddr F0:65:DD:40:36:93 capability 0x01 oob 0x00 auth 0x03
    Capability: DisplayYesNo (OOB data not present)
    Authentication: Dedicated Bonding (MITM Protection)
2013-06-05 06:05:44.176654 > HCI Event: Command Complete (0x0e) plen 10
    IO Capability Request Reply (0x01|0x002b) ncmd 1
    status 0x00 bdaddr F0:65:DD:40:36:93
2013-06-05 06:05:44.182519 > HCI Event: IO Capability Response (0x32) plen 9
    bdaddr F0:65:DD:40:36:93 capability 0x03 oob 0x00 auth 0x02
    Capability: NoInputNoOutput (OOB data not present)
    Authentication: Dedicated Bonding (No MITM Protection)

2013-06-05 06:05:51.970506 < HCI Command: IO Capability Request Reply (0x01|0x002b) plen 9
    bdaddr F0:65:DD:40:36:93 capability 0x01 oob 0x00 auth 0x03
    Capability: DisplayYesNo (OOB data not present)
    Authentication: Dedicated Bonding (MITM Protection)
2013-06-05 06:05:51.973188 > HCI Event: Command Complete (0x0e) plen 10
    IO Capability Request Reply (0x01|0x002b) ncmd 1
    status 0x00 bdaddr F0:65:DD:40:36:93
2013-06-05 06:05:51.976954 > HCI Event: IO Capability Response (0x32) plen 9
    bdaddr F0:65:DD:40:36:93 capability 0x03 oob 0x00 auth 0x02
    Capability: NoInputNoOutput (OOB data not present)
    Authentication: Dedicated Bonding (No MITM Protection)

fugu receive General Bonding not Dedicated Bonding the second time.
I will add some logs to trace the reason.

Comment 23

[Shawn Huang [:shawnjohnjr][:shuang] (as a happy gecko contributor)]

Any update?

Comment 24

[Xinhe Yan]

Sorry, no new information. This bug is a low priority bug. Tarako wireless chip has more high priority.

Comment 25

[Xinhe Yan]

I test on tarako. Cannot connect Nokia BH105 and jabra easygo.

I also test on sp8810 sp7710 sp6821 with broadcom\beken\trout. They both work good on android.
unfortunately they cannot work on firefox.

Our bluez engineer will check this on our side.

Shawn, can you find jabra easygo in Taipei?

Comment 26

[Shawn Huang [:shawnjohnjr][:shuang] (as a happy gecko contributor)]

I just order one jabra easygo and will arrive on Monday. But I cannot confirm the connection problem you mentioned on BH105 and easygo are the same, we need more information to analyze.

Comment 27

[Shawn Huang [:shawnjohnjr][:shuang] (as a happy gecko contributor)]

I can't even pair with Jabra EasyGo. Can you confirm this is the same problem that you observed? Need to confirm it's 'connection' or 'pair' problem.
 
HCI sniffer - Bluetooth packet analyzer ver 2.0
device: hci0 snap_len: 1028 filter: 0xffffffff
< HCI Command: Create Connection (0x01|0x0005) plen 13
    bdaddr 1C:48:F9:3C:64:7F ptype 0xcc18 rswitch 0x01 clkoffset 0x5754 (valid)
    Packet type: DM1 DM3 DM5 DH1 DH3 DH5 
> HCI Event: Command Status (0x0f) plen 4
    Create Connection (0x01|0x0005) status 0x00 ncmd 1
> HCI Event: Connect Complete (0x03) plen 11
    status 0x00 handle 50 bdaddr 1C:48:F9:3C:64:7F type ACL encrypt 0x00
< HCI Command: Read Remote Supported Features (0x01|0x001b) plen 2
    handle 50
> HCI Event: Command Status (0x0f) plen 4
    Read Remote Supported Features (0x01|0x001b) status 0x00 ncmd 1
> HCI Event: Max Slots Change (0x1b) plen 3
    handle 50 slots 5
> HCI Event: Read Remote Supported Features (0x0b) plen 11
    status 0x00 handle 50
    Features: 0xff 0xff 0x8b 0xfe 0x98 0xff 0x59 0x83
< HCI Command: Read Remote Extended Features (0x01|0x001c) plen 3
    handle 50 page 1
> HCI Event: Command Status (0x0f) plen 4
    Read Remote Extended Features (0x01|0x001c) status 0x00 ncmd 1
< HCI Command: Change Connection Packet Type (0x01|0x000f) plen 4
    handle 50 ptype 0xcc18
    Packet type: DM1 DM3 DM5 DH1 DH3 DH5 
> HCI Event: Command Status (0x0f) plen 4
    Change Connection Packet Type (0x01|0x000f) status 0x00 ncmd 1
> HCI Event: Connection Packet Type Changed (0x1d) plen 5
    status 0x00 handle 50 ptype 0xcc18
    Packet type: DM1 DM3 DM5 DH1 DH3 DH5 
> HCI Event: Read Remote Extended Features (0x23) plen 13
    status 0x00 handle 50 page 1 max 1
    Features: 0x01 0x00 0x00 0x00 0x00 0x00 0x00 0x00
< HCI Command: Remote Name Request (0x01|0x0019) plen 10
    bdaddr 1C:48:F9:3C:64:7F mode 2 clkoffset 0x0000
> HCI Event: Command Status (0x0f) plen 4
    Remote Name Request (0x01|0x0019) status 0x00 ncmd 1
> HCI Event: Remote Name Req Complete (0x07) plen 255
    status 0x00 bdaddr 1C:48:F9:3C:64:7F name 'JABRA EASYGO'
< HCI Command: Authentication Requested (0x01|0x0011) plen 2
    handle 50
> HCI Event: Command Status (0x0f) plen 4
    Authentication Requested (0x01|0x0011) status 0x00 ncmd 1
> HCI Event: Link Key Request (0x17) plen 6
    bdaddr 1C:48:F9:3C:64:7F
< HCI Command: Link Key Request Negative Reply (0x01|0x000c) plen 6
    bdaddr 1C:48:F9:3C:64:7F
> HCI Event: Command Complete (0x0e) plen 10
    Link Key Request Negative Reply (0x01|0x000c) ncmd 1
    status 0x00 bdaddr 1C:48:F9:3C:64:7F
> HCI Event: IO Capability Request (0x31) plen 6
    bdaddr 1C:48:F9:3C:64:7F
< HCI Command: IO Capability Request Reply (0x01|0x002b) plen 9
    bdaddr 1C:48:F9:3C:64:7F capability 0x01 oob 0x00 auth 0x03
    Capability: DisplayYesNo (OOB data not present)
    Authentication: Dedicated Bonding (MITM Protection)
> HCI Event: Command Complete (0x0e) plen 10
    IO Capability Request Reply (0x01|0x002b) ncmd 1
    status 0x00 bdaddr 1C:48:F9:3C:64:7F
> HCI Event: IO Capability Response (0x32) plen 9
    bdaddr 1C:48:F9:3C:64:7F capability 0x03 oob 0x00 auth 0x02
    Capability: NoInputNoOutput (OOB data not present)
    Authentication: Dedicated Bonding (No MITM Protection)
> HCI Event: User Confirmation Request (0x33) plen 10
    bdaddr 1C:48:F9:3C:64:7F passkey 140355
< HCI Command: User Confirmation Request Reply (0x01|0x002c) plen 6
    bdaddr 1C:48:F9:3C:64:7F
> HCI Event: Command Complete (0x0e) plen 10
    User Confirmation Request Reply (0x01|0x002c) ncmd 1
    status 0x00 bdaddr 1C:48:F9:3C:64:7F
> HCI Event: Simple Pairing Complete (0x36) plen 7
    status 0x05 bdaddr 1C:48:F9:3C:64:7F
    Error: Authentication Failure
> HCI Event: Auth Complete (0x06) plen 3
    status 0x05 handle 50
    Error: Authentication Failure
< HCI Command: Disconnect (0x01|0x0006) plen 3
    handle 50 reason 0x13
    Reason: Remote User Terminated Connection
> HCI Event: Command Status (0x0f) plen 4
    Disconnect (0x01|0x0006) status 0x00 ncmd 1
> HCI Event: Disconn Complete (0x05) plen 4
    status 0x00 handle 50 reason 0x16
    Reason: Connection Terminated by Local Host

Comment 28

[Xinhe Yan]

(In reply to Shawn Huang [:shuang] [:shawnjohnjr] from comment #27)
> I can't even pair with Jabra EasyGo. Can you confirm this is the same
> problem that you observed? Need to confirm it's 'connection' or 'pair'
> problem.

It is the same problem as what i saw.
In most time, can not pair with Jabra EasyGo.
Only one time, can pair with Jabra EasyGo. But connect will fail.

Comment 29

[Shawn Huang [:shawnjohnjr][:shuang] (as a happy gecko contributor)]

This bug also can be reproduced on buri (gecko/gaia with v1.3). So we would take care of this bug first.

Comment 30

[Shawn Huang [:shawnjohnjr][:shuang] (as a happy gecko contributor)]

Note: This bug cannot be reproduced on Nexus4/Nexus5 which uses bluedroid as stack.

Comment 31

[Shawn Huang [:shawnjohnjr][:shuang] (as a happy gecko contributor)]

(In reply to Xinhe Yan from comment #28)
> (In reply to Shawn Huang [:shuang] [:shawnjohnjr] from comment #27)
> > I can't even pair with Jabra EasyGo. Can you confirm this is the same
> > problem that you observed? Need to confirm it's 'connection' or 'pair'
> > problem.
> 
> It is the same problem as what i saw.
> In most time, can not pair with Jabra EasyGo.
> Only one time, can pair with Jabra EasyGo. But connect will fail.
Hello Xinhe,
I've tried to digging into this bug, and I found the failure required to prove from Bluetooth stack level. As you see log from Comment 27, this is SSP just work pairing (DisplayYesNo/DisplayYesNo), and bluetooth stack would handle it by itself, gecko don't take further action until pairing complete results return. From my point of view, nothing bluez pass by until pairing completed but HCI error code 'Authentication Failure', as you can see pairing failure return directly from stack. Since we don't have air sniffer to analyze this bug further.
By the way, please don't pair while 'Scan', I found the fail rate is higher.
This might need your bluetooth stack team provides frontline air sniffer trace to prove authentication error.

Comment 32

[Shawn Huang [:shawnjohnjr][:shuang] (as a happy gecko contributor)]

(In reply to Shawn Huang [:shuang] [:shawnjohnjr] from comment #31)
> (In reply to Xinhe Yan from comment #28)
> > (In reply to Shawn Huang [:shuang] [:shawnjohnjr] from comment #27)
> I've tried to digging into this bug, and I found the failure required to
> prove from Bluetooth stack level. As you see log from Comment 27, this is
> SSP just work pairing (DisplayYesNo/DisplayYesNo), and bluetooth stack would
Sorry for typo, it shall be (Initiator: DisplayYesNo, Responder:NoInputNoOutput).

Comment 33

[Shawn Huang [:shawnjohnjr][:shuang] (as a happy gecko contributor)]

Any update? I need air sniffer log to clarify this bug.

Comment 34

[Shawn Huang [:shawnjohnjr][:shuang] (as a happy gecko contributor)]

I will take this bug until Comment 31 had been clarified.

Comment 35

[James Zhang (Spreadtrum)]

Xinhe, please check it, can we close this bug after we upgrade new trout drvier?

Comment 36

[Xinhe Yan]

E/GeckoBluetooth(   84): AgentEventFilter: AgentEventFilter: /B2G/bluetooth/agen
t, RequestPairingConsent
E/GeckoBluetooth(   84): AgentEventFilter: [AgentEventFilter] ignore /B2G/blueto
oth/agent :Unhandled event
E/GeckoBluetooth(   84): AgentEventFilter: AgentEventFilter: /B2G/bluetooth/agen
t, RequestPairingConsent

Hi Shawn,
Our bluez engineer think gecko should handle this event. But we are not sure about this.
What do you think?

Comment 37

[Shawn Huang [:shawnjohnjr][:shuang] (as a happy gecko contributor)]

(In reply to Xinhe Yan from comment #36)
> E/GeckoBluetooth(   84): AgentEventFilter: AgentEventFilter:
> /B2G/bluetooth/agen
> t, RequestPairingConsent
> E/GeckoBluetooth(   84): AgentEventFilter: [AgentEventFilter] ignore
> /B2G/blueto
> oth/agent :Unhandled event
> E/GeckoBluetooth(   84): AgentEventFilter: AgentEventFilter:
> /B2G/bluetooth/agen
> t, RequestPairingConsent
> 
> Hi Shawn,
> Our bluez engineer think gecko should handle this event. But we are not sure
> about this.
> What do you think?

Yes. Gecko should handle this event for consent case and directly call PairingConfirmation, Gecko missed implement this part, but it's a different case. I opened a bug 997626 for fixing this missing part. This is a gecko bug for sure.

However, this still does not answer as Comment 27 shows, pairing initiator is b2g phone. We can experience pairing failure during discovery easily.

Regarding consent case you mentioned shall follow conditions:
1. Local IO capabilities are DisplayYesNo and remote IO capabiltiies are DisplayOnly 
or NoInputNoOutput ---> Matched this bug STR
2. Call PairingConsent callback for "incoming" requests. ----> This does not match as we discuss in Comment 27 (outing pairing), it shall only valid for 'incoming'

It's not usual for Bluetooth headset to initialize pairing.

See both: 
external/bluetooth/bluez/plugins/hciops.c:1184
external/bluetooth/bluedroid/btif_dm.c:736

Please feel free to correct me.

Comment 38

[Xinhe Yan]

(In reply to Shawn Huang [:shuang] [:shawnjohnjr] from comment #37)
> (In reply to Xinhe Yan from comment #36)
> > E/GeckoBluetooth(   84): AgentEventFilter: AgentEventFilter:
> > /B2G/bluetooth/agen
> > t, RequestPairingConsent
> > E/GeckoBluetooth(   84): AgentEventFilter: [AgentEventFilter] ignore
> > /B2G/blueto
> > oth/agent :Unhandled event
> > E/GeckoBluetooth(   84): AgentEventFilter: AgentEventFilter:
> > /B2G/bluetooth/agen
> > t, RequestPairingConsent
> > 
> > Hi Shawn,
> > Our bluez engineer think gecko should handle this event. But we are not sure
> > about this.
> > What do you think?
> 
> Yes. Gecko should handle this event for consent case and directly call
> PairingConfirmation, Gecko missed implement this part, but it's a different
> case. I opened a bug 997626 for fixing this missing part. This is a gecko
> bug for sure.
> 
> However, this still does not answer as Comment 27 shows, pairing initiator
> is b2g phone. We can experience pairing failure during discovery easily.
> 
> Regarding consent case you mentioned shall follow conditions:
> 1. Local IO capabilities are DisplayYesNo and remote IO capabiltiies are
> DisplayOnly 
> or NoInputNoOutput ---> Matched this bug STR
> 2. Call PairingConsent callback for "incoming" requests. ----> This does not
> match as we discuss in Comment 27 (outing pairing), it shall only valid for
> 'incoming'
> 
> It's not usual for Bluetooth headset to initialize pairing.
Unfornatelly,this happed in BH105.

gecko send pair request by dbus. This is outing pairing. Except that, other cases should be treat as incoming pairing. 

Nokia BH105 different from other headset. Disconnct headset and reconnct. Link key missing, need create link key again.
HCI recieve io capability request. This can be seen as incoming pairing.

Android handle RequestPairingConsent and gecko no. Our bluez engineer think that is why tarako failed.

Comment 39

[Shawn Huang [:shawnjohnjr][:shuang] (as a happy gecko contributor)]

(In reply to Xinhe Yan from comment #38)
> 
> Nokia BH105 different from other headset. Disconnct headset and reconnct.
> Link key missing, need create link key again.
> HCI recieve io capability request. This can be seen as incoming pairing.
> 
> Android handle RequestPairingConsent and gecko no. Our bluez engineer think
> that is why tarako failed.
Thanks for clarification. Then it's clear we will fix RequestPairingConsent (bug 997626) and patch ready ETA will be April 21 and land on April 22 for 1.3T.

Comment 40

[Shawn Huang [:shawnjohnjr][:shuang] (as a happy gecko contributor)]

(In reply to Xinhe Yan from comment #38) 
> Nokia BH105 different from other headset. Disconnct headset and reconnct.
> Link key missing, need create link key again.
> HCI recieve io capability request. This can be seen as incoming pairing.
> 
> Android handle RequestPairingConsent and gecko no. Our bluez engineer think
> that is why tarako failed.
Can you confirm that Jabra EasyGo with the same reason? If it's not, we can only focus on consent pairing. And ignore Jabra Easygo, because based on my test results, Easygo headset does not apply the same reason. If so, please raise 1.3T+ consideration for Bug 997626.

Comment 41

[Xinhe Yan]

Our bluez had a bug. You need set 'visible to all' in setting. This is a sprd bug. We need send visible to prevent controller sleep. This bug already fixed in our side.
When I report this bug, I did not find the root cause. Sorry about that.

For Nokia BH105, I found patch in 997626 can fix this bug. I will ask 1.3t+ for 997626.

Comment 42

[Xinhe Yan]

Close this bug.