Closed Bug 849101 Opened 8 years ago Closed 7 years ago
[Bluetooth]one device unpair file transfer
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.
8 years ago
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 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
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.
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.
8 years ago
blocking-b2g: --- → leo?
Shawn, can you try again once you have access to a device like the reporter's device?
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.
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.
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.
I'd updated some info in https://bugzilla.mozilla.org/show_bug.cgi?id=854846#c9
steal the bug.
Assignee: alive → arthur.chen
Info updated in https://bugzilla.mozilla.org/show_bug.cgi?id=854846#c12.
Assignee: arthur.chen → shuang
Target Milestone: --- → 1.1 QE2
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]
Close this since bug 854846 is fixed and landed. Feel free to reopen if bug still can be reproduced.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
I created the test cases. This should be +
Flags: in-moztrap- → in-moztrap+
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: 184.108.40.206-prerelease
You need to log in before you can comment on or make changes to this bug.