24

I wrote a simple python program to play and pause banshee music player. While its working on my own machine, I have trouble doing it to a remote computer, connected to the same router (LAN). I edited the session.conf of the remote machine, to add this line:

<listen>tcp:host=localhost,port=12434</listen>

and here is my program:

    import dbus


    bus_obj=dbus.bus.BusConnection("tcp:host=localhost,port=12434")
    proxy_object=bus_obj.get_object('org.bansheeproject.Banshee',                              
    '/org/bansheeproject/Banshee/PlayerEngine')

    playerengine_iface=dbus.Interface(proxy_object,
    dbus_interface='org.bansheeproject.Banshee.PlayerEngine')

    var=0

    while (var!="3"):
        var=raw_input("\nPress\n1 to play\n2 to pause\n3 to exit\n")


            if var=="1":
                print "playing..."
                playerengine_iface.Play()

            elif var=="2":
                print "pausing"
                playerengine_iface.Pause()

This is what i get when i try to execute it

Traceback (most recent call last):
  File "dbus3.py", line 4, in <module>
    bus_obj=dbus.bus.BusConnection("tcp:host=localhost,port=12434")
  File "/usr/lib/python2.7/dist-packages/dbus/bus.py", line 125, in __new__
    bus = cls._new_for_bus(address_or_type, mainloop=mainloop)
dbus.exceptions.DBusException: org.freedesktop.DBus.Error.NoServer: Failed to connect to socket "localhost:12434" Connection refused

What am I doing wrong here? should i edit /usr/lib/python2.7/dist-packages/dbus/bus.py

UPDATE:

ok, here is the deal when i add

<listen>tcp:host=192.168.1.7,port=12434</listen>

to to /etc/dbus-1/session.conf, then reboot, hoping it would start listening on reboot, It never boots. It gets stuck on loading screen and occasionally, a black screen with the following text flashes:

Pulseaudio Configured For Per-user Sessions Saned Disabled;edit/etc/default/saned

so, when i go ctrl+alt+f1 , change session.conf to original state and reboot, it boots properly.

Whats all that about? How can I make dbus daemon listen for tcp connections, without encountering problems?

Dale E. Moore
  • 431
  • 7
  • 19
Gautam
  • 475
  • 1
  • 3
  • 8
  • default (ubuntu). Sorry, i have close to zero knowledge when it comes to networking, should i configure the iptable to allow the connection? I thought iptable allows everything by default – Gautam Apr 15 '12 at 09:58
  • Useful network commands: `netstat -na`, `lsof -ni`, `tcpdump -n -i eth0` and `iptables -nvL`. I think using a combination of those will tell you if your process is listening at all and if yes if it's somehow blocked. Good Luck! – hochl Apr 15 '12 at 10:42
  • 1
    you can forward tcp packets using `socat` to local unix socket - that way you don't need to restart dbus daemon. Also, try `tcp:host=0.0.0.0,port=12434` - this will bind listening socket to all interfaces. (check if its actually listening after restart - `telnet 192.168.1.7 12434` – Andrey Sidorov Sep 19 '12 at 05:50

3 Answers3

42

I recently needed to set this up, and discovered that the trick is: order matters for the <listen> elements in session.conf. You should make sure the TCP element occurs first. Bizarre, I know, but true, at least for my case. (I see exactly the same black screen behavior if I reverse the order and put the UNIX socket <listen> element first.)

Also, prepending the TCP <listen> tag is necessary, but not sufficient. To make remote D-Bus connections via TCP work, you need to do three things:

  1. Add a <listen> tag above the UNIX one, similar to this:

    <listen>tcp:host=localhost,bind=*,port=55556,family=ipv4</listen>
    <listen>unix:tmpdir=/tmp</listen>
    
  2. Add a line (right below the <listen> tags is fine) that says:

    <auth>ANONYMOUS</auth>
    
  3. Add another line below these that says:

    <allow_anonymous/>
    

The <auth> tag should be added in addition to any other <auth> tags that may be contained in your session.conf. In summary, your session.conf should contain a snippet that looks like this:

<listen>tcp:host=localhost,bind=*,port=55556,family=ipv4</listen>
<listen>unix:tmpdir=/tmp</listen>

<auth>ANONYMOUS</auth>
<allow_anonymous/>

After doing these three things, you should be able to connect to the session bus remotely. Here's how it looks when specifying a remote connection in D-Feet:

D-Feet screen capture

Note that, if you want to connect to the system bus, too, you need to make similar changes to /etc/dbus-1/system.conf, but specify a different TCP port, for example 55557. (Oddly enough, the element order appears not to matter in this case.)

The only weird behavior I've noticed in this configuration is that running Desktop apps with sudo (e.g., sudo gvim) tends to generate errors or fail outright saying "No D-BUS daemon running". But this is something I need to do so rarely that it hardly matters.

If you want to send to a remote machine using dbus-send, you need to set DBUS_SESSION_BUS_ADDRESS accordingly, e.g., to something like:

export DBUS_SESSION_BUS_ADDRESS=tcp:host=localhost,bind=*,port=55556,family=ipv4

