Cannot find bluetooth headset to pair with

RESOLVED FIXED

Status

defect
--
major
RESOLVED FIXED
4 years ago
4 years ago

People

(Reporter: ggrisco, Unassigned)

Tracking

unspecified
ARM
Gonk (Firefox OS)

Firefox Tracking Flags

(blocking-b2g:2.2+, b2g-v2.2 fixed, b2g-master unaffected)

Details

(Whiteboard: [caf priority: p2][CR 790495][POVB])

Attachments

(1 attachment)

(Reporter)

Description

4 years ago
Steps to reproduce:

1. Turn on bluetooth headset
2. From device Settings, turn on Bluetooth

Expected result: bluetooth headset should show up in the device list
Actual result:  bluetooth headset never shows up in list

note:  The device list does show other BT devices, such as FFOS v2.1 (kk) device, but it can never find my headset.  The v2.1 device could find and pair with the headset.

headset used:  Plantronics Savor
Hey Bruce?  Could you take a look at this please?  I saw bug 1120889 and thought it might be related.
Flags: needinfo?(brsun)
Hi Greg,
Could you please tell us which gecko commit do you use? There are many strange issues after introduced patch in bug 1120889.
Flags: needinfo?(ggrisco)
(Reporter)

Comment 3

4 years ago
(In reply to Shawn Huang [:shawnjohnjr] from comment #2)
> Hi Greg,
> Could you please tell us which gecko commit do you use? There are many
> strange issues after introduced patch in bug 1120889.

Hi Shawn, this is the gecko commit I was using:  29ba8859a5dcf7c207ba2f846a99dbe3a4232bb5
Flags: needinfo?(ggrisco)
Whiteboard: [CR 790495]
Whiteboard: [CR 790495] → [caf priority: p2][CR 790495]
blocking-b2g: 2.2? → 2.2+
Hi Greg,
Could you please provide snoop log? So we can identify we actually get device "Plantronics Savor" from bluetooth controller. I tested our Plantronics Voyager PRO with Neuxs-5-L, the headset can be found.
As long as bluedroid callback indeed provide us device, and bluetoothd doesn't send to Gecko, we should fix.
Thanks!
Flags: needinfo?(ggrisco)
Bruce,
Meanwhile, we can double confirm our current implementation see if there is any chance UI does not show all the device names that bluedroid returned. Greg said his headset can never be found.
(In reply to Naoki Hirata :nhirata (please use needinfo instead of cc) from comment #1)
> Hey Bruce?  Could you take a look at this please?  I saw bug 1120889 and
> thought it might be related.

These two bugs might not the same. The device can be discovered but cannot be paired properly on bug 1120889.

BTW, I will try to dig into source codes to see if any clues can be found as stated on comment 5 in the mean time.
Flags: needinfo?(brsun)
ni myself for tracking
Flags: needinfo?(brsun)
(In reply to Greg Grisco from comment #0)
> Steps to reproduce:
> 
> 1. Turn on bluetooth headset
> 2. From device Settings, turn on Bluetooth
> 
> Expected result: bluetooth headset should show up in the device list
> Actual result:  bluetooth headset never shows up in list
> 
> note:  The device list does show other BT devices, such as FFOS v2.1 (kk)
> device, but it can never find my headset.  The v2.1 device could find and
> pair with the headset.
> 
> headset used:  Plantronics Savor

Hi Greg,
Because we don't have any logcat log or snoop log, just want to confirm with you, the problem you saw is that only 'Plantronics Savor' device cannot be found? Or all the surrounding devices cannot be found?
(Reporter)

Comment 9

4 years ago
Hi Shawn, in my test I used:

A: FFOS 2.2 device on L gonk
B: FFOS 2.1 device on KK
C: Plantronics Savor

A could find B but not C
B could find both A and C

Please let me know what kind of logs you would like me to collect.

Thanks,

-Greg
Flags: needinfo?(ggrisco)
(In reply to Greg Grisco from comment #9)
> Hi Shawn, in my test I used:
> 
> A: FFOS 2.2 device on L gonk
> B: FFOS 2.1 device on KK
> C: Plantronics Savor
> 
> A could find B but not C
> B could find both A and C
> 
> Please let me know what kind of logs you would like me to collect.
> 
> Thanks,
> 
> -Greg

Hi Greg,
Could you get snoop log?
Can you 'adb pull' to get config from (/system/etc/bluetooth/bt_stack.conf)
And change flag BtSnoopLogOutput

#Enable BtSnoop logging function
#valid value : true, false
BtSnoopLogOutput=true

Then
adb push bt_stack.conf /system/etc/bluetooth
adb reboot

After rebooting, perform necessary test steps.
While you finished test, please pull the log.

adb pull /sdcard/btsnoop_hci.log btsnoop_hci.log"
(Reporter)

Comment 11

4 years ago
After setting BtSnoopLogOutput to true, I repeated the steps and now the headset shows up in the device list (I never saw it before after many attempts).  Pairing with it is very flaky.  I saw dialog that said it could not pair, but then it showed up in the list as paired.

I was excited to share the snoop logs, but it wasn't generated at BtSnoopFileName (/sdcard/btsnoop_hci.log).  I checked my sdcard and it seemed to have plenty of space, so not sure why this isn't working.
Flags: needinfo?(ggrisco)
(Reporter)

Comment 12

4 years ago
Oh, I see...
E/btsnoop ( 1007): btsnoop_open unable to open '/sdcard/btsnoop_hci.log': Permission denied
(Reporter)

Comment 13

4 years ago
Hi Shawn, with latest code I have been able to scan for the headset and pair to it.  Connection is still unstable though.  I managed to collect btsnoop where I connected to headset and automatically it disconnected (without user interaction).  But this seems like a different problem than what was first reported.  Let me know if you want another bug for it.  I'll upload btsnoop here for now.
Flags: needinfo?(shuang)
(Reporter)

Comment 14

4 years ago
Posted file btsnoop_hci.log

Comment 15

4 years ago
Hi Teri, can you help to check if this issue happens? thanks
Flags: needinfo?(twen)
(In reply to Greg Grisco from comment #13)
> Hi Shawn, with latest code I have been able to scan for the headset and pair
> to it.  Connection is still unstable though.  I managed to collect btsnoop
> where I connected to headset and automatically it disconnected (without user
> interaction).  But this seems like a different problem than what was first
> reported.  Let me know if you want another bug for it.  I'll upload btsnoop
> here for now.

I think we can open another bug for it. For me, it seems discovery function can work at your side.
Flags: needinfo?(shuang)
(In reply to Greg Grisco from comment #13)
> Hi Shawn, with latest code I have been able to scan for the headset and pair
> to it.  Connection is still unstable though.  I managed to collect btsnoop
> where I connected to headset and automatically it disconnected (without user
> interaction).  But this seems like a different problem than what was first
> reported.  Let me know if you want another bug for it.  I'll upload btsnoop
> here for now.

Hi Greg,
I've reviewed the log you attached but I did not see any disconnection.
After receiving AT+XAPL and AT+XEVENT AT commands, there is no further AT commands incoming. But the log doesn't contain disconnection log.
Checking AT+XAPL/AT+XEVENT, this reminds me an old bug, see also bug 838089.
https://bugzilla.mozilla.org/show_bug.cgi?id=838089

"After paired and connected with Plantronics Voyager Legend, it sent lots of vendor-defined AT commands to us. We sent |OK| back and everything looked fine. However, after that, the device wouldn't send any AT commands that we could recognize. According to the HFP spec, we should respond with |ERROR| when we received unknown AT commands."

I'm not sure this is the exact case that you encountered since the snoop log does not show disconnection. But I do see no other AT commands received after replying "ERROR" to handset.
Anyway, I think we shall open an another bug for this disconnection symptom.
(Reporter)

Comment 19

4 years ago
Ok, I'll try to diagnose the problem more and open a new bug thereafter.  Thanks for looking at the logs.
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → WORKSFORME

Comment 20

4 years ago
No action needed for QA, clear ni.
Flags: needinfo?(twen)
Resolution: WORKSFORME → FIXED
Whiteboard: [caf priority: p2][CR 790495] → [caf priority: p2][CR 790495][POVB]

Updated

4 years ago

Updated

4 years ago
No longer blocks: CAF-v3.0-FL-metabug
You need to log in before you can comment on or make changes to this bug.