849101 - [Bluetooth]one device unpair file transfer

Status: VERIFIED FIXED

(Firefox OS Graveyard :: Gaia::Bluetooth, defect, P1)

Description

[leo.bugzilla.gecko]

Step:
pairng > 1, 2 case 

1. FFOS device unpair
- Other devices in the device to FFOS during file transfer has been successfully transmitted.
2. other device unpair
- When transferring files to other devices from the device FFOS other devices, the pair request may rise FFOS device no response.

Please, this issue check.
Thanks.

Comment 1

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

I'm sorry, I still cannot fully understand the steps. Can you explain it again? And can you provide hcidump trace? Please refer to https://wiki.mozilla.org/B2G/Bluetooth
hcidump log

    hcidump is a tool for Bluetooth protocol analysis.
    If you're using release build, hcidump would not be included. Please refer to Bug 828810 comment 7 for the step-by-step about how to get hcidump from release build.
    Take the following steps to get hcidump log:
        1. Turn on Bluetooth
        2 - 1. For headset/car kit issues, please enter adb shell hcidump --ascii -t > hcidump.txt
        2 - 2. For file transferring and other issues, please enter adb shell hcidump --hex -t > hcidump.txt
        3. Do the test
        4. Attach hcidump.txt to the bug

Comment 2

[leo.bugzilla.gecko]

step-by-step
1. Turn on Bluetooth
2. B device and pair
3. A device unpair
4. Request file to the B devices in the A device

Expected reaction
 - The pairing request after a connection attempt

Result reaction
 - A device pair request
 - B devices stop

please one more isuue check.

Comment 3

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

Can you clarify "A" device and "B" device are? Are they both FFOS device? I cannot reproduce issues using two FFOS devices.

Comment 4

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

Information from reporter:
Phone1(FFOS) and Phone2(FFOS) are paired.
In paired list of Phone1, unpair phone2.
Then the paired list does not exist in Phone1, but Phone2 remain paired list.
In that state, Phone2 send image file to Phone1 via bluetooth opp.
Then pairing request popup is shown in Phone1, because PIN or Key Missing and try again Link Key Request.
In this case, Phone2 is locked up! Cannot any touch and action.
After 10 seconds, authentication failure occurs and lockup solved.
I think it would be easily reproducible.

In another example between android phones, it works well.

Comment 5

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

119	Event			User Confirmation Request					10	13	 00:00:00.329852	2013/3/26  04:39:17.307836	

120	Event			Simple Pairing Complete	Authentication Failure				7	10	 00:00:30.200820	2013/3/26  04:39:47.508656	

From the packet 119 to 120, it took 30 seconds, it looks like authentication fail due to timeout. I guess somehow here, pairing stuck at Phone2.

Comment 6

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

I think there are some differences at your environment and our developing phone (unagi).
This is why we cannot reproduce issue.
The reason as following:
Following your statement and trace, I can see the second-round pairing process, it goes through "numeric comparison".
However, our developing phone behaves differently, it directly goes "just work", which does not require to show up numeric comparison.
So things can continually work fine under "just work" condition.

Comment 7

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

Settings application does not receive RequestConfirmation request, which causes "Confirm" dialog missing, it could results "Authentification Failure" due to 30 seconds timeout.

Comment 8

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

Interesting thing which is not about the root cause but worth mentioned that is the same BluetoothOppManager which creates RFCOMM socket with LM_AUTH, LM_ENCRYPT option through BluetoothUnixSocketConnector.
On different platforms, different results.
Unagi to Unagi, is to have MITM Protection Not Required-General Bonding. Numberic comparision with auto accept allowed for both sides, which is "just work".
But on other b2g devices, which is MITM Protection Required-Dedicated bonding, use IO capabilities to determine authentication (DisplayYesNo both sides), which is "numeric comparision".

Comment 9

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

Note: This bug cannot be reproduced on unagi. But it seems cannot be reproudced on reporter's phone.

Comment 10

[Andrew Overholt [:overholt]]

Shawn, can you try again once you have access to a device like the reporter's device?

Comment 11

[leo.bugzilla.gecko]

Dear Mozilla,

I think that this issue is reproduced in our phone.
Becease our phone is shown "numeric comparision" as Shawn's comment.

But it is issue that the screen is stuck during about 10 second, because if the screen is not stuck, pairing request popup is shown and I could continue to proceed next step.

To help you understand, I'll send the reproduced movie to Shawn.
Please check it.

Thanks.

Comment 12

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

Confirmed this issue is 100% reproducible. Similar problem can be observed on Bug 854846, which also happened with Mac OS. Currently we found SystemMessage were not been received by Setting application, it leads Pairing Confirmation dialog missing, so user cannot confirm pairing request. One doubt is that maybe Setting application was not even be launched when SystemMessage sent.

Comment 13

[(inactive after 6/18) Alive Kuo [:alive]]

Shawn, you could deliver this issue to me if you think it's a gaia bug.

Comment 14

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

Hi Alive,
I've delivered to you, since I cannot see anything we can do for gecko bluetooth. Feel free if you need my help.

Comment 15

[(inactive after 6/18) Alive Kuo [:alive]]

I'd updated some info in https://bugzilla.mozilla.org/show_bug.cgi?id=854846#c9

Comment 16

[Arthur Chen [:arthurcc][inactive after 6/30]]

steal the bug.

Comment 17

[Arthur Chen [:arthurcc][inactive after 6/30]]

Info updated in https://bugzilla.mozilla.org/show_bug.cgi?id=854846#c12.

Comment 18

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

This bug depends on Bug 854846. I will confirm again after Bug 854846 patch landed.

Comment 19

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

Root cause:
A blocking call (connect) on IO thread in unixsocket. If the pairing confirmation window which is a iframe is also loaded in IO thread, then it might be blocked by the blocking call of connect.

Comment 20

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

Close this since bug 854846 is fixed and landed. Feel free to reopen if bug still can be reproduced.

Comment 21

[Walter Chen[:ypwalter][:wachen]]

https://moztrap.mozilla.org/manage/case/8459/

Comment 22

[Walter Chen[:ypwalter][:wachen]]

I created the test cases. This should be +

Comment 23

[Parul Mathur]

Executed test case https://moztrap.mozilla.org/manage/case/8459/ where 
FFOS Device: leo phone
Other Device: unagi phone

Verified that the bug has been fixed on: 
Device: Leo phone 
Build Identifier: 20130611074722
Update channel: leo/1.1.0/nightly
Gecko: http://hg.mozilla.org/releases/mozilla-b2g18/rev/8d0562d20324
Gaia: 8c64e19b82d4e0490a7780232d3d6bd07d0ba9ec1370937291
Git commit info: 2013-06-11 07:54:51 
OS version: 1.1.0.0-prerelease