Unable to pair with in-car hands-free system after OTA-9 update

Bug #1539158 reported by Stunts
114
This bug affects 24 people
Affects Status Importance Assigned to Milestone
Canonical System Image
Fix Released
Critical
John McAleely
bluez (Ubuntu)
Won't Fix
Medium
Simon Fels
ubuntu-system-settings (Ubuntu)
Fix Released
Critical
Konrad Zapałowicz

Bug Description

After OTA-9 I started having trouble with my bluetooth connection to the car hands-free system (no sound, and incoming calls no longer displayed the number), so I have reset both the car and the phone connections (eg. forgot the devices).
Now I can't even pair the phone with the car's system.
The car finds the phone, and then asks me to enter the code "0000" to pair the device, but after a few moments, it just says the connection failed and asks me to try again. Which fails again.

It was working fine just before the update.

Any logs I should post to help debug?

PS - The car is a 2015 Honda Civic Tourer, if that matters.

Related branches

Revision history for this message
Stunts (f-pinamartins) wrote :

Could be a duplicate of
https://bugs.launchpad.net/ubuntu/+source/bluez/+bug/1435040
But it might not be, since my issue only started with OTA-9.

Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in bluez (Ubuntu):
status: New → Confirmed
Bill Filler (bfiller)
Changed in bluez (Ubuntu):
importance: Undecided → High
Changed in canonical-devices-system-image:
importance: Undecided → High
milestone: none → ww08-2016
assignee: nobody → John McAleely (john.mcaleely)
Changed in bluez (Ubuntu):
assignee: nobody → Simon Fels (morphis)
Revision history for this message
Marco Graziotti (graziottimarco) wrote :

I can't pair the device to the system. I'm using MX4 with OTA9.

I have a Nissan, with "Nissan Connect" (first version, 2011 edition, see pic attached).
The car finds the phone "Meizu MX4 Ubuntu Edition", and then asks me to enter the code "1234" to pair the device, but after this it says "connection failed".

This system can connect phones with bluetooth 4; for example, I have also a Samsung S3, and it works.

Revision history for this message
Stunts (f-pinamartins) wrote :

@MarcoGraziotti:
Could you connect before OTA9?

Revision history for this message
Marco Graziotti (graziottimarco) wrote :

@Stunts:

No. I'm never been able to pair them.
It never work in my own case.

Changed in canonical-devices-system-image:
importance: High → Critical
tags: added: bluetooth
Changed in canonical-devices-system-image:
status: New → Confirmed
Revision history for this message
higuita (higuita) wrote :

I updated to my ubuntu phone to OTA-9 and my phone stop working with a Toyota Prius... it can pair, but incoming or outgoing calls have no audio (both in and out) but i can accept and reject calls. Before OTA-9 it worked fine

I have a console installed, but i didn't yet try to check it... any tip on what to check or what to run/change is welcome.

Thanks

Revision history for this message
Stunts (f-pinamartins) wrote :

Attached is the syslog from my Krillin device from a few minutes before attempting the pairing until failure.
I hope this may help speed things up.
I'm willing to test new stuff to help fix this issue.

Revision history for this message
Marco Graziotti (graziottimarco) wrote :

Where I can find the bluetooth syslog file? I wanna attach my own log to helping the fix procedure.

Thank you.

Revision history for this message
Stunts (f-pinamartins) wrote :

@Marco Graziotti:
The syslog is nothing special. You can find it in "/var/log/syslog".

There is also this:
https://wiki.ubuntu.com/DebuggingBluetooth

I recently found that documentation, and I am planning on getting that info out here. But sofar I haven't had the chance to try it.
It will probably contain much more detailed information.

Revision history for this message
Marco Graziotti (graziottimarco) wrote :

@Stunts

Thank you for your reply.

For generating bluetooth log files with debugging information it's necessary to switch in read and write mode ( sudo mount -o remount,rw / ), after this, how can I restore the read only mode?

Thank you

Revision history for this message
Marco Graziotti (graziottimarco) wrote :

I asked this because I read that it's dangerous switch in RW mode.

At this url: http://askubuntu.com/questions/600065/consequences-of-using-apt-get-in-ubuntu-touch
I read this: http://askubuntu.com/a/600313

['evergreen' answer]
"By default the system is read-only. You can switch to read-write mode, although this disables Ubuntu system upgrades.The main purpose for this is developing the Ubuntu system directly. This is not required for developing apps or using the system normally. Recovering from read-write mode is possible but requires reinstalling the system from scratch. Warning: Switching a device to read-write mode (and/or recovering from it) is an advanced feature and may result in complete data loss. Warning: Switching a device to read-write mode disables automatic over-the-air delta updates. Accepting a full over-the-air update after making a device writable may undo changes you have made."

Revision history for this message
Stunts (f-pinamartins) wrote :

@Marco

Woha, I actually asked the askubuntu referenced question. Talk about full circle.
Anyway, I have gotten my system on rw mode, using "sudo mount -o remount,rw /". I did this to insert a new ringtone on my phone (which can now be done via the GUI without changing the image to rw mode).
In order to revert back to read-only mode you have to do "sudo mount -o remount,ro /".
I did not feel any side effects for inserting that extra ogg, and I don't think getting that extra log information will either. Just remember to put the image back to 'ro' mode after you are done with collecting the logs.

Revision history for this message
Marco Graziotti (graziottimarco) wrote :

Hi,

today I've tried to make a log file about the bluetooth pair problem. I followed this istruction: https://wiki.ubuntu.com/DebuggingBluetooth for generating log files with debugging information.
After this, I tried to pair my phone with car bluettoth system, and I have copied the "bluetoothhd" file from my phone (/usr/sbin/) to my desktop.
I have opened this file but only a little part it's readable, part of this file contain unreadable characters; so I attach at this message only the readable parts.

Please, let me know if this procedure is correct. This file attached it's useful for debugging?

Thank you

Revision history for this message
Stunts (f-pinamartins) wrote :

Ok, I have generated a verbose bluetooth log.
However, this log contains some personal information, that I would prefer not to make public (email address, partial wifi credentials, etc). How can I make it avaialable to devs in a more private way?