This works even if the bus you want to send to is actually the system bus of the remote machine, as long as the setting matches the TCP <listen> tag in /etc/dbus-1/system.conf on the target. (Thanks to Martin Vidner for this tip. Until I stumbled across his answer to this question, I didn't believe dbus-send supported remote operation.)

UPDATE: If you're using systemd (and want to access the system bus), you might also need to add a line saying ListenStream=55557 to /lib/systemd/system/dbus.socket, like so:

[Socket]
ListenStream=/var/run/dbus/system_bus_socket
ListenStream=55557  # <-- Add this line

UPDATE2: Thanks to @altagir for pointing out that recent versions of D-Bus will enable AppArmor mediation on systems where it's available, so you may also need to add <apparmor mode="disabled"/> to session.conf/system.conf for these instructions to work.

evadeflow
  • 4,704
  • 38
  • 51
  • Just an FYI, I needed something like this for mine to work (note the binding and setting of family): tcp:host=localhost,bind=*,port=55884,family=ipv4 – Shorin Feb 21 '13 at 20:02
  • 1
    Thanks, @Shorin. I updated my answer to contain the `bind` and `family` key/values pairs. I don't think they're required in all cases (they weren't in mine), and the values may need to be adjusted for different systems, but including them probably makes the answer more complete and helpful to others. :-) – evadeflow Feb 25 '13 at 16:51
  • 1
    Btw, I tried this on an Android device. It hangs on reboot. Needed to flash to get working again. – alanjds Apr 15 '14 at 02:09
  • If you are struggling to get dbus running on Microsoft's Windows subsystem for linux, this answer will actually help. – baldrs Aug 09 '16 at 09:06
  • I don't understand how my python dbbus-client would know where the target bus is on the network. Shouldn't there be an IP address of the remote target specified somewhere in the client app? – Tushar Vazirani Nov 21 '17 at 17:43
  • 2
    @TusharVazirani: You can use the `DBUS_SESSION_BUS_ADDRESS` environment variable to specify the remote target, i.e., run it using something like `DBUS_SESSION_BUS_ADDRESS=tcp:host=192.168.1.17,bind=*,port=55556,family=ipv4 ./my_python_app.py`. (NOTE: As mentioned in my answer, this works even if the bus you're connecting to is actually the _system_ bus of the remote machine—provided its `system.conf` is configured to allow connections via TCP.) – evadeflow Nov 21 '17 at 23:44
  • I am using these settings but I cannot receive any signals from my remote application. Do these settings work for receiving signals as well? – Tushar Vazirani Mar 02 '18 at 16:24
  • Thank you so much for this answer, using wireshark, and netstat i'm able to see that my python app is able to connect to interface and call, but i'm getting back DBusException: org.freedesktop.DBus.Error.AccessDenied :( Any suggestions please? – sayo9394 Sep 03 '18 at 03:50
7

since dbus 1.6.12 (e.g. kubuntu 13.10), your connection will also be rejected unless you add to your dbus config file (either /etc/dbus-1/mybus.conf or the interface requiring remote access i.e. system.d/my.interface.conf)

<apparmor mode="disabled"/>

UPDATE: After struggling to create a apparmor profile allowing the service to connect to the custom dbus-daemon, it seems the connection is always rejected due to a bug in DBUS... So for now we MUST disable apparmor whenever you use tcp=... Bug fix targetted for 14.04

I opened a bug at bugs.launchpad.net following discussion here with Tyler Hicks:

The AppArmor mediation code only has the ability to check peer labels over UNIX domain sockets. It is most likely seeing an error when getting the label and then refusing the connection.

Note: the disable flag is not recognized by dbus < 1.6.12, so you need to package different versions of mydaemon.conf depending on systen), else dbus-daemon will fail on launch if no apparmor... I used for now in my CMakeLists.txt :

IF(EXISTS "/usr/sbin/apparmor_status")
  install(FILES dbus_daemon-apparmordisabled.conf RENAME dbus_daemon.conf DESTINATION /etc/dbus-1/ )
ELSE (EXISTS "/usr/sbin/apparmor_status")
   install(FILES dbus_daemon.conf DESTINATION /etc/dbus-1/ )
ENDIF(EXISTS "/usr/sbin/apparmor_status")
altagir
  • 640
  • 8
  • 18
3

Another thanks @Shorin, and another FYI - I had to do something like this to make mine work:

<listen>tcp:host=localhost,bind=0.0.0.0,port=55884</listen>

Note the bind=0.0.0.0 - the bind=* didn't work for me, and I left out the family=ipv4 part. I'm on Ubuntu 12.04. I did use netstat on the remote machine to confirm dbus was listening on the port and telnet from local to confirm the port was open.

netstat -plntu | grep 55884

tcp   0     0 0.0.0.0:55884    0.0.0.0:*     LISTEN    707/dbus-daemon

You have to see something like 0 0.0.0.0:55884 and not something like 0 127.0.0.1:55884.

sth
  • 222,467
  • 53
  • 283
  • 367
kepler22b
  • 31
  • 1