1003552 - [B2G][Bluetooth][Open_C] Active Bluetooth devices are not always found or able to be discovered.

Status: RESOLVED WONTFIX

(Firefox OS Graveyard :: Vendcom, defect)

Description

[Lionel Mauritson]

Attachment: Bluetooth4.zip

Description:
When searching for devices not all active devices are found or able to be found if they are activated after the search has begun. The Open_C device appears to stop searching after the first few seconds.

Repro Steps:
1) Update a Open_C to BuildID: 20140428000206
2) Enable Bluetooth on two devices, but do not enable the "Visible" switch.
3) Begin a search on Device A
4) Enable the "Visible" switch on Device B after a couple seconds.

Actual:
Device B is not always found by Device A.
Or
Device B is found by Device A, but usually after a significant amount of time / multiple attempts.

Expected:
Device B is found quickly by Device A.

1.4F Environmental Variables:
Device: Open_C 1.4F
BuildID: 20140428000206
Gaia: d23e479e8a4ce0bc620acb2d7e2f82801aa4d0ea
Gecko: 36f67ce46855
Version: 30.0a2
Firmware Version: P821A10-ENG_20140410

Note: Related to Bug 911950

Repro frequency: 75%
Link to failed test case:
See attached: http://youtu.be/k09y1TVoWOE and logcat

Comment 1

[Lionel Mauritson]

Using a Buri 1.4 the search is much faster and devices are found more easily.

1.4 Environmental Variables:
Device: Buri 1.4 MOZ
BuildID: 20140428000206
Gaia: d23e479e8a4ce0bc620acb2d7e2f82801aa4d0ea
Gecko: 36f67ce46855
Version: 30.0a2
Firmware Version: v1.2-device.cfg

Comment 2

[Jason Smith [:jsmith]]

Does this reproduce on a 1.3 Open C base image?

Comment 3

[Jocelyn Liu [:jocelyn] [:joliu]]

Hi Lionel,

I have try to reproduce on 1.3 and 1.4 openc and couldn't reproduce the bug.
Could you please provide hcidump with timestamp from your end?
Besides, please also let me know the bluetooth address of the device that supposed to be found.

Thanks,
Jocelyn

Comment 4

[Lionel Mauritson]

Attachment: hcidump.txt

Bluetooth Address of device
24:0A:11:7E:5B:50

Log attached

Comment 5

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

(In reply to Lionel Mauritson from comment #1)
> Using a Buri 1.4 the search is much faster and devices are found more easily.
> 
> 1.4 Environmental Variables:
> Device: Buri 1.4 MOZ
> BuildID: 20140428000206
> Gaia: d23e479e8a4ce0bc620acb2d7e2f82801aa4d0ea
> Gecko: 36f67ce46855
> Version: 30.0a2
> Firmware Version: v1.2-device.cfg

Buri is ICS-based and use different version of bluez stack, we saw different behavior on OpenC. OpenC uses JB-based bluez stack from CAF. See also bug 1005754.

Comment 6

[Lionel Mauritson]

On the 1.3 Base image for the Open_C Bluetooth devices are found much more quickly.

Comment 7

[Jason Smith [:jsmith]]

Does this reproduce on Flame?

Comment 8

[Lionel Mauritson]

Testing on the latest 1.4 Flame build there were no issues detecting nearby Bluetooth devices in a timely manner.

Device: Flame 1.4 
BuildID: 20140515000202
Gaia: 2e97bee6bb79d3577dba1bf2a1bbfcba64ee99ab
Gecko: 0cb91945f404
Version: 30.0
Firmware Version: v10F-3

Comment 9

[Jason Smith [:jsmith]]

So this is specific to the Open C on 1.4.

Do you think this is a vendor bug or a legitimate Bluetooth bug on our side?

Comment 10

[Jocelyn Liu [:jocelyn] [:joliu]]

It's more like a vendor bug to me, since I flashed gecko/gaia 1.4 from pvt into my Open C, but couldn't reproduce this bug.
And from the hcidump log that Lionel attached,
2014-05-09 12:14:37.000440 > HCI Event: Command Complete (0x0e) plen 4
    LE Set Scan Parameters (0x08|0x000b) ncmd 1
    status 0x00
...
2014-05-09 12:14:44.265078 < HCI Command: Inquiry Cancel (0x01|0x0002) plen 0

an inquiry cancel was sent before timeout, which is not the expected behavior.
In bug1005754, there's also an unexpected inquiry cancel, and was not triggered by gecko.
I suspect that this is also caused by stack level code.

We need ventor to check in bluez stack level that why the inquiry cancel will be requested on openC device.
Yang, besides bug1005754, could you please also check this one from the stack level?

Thanks,
Jocelyn

Comment 11

[Jason Smith [:jsmith]]

Moving back to qawanted as the above analysis is concluding that this probably is present on 1.3 as well.

Comment 12

[Lionel Mauritson]

On the 1.3 Base image for the Open_C Bluetooth devices are found much more quickly.

Device: Open_C 1.3 
BuildID: 20140505052400
Version: 28.0
Firmware Version: P821A10V1.0.0B06_LOG_DL

Comment 13

[Lionel Mauritson]

Additional: 
When compared to other devices I would still consider it a little on the slow side, but the search was faster than when on a 1.4 build.
The flame will find the same device within seconds while the Open_C may take up to 10 seconds but will eventually find the device. On 1.4 Open_C the device may never be found even after multiple attempts.

My apologies for the split comment.

Comment 14

[Jason Smith [:jsmith]]

Moving to vendcom then per the above comments.

Comment 15

[Jocelyn Liu [:jocelyn] [:joliu]]

Clear the needinfo request since this bug already moved to vendcom.

Comment 16

[Ben Tian (inactive)]

De-assign owner from Jocelyn since this bug is Vendcom problem.

Comment 17

[BMO Automation]

Firefox OS is not being worked on