Here is what I did:
Make "/" rw
Edit /etc/init/bluetooth.conf and add a "-d" after the exec line
Reboot the phone
Turn on bluetooth
Attempt to pair with car's hands free system
Phone is found
Pairing fails
Tried pairing again
Pairing fails
Go to terminal,
cp /var/log/syslog ~/
mount "/" as rw again
Remove the "-d" from /etc/init/bluetooth.conf
Reboot to stop log from growing to much again.

I have stripped the syslog to include only data from after the first reboot (I doubt what was before would be interesting).
Feedback, on how to proceed, please. Is this the correct procedure for getting detailed bluetooth logs?
Tonight I might have the chance to strip personal info from the file I want to upload.

Revision history for this message
Konrad Zapałowicz (kzapalowicz) wrote :

Nice that you managed to get the log, well done. As for the personal info I suppose that it is better you remove it however if that is too complicated just let us know and we will figure something out. Thanks.

Revision history for this message
Stunts (f-pinamartins) wrote :

Ok, I think I stripped any sensitive information from that log.
I hope it contains what you need.
Let me know if you require anything else (including potential solutions for testing).

Revision history for this message
Stunts (f-pinamartins) wrote :

Sorry about the spam. I forgot the attachment.

Simon Fels (morphis)
tags: added: bluetooth-ota10bluetooth
removed: bluetooth
tags: added: bluetooth bluetooth-ota10
removed: bluetooth-ota10bluetooth
tags: added: bluez-touch
Revision history for this message
Simon Fels (morphis) wrote :

Analyzed the latest log files and came to following conclusion about that is going on here:

The key point here is that the car initiates the pairing with the phone which then leads to a timing problem in ubuntu-system-settings. But step by step:

Feb 23 09:43:45 ubuntu-phablet bluetoothd[880]: src/adapter.c:device_found_callback() hci0 addr 84:38:35:62:28:DF, rssi -91 flags 0x0000 eir_len 72
Feb 23 09:43:45 ubuntu-phablet bluetoothd[880]: src/device.c:device_create() dst 84:38:35:62:28:DF
Feb 23 09:43:45 ubuntu-phablet bluetoothd[880]: src/device.c:device_new() address 84:38:35:62:28:DF
Feb 23 09:43:45 ubuntu-phablet bluetoothd[880]: src/device.c:device_new() Creating device /org/bluez/hci0/dev_84_38_35_62_28_DF
Feb 23 09:43:45 ubuntu-phablet bluetoothd[880]: src/device.c:device_set_legacy() legacy 0
Feb 23 09:43:45 ubuntu-phablet bluetoothd[880]: src/device.c:device_set_rssi_with_delta() rssi -91
Feb 23 09:43:45 ubuntu-phablet bluetoothd[880]: src/device.c:btd_device_device_set_name() /org/bluez/hci0/dev_84_38_35_62_28_DF MacBook Air de Cristina
Feb 23 09:43:45 ubuntu-phablet bluetoothd[880]: src/device.c:device_set_class() /org/bluez/hci0/dev_84_38_35_62_28_DF 0x38010C

Here we see that bluez correctly finds the device and directly continues with an pairing attempt which it gets from the remote device

Feb 23 09:43:46 ubuntu-phablet bluetoothd[880]: src/adapter.c:pin_code_request_callback() hci0 00:0A:30:B3:52:4B
Feb 23 09:43:46 ubuntu-phablet bluetoothd[880]: src/device.c:device_create() dst 00:0A:30:B3:52:4B
Feb 23 09:43:46 ubuntu-phablet bluetoothd[880]: src/device.c:device_new() address 00:0A:30:B3:52:4B
Feb 23 09:43:46 ubuntu-phablet bluetoothd[880]: src/device.c:device_new() Creating device /org/bluez/hci0/dev_00_0A_30_B3_52_4B
Feb 23 09:43:46 ubuntu-phablet bluetoothd[880]: src/device.c:new_auth() Requesting agent authentication for 00:0A:30:B3:52:4B
Feb 23 09:43:46 ubuntu-phablet bluetoothd[880]: src/agent.c:agent_ref() 0xb7113930: ref=2
Feb 23 09:43:46 ubuntu-phablet bluetoothd[880]: src/agent.c:agent_ref() 0xb7113930: ref=3

So there is basically no time span between the phone detecting the device and getting the pairing request. BlueZ then sends out the pairing request to its registered agents:

Feb 23 09:43:46 ubuntu-phablet bluetoothd[880]: Agent /com/canonical/SettingsBluetoothAgent/adapteragent replied with an error: org.bluez.Error.Rejected, The request was rejected: RequestPinCode
Feb 23 09:43:46 ubuntu-phablet bluetoothd[880]: src/adapter.c:btd_adapter_pincode_reply() hci0 addr 00:0A:30:B3:52:4B pinlen 0

.. which gets denied from settings app as it doesn't have the device in its internal list yet. See https://bazaar.launchpad.net/~system-settings-touch/ubuntu-system-settings/trunk/view/head:/plugins/bluetooth/agent.cpp#L115 for details.

We need to rework ubuntu-system-settings here to add the new device based on the object path it gets from bluez with the pairing request.

Changed in bluez (Ubuntu):
status: Confirmed → Invalid
Changed in ubuntu-system-settings (Ubuntu):
status: New → Confirmed
Simon Fels (morphis)
Changed in ubuntu-system-settings (Ubuntu):
status: Confirmed → In Progress
importance: Undecided → High
importance: High → Critical
assignee: nobody → Simon Fels (morphis)
Changed in canonical-devices-system-image:
status: Confirmed → In Progress
Revision history for this message
Simon Fels (morphis) wrote :

MP with a possible fix is linked now.

@Stunts: I've put the MP into silo 67 (https://requests.ci-train.ubuntu.com/#/ticket/1102). Can you install that one on your device and try if that fixes the problem for you?

Revision history for this message
Stunts (f-pinamartins) wrote :

@Simon
Thanks!
Just to make sure: in order to try this, all I have to do is add the PPA to sources.list and install it using apt-get?
Or is there more to this, such as re-flashing the device with some daily build image?
If procedures other than adding the PPA are required, would you please point me to the relevant documentation?
If it's just a matter of adding the PPA I can still test it today. Otherwise I'll have to do it over the weekend.

Revision history for this message
John McAleely (john.mcaleely) wrote :

@kenvandine I guess you need to take this bug to land with some other fixes?

