Closed Bug 834816 Opened 11 years ago Closed 11 years ago

Bluetooth fails to reconnect when bluetooth turned off then back on

Categories

(Firefox OS Graveyard :: General, defect)

Product:
Firefox OS Graveyard
Component:
General
Platform:
ARM
Gonk (Firefox OS)
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(blocking-b2g:tef+, firefox19 wontfix, firefox20 wontfix, firefox21 fixed, b2g18 fixed, b2g18-v1.0.0 wontfix, b2g18-v1.0.1 verified)

Status:
VERIFIED FIXED
Milestone:
B2G C4 (2jan on)
Project Flags:
blocking-b2g tef+
Tracking Flags:
Tracking Status
firefox19 --- wontfix
firefox20 --- wontfix
firefox21 --- fixed
b2g18 --- fixed
b2g18-v1.0.0 --- wontfix
b2g18-v1.0.1 --- verified

People

(Reporter: ggrisco, Assigned: echou)

Details

(Whiteboard: [cr 443701])

Attachments

(3 files, 3 obsolete files)

Step 2 hcidump
39.67 KB, text/plain
Details
Step 3 hcidump
871 bytes, text/plain
Details
patch 1: v1: Disconnect all ACL connections before disabling Bluetooth
3.14 KB, patch
qdot
: review+
Details | Diff | Splinter Review 
1. Turn on WIFI and connect to an APN.
2. Turn on BT and connect to a BT headset
3. Turn off BT and turn back on.

Expected result: BT headset should connect back to the device. 
Actual Result:  The device is not connecting back to BT headset and it is saying check for the device, whether it is in range or not.
blocking-b2g: --- → tef?
Whiteboard: 443701
Whiteboard: 443701 → [cr 443701]
Assignee: nobody → echou
blocking-b2g: tef? → tef+
I just had a quick test (tried for 5 times) with my headset (Jabra WAVE) and latest b2g18 but cannot reproduce. Could you provide more information for us? Thanks. (build info, Headset model, occurrence and hcidump are especially useful)
Flags: needinfo?(ggrisco)
I just sync'd latest code and tried with my plantronics savor headset.  On the very first attempt, after step 3 I see a dialog that says 

"Check that the device you're trying to connect with is still in range and has Bluetooth turned on."  

But if I select the bluetooth device from the list and then select "Connect" then it will connect.

I also tried with WIFI turned off and the same problem persists.  So step 1 can be disregarded -- I will also edit the title.

I also tried on AU189 (most recent AU) and found the problem to be just as easily reproducible.
Flags: needinfo?(ggrisco)
This is the hcidump I see after turning bluetooth.  The message (from Comment 2) is seen in this case.

device: hci0 snap_len: 1504 filter: 0xffffffff
> HCI Event: Inquiry Complete (0x01) plen 1
    status 0x00
< HCI Command: Remote Name Request (0x01|0x0019) plen 10
    bdaddr 40:2C:F4:F1:DE:42 mode 0 clkoffset 0x0000
> HCI Event: Command Status (0x0f) plen 4
    Remote Name Request (0x01|0x0019) status 0x00 ncmd 1
> HCI Event: Connect Complete (0x03) plen 11
    status 0x0d handle 2 bdaddr 48:C1:AC:05:4E:6E type ACL encrypt 0x00
    Error: Connection Rejected due to Limited Resources
The error code shows "Connection Rejected due to Limited Resources" usually related to ACL connection resource is not available (no free ACL resource). And remote device replied this error message to Firefox OS. 
It looks connection was not been released from headset side while Firefox OS is trying to connect with.
Can you confirm no other phone is trying to connect with headset? Can you also attach the full log?
Hi Shawn,

> It looks connection was not been released from headset side while Firefox OS
> is trying to connect with.
> Can you confirm no other phone is trying to connect with headset? Can you
> also attach the full log?

I guess this happened because Unagi requested for a connection when a connection had already existed. This could happen, actually. We should be able to do more tests with our headsets and see if we can reproduce.

