[upstream] Regression: cannot use impress remote over bluetooth with ubuntu bionic

[Sergio Callegari]

Trying to use the impress remote (https://wiki.documentfoundation.org/Impress_Remote) over bluetooth with libreoffice over ubuntu bionic fails.

The handset errors out that it cannot connect with Libreoffice on the computer even if the bluetooth adapter on the handset and on the computer are correctly paired.

This does not seem to be an issue in the Libreoffice or in the impress remote code:

- I have tested also past LibO versions
- The Impress remote codebase has not changed recently

This used to work on the same hardware (headset and laptop) with ubuntu 16.04.

Hence the issue seems to be in a regression in the ubuntu bluetooth stack.

To replicate:

1) Install Libreoffice on Ubuntu bionic (either from the ubuntu repo or with the deb packages from the document fundation)

2) Assure that your computer has bluetooth

3) Install impress remote on an android handset (either from the play store of via fdroid)

4) Assure that "remote control" is enabled in impress Tools>Options>Impress>General

5) Pair the bluetooth adapters in the laptop and in the computer

6) Open a presentation on the laptop

7) Open the remote on the handset, got to the bluetooth pane see the computer there, touch it

8) See the impress remote erroring out

Most likely you will also get a bluetooth error on dmesg

RFCOMM server failed for LibreOffice Impress Remote: rfcomm_bind: Address already in use (98)

Same issue was reported for fedora

ProblemType: Bug
DistroRelease: Ubuntu 18.04
Package: bluez 5.48-0ubuntu3.1
ProcVersionSignature: Ubuntu 4.15.0-36.39-generic 4.15.18
Uname: Linux 4.15.0-36-generic x86_64
ApportVersion: 2.20.9-0ubuntu7.4
Architecture: amd64
CurrentDesktop: KDE
Date: Wed Oct 17 16:57:29 2018
EcryptfsInUse: Yes
InstallationDate: Installed on 2013-12-12 (1769 days ago)
InstallationMedia: Kubuntu 13.10 "Saucy Salamander" - Release amd64 (20131016.1)
InterestingModules: rfcomm bnep btusb bluetooth
MachineType: Notebook W740SU
ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-4.15.0-36-generic root=/dev/mapper/zagar_ssd--vg-root ro quiet splash resume=/dev/zagar_ssd-vg/swap_1 acpi_backlight=vendor vt.handoff=1
SourcePackage: bluez
UpgradeStatus: Upgraded to bionic on 2018-06-08 (131 days ago)
dmi.bios.date: 10/02/2013
dmi.bios.vendor: American Megatrends Inc.
dmi.bios.version: 4.6.5
dmi.board.asset.tag: Tag 12345
dmi.board.name: W740SU
dmi.board.vendor: Notebook
dmi.board.version: Not Applicable
dmi.chassis.asset.tag: No Asset Tag
dmi.chassis.type: 9
dmi.chassis.vendor: Notebook
dmi.chassis.version: N/A
dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvr4.6.5:bd10/02/2013:svnNotebook:pnW740SU:pvrNotApplicable:rvnNotebook:rnW740SU:rvrNotApplicable:cvnNotebook:ct9:cvrN/A:
dmi.product.family: Not Applicable
dmi.product.name: W740SU
dmi.product.version: Not Applicable
dmi.sys.vendor: Notebook
hciconfig:
 hci0: Type: Primary Bus: USB
  BD Address: 00:C2:C6:1A:28:71 ACL MTU: 310:10 SCO MTU: 64:8
  UP RUNNING PSCAN ISCAN
  RX bytes:245088 acl:15156 sco:0 events:1266 errors:0
  TX bytes:15571 acl:402 sco:1 commands:131 errors:0

[Sergio Callegari (callegar)]

See https://bugzilla.redhat.com/show_bug.cgi?id=1581879

[Cristian Aravena Romero (caravena)]

Did this issue start happening after an update/upgrade? Was there a
prior kernel version where you were not having this particular problem?

Would it be possible for you to test the latest upstream kernel? Refer
to https://wiki.ubuntu.com/KernelMainlineBuilds . Please test the latest
v4.19 kernel[0].

If this bug is fixed in the mainline kernel, please add the following
tag 'kernel-fixed-upstream'.

If the mainline kernel does not fix this bug, please add the tag:
'kernel-bug-exists-upstream'.

Once testing of the upstream kernel is complete, please mark this bug as
"Confirmed".

Thanks in advance.

[0] http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.19-rc8

[Sergio Callegari (callegar)]

Description:
The fault seems to be on the Libreoffice application running on the computer, not on the android impress remote app.

Running libreoffice, the computer reports a bluetoothd error on syslog, namely

bluetoothd[1491]: RFCOMM server failed for LibreOffice Impress Remote: rfcomm_bind: Address already in use (98)

After that the remote handset cannot connect via bluetooth to LibO even if the the bluetooth adapters in the computer and the handset are paired.

The issue appears in the bug trackers of both Ubuntu and Fedora and regards Ubuntu 18.04 and Fedora 27.

I am 100% sure that in the past the impress remote was working via bluetooth on the same hardware (both computer and handset).

It is unclear to me if the issue is with the bluetooth stack of recent linux distros (bluez? kernel?) or if something has changed in it and LibO is trying to still use it in some old way that is now wrong.

The issue is now present using any LibO version from 5.4 to 6.1.

See https://bugzilla.redhat.com/show_bug.cgi?id=1581879
and https://bugs.launchpad.net/bugs/1798400

Steps to Reproduce:
See description

Actual Results:
See description

Expected Results:
See description

Reproducible: Always

User Profile Reset: No

Additional Info:
[Information automatically included from LibreOffice]
Locale: en-US
Module: StartModule
[Information guessed from browser]
OS: Linux (All)
OS is 64bit: yes

[Sergio Callegari (callegar)]

I have stayed a long time without trying impress remote, so I do not know exactly when the issue started. However, I am sure that last year at this time (aka on 16.04) the issue did not exist.

Just tried latest non-RC kernel from mainline 4.18.x and the issue is still there.

[Sergio Callegari (callegar)]

I think that the issue can be either a bug in the bluetooth stack or merely something that has /changed/ in the bluetooth stack, that libreoffice has not tracked properly. Hence, I have also opened a bug upstream for LibO, mentioning this one.

[Daniel van Vugt (vanvugt)]

I agree this is most likely a LibO bug, as is:
https://bugzilla.redhat.com/show_bug.cgi?id=1581879

[Launchpad Janitor (janitor)]

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

[Sergio Callegari (callegar)]

Still present in 6.2.0 RC 1

[CL0NE (cl0ne)]

Can confirm on Arch Linux with LO version 6.2.3.2

[Xiscofauli (xiscofauli)]

Thank you for reporting the bug.
Could you please try to reproduce it with a master build from http://dev-builds.libreoffice.org/daily/master/ ?
You can install it alongside the standard version.
I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' if the bug is still present in the master build

[Sergio Callegari (callegar)]

Cannot test daily builds right now, but 6.3.0 beta 1 still has the issue.
Launching impress reports:
bluetoothd[1386]: RFCOMM server failed for LibreOffice Impress Remote: rfcomm_bind: Address already in use (98)
in the system logs and then the remote app cannot contact the host.

[Qa-admin-q (qa-admin-q)]

[Automated Action] NeedInfo-To-Unconfirmed

[Sergio Callegari (callegar)]

Issue persists with current LibO 6.3.1.2 and most likely due to the fact that the bluetooth stack on linux (bluez) has changed in the past years and impress has not cought up.

Problem is now more visible due to the startup tooltips in Impress 6.3.x which explicitly introduce the impress remote functionality inviting the users to test it. Goes like: start Impress -> see tooltip -> get interested -> download and install phone app -> try -> fail -> get disappointed and remove phone app.

Because the phone based remote is one of those little things with a great wow factor that makes LibO really shine out and amaze people when used in front of an audience, it would really be great if the functionality could be restored. It is literally a little big thing helping getting a foot in the door.

In fact, I suppose that if one could also add a "spotlight" and "zoom" functionality in it (in addition to the pointer) and the ability to use the phone accelerometers for moving the pointer (in place of the finger on the screen) it would make LibO a serious contender for all those coveting the "Logitech spotlight" that is currently the hot thing in presentations selling for over $100. See also https://github.com/jahnf/Projecteur .

[Sergio Callegari (callegar)]

Wonder if it could be useful to kindly ask Andrzej Hunt if he can look into the issue. If I am not wrong he is the author of the current bluez 5 code in Impress.

[John Poole (jlpoole)]

Here is a link to the code (& log) regarding the impress remote project:
https://cgit.freedesktop.org/libreoffice/impress_remote/

I have a presentation upcoming in three days and really would have liked to use the remote feature to impress/wow the audience. There's not enough time for me to dig into the code and try to determine the state of bluetooth vis-a-vis Android and Impress. Looks like something that might require 10-20 hours to master just to assess.

Agree: it doesn't behoove the project to advertise features which may not work, e.g. remote impress.

Using Gentoo Linux (4.19.72-gentoo) on a Dell Inspiron 17 5000 laptop purchased October 2018 (Bluetooth 4) with net-wireless/bluez 5.50-r2 against an Android 7.0, kernel version 3.10.49, model LGL158VL

[Sergio Callegari (callegar)]

Issue still present in LibO 6.4.3.1.

I see the bug as still unconfirmed after more than one year. I wonder if it could be confirmed, given that the same issue has also been reported for redhat (https://bugzilla.redhat.com/show_bug.cgi?id=1581879)

[Sergio Callegari (callegar)]

@John Poole

Can you please indicate that you are also experiencing the issue in the issue tracker at the document foundation at https://bugs.documentfoundation.org/show_bug.cgi?id=120663 ?

The issue is still "unconfirmed" there, and until it is "confirmed" by multiple reporters, there is little chance that it can be dealt with.

[Sergio Callegari (callegar)]

The bug is also confirmed in the ubuntu launchpad at https://bugs.launchpad.net/ubuntu/+source/bluez/+bug/1798400.

Users there are reporting that they are experiencing the issue in ubuntu (from bionic, I think) and gentoo. This adds to the reports in fedora and to the confirmation here on arch linux.

I think that this is enough to mark as "NEW"

[Sergio Callegari (callegar)]

Andrzej, I am CC-ing you on this, because I believe that you were one of the original corder of the BT code for the impress remote on linux. I hope that you may able to provide some advice on this. If I'm wrong, please take my apology for the noise.

[Kilasa4010 (kilasa4010)]

Can confirm that my samsung galaxy running Android 9 and linux mint 19.3 are still not working appropriately with the impress remote. It refuses to connect via bluetooth no matter what I do.

[Felix-huber (felix-huber)]

This issue was annoying me for a while too. So I sat down and debugged bluez to see why the bind fails: LO is using the default channel (3) for the RFCOMM protocol as it should be. However, the bind call fails, because another process has already bound that channel via DBUS. Changing the default RFCOMM channel in the bluez source temporaliy to 2 (UDP, unused) and recompiling bluez made remote impress work immediately!

So I inspected the DBUS users via the old mdbus tool from openmoko and it turned out that the other process is PulseAudio: The HS profile needs the RFCOMM for the AT Commands and registers channel 3. Stop PA and impress remote works again.

So now we have two programs that need RFCOMM for the mobile phone. :-(
One solution would be that LO explicitly requests channel 2 instead of the default one. Channel 2 is UDP and unused to my knowledge. This will work until another programm needs RFCOMM and chooses 2 as a free channel...

Or, in the long run, there needs to be some kind of multipexing between the apps that use the RFCOMM protocol.

[Sergio Callegari (callegar)]

Thanks for the analysis!

From it, I still wonder whether this is a pulseaudio bug, though. Why is pulseaudio ever binding to RFCOMM channel 3 *before* there is any need to do so? That is, until I am not connected to any device using channel 3, why is pulseaudio already using it up?

In other words, it seems reasonable to me to have the laptop connected to the phone as a headset and in this case not to have the impress remote working. But in case I start impress before setting up a bluetooth connection to the phone, why should be the pulseaudio binding already there?

[Sergio Callegari (callegar)]

The premise is that my ignorance on BT is complete. After some investigation, it is my understanding that RFCOMM channels are to RFCOMM communication a bit like ports in TCP and UDP, with the main difference that while there are really a lot of TCP/UDP ports and some of them are reserved as "well known ports", the number of channels in RFCOMM is extremely limited, so that there cannot be well known ports. Furthermore, I understand that no one should "hardwire" RFCOMM channels and that channels should be released whenever not strictly needed.

If this understanding from myself is correct, there may be issues both in LibO and in PA.
From my understanding:

- LibO and the Impress remote should not hardwire RFCOMM channel 3. I understand that they should dynamically allocate a channel and make it discoverable via SDP.

- Impress should not keep binded to an RFCOMM channel all the time. There should be a visible option to switch on and off the binding (probably there should be a couple of impress remote related options in the "Slide Show -> Slide Show Settings" window, including one to fire up the BT rfcomm binding).

- PA should probably similarly not hardwire channel 3 for its HSP role, but here the situation seems more complex, because it may be the case that PA needs to strive for compatibility with devices that do not play to the rules.

- PA should probably have a DBUS interface to switch on and off the RFCOMM binding, so that to use an application needing RFCOMM channel 3, one does not need to take down the whole of PA.

I have opened a bug on PA too. See it at https://gitlab.freedesktop.org/pulseaudio/pulseaudio/issues/827. That report is bad, because when I made it my understanding of BT was even poorer than it is now.

In any case, it seems to me that the current issue could be fixed completely on the LibO side, by dynamically allocating the channel and by letting the app running on the phone discover it via SDP.

[Qa-admin-q (qa-admin-q)]

Dear sergio.callegari,

To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year.

There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present.

If you have time, please do the following:

Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/

If the bug is present, please leave a comment that includes the information from Help - About LibreOffice.

If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice.

Please DO NOT

Update the version field
Reply via email (please reply directly on the bug tracker)
Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not
appropriate in this case)

If you want to do more to help you can test to see if your issue is a REGRESSION. To do so:
1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/

2. Test your bug
3. Leave a comment with your results.
4a. If the bug was present with 3.3 - set version to 'inherited from OOo';
4b. If the bug was not present in 3.3 - add 'regression' to keyword

Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa

Thank you for helping us make LibreOffice even better for everyone!

Warm Regards,
QA Team

MassPing-UntouchedBug

[Sergio Callegari (callegar)]

The bug is still there as of LibO 7.3.x. Up in comment 12 (https://bugs.documentfoundation.org/show_bug.cgi?id=120663#c12) there is a nice analysis of the underlying problem why the remote cannot work.

Established that, I think that most users go used to the fact that the remote functionality does not work in linux. Personally, I have uninstalled the android app on the phone so I do not have an unfortunate reminder about it. In fact, the real issue is probably the advertisement of a functionality that is not there.

For the time being I suggest disabling the remote-via-bluetooth functionality in linux and closing the bug by simply saying that the remote via bluetooth cannot be supported on linux where there are evidently issues that span other software pieces such as the bluetooth stack and pulse audio. To the best of my understanding, these involve the hijacking of the default rfcomm channel by pulse audio before it even needs it and the lack of a standard approach to let other applications find a free channel to use and advertise it to their counterparts.

Alternatively (but I would not consider this a good solution), the configuration options could be enhanced to add the possibility to choose a bluetooth channel in libreoffice and in the mobile phone application, so that the user can manually work around the fact that the predefined channel is locked by some other application.

As a final point, note that even if the remote-via-wifi may seem a good alternative, in fact in most cases it is practically useless. In most cases, presentations will not be given at a place where you control the network, but at sites with site-provided wifi, such as universities, schools, conference places, business sites, etc. All these locations tend to have wifi deployments that block stuff on the ports used by impress remote.

[Sergio Callegari (callegar)]

Bug still there. In most situations the remote cannot be used at all. Not via bluetooth (because of this issue), neither via wifi (because you typically do presentations at sites where you do not control the wifi network and traffic to the relevant ports gets blocked). Suggested upstream some possible solutions including stop advertising the functionality. Consider closing as Wontfix because I think there is really nothing that downstream can do about it.

[Sergio Callegari (callegar)]

Noticed that among the many tips of the day, LibO also suggests to use Android or IPhone to remotely control an Impress presentation. The "more info" page then excplicitly declares that the feature is cross platform "GNU/Linux, Windows or macOS." either via Bluetooth or Wifi.

However to use the feature with bluetooth on linux has been impossible for the last 5 years, because the feature is broken on this platform (this bug provides a diagnosis of the underlying issue). Using the feature with wifi is equally problematic, because those places where you need to deliver a presentation are typically those very places where you do not control the wifi network that may make it impossible for the computer and the phone to communicate.

As a consequence, this tip of the day looks inappropriate on linux, making many users waste a significant amount of time trying to use a feature that simply cannot work. May I suggest removing this tip of the day on linux?

[Sergio Callegari (callegar)]

Noticed that in the forthcoming LibO 24.2, the "remote" is being given prominence, by moving its settings from the Tools ▸ Options ▸ LibreOffice Impress configuration dialog to the Slide Show ▸ Slide Show Settings menu.

IMHO this makes it quite important to have this feature working as intended on all the supported platforms.

The remote is meant to work either with a WIFI connection or a Bluetooth one.

The current bug is about the Bluetooth connection.

Bluetooth Connection
--------------------

As of today, because of the issue at hand, the Bluetooth connection is completely unusable on standard Linux distributions that use Pulseaudio (a detailed discussion why is in the previous comments).

Notwithstanding the fact that this but is about the Bluetooth connection, I am providing also a few notes about the Wifi connection to highlight why the Bluetooth connection is so important and should be fixed.

WIFI Connection
---------------

Unfortunately, the WIFI option is practically unusable in almost every professional working environment, including universities and conferencing sites. This is because in all these environments the network is completely out of the user control, restricted in any possible way, heavily firewalled, with the wifi framework consisting of multiple access points under the same SSID. In a similar arrangement the possibility of the remote to reach LibO at a non-standard TCP port is erratic if not negligible.

The impossibility to use the WIFI connection precisely in those real world environments where the usage of the remote would be most important is the reason why a working Bluetooth connection is needed.

Note that in practice the WIFI connection situation could be improved by suggesting the possibility to let the presenter laptop connect to the internet via the mobile phone hotspot. This would need the remote app to try to connect to LibO not just via the phone default interface, but also on the network used for the hotspot.