Changed in canonical-devices-system-image:
assignee: John McAleely (john.mcaleely) → Bill Filler (bfiller)
Revision history for this message
Marco Graziotti (graziottimarco) wrote :

Thanks to the instruction provided by "Stunt" ( https://bugs.launchpad.net/ubuntu/+source/bluez/+bug/1539158/comments/14 ), I have generated a bluetooth log file that you can find attached at this message.

My own hands free system it's a NISSAN CONNECT, I'm using a Meizu MX4 with OTA 9.1.

I hope that this log file contains what you need and let me know if you require anything else.

Thank you.

P.S.: I think I have removed any sensitive information from that log.

Revision history for this message
Simon Fels (morphis) wrote :

@Stunts: Do the following on your HOST system:

$ sudo add-apt-repository ppa:phablet-team/ubuntu/tools
$ sudo apt-get install phablet-tools-citrain

Now connect the phone over adb (make sure developer mode is enabled):

Still from the HOST system:

$ citrain device-upgrade <silo number> <your device PIN>

PLEASE KEEP IN MIND: This will change the content of the device rootfs system. If you don't want to reflash via ubuntu-device-flash or don't know how to do that it might be better to wait until this fix lands with the next OTA.

Revision history for this message
Stunts (f-pinamartins) wrote :

Humm... I guess I'll have to read a bit on how to do the reflashes.
Worst case scenario I'll have to wait until OTA10, which should be released somewhere in April IIRC.
I will report back if I make some progress on this front (hopefully with enough time before OTA10 lands for any further tweaking).

Revision history for this message
Marco Graziotti (graziottimarco) wrote :

@Stunts:

I have followed the instruction that you shared here: https://bugs.launchpad.net/ubuntu/+source/bluez/+bug/1539158/comments/14 now I'm trying to remove "-d" option from "/etc/init/bluetooth.conf" but when I'm saving the file, nano's editor ask me if I wanna save the file as:

- M-D DOS format
- M-M Mac format
- M-A Append
- M-P Prepend
- M-B Backup file

(see picture attached)

How did you save the file?

***

@Simon Fels:

Can the log file I attached in message 22 be useful?

Revision history for this message
Stunts (f-pinamartins) wrote :

@Marco:
Just "press" "Enter" and the file should be saved. Don't worry about that message. Nano always asks that question before saving a file.

Revision history for this message
Marco Graziotti (graziottimarco) wrote :

@Stunts:

No way.
When I'm trying to save the file pressing "enter", nothing happen. Editor ask me for a format (M-D DOS format; M-M Mac format; M-A Append; ecc), see the picture attached at message #25

This is the procedure that I have applied:

- connect MX4 via terminal adb
- insert command: sudo mount -o remount,rw /
- edit file with: sudo nano /etc/init/bluetooth.conf
- remove -d option from: exec /usr/sbin/bluetoothd -d
- press CTRL + O for saving
- trying to press enter for apply changes, but nothing happen

What can I do?

Thank you

Marco

Revision history for this message
Stunts (f-pinamartins) wrote :

@Marco

Sorry, I cannot reproduce that. In both my desktop and my phone, pressing "Enter" on the save dialog will result in saving the file...
You may wish to try "Ctrl+X" instead of "Ctrl+O", to try to work around the problem, but I'm not sure it will achieve anything...

Simon Fels (morphis)
Changed in ubuntu-system-settings (Ubuntu):
assignee: Simon Fels (morphis) → Ken VanDine (ken-vandine)
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package ubuntu-system-settings - 0.3+16.04.20160318-0ubuntu1

---------------
ubuntu-system-settings (0.3+16.04.20160318-0ubuntu1) xenial; urgency=medium

  * Process pairing attempts for unknown devices correctly (LP:
    #1539158)

 -- Simon Fels <email address hidden> Fri, 18 Mar 2016 17:56:23 +0000

Changed in ubuntu-system-settings (Ubuntu):
status: In Progress → Fix Released
Changed in canonical-devices-system-image:
status: In Progress → Fix Committed
Revision history for this message
Stunts (f-pinamartins) wrote :

Problem persists after updating to OTA10.
The symptoms appear to be the same.
I will enable verbose logging again and report back.
This time I will most certainly try any silos you may provide as I have already learned a bit more abut the system.

Revision history for this message
Marco Graziotti (graziottimarco) wrote :

Problem persist for me too after updating to OTA-10.

I'm using Meizu MX4 with "Nissan Connect" (first version, 2011 edition, see pic: https://launchpadlibrarian.net/236039500/Nissan-Connect-First-Version.jpg ).
The phone finds "Nissan Connect", but when the pair procedure starts, it stops by itself before than asks me to enter the pin code "1234" to pair the device. After this stops the Nissan Connect display says "connection failed".

"Nissan Connect" can connect phones with bluetooth 4, for example, I have also a Samsung S3 mini, and it works.

Revision history for this message
Stunts (f-pinamartins) wrote :

Attaching a stripped syslog, using the same procedure as done in comment #14.
I hope it contains the required information.
Upon a quick uninformed look, the error seems to be the same as before, but I may well be missing something.

Revision history for this message
Konrad Zapałowicz (kzapalowicz) wrote :
Changed in canonical-devices-system-image:
status: Fix Committed → Fix Released
Revision history for this message
Stunts (f-pinamartins) wrote :

Fix Released - Is there some silo I can try to test this?

Thanks.

Revision history for this message
Pat McGowan (pat-mcgowan) wrote :

It hopefully works in the latest update, v10+

Revision history for this message
Stunts (f-pinamartins) wrote :

That's great news!
I'll try it again tomorrow morning and report back.

Revision history for this message
Marco Graziotti (graziottimarco) wrote :

In my own case it don't work.

It's impossible to pair the MX4 (OTA-10.1) to "Nissan Connect" bluetooth. Also, it's now impossible to forget the "Nissan Connect" paired before. The "forget" button isn't cliccable (see pictures attached).

You can find my bluetooth log file (with OTA-9) attached at the message number 22 ( https://bugs.launchpad.net/ubuntu/+source/bluez/+bug/1539158/comments/22 ).

If needed, I can prepare a new log file.

Revision history for this message
Stunts (f-pinamartins) wrote :

I can confirm that it is not working for me either.
However, there is a small difference from the previous tries:
Now the car system asks for the pin code, and it takes 4-5 seconds before failing, whereas previously it instantly failed.
I will report back later with the debug log.

Revision history for this message
Stunts (f-pinamartins) wrote :

I am attaching the log with OTA10.1.
As far as I can tell, the error is still the same. But all the experience I have with debugging bluetooth errors is what you see in this bug report.

Changed in canonical-devices-system-image:
status: Fix Released → Confirmed
milestone: 10 → 11
Changed in ubuntu-system-settings (Ubuntu):
status: Fix Released → Confirmed
Changed in bluez (Ubuntu):
status: Invalid → Confirmed
Bill Filler (bfiller)
Changed in canonical-devices-system-image:
assignee: Bill Filler (bfiller) → John McAleely (john.mcaleely)
Revision history for this message
Stunts (f-pinamartins) wrote :

Sorry about the noise, but is there any further info I can provide, or patches I can try?
This is a critical functionality for me.

Revision history for this message
Konrad Zapałowicz (kzapalowicz) wrote :

Hey, the Bluetooth bugs with cars are our top priority at the moment and we are putting the effort into fixing them as soon as we can.

Revision history for this message
Konrad Zapałowicz (kzapalowicz) wrote :

@Stunts:

There is one thing, however, that you could try on your phone. In order to make sure that the flaw is still in the Ubuntu System Settings you could try to pair and connect with the car using the bluetoothctl commandline interface w/o even opening the Bluetooth settings scope.

In order to achieve this you will have to connect to the phone either using the ssh or use any kid of terminal emulator on it. Let me know if you need further instructions in order to accomplish this and I will walk you through.

Thanks

Revision history for this message
Stunts (f-pinamartins) wrote :

@Konrad
Great idea.
Ok, so I went here[1] to get info on running "bluetoothctl" and pairing a device via this interface.
Here's the result:
Pairing works via "bluetoothctl". I did not have to enter a PIN code as before and as mentioned in the car's instructions.
After pairing was working, I was able to:
1. Browse the phone's address book;
2. Set "speed dials" using the phone's address book
3. Activate "Bluetooth" as a "source" for audio in the car, open the "Music" app and the music played through the car's speakers (albeit with a very low volume, and car controls don't work (next track, previous track, etc). This is an improvement as I had never been able to play the phone's audio via the car's speakers.
Unfortunately, the good news stop here.
1. Placing a call using the car's phone interface results in the phone placing the call, but no audio can be heard. Not even the "ring". The person on the other side had long hung up the call, but the phone's interface remained frozen and silent as if it were still trying to make the outgoing call.
2. Once somebody called me, I expected the car to display the name of the person calling me. Instead I get "Unknown". Not even the phone number of the person calling is displayed.
3. Trying to answer the call results only in silence. I can't hear what the other person is saying, and they can't hear me. I was, however able to "answer" and "disconnect" the call using the car's interface.
4. Turning off bluetooth on the phone made it usable just as normal again.

So all in all, what is currently happening is the same set of symptoms I had when I first got OTA9 and the pairing was already configured.
Should a separate issue be opened? We are looking at 2 distinct things here (maybe three) - one is the pairing problem. The other is the silence during the calls, and the other is the missing name of the caller.
That being said, what would you like me to log first and attempt to tackle?

[1] https://wiki.archlinux.org/index.php/Bluetooth#Configuration_via_the_CLI

Revision history for this message
Konrad Zapałowicz (kzapalowicz) wrote :

This is awesome, thank you for performing the test case. Now I know that the flaw is still somewhere in the Ubuntu System Settings and it is most probably a race.

As for the other issues that you have observed I would prefer to first solve the pairing bug and the other you mention will be waiting in the queue. The best thing, as you suggest, would be to report these as separate issues so that we can track them and manage the priorities.

Best

Revision history for this message
Stunts (f-pinamartins) wrote :

You are welcome. Let me know if you need me to test something else.
I have also opened 2 new tickets for the 2 "downstream" reported issues:

https://bugs.launchpad.net/ubuntu/+source/bluez/+bug/1578176
https://bugs.launchpad.net/ubuntu/+source/bluez/+bug/1578178

Revision history for this message
Konrad Zapałowicz (kzapalowicz) wrote :

It seems that I know what is happening and why the pairing is denied. I think that it is because the device when added to the internal data structures is not yet fully initialized as the properties are gathered asynchronously. In the same time the pin request is executed that tries to use the yet not valid device. As a consequence the pairing is denied as the whole procedure is interrupted.

Now, just to confirm what is happening on the Ubuntu System Settings side I would like to look at the Ubuntu System Settings log. You can find somewhere in .cache/upstart/application [now I'm not sure] legacy/ubuntu-system-settings.log It would be awesome if you could search for it and paste here. Thanks in advance.

Revision history for this message
Konrad Zapałowicz (kzapalowicz) wrote :

@Stunts

I have made an improvement and I wonder if it will have any positive effect on your side. Could you install silo 00 on your device and try if that fixes the problem for you?

Revision history for this message
Stunts (f-pinamartins) wrote :

I cannot seem to find the log you requested anywhere.
I found similar files under ~/.cache, but they seemed to be specific logs (for system updates, for example), not a generic one like the mentioned ones. Wiki pages also refer the file location you mentioned, but it does not seem to exist anymore.

I'll try silo 00 over the weekend and report back.

Changed in ubuntu-system-settings (Ubuntu):
assignee: Ken VanDine (ken-vandine) → Konrad Zapałowicz (kzapalowicz)
Changed in canonical-devices-system-image:
status: Confirmed → In Progress
Changed in ubuntu-system-settings (Ubuntu):
status: Confirmed → In Progress
Revision history for this message
Konrad Zapałowicz (kzapalowicz) wrote :

@Stunts

I wonder if you had time and chance to test the possible fix. Let me know because if it works then we could include it in the upcoming OTA

Thanks.

Revision history for this message
Stunts (f-pinamartins) wrote : Re: [Bug 1539158] Re: Unable to pair with in-car hands-free system after OTA-9 update

Sorry about the lag.

I had a bit of an emergency this weekend, since the HDD on my home
server (which is also my router) failed. I had to find a replacement,
restore from backups, and reinstall the OS.

It was still running Ubuntu 10.04, and migrating to 16.04 is taking
longer than I anticipated, since a lot has changed in 6 years (systemd
taking most of my time), and most config files had to altered. Heck,
even iptables rules no longer work!

You can imagine that the phone has taken a backseat for a while.

Anyway, I should have everything back up and running tomorrow (only
openvpn, network bridging and cups left to configure) and I'll get to
the silo afterwards. Thanks for your work and I'll be back on testing ASAP.

Francisco

On 10-05-2016 07:22, Konrad Zapałowicz wrote:
> @Stunts
>
> I wonder if you had time and chance to test the possible fix. Let me
> know because if it works then we could include it in the upcoming OTA
>
> Thanks.
>

Revision history for this message
Konrad Zapałowicz (kzapalowicz) wrote :

I absolutely understand and good luck with finishing all of the updates. Sounds like you had a lot of fun hacking :-)

Changed in canonical-devices-system-image:
milestone: 11 → 12
Revision history for this message
Konrad Zapałowicz (kzapalowicz) wrote :

@Stunts

Have you had time to verify the silo 00?

Revision history for this message
Stunts (f-pinamartins) wrote :

Sorry about the delay. I'll try this ASAP, which is likely before the weekend.
I'll report back with results soon.

Revision history for this message
Stunts (f-pinamartins) wrote :

Ok, so I think I'm ready to test that silo.
Are these instructions up-to-date, (especially the recovery process)?
https://wiki.ubuntu.com/LandingTeam/SiloTestingGuidelines

Or should I get them from somewhere else?

Revision history for this message
Stunts (f-pinamartins) wrote :

Did this fix land in OTA11?
Because I can now pair the car's bluetooth system with the phone without any issues.

Revision history for this message
Marco Graziotti (graziottimarco) wrote :

In my own case the bug persists with OTA 11 (Meizu MX4).

@Stunts for this bug the milestone it's OTA12.

Revision history for this message
Konrad Zapałowicz (kzapalowicz) wrote :

@Stunts, no it did not. Have you used the silo for testing or just OTA11?

Revision history for this message
Stunts (f-pinamartins) wrote :

I didn't get to try the silo.
After your comment, I found this very strange and took a better look:

Before, I used to wait for the car to find the phone, and after being found the car requested me to enter 0000 in the phone for pairing (which failed immediately).

What is occurring now, is that the car is asking me to use the phone to find the bluetooth system, which the phone does without any trouble, and after that, the pairing is automatic.

I will try to reproduce the previous conditions and report back.

Revision history for this message
Konrad Zapałowicz (kzapalowicz) wrote :

Interesting, please try.

Revision history for this message
Stunts (f-pinamartins) wrote :

Ok, I can confirm that I am unable to pair the phone with that car's bluetooth system if I have the car's system try to find and pair with the phone.
However, if I let the phone try to find the car's system, pairing works without issue.
I will retest using 'bluetoothctl' just to make sure I didn't make the same mistake before.
Also, can I still try silo 0 now that my phone is on OTA 11?

Revision history for this message
Konrad Zapałowicz (kzapalowicz) wrote :

Yes, you can try it

Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package ubuntu-system-settings - 0.4+16.10.20160609-0ubuntu1

---------------
ubuntu-system-settings (0.4+16.10.20160609-0ubuntu1) yakkety; urgency=medium

  * Fix pin code request is rejected because device is not valid (LP:
    #1539158)

 -- Konrad Zapałowicz <email address hidden> Thu, 09 Jun 2016 11:16:36 +0000

Changed in ubuntu-system-settings (Ubuntu):
status: In Progress → Fix Released
Changed in canonical-devices-system-image:
status: In Progress → Fix Committed
Revision history for this message
higuita (higuita) wrote :

Hi

After updating to OTA-11, i still can pair with the car, but on incoming or outoing calls i have no audio. This in a Toyota Prius and before OTA-9 it worked fine

it looks like this fix did solved the pairing problem, but there is still something failing in using the audio in the cars

Revision history for this message
Stunts (f-pinamartins) wrote :
Revision history for this message
Michał Sawicz (saviq) wrote :

FWIW I still can't pair with my hands-free system.

Revision history for this message
higuita (higuita) wrote :

@Stunts: yes, it is the same issue. I can pair the phone, but no audio

Changed in canonical-devices-system-image:
status: Fix Committed → Fix Released
Revision history for this message
Marco Graziotti (graziottimarco) wrote :

After the OTA-12 update, my MX4 still not working. Also I cant remove the "Nissan Connect" as paired device (see the image attached). I never been able to pair MX4 with Nissan Connect, so I don't know why it results as paired.

Revision history for this message
Cesar Herrera (chg1) wrote :

I have an E4.5 and with OTA-12 I can't pair to C4 Citroen.
Time ago I did some tests. When the phone detect a car tried to match it. Now their names still appear. This is very strange.

Revision history for this message
Konrad Zapałowicz (kzapalowicz) wrote :

Hey,

I'll try to help a bit here.

First as for the unknown or unwanted entries on the paired devices lists [and such] you can try to remove them from the bluetoothctl level.

) enable developers mode & connect it via usb cable
) login with adb shell to the deivce
) type $ bluetoothctl
) then type: devices - to list the known devices
) to remove type: remove $BDADDR - where BDADDR is a Bluetooth address of the device [not it's name]

Second we are in the of releasing the newest bluez 5.41 which is now in silo 37. If you are familiar with installing silos on your device you can try it out and check if it improves anything. It includes fixes for link management and pairing therefore there is a chance [although not certain] that there might be joy.

If unsure please ask.

Best,
Konrad

Revision history for this message
Marco Graziotti (graziottimarco) wrote :

Hi Konrad,

thank you for your answer, I will try to apply the procedure that you
have described during this weekend.
I never installed a silos, so maybe it's better to wait the OTA-13 that
incude bluez 5.41.

Thank you,
Marco

Il 28/07/2016 10:54, Konrad Zapałowicz ha scritto:
> Hey,
>
> I'll try to help a bit here.
>
> First as for the unknown or unwanted entries on the paired devices lists
> [and such] you can try to remove them from the bluetoothctl level.
>
> ) enable developers mode & connect it via usb cable
> ) login with adb shell to the deivce
> ) type $ bluetoothctl
> ) then type: devices - to list the known devices
> ) to remove type: remove $BDADDR - where BDADDR is a Bluetooth address of the device [not it's name]
>
> Second we are in the of releasing the newest bluez 5.41 which is now in
> silo 37. If you are familiar with installing silos on your device you
> can try it out and check if it improves anything. It includes fixes for
> link management and pairing therefore there is a chance [although not
> certain] that there might be joy.
>
> If unsure please ask.
>
> Best,
> Konrad
>

Revision history for this message
Konrad Zapałowicz (kzapalowicz) wrote :

Hey,

the procedure is not very difficult and once all the tools are installed it
is straightforward however if you do not feel confident, given that it is
not certain that it will help for issues with cars, I would recommend
waiting till OTA-13.

Best,
Konrad

On Thu, Jul 28, 2016 at 1:05 PM, Marco Graziotti <email address hidden>
wrote:

> Hi Konrad,
>
> thank you for your answer, I will try to apply the procedure that you have
> described during this weekend.
> I never installed a silos, so maybe it's better to wait the OTA-13 that
> incude bluez 5.41.
>
> Thank you,
> Marco
>
> Il 28/07/2016 10:54, Konrad Zapałowicz ha scritto:
>
>> Hey,
>>
>> I'll try to help a bit here.
>>
>> First as for the unknown or unwanted entries on the paired devices lists
>> [and such] you can try to remove them from the bluetoothctl level.
>>
>> ) enable developers mode & connect it via usb cable
>> ) login with adb shell to the deivce
>> ) type $ bluetoothctl
>> ) then type: devices - to list the known devices
>> ) to remove type: remove $BDADDR - where BDADDR is a Bluetooth address of
>> the device [not it's name]
>>
>> Second we are in the of releasing the newest bluez 5.41 which is now in
>> silo 37. If you are familiar with installing silos on your device you
>> can try it out and check if it improves anything. It includes fixes for
>> link management and pairing therefore there is a chance [although not
>> certain] that there might be joy.
>>
>> If unsure please ask.
>>
>> Best,
>> Konrad
>>
>>
>

Revision history for this message
Ferry Toth (ftoth) wrote :

My Meizu MX4 is paired with my car (Renault with Carminat TomTom), but the connection breaks within 2 sec. after connecting.

The sad thing is that it did work a bit before OTA 9.

Will this be fixed by the new silo?

Revision history for this message
Cesar Herrera (chg1) wrote :

Hellow Konrad:
I enable the developer mode, connect the phone to the computer and write adb shell in a terminal.
It shows this:

c@C:~$ adb shell
* daemon not running. starting it now on port 5037 *
* daemon started successfully *
error: device not found
c@C:~$

I don't know how to continue.
Cheers,
Cesar

----------------------------------------
> Date: Thu, 28 Jul 2016 08:54:41 +0000
> From: <email address hidden>
> To: <email address hidden>
> Subject: [Bug 1539158] Re: Unable to pair with in-car hands-free system after OTA-9 update
>
> Hey,
>
> I'll try to help a bit here.
>
> First as for the unknown or unwanted entries on the paired devices lists
> [and such] you can try to remove them from the bluetoothctl level.
>
> ) enable developers mode & connect it via usb cable
> ) login with adb shell to the deivce
> ) type $ bluetoothctl
> ) then type: devices - to list the known devices
> ) to remove type: remove $BDADDR - where BDADDR is a Bluetooth address of the device [not it's name]
>
> Second we are in the of releasing the newest bluez 5.41 which is now in
> silo 37. If you are familiar with installing silos on your device you
> can try it out and check if it improves anything. It includes fixes for
> link management and pairing therefore there is a chance [although not
> certain] that there might be joy.
>
> If unsure please ask.
>
> Best,
> Konrad
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1539158
>
> Title:
> Unable to pair with in-car hands-free system after OTA-9 update
>
> Status in Canonical System Image:
> Fix Released
> Status in bluez package in Ubuntu:
> Confirmed
> Status in ubuntu-system-settings package in Ubuntu:
> Fix Released
>
> Bug description:
> After OTA-9 I started having trouble with my bluetooth connection to the car hands-free system (no sound, and incoming calls no longer displayed the number), so I have reset both the car and the phone connections (eg. forgot the devices).
> Now I can't even pair the phone with the car's system.
> The car finds the phone, and then asks me to enter the code "0000" to pair the device, but after a few moments, it just says the connection failed and asks me to try again. Which fails again.
>
> It was working fine just before the update.
>
> Any logs I should post to help debug?
>
> PS - The car is a 2015 Honda Civic Tourer, if that matters.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/canonical-devices-system-image/+bug/1539158/+subscriptions

Revision history for this message
Marco Graziotti (graziottimarco) wrote :

Hi Konrad,

I tried to remove the "Nissan Connect" device, but i got this error:
"*Failed to remove device: org.bluez.Error.NotReady*".
Here you can read what I'm doing:

*user@user-laptop:~$ adb shell*
* daemon not running. starting it now on port 5037 *
* daemon started successfully *

phablet@ubuntu-phablet:~$ $ bluetoothctl
bash: $: command not found

*phablet@ubuntu-phablet:~$ bluetoothctl*
[NEW] Controller 38:BC:1A:29:69:4B MX4 Ubuntu Edition [default]
[NEW] Device 90:F1:AA:7B:80:0F [Samsung] Soundbar
[NEW] Device 60:38:0E:59:32:39 NISSAN CONNECT

*[bluetooth]# devices*
Device 90:F1:AA:7B:80:0F [Samsung] Soundbar
Device 60:38:0E:59:32:39 NISSAN CONNECT

*[bluetooth]# remove 60:38:0E:59:32:39**
**Failed to remove device: org.bluez.Error.NotReady*

What can I do?

Thank you

Il 28/07/2016 10:54, Konrad Zapałowicz ha scritto:
> Hey,
>
> I'll try to help a bit here.
>
> First as for the unknown or unwanted entries on the paired devices lists
> [and such] you can try to remove them from the bluetoothctl level.
>
> ) enable developers mode & connect it via usb cable
> ) login with adb shell to the deivce
> ) type $ bluetoothctl
> ) then type: devices - to list the known devices
> ) to remove type: remove $BDADDR - where BDADDR is a Bluetooth address of the device [not it's name]
>
> Second we are in the of releasing the newest bluez 5.41 which is now in
> silo 37. If you are familiar with installing silos on your device you
> can try it out and check if it improves anything. It includes fixes for
> link management and pairing therefore there is a chance [although not
> certain] that there might be joy.
>
> If unsure please ask.
>
> Best,
> Konrad
>

Revision history for this message
Konrad Zapałowicz (kzapalowicz) wrote :

What is your phone?

Revision history for this message
Konrad Zapałowicz (kzapalowicz) wrote :

Marco,

this is super strange, I will think of possible solutions however in the
meantime what is the output from

info 60:38:0E:59:32:39

Thanks,
K

On Fri, Jul 29, 2016 at 12:40 PM, Marco Graziotti <email address hidden>
wrote:

> Hi Konrad,
>
> I tried to remove the "Nissan Connect" device, but i got this error: "*Failed
> to remove device: org.bluez.Error.NotReady*".
> Here you can read what I'm doing:
>
> *user@user-laptop:~$ adb shell*
> * daemon not running. starting it now on port 5037 *
> * daemon started successfully *
>
> phablet@ubuntu-phablet:~$ $ bluetoothctl
> bash: $: command not found
>
> *phablet@ubuntu-phablet:~$ bluetoothctl*
> [NEW] Controller 38:BC:1A:29:69:4B MX4 Ubuntu Edition [default]
> [NEW] Device 90:F1:AA:7B:80:0F [Samsung] Soundbar
> [NEW] Device 60:38:0E:59:32:39 NISSAN CONNECT
>
> *[bluetooth]# devices*
> Device 90:F1:AA:7B:80:0F [Samsung] Soundbar
> Device 60:38:0E:59:32:39 NISSAN CONNECT
>
> *[bluetooth]# remove 60:38:0E:59:32:39*
> *Failed to remove device: org.bluez.Error.NotReady*
>
> What can I do?
>
> Thank you
>
>
> Il 28/07/2016 10:54, Konrad Zapałowicz ha scritto:
>
> Hey,
>
> I'll try to help a bit here.
>
> First as for the unknown or unwanted entries on the paired devices lists
> [and such] you can try to remove them from the bluetoothctl level.
>
> ) enable developers mode & connect it via usb cable
> ) login with adb shell to the deivce
> ) type $ bluetoothctl
> ) then type: devices - to list the known devices
> ) to remove type: remove $BDADDR - where BDADDR is a Bluetooth address of the device [not it's name]
>
> Second we are in the of releasing the newest bluez 5.41 which is now in
> silo 37. If you are familiar with installing silos on your device you
> can try it out and check if it improves anything. It includes fixes for
> link management and pairing therefore there is a chance [although not
> certain] that there might be joy.
>
> If unsure please ask.
>
> Best,
> Konrad
>
>
>
>

Revision history for this message
Marco Graziotti (graziottimarco) wrote :

Hi Konrad,

the problem was that my bluetooth is turned off :D :D
Now I'm able to remove the NISSAN CONNECT device

[bluetooth]# remove 60:38:0E:59:32:39
[DEL] Device 60:38:0E:59:32:39 NISSAN CONNECT
Device has been removed

Now I will try to pair it again.

Thank you,
Marco

Il 29/07/2016 12:43, Konrad Zapałowicz ha scritto:
> Marco,
>
> this is super strange, I will think of possible solutions however in
> the meantime what is the output from
>
> info 60:38:0E:59:32:39
>
> Thanks,
> K
>
> On Fri, Jul 29, 2016 at 12:40 PM, Marco Graziotti
> <<email address hidden> <mailto:<email address hidden>>> wrote:
>
> Hi Konrad,
>
> I tried to remove the "Nissan Connect" device, but i got this
> error: "*Failed to remove device: org.bluez.Error.NotReady*".
> Here you can read what I'm doing:
>
> *user@user-laptop:~$ adb shell*
> * daemon not running. starting it now on port 5037 *
> * daemon started successfully *
>
> phablet@ubuntu-phablet:~$ $ bluetoothctl
> bash: $: command not found
>
> *phablet@ubuntu-phablet:~$ bluetoothctl*
> [NEW] Controller 38:BC:1A:29:69:4B MX4 Ubuntu Edition [default]
> [NEW] Device 90:F1:AA:7B:80:0F [Samsung] Soundbar
> [NEW] Device 60:38:0E:59:32:39 NISSAN CONNECT
>
> *[bluetooth]# devices*
> Device 90:F1:AA:7B:80:0F [Samsung] Soundbar
> Device 60:38:0E:59:32:39 NISSAN CONNECT
>
> *[bluetooth]# remove 60:38:0E:59:32:39**
> **Failed to remove device: org.bluez.Error.NotReady*
>
> What can I do?
>
> Thank you
>
>
> Il 28/07/2016 10:54, Konrad Zapałowicz ha scritto:
>> Hey,
>>
>> I'll try to help a bit here.
>>
>> First as for the unknown or unwanted entries on the paired devices lists
>> [and such] you can try to remove them from the bluetoothctl level.
>>
>> ) enable developers mode & connect it via usb cable
>> ) login with adb shell to the deivce
>> ) type $ bluetoothctl
>> ) then type: devices - to list the known devices
>> ) to remove type: remove $BDADDR - where BDADDR is a Bluetooth address of the device [not it's name]
>>
>> Second we are in the of releasing the newest bluez 5.41 which is now in
>> silo 37. If you are familiar with installing silos on your device you
>> can try it out and check if it improves anything. It includes fixes for
>> link management and pairing therefore there is a chance [although not
>> certain] that there might be joy.
>>
>> If unsure please ask.
>>
>> Best,
>> Konrad
>>
>
>

Revision history for this message
Marco Graziotti (graziottimarco) wrote :

Hi Konrad,

I tryed to pair again the phone with my car, but it don't work. The car
say "Pairing failed".
After this, to remove the device, I needed to use the terminal again.

To resolve, I need to wait for OTA-13, or I need instruction for
installing the new bluez silo.

Thank you,
Marco

Il 29/07/2016 12:43, Konrad Zapałowicz ha scritto:
> Marco,
>
> this is super strange, I will think of possible solutions however in
> the meantime what is the output from
>
> info 60:38:0E:59:32:39
>
> Thanks,
> K
>
> On Fri, Jul 29, 2016 at 12:40 PM, Marco Graziotti
> <<email address hidden> <mailto:<email address hidden>>> wrote:
>
> Hi Konrad,
>
> I tried to remove the "Nissan Connect" device, but i got this
> error: "*Failed to remove device: org.bluez.Error.NotReady*".
> Here you can read what I'm doing:
>
> *user@user-laptop:~$ adb shell*
> * daemon not running. starting it now on port 5037 *
> * daemon started successfully *
>
> phablet@ubuntu-phablet:~$ $ bluetoothctl
> bash: $: command not found
>
> *phablet@ubuntu-phablet:~$ bluetoothctl*
> [NEW] Controller 38:BC:1A:29:69:4B MX4 Ubuntu Edition [default]
> [NEW] Device 90:F1:AA:7B:80:0F [Samsung] Soundbar
> [NEW] Device 60:38:0E:59:32:39 NISSAN CONNECT
>
> *[bluetooth]# devices*
> Device 90:F1:AA:7B:80:0F [Samsung] Soundbar
> Device 60:38:0E:59:32:39 NISSAN CONNECT
>
> *[bluetooth]# remove 60:38:0E:59:32:39**
> **Failed to remove device: org.bluez.Error.NotReady*
>
> What can I do?
>
> Thank you
>
>
> Il 28/07/2016 10:54, Konrad Zapałowicz ha scritto:
>> Hey,
>>
>> I'll try to help a bit here.
>>
>> First as for the unknown or unwanted entries on the paired devices lists
>> [and such] you can try to remove them from the bluetoothctl level.
>>
>> ) enable developers mode & connect it via usb cable
>> ) login with adb shell to the deivce
>> ) type $ bluetoothctl
>> ) then type: devices - to list the known devices
>> ) to remove type: remove $BDADDR - where BDADDR is a Bluetooth address of the device [not it's name]
>>
>> Second we are in the of releasing the newest bluez 5.41 which is now in
>> silo 37. If you are familiar with installing silos on your device you
>> can try it out and check if it improves anything. It includes fixes for
>> link management and pairing therefore there is a chance [although not
>> certain] that there might be joy.
>>
>> If unsure please ask.
>>
>> Best,
>> Konrad
>>
>
>

Revision history for this message
Konrad Zapałowicz (kzapalowicz) wrote :

Hey,

We might have fix for issues where the pairing is initiated by the car. It is currently in silo 46 and we are working towards including it in the next OTA update.

Best,
Konrad

Revision history for this message
Stunts (f-pinamartins) wrote :

Hi Konrad,

OTA13 freeze is tomorrow. Is the fix from silo 46 landing there? The latest upstream Bluez is mentioned in the landings email, but I didn't see any references to this issue (but I could have missed it in a previous email).
Thanks.

Revision history for this message
Konrad Zapałowicz (kzapalowicz) wrote :

Hey,

Silo 46 is next in queue to land just needs a little bit of tweaking after the recent landings of Ubuntu System Settings. I expect it to be the part of OTA13.

Revision history for this message
Konrad Zapałowicz (kzapalowicz) wrote :

For you to know that silo has landed and will be a part of OTA13

Revision history for this message
Stunts (f-pinamartins) wrote :

Thank you Konrad!
Eagerly waiting for OTA13.

Revision history for this message
Stunts (f-pinamartins) wrote :

YES! Confirming that OTA13 has solved the pairing issue. I can now pair my BQ Aquaris E4.5 with the HFS without any problems.

Furthermore - once pairing is done, I get the "volume" notification with the title: "Bluetooth speakers" and I can play music via the car's speakers (albeit I can't control the playback via the physical buttons on the car, but that is bug #1398193 (https://bugs.launchpad.net/ubuntu/+source/bluez/+bug/1398193)).
Also, if I try to place a call I get the "volume" notification again, switching back to the phone's speakers. However, I get no audio neither in the car's speakers, nor in the phone's speakers. After the call ends, I get the "volume" notification again switching to the "bluetooth speakers" (but that is bug #1578176 (https://bugs.launchpad.net/ubuntu/+source/bluez/+bug/1578176).

Can anyone else confirm that pairing is now working as intended?

Revision history for this message
Marco Graziotti (graziottimarco) wrote :

In my own case the problem remain the same. No difference between OTA-12 and 13 on Meizu MX4, pairing process always fail.
Also I can't remove "Nissan Connect" device, to remove it I needed to use the terminal again.

How can I provide more details?

Thank you

Revision history for this message
Cesar Herrera (chg1) wrote :

With OTA-13 I can't pair to Citroen C4 either.
Cheers

Revision history for this message
Cesar Herrera (chg1) wrote :

I forgot to say my phone is BQ E4.5

Revision history for this message
Stunts (f-pinamartins) wrote :

@Marco and @Cesar:
Were you able to pair the phone with the car's HFS before OTA9?
If that is not the case, you may wish to track bug #1435040 (if you are not tracking it already).

Revision history for this message
Cesar Herrera (chg1) wrote :

I only paired with very old OTA's. It was when started the E4.5

Revision history for this message
Marco Graziotti (graziottimarco) wrote :

I bought MX4 when it was released in Europe and Italy (more then 1 year ago), I don't remember what number of version it was. Maybe OTA-10?

I'm never been able to pair MX4 with Nissan Connect system. What can I do?

Revision history for this message
Stunts (f-pinamartins) wrote :

Ok, so it turns out I'm still having some issues with this after OTA-14.
I can still pair the phone with the Hands Free System (HFS), but...
I can only do this if I make the phone search for the HFS. If I try the pairing by having the HFS search for the phone, I get an error - the PIN (hardcoded to 0000) is requested by the HFS, but the phone never displays any requests, and the connection fails with an error.
Would a new log file, this time with this very behaviour, be interesting for further debugging?

tags: added: ubuntu-touch
tags: removed: ubuntu-touch
Revision history for this message
Daniel van Vugt (vanvugt) wrote :

Reduced priority for Ubuntu Touch bugs.

Changed in bluez (Ubuntu):
importance: High → Medium
Revision history for this message
Daniel van Vugt (vanvugt) wrote :

Ubuntu Touch is no longer supported.

Changed in bluez (Ubuntu):
status: Confirmed → Won't Fix
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.