Trying to send or recieve files with bluedevil 2.0-rc1 doesn't work. It works as expected with libbluedevil-1.9.4 / bluedevil 1.3.2. Reproducible: Always Steps to Reproduce: Sending : 1. Clicking on my "known device" (mobile phone), "Send Files" in systray 2. Choosing one .jpeg image 3. Clicking "Send files" Receiving : 1. Selecting image to share on my mobile phone (android) via bluetooth 2. Selecting paired device running bluedevil 2.0-rc1 3. Sending fails with failure reason "Connection failed" Actual Results: Image is not sent / received. Expected Results: Image should be sent / received. Bluedevil running on kde 4.12.2.
I can confirm this behaviour on 3 separate Gentoo installs (two amd64, one x86, all running with Bluez-5.15, and (lib)bluedevil-2.0rc1
Same on 2 machines of mine. Both Gentoo, every bluez 5.16/5.18 and bluedevil 2.0 with/without obexd combination fails. Send files ends into nothing (Nokia Symbian/Nexus Android 4.4.2 doesn't give any message) Recieve files fail (Nokia Symbian/Nexus Android 4.4.2 gives fail-message) bluedevil 1.3.2 with bluez 4.101-r8 works as expected. See https://bugs.gentoo.org/show_bug.cgi?id=506920
Created attachment 86575 [details] dbus-monitor output adding a dbus-monitor output. The only useraction was sending a picture with dolphin/bluedevil. This is the failing scenario with bluedevil 2.
Created attachment 86577 [details] dbus-monitor log working bluedevil-1.3.2 another dbus-log with working bluedevil 1.3.2 and bluez 4.101-r8 both logs using Gentoo-machines on the same patchlevel (except bluez&bluedevil) running with KDE 4.12.5, kernel 3.12.13-gentoo, dbus 1.6.18
konsole-output of bluedevil-sendfile (version 2.0-r1 bluez 5.18) $ bluedevil-sendfile Fontconfig warning: "/etc/fonts/conf.d/50-user.conf", line 14: reading configurations from ~/.fonts.conf is deprecated. Object::connect: No such signal BlueDevil::Adapter::deviceFound(QVariantMap) Object::connect: (receiver name: 'Discover') ======================== Address: "00:1C:9A:F5:CB:6F" Name: "VrennsPad2" Alias: "VrennsPad2" Icon: "phone" ======================== Address: "08:60:6E:3F:54:62" Name: "Karapad" Alias: "Karapad" Icon: "computer" Object::connect: No such signal org::freedesktop::UPower::DeviceAdded(QDBusObjectPath) Object::connect: No such signal org::freedesktop::UPower::DeviceRemoved(QDBusObjectPath) bluedevilsendfile(2197) KSambaSharePrivate::findSmbConf: KSambaShare: Could not find smb.conf! Click on send file just closes the dialog, my phone or tablet dosen't recognize that gentoo wanted to send something.
Created attachment 86579 [details] hcidump pc recieving a file hcidump where bluedevil2 should recieve a file from my nokia phone, SymbianOS.
hcidump of sending a file with bluedevil2 just shows HCI sniffer - Bluetooth packet analyzer ver 5.18 device: hci0 snap_len: 1500 filter: 0xffffffffffffffff on the konsole.
I see now bluedevil1 has following lines of dbus: method call sender=:1.103 -> dest=org.openobex.client serial=26 path=/; interface=org.openobex.Client; member=SendFiles array [ dict entry( string "Destination" variant string "00:1C:9A:F5:CB:6F" ) ] array [ string "/home/stephan/bilder/aquarium/03032007(004).jpg" ] object path "/BlueDevil_sendAgent" bluedevil 2 has following lines: member=AddMatch string "type='signal',sender='org.freedesktop.DBus',interface='org.freedesktop.DBus',member='NameOwnerChanged',arg0='org.bluez.obex'" It seems that bluedevil2 uses org.bluez.obex instead of org.openobex.client as sending "dbus object?", but where the hell is the destination declared?
I managed to get this thing working on Gentoo. The problem is with obexd daemon not running (and nothing seems to start it). That not a fix but as soon as I started it manually in a console (as a normal user) I was able to transfer files both way to my cell phone.
Starting /usr/libexec/bluetooth/obexd works for me in one direction: bluedevil -> Nokia phone other direktion ony works with /usr/libexec/bluetooth/obexd -a but then files land in $HOME/.cache/obexd/ my android nexus 7 is never able to recieve files from bluedevil 2 nexus -> bluedevil works only with obexd -a thats strange.
I've also tried running obexd manually, as Francois mentioned in #9, but I'm getting same results as Stephan reported in #10 (tried only with android device). If obexd is started without --auto-accept arg, kde tray icon shows that there's incoming file request when sending file from android, but nothing seems to happen after that. Here's related obexd output from that event: obexd[4673]: obexd/plugins/bluetooth.c:profile_new_connection() device /org/bluez/hci0/dev_<device_id> obexd[4673]: obexd/src/obex.c:obex_session_start() obexd[4673]: obexd/src/obex.c:cmd_connect() obexd[4673]: CONNECT(0x0), (null)(0xffffffff) obexd[4673]: obexd/src/obex.c:cmd_connect() Selected driver: Object Push server obexd[4673]: CONNECT(0x0), (null)(0x0) obexd[4673]: obexd/src/obex.c:cmd_put() obexd[4673]: PUT(0x2), (null)(0xffffffff) obexd[4673]: obexd/src/obex.c:parse_type() TYPE: image/jpeg obexd[4673]: obexd/src/obex.c:parse_name() NAME: 20140720_094723.jpg obexd[4673]: obexd/src/obex.c:parse_length() LENGTH: 3305649 obexd[4673]: PUT(0x2), FORBIDDEN(0x43) obexd[4673]: obexd/src/obex.c:cmd_disconnect() session 0x1ae9500 obexd[4673]: DISCONNECT(0x1), (null)(0xffffffff) obexd[4673]: DISCONNECT(0x1), SUCCESS(0x20) obexd[4673]: disconnected: Transport got disconnected obexd[4673]: obexd/src/obex.c:obex_session_destroy() If you need more debug info, let me know.
Francois (or anyone else attached running Gentoo) Did you manually install obexd? The bluedevil-2.0 ebuilds explicitly ask for obexd to be built with USE=-server and instead to use obex-data-server (or in the case of the -r1 package, simply !obexd at all).
Today tested ebuild 2.0_rc1-r1 (which uninstalls obexd): send and receive with android fails. obex-data-server is not active. manual start of obex-data-server (root or user) fails the same way :-( another idea: does this only interfere with gentoo-users running openrc or are systemd users affected too? (where communicaton/start of obex-data-server may differ)
I can't speak to systemd as I only use OpenRC, but historically when it worked on Gentoo (the pre 2.x series), I had never started any service but bluetooth. I was under the assumption that bluedevil was in charge of starting obexd/obex-data-server (but you know what they say about assume).
I assume the same (bluedevil should start or just use obex-data-server). But I don't know it, so I ask, searching for any pattern concerning this bug as I lack resources debugging/understanding the code.
I'm also using openrc, what led me to 0001-Allow-using-obexd-without-systemd-in-the-user-sessio.patch used with gentoo packaging and non-systemd users. Cultprint seems to be missing org.bluez.obex dbus service file that is never installed on gentoo system. In fact, when mentioned dbus service is running, bluedevil 2.0-rc1 works with bluez 5.21 at least on my machine (tested only pairing and file upload/download with android). See bug https://bugs.gentoo.org/show_bug.cgi?id=517818 on gentoo tracker.
I confirm that using bluez-5.21 and manually starting obexd included with bluez, I can send/receive to my android phone. Just waiting now to the -r1.ebuild to hit the mirrors to confirm that it works end to end. Thanks for the reference Uros!
(In reply to Stephan Karacson from comment #10) > other direktion ony works with /usr/libexec/bluetooth/obexd -a Sorry for not reading my email. I got the same problem and found the same solution as -r1 ebuild 2-3 days ago. I had to add the -a parameter as well. There is another bug in obexd daemon that prevent saving the file in the right directory (e.g. the one selected by the user in bluedevil GUI). By default without parameters, obexd save the incoming file in $HOME (or in $XDG_CACHE_HOME if this variable exist). -r1 build does that. Be aware due to a bug in obexd/main.c lines 286-298, obexd daemon with save the file in $XDG_CACHE_HOME/obexd instead of $XDG_CACHE_HOME. To get the right thing I had to specify in the dbus service file where I want to save the file. /usr/libexec/bluetooth/obexd -a -r MyDownloadDir Technically and according to the source code it possible to use relative or absolute pathnames for this -r parameter. This works fine hopefully.
Tested bluedevil 2.0_rc1 & 2.0_rc1-r1 with bluez 5.21-r1. Works out of the box with my android and old nokia in both directions. Thank you a lot Uros, Francois C. Dave Flogeras and all the others hunting down the bug. ps: I can confirm the directory-bug of Uros. All saved in HOME.
Thanks for all your input and testing. I'll just resolve this as fixed downstream, since it was gentoo packaging related.