Eric
No other phones were trying to connect.  We saw this same problem with different headsets.  Also, reconnecting used to not be an issue with this same headset that I tested with.
Marking status-b2g18 and status-b2g18-v1.0.0 as affected, please update the status to fixed once this is verified landed on v1-train/mozilla-b2g18 and v1.0.0/mozilla-b2g18_v_1_0_0
status-b2g18: --- → affected
status-b2g18-v1.0.0: --- → affected
Hi Greg,

I agree with what Eric said in Comment 5. I think the root cause is that we try to create a new connection while we've already connected with a headset. As a result, the connect request is refused and the error message ("Check that the device you're trying to connect with is still in range....") is shown.

This issue is addressed in Bug 824599. Can we verify this issue again after Bug 824599 is fixed, Greg?
By the way, we'll be appreciated if you can provide full hcidump for us. Thanks.
Attached file Step 2 hcidump (obsolete) — 
hcidump during pairing and initial connect until we turn BT off in step 3.
Attached file Step 3 hcidump (obsolete) — 
hcidump taken after turning BT back on until the error message is displayed.
(In reply to Gina Yeh from comment #9)
> By the way, we'll be appreciated if you can provide full hcidump for us.
> Thanks.

Hi Gina, I added two hcidumps (described above).  I'll retry once there is a patch available for 824599, thanks.
Moving to Boot2Gecko:General to reflect the fact that this bug seems to be a platform issue.
Component: Gaia::Settings → General
Eric, how are things going here?
Flags: needinfo?(echou)
Summary: Bluetooth fails to reconnect when WIFI connected and1 bluetooth turned off then back on → Bluetooth fails to reconnect when bluetooth turned off then back on
(In reply to ggrisco from comment #12)
> (In reply to Gina Yeh from comment #9)
> > By the way, we'll be appreciated if you can provide full hcidump for us.
> > Thanks.
> 
> Hi Gina, I added two hcidumps (described above).  I'll retry once there is a
> patch available for 824599, thanks.

Greg, since bug 824599 has been landed, could you try again with the latest build? If it still fails to connect, please attach another hcidump log for us to cross-reference. Thank you.
Flags: needinfo?(echou) → needinfo?(ggrisco)
Attached file Step 2 hcidump — 
hcidump of initial pair/connect until turning BT off
Attachment #708657 - Attachment is obsolete: true
Flags: needinfo?(ggrisco)
Attached file Step 3 hcidump — 
hcidump of step 3 after turning BT back on and reconnect does not happen
Attachment #708658 - Attachment is obsolete: true
patch from 824599 doesn't seem to fix this problem for me.  I added hcidumps of latest test run with this patch.
For Comment18, which Bluetooth headset do you use to reproduce problem? Plantronics Savor? Or AU189. If it's AU189, can you provide information about AU189? Is it available from the market?
Flags: needinfo?(ggrisco)
(In reply to Greg Grisco from comment #18)
> patch from 824599 doesn't seem to fix this problem for me.  I added hcidumps
> of latest test run with this patch.

Thanks, Greg. These logs are helpful.

The problem seems to be that, when users disable Bluetooth, we call bluetooth.disable() to turn off Bluetooth and close profile sockets at the same time. Therefore, if the Bluetooth is turned off before connections of each layer is dropped, remote Bluetooth device would keep the connection for a periopd of time (supervision timeout). In the mean time, our connection request would be rejected since only one ACL connection could exist at a time between two devices.

Greg, I'll make a quick patch, it will not the final solution but could prove if my idea is right. So please help with applying the patch and see if it works. Thank you.
(In reply to Eric Chou [:ericchou] [:echou] from comment #21)
So if we were to wait longer before turning BT back on then the remote device should be in a state to accept the connection?

I don't remember this being a problem before.  Not too long ago I used to be able to turn off BT and turn it back on and have it automatically reconnect to same device.

Anyway, I'll try your patch when it's ready, thanks.
Flags: needinfo?(ggrisco)
Hi Greg, please take this patch and see if it could fix the problem, thanks!
Flags: needinfo?(ggrisco)
(In reply to Greg Grisco from comment #22)
> (In reply to Eric Chou [:ericchou] [:echou] from comment #21)
> So if we were to wait longer before turning BT back on then the remote
> device should be in a state to accept the connection?
> 

Yes, however, you have to wait long enough. You could try the following steps:

Connected -> Turn off BT on Unagi -> Wait for more than 40 seconds -> Turn on BT again and see if it's connected automatically.

> I don't remember this being a problem before.  Not too long ago I used to be
> able to turn off BT and turn it back on and have it automatically reconnect
> to same device.

That's weird. :/

> 
> Anyway, I'll try your patch when it's ready, thanks.

The patch has been ready. Thanks.
This is better now.  About 15s after turning bluetooth back on, the popup (mentioned in the Description) is displayed.  But after another 15-30 seconds, the BT headset does reconnect.

I saw the same behavior even after leaving BT turned off for ~3 minutes.
Flags: needinfo?(ggrisco)
Anything I can do to resolve this tef+ bug?
Eric is likely out all week on holiday.

Greg, can you summarize comment #25 - does the patch address the problem to a satisfactory level?
(In reply to Dietrich Ayala (:dietrich) from comment #27)
> Greg, can you summarize comment #25 - does the patch address the problem to
> a satisfactory level?

I think the main problem is fixed (headset is automatically re-connected now).  

Seeing the following dialog when BT is turned back on is still an 
annoyance though: "Check that the device you're trying to connect with is still in range and has Bluetooth turned on.".  Just my opinion, but I feel like there should be a way to avoid the dialog unless we truly cannot reconnect.
(In reply to Greg Grisco from comment #28)
> (In reply to Dietrich Ayala (:dietrich) from comment #27)
> > Greg, can you summarize comment #25 - does the patch address the problem to
> > a satisfactory level?
> 
> I think the main problem is fixed (headset is automatically re-connected
> now).  
> 
> Seeing the following dialog when BT is turned back on is still an 
> annoyance though: "Check that the device you're trying to connect with is
> still in range and has Bluetooth turned on.".  Just my opinion, but I feel
> like there should be a way to avoid the dialog unless we truly cannot
> reconnect.

Thanks, Greg. Since this patch actually solved the problem, I'll try to modify and upload a patch tomorrow. About the reason why the error dialog is still shown, I think it could be another timing issue. Currently, if Bluetooth is turned off while a connection exists, the auto-reconnect mechanism would be launched. However, the auto-reconnection request may possibly be sent after remote devices connect with us, and the error screen would be shown in that case indicating the failure of the auto-reconnection. 

I agree with Greg that there should be a way to avoid this happening, so I'll file a followup after the patch lands to keep tracking this problem.
* Slightly revised the hotfix patch: Added comments and created function DisconnectAllAcls
* An ACL is a low-level Bluetooth connection. Once an ACL between two Bluetooth devices is dropped, all profile communications would be stopped right away. The best solution for this issue should be "Close profile sockets, disconnect ACLs, and then Bluetooth is turned off". However, it looks like a huge task. So I chose to drop ACL connections directly, which has been proven working.
Attachment #711165 - Attachment is obsolete: true
Attachment #713418 - Flags: review?(kyle)
Attachment #713418 - Flags: review?(kyle) → review+
https://hg.mozilla.org/mozilla-central/rev/74828c564a36
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Verified fixed the issue back in the original Description section.

Verified this using the following bluetooth devices:

Jabra_sp200
RF-QX4

Unagi used:
Build ID: 20130313070202
Kernel Date: Dec 5
Gecko: http://hg.mozilla.org/releases/mozilla-b2g18_v1_0_1/rev/e74dafa6b2d9
Gaia: b34e726147f8e671ad8c538b50900ccfbffcb084
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: