[Bug 1214409] New: bluetooth file transfer not working
https://bugzilla.suse.com/show_bug.cgi?id=1214409 Bug ID: 1214409 Summary: bluetooth file transfer not working Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.5 Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: KDE Workspace (Plasma) Assignee: opensuse-kde-bugs@opensuse.org Reporter: comes@naic.edu QA Contact: qa-bugs@suse.de Target Milestone: --- Found By: --- Blocker: --- In Leap 15.4 I'm able to transfer files via bluetooth from my android phone to the plasma desktop. In Leap 15.5 it is not possible. After some investigation I found two different causes for such failure. 1) In order to transfer files to the desktop, the obexd daemon must be running. In Leap 15.4 such program was part of the bluez rpm. In Leap 15.5 obexd is part of the bluez-obexd rpm but such package is not installed during the plasma installation. I guess the fix should be that the package bluedevil5 should require bluez-obexd. This is a plasma bug I think. 2) Once bluez-obexd is installed, the file transfer via bluetooth still doesn't work. And that's because the obexd daemon is not running. It is supposed to be started by systemd but it is not. After I run manually /usr/lib/bluetooth/obexd then the file transfer via bluetooth to the plasma desktop works. This is either a bluez bug (incorrect systemd configuration) or a systemd bug. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1214409 https://bugzilla.suse.com/show_bug.cgi?id=1214409#c1 Fabian Vogt <fabian@ritter-vogt.de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |fabian@ritter-vogt.de --- Comment #1 from Fabian Vogt <fabian@ritter-vogt.de> --- Duplicate of bug 1198626? -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1214409 https://bugzilla.suse.com/show_bug.cgi?id=1214409#c2 --- Comment #2 from Giacomo Comes <comes@naic.edu> --- (In reply to Fabian Vogt from comment #1)
Duplicate of bug 1198626? Yes and no. The source of the problem is the change in the bluez package. obexd now is in a separate rpm and it needs systemctl --user to get activated. In the past all it was necessary was to install the rpm bluez. After reading boo#1198626 I came to the conclusion that now each desktop environment needs to take care to install bluez-obexd and start the obex service.
For plasma it means: In the package powerdevil5, in the file /usr/lib/systemd/user/plasma-powerdevil.service, add the line: [Unit] Description=Powerdevil PartOf=graphical-session.target After=plasma-core.target +Wants=obex.service and also add: Requires: bluez-obexd in the spec file of either powerdevil5 or bluedevil5 (which one do you think is more appropriate?). I tested such changes and with them in place, bluetooth now works in Leap 15.5 as it was working in 15.4. Please let me know your thoughts so I can submit a sr for tumbleweeed. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1214409 https://bugzilla.suse.com/show_bug.cgi?id=1214409#c3 --- Comment #3 from Fabian Vogt <fabian@ritter-vogt.de> --- Yeah, arguably bluedevil5 should require bluez-obexd. But obexd.service needs to be dbus activated, not unconditionally started by Plasma or each DE individually. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1214409 https://bugzilla.suse.com/show_bug.cgi?id=1214409#c4 --- Comment #4 from Giacomo Comes <comes@naic.edu> --- (In reply to Fabian Vogt from comment #3)
But obexd.service needs to be dbus activated, not unconditionally started by Plasma or each DE individually.
If I understand correctly, you mean that the fix has to come from the bluez-obexd package. Unfortunately boo#1198626 has been sitting there unfixed for 16 months. I have almost no experience with dbus, so at the moment I cannot be of much help. Can you point me to some documentation where I can better understand the dbus/systemd business? -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1214409 https://bugzilla.suse.com/show_bug.cgi?id=1214409#c5 --- Comment #5 from Fabian Vogt <fabian@ritter-vogt.de> --- (In reply to Giacomo Comes from comment #4)
(In reply to Fabian Vogt from comment #3)
But obexd.service needs to be dbus activated, not unconditionally started by Plasma or each DE individually.
If I understand correctly, you mean that the fix has to come from the bluez-obexd package. Unfortunately boo#1198626 has been sitting there unfixed for 16 months.
Yep :-/
I have almost no experience with dbus, so at the moment I cannot be of much help. Can you point me to some documentation where I can better understand the dbus/systemd business?
Maybe you can check how other distros do it? Maybe it's documented for bluez upstream? -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1214409 https://bugzilla.suse.com/show_bug.cgi?id=1214409#c6 --- Comment #6 from Giacomo Comes <comes@naic.edu> --- I think I found the proper solution. The package bluez-obexd does already have all what is required and it doesn't need to be changed (it is identical to the fedora rpm). What is missing is to automatically enable the user obex.service. This is done by adding the line: enable obex.service in the file /usr/lib/systemd/user-preset/95-default-SUSE.preset (package systemd-presets-common-SUSE) With such change in place, and by making bluedevil5 require bluez-obexd, the problem is solved. If you don't have objections, I'll prepare and submit the changes for bluedevil5 and systemd-presets-common-SUSE. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1214409 https://bugzilla.suse.com/show_bug.cgi?id=1214409#c7 --- Comment #7 from Fabian Vogt <fabian@ritter-vogt.de> --- (In reply to Giacomo Comes from comment #6)
I think I found the proper solution. The package bluez-obexd does already have all what is required and it doesn't need to be changed (it is identical to the fedora rpm). What is missing is to automatically enable the user obex.service.
This is done by adding the line: enable obex.service in the file /usr/lib/systemd/user-preset/95-default-SUSE.preset (package systemd-presets-common-SUSE)
With such change in place, and by making bluedevil5 require bluez-obexd, the problem is solved. If you don't have objections, I'll prepare and submit the changes for bluedevil5 and systemd-presets-common-SUSE.
That would require a review by the security team. All the "enabling" of the service does is create an alias of dbus-org.bluez.obex.service to obex.service, which seems weird. Are there any other providers of this service? IMO /usr/share/dbus-1/services/org.bluez.obex.service needs to be changed to use SystemdService=obex.service instead, then no preset needs to be changed. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1214409 https://bugzilla.suse.com/show_bug.cgi?id=1214409#c8 --- Comment #8 from Giacomo Comes <comes@naic.edu> ---
That would require a review by the security team.
All the "enabling" of the service does is create an alias of dbus-org.bluez.obex.service to obex.service, which seems weird. Are there any other providers of this service? IMO /usr/share/dbus-1/services/org.bluez.obex.service needs to be changed to use SystemdService=obex.service instead, then no preset needs to be changed.
I think upstream decided to implement /usr/share/dbus-1/services/org.bluez.obex.service the way it did because the user then have the option to enable or disable the dbus obex service. Previously is was always enabled and the user could not disable it (I think). About the review by the security team, are you sure that it is required? It is not like a new dbus services is being introduced. In Leap 15.4 the obexd dbus service was already there and enabled by default. In Leap 15.5 it is necessary to add: enable obex.service to systemd-presets-common-SUSE to enable it, but I don't see how the final result is different from Leap 15.4 and why the security team should be opposed to it. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1214409 https://bugzilla.suse.com/show_bug.cgi?id=1214409#c10 --- Comment #10 from Giacomo Comes <comes@naic.edu> ---
The only reason to use an `Alias` is because there could be multiple providers.
I did find the message in the linux-bluetooth mailing list about why the alias line was introduced. See these messages: https://marc.info/?t=133720198500001&r=1&w=4 As I supposed, the alias is there to allow enable/disable of the service using systemd and that was the way fedora was doing it before it was officially implemented in bluez. What do you think? Should I keep the upstream way, or do I modify the dbus obex.service? -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1214409 Gerhard Stengel <gstengel@gmx.net> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |gstengel@gmx.net -- You are receiving this mail because: You are on the CC list for the bug.
participants (1)
-
bugzilla_noreply＠suse.com