Trying to revive 'ubtd' (Bluetooth file transfer)

PhAndersson

Hello

I'm trying to revive the 'ubtd' app (Bluetooth file transfer) initially written by Michael Zanetti and Ian L., but I've hit a roadblock and I could use some guidance.

I'm currently targetting UT 20.04 on a Pixel 3a.

By default, the OBEX daemon doesn't run on the phone. A 'systemd' unit file is supposed to start it (/usr/lib/systemd/user/dbus-org.bluez.obex.service), but it is reported as "loaded / inactive (dead)" by 'systemctl' -- I'm not sure why as I was unable to find relevant log entries.

I can manually start the OBEX daemon using the following command:

$ systemctl --user start obex.service

In this case, the 'obexd' daemon keeps running and uses the same command-line parameters as those specified for the D-Bus related service (obexd -P ftp,irmc,mas,pcsuite -r /home/phablet).

Nonetheless, after pairing the phone with my laptop, when I start my app (the one that is supposed to receive incoming file transfers), I see the following messages in its log:

[03/01/2026 12:25] creating agent on dbus
[03/01/2026 12:25] registering agent
[03/01/2026 12:25] registering agent on obexd-server
[03/01/2026 12:25] Error registering agent for the default adapter: QDBusError("org.freedesktop.DBus.Error.ServiceUnknown", "The name org.bluez.obex was not provided by any .service files")

For information, the obex.service unit file does expose "org.bluez.obex" as BusName, not as Name -- not sure how relevant that is.

On its side, the OBEX daemon logs the following:

[03/01/2026 12:25] CONNECT(0x0), <unknown>(0xff)
[03/01/2026 12:25] CONNECT(0x0), <unknown>(0x0)
[03/01/2026 12:25] PUT(0x2), <unknown>(0xff)
[03/01/2026 12:25] PUT(0x2), Forbidden(0x43)
[03/01/2026 12:25] DISCONNECT(0x1), <unknown>(0xff)
[03/01/2026 12:25] DISCONNECT(0x1), Success(0x20)
[03/01/2026 12:25] disconnected: Transport got disconnected

So 'obexd' seems to receive the file sent by the laptop (from the point of view of the laptop, the transfer succeeds), but fails to hand it over to my app, which I guess makes sense as it failed to register itself with the daemon.

Can anyone suggest a fix, further ways to troubleshoot or point me to relevant documentation?

Thanks in advance.

lduboeuf

@PhAndersson
I guess you already checked if the service is registered to dbus after starting the obexd service:
e.g: busctl list | grep bluez ( no idea if it works on 20.04 though)
But maybe that service is supposed to be up only after pairing and with the profile set, in that case maybe bluez is not properly setup on UT for that ?

Otherwise idk, i'm on 24.04, and even starting obex fails....

PhAndersson

@lduboeuf Many thanks for the suggestion. No, I had not checked the output of busctl list. Here is what it says in the "default" state (i.e. no 'obexd' running, phone not connected to laptop over BT):

org.bluez                                   2170 bluetoothd      root             :1.40         bluetooth.service               -       -

If I then start 'obexd' manually as explained above, the output remains the same. If I then connect the phone to the laptop over BT, the output is still the same.

For what it's worth, I performed the same test on the laptop (openSUSE Leap 15.6), where 'obexd' is always running and known to be functional, and the busctl list output there also only lists 'bluetoothd', so I'm not sure whether 'obexd' is expected to appear there at all.

PhAndersson

This being said, a further test confirms that when 'obexd' is running, it does register with D-Bus, only not with the expected name:

:1.129                                      5035 obexd           phablet          :1.129        user@32011.service              -       -

(the behaviour is the same on the laptop, BTW -- there at least, none of the D-Bus services that are started by a regular user register a name on the bus, even though a 'BusName' parameter is specified in their unit file; only services started as 'root' seem allowed to do that).

lduboeuf

@PhAndersson

In Xenial, it was working, when i look at patches on Xenial, it appear there are some related to obexd, that may explain:
https://github.com/ubports/bluez-packaging/tree/xenial/debian/patches

PhAndersson

@lduboeuf That's a very good point -- thanks a lot. I'll have a look at those patches, but most of all you reminded me that I still have a working Xiaomi phone running Xenial, so I'll investigate the way the Bluez/OBEX stack is configured there.

PhAndersson

OK, first batch of results:

'obexd' is started by default on Xenial and runs with the same command-line parameters
the same two OBEX-related packages are installed, but of course their version differ (5.53 for bluez-obexd, 1.7.1 for libopenobex2)
the files provided by the 'bluez-obexd' package are the same, except for the dbus-org.bluez.obex.service unit file that is missing on Xenial
the output of busctl list | grep bluez is quite close to what it is on Focal, except that the corresponding 'systemd' unit file is not shown
the output of busctl list | grep obex shows something in lieu of a unit file ('session-c1.scope' -- what is it?), but still doesn't advertise any name for the service (see below)
further digging reveals that although 'systemd' is already present on the system, it is not used for user-related processes (i.e. no systemd --user process) -- 'obexd' has been started by upstart --user (based on its PPID)

Maybe the problem on Focal stems from a lack of integration between the OBEX daemon and systemd --user (which could also explain why the service doesn't start although enabled)?

For what it's worth, here is the output of busctl list | grep obex on Xenial:

:1.59                                             4084 obexd           phablet          :1.59         session-c1.scope          c1         -

lduboeuf

@PhAndersson said in Trying to revive 'ubtd' (Bluetooth file transfer):

OK, first batch of results:

'obexd' is started by default on Xenial and runs with the same command-line parameters

the same two OBEX-related packages are installed, but of course their version differ (5.53 for bluez-obexd, 1.7.1 for libopenobex2)

the files provided by the 'bluez-obexd' package are the same, except for the dbus-org.bluez.obex.service unit file that is missing on Xenial

the output of busctl list | grep bluez is quite close to what it is on Focal, except that the corresponding 'systemd' unit file is not shown

the output of busctl list | grep obex shows something in lieu of a unit file ('session-c1.scope' -- what is it?), but still doesn't advertise any name for the service (see below)

further digging reveals that although 'systemd' is already present on the system, it is not used for user-related processes (i.e. no systemd --user process) -- 'obexd' has been started by upstart --user (based on its PPID)

Maybe the problem on Focal stems from a lack of integration between the OBEX daemon and systemd --user (which could also explain why the service doesn't start although enabled)?

For what it's worth, here is the output of busctl list | grep obex on Xenial:
:1.59                                             4084 obexd           phablet          :1.59         session-c1.scope          c1         -                  

Yes indeed, Xenial relies on upstart instead of systemd. Maybe something is missing there.
This discussion could interest core team. @peat_psuwit do you have an idea ?