Bug 120663 - No impress remote: Impress incompatible with current bluetooth stack on linux (RFCOMM server failed for LibreOffice Impress Remote: rfcomm_bind: Address already in use)
Summary: No impress remote: Impress incompatible with current bluetooth stack on linux...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
6.1.2.1 release
Hardware: All Linux (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-10-17 15:57 UTC by Callegar
Modified: 2020-03-17 19:10 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Callegar 2018-10-17 15:57:39 UTC
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
Comment 1 Callegar 2018-12-21 21:44:15 UTC
Still present in 6.2.0 RC 1
Comment 2 Vladislav Glinsky 2019-05-04 16:40:31 UTC
Can confirm on Arch Linux with LO version 6.2.3.2
Comment 3 Xisco Faulí 2019-06-10 15:40:43 UTC
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
Comment 4 Callegar 2019-06-10 16:32:40 UTC
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.
Comment 5 QA Administrators 2019-06-11 03:01:43 UTC Comment hidden (obsolete)
Comment 6 Callegar 2019-09-04 10:12:24 UTC
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 .
Comment 7 Callegar 2019-09-04 10:18:27 UTC
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.
Comment 8 Callegar 2019-12-10 13:43:50 UTC
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)
Comment 9 Callegar 2019-12-19 10:18:04 UTC
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"
Comment 10 Callegar 2019-12-19 10:29:47 UTC
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.
Comment 11 kilasa4010 2019-12-27 03:12:29 UTC
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.
Comment 12 felix.huber 2020-02-20 18:08:27 UTC
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.
Comment 13 Callegar 2020-02-20 18:19:10 UTC
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?
Comment 14 Callegar 2020-03-17 19:10:05 UTC
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.