Closed Bug 849101 Opened 8 years ago Closed 7 years ago

[Bluetooth]one device unpair file transfer


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

Gonk (Firefox OS)


(blocking-b2g:leo+, b2g18 verified)

1.1 QE2 (6jun)
blocking-b2g leo+
Tracking Status
b2g18 --- verified


(Reporter: leo.bugzilla.gecko, Assigned: shawnjohnjr)



(Whiteboard: [status:depends on 854846][target:5/17])

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.
Assignee: nobody → shuang
I'm sorry, I still cannot fully understand the steps. Can you explain it again? And can you provide hcidump trace? Please refer to
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
Flags: needinfo?(leo.bugzilla.gecko)
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.
Flags: needinfo?(leo.bugzilla.gecko)
Can you clarify "A" device and "B" device are? Are they both FFOS device? I cannot reproduce issues using two FFOS devices.
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.
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.
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.
Settings application does not receive RequestConfirmation request, which causes "Confirm" dialog missing, it could results "Authentification Failure" due to 30 seconds timeout.
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".
Note: This bug cannot be reproduced on unagi. But it seems cannot be reproudced on reporter's phone.
blocking-b2g: --- → leo?
Shawn, can you try again once you have access to a device like the reporter's device?
Flags: needinfo?(shuang)
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.

Depends on: 854846
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.
Flags: needinfo?(shuang)
blocking-b2g: leo? → ---
blocking-b2g: --- → leo?
blocking-b2g: leo? → leo+
Shawn, you could deliver this issue to me if you think it's a gaia bug.
Assignee: shuang → alive
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.
steal the bug.
Assignee: alive → arthur.chen
Assignee: arthur.chen → shuang
Target Milestone: --- → 1.1 QE2
This bug depends on Bug 854846. I will confirm again after Bug 854846 patch landed.
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.
Whiteboard: [status:depends on 854846][target:5/17]
Priority: -- → P1
Close this since bug 854846 is fixed and landed. Feel free to reopen if bug still can be reproduced.
Closed: 7 years ago
Resolution: --- → FIXED
Flags: in-moztrap?
Flags: in-moztrap? → in-moztrap-
I created the test cases. This should be +
Flags: in-moztrap- → in-moztrap+
Executed test case 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
Gaia: 8c64e19b82d4e0490a7780232d3d6bd07d0ba9ec1370937291
Git commit info: 2013-06-11 07:54:51 
OS version:
You need to log in before you can comment on or make changes to this bug.