mvidner / ruby-dbus

A Ruby binding for DBus
GNU Lesser General Public License v2.1
170 stars 51 forks source link

UNIX_FD in practice? #107

Open mahlonsmith opened 2 years ago

mahlonsmith commented 2 years ago

Heya!

I'm using ruby-dbus to attempt a Bluetooth serial profile callback, and I'm running into a "Tried to send message with Unix file descriptors to a client that doesn't support that." error message from dbus.

It's entirely possible I'm defining the callback incorrectly, but I think that's correct. Example profile definition and registration (as defined here)

class SerialConnection < DBus::Object
    dbus_interface( 'org.bluez.Profile1' ) do

        dbus_method( :Release ) do
            puts "... release"
            nil
        end

        dbus_method( :NewConnection, "in device:o, in fd:h, in fd_props:a{sv}" ) do |device, fd, fd_props|
            puts "... incoming connection %p %p %p" % [ device, fd, fd_props ]
                    # sock = Socket.for_fd( fd )
                    # ...
            nil
        end

        dbus_method( :RequestDisconnection, "in device:o" ) do |device|
            puts "... disconnect"
            nil
        end
    end
end

serial_conn = SerialConnection.new( '/serial/connection' )

bluez_service = DBus::SystemBus.instance.service( 'org.bluez' ).introspect
bluez_profile_manager = bluez_service[ '/org/bluez' ][ 'org.bluez.ProfileManager1' ]

bluez_profile_manager.RegisterProfile( serial_conn.path, '1101', {
    'Name'    => 'Serial Port',
    'Role'    => 'server',
    'RequireAuthorization' => false,
    'Channel' => DBus.variant( 'q', 22 )
});

# ... enter dbus main loop here

When an RFCOMM compatible client connects, the dbus monitor shows it disconnect immediately (the callback doesn't fire at all).

signal time=1649451498.238931 sender=:1.2 -> destination=(null destination) serial=870 path=/org/bluez/hci0/dev_0C_8D_CA_99_D7_E7; interface=org.freedesktop.DBus.Properties; member=PropertiesChanged
   string "org.bluez.Device1"
   array [
      dict entry(
         string "Connected"
         variant             boolean true
      )
   ]
   array [
   ]
method call time=1649451498.709483 sender=:1.2 -> destination=:1.73 serial=871 path=/serial/connection; interface=org.bluez.Profile1; member=NewConnection
   object path "/org/bluez/hci0/dev_0C_8D_CA_99_D7_E7"
   file descriptor
         inode: 72836         type: socket
         address family: bluetooth
   array [
   ]
error time=1649451498.709751 sender=org.freedesktop.DBus -> destination=:1.2 error_name=org.freedesktop.DBus.Error.NotSupported reply_serial=871
   string "Tried to send message with Unix file descriptorsto a client that doesn't support that."
signal time=1649451503.316416 sender=:1.2 -> destination=(null destination) serial=872 path=/org/bluez/hci0/dev_0C_8D_CA_99_D7_E7; interface=org.freedesktop.DBus.Properties; member=PropertiesChanged
   string "org.bluez.Device1"
   array [
      dict entry(
         string "Connected"
         variant             boolean false
      )
   ]
   array [
   ]

It seems like it's complaining specifically about the second argument to the NewConnection method.

   file descriptor
         inode: 72836         type: socket
         address family: bluetooth

Is there a different path I should be taking to tackle this?

Thanks for any insight provided.

mahlonsmith commented 2 years ago

Ah, and I now see the commit message at https://github.com/mvidner/ruby-dbus/commit/ac217605270ecf5beefdade9598e6556217e68b0.

Not sure yet if that's still the case (10 years ago), but if so, this issue is actually a feature request. :-)

mvidner commented 2 years ago

You're right, UNIX_FD is not actually implemented. A major reason is that the spec is vague about the file descriptors are actually passed, and I was not determined enough to dig it up in other implementations. The Bluetooth use case looks a bit complex but fortunately there's UDisks OpenDevice which is simple enough for me to try and figure it out.

mahlonsmith commented 2 years ago

Excellent!

Found this project as well, and I can confirm it works -- clearly a very specific use case, and using a gio library C extension - but more stuff to dig into to see what is going on under the hood, at least. (I'll also be diggin'...)