What I did was connect to a Bluetooth device:
This resulted in the following HCI error:
> HCI Event: Command Status (0x0f) plen 4 #1997 [hci0] 60.389250
LE Create Connection (0x08|0x000d) ncmd 1
Status: Memory Capacity Exceeded (0x07)
I found the following error in the error parameter of g_dbus_connection_call_sync() :
GDBus.Error:org.bluez.Error.Failed: Software caused connection abort
I then tried:
This turned out to be true.
I then did:
msg = g_dbus_error_get_remote_error(error);
But msg was NULL.
Is there anything I can do to get a more specific error?
NULL is unexpected, but that doesn’t really matter here: The expected result is
org.bluez.Error (read: the error name returned by the service), which doesn’t tell you anything you don’t know already.
TIL that the D-Bus protocol allows passing arbitrary arguments in messages of type
ERROR. If bluez uses that, then you can use the lower-level API to examine the arguments:
message = g_dbus_connection_send_message_with_reply_sync ()
if (g_dbus_message_get_message_type (message) == G_DBUS_MESSAGE_TYPE_ERROR)
GVariant *body = g_dbus_message_get_body (message);
But that’s a big if, it’s much more likely than not that the generic “Software caused connection abort” is all bluez is giving you. If there was a more detailed error, I’d expect a more specific error name, so callers don’t have to jump through hoops to get to the details.
Florian Müllner wrote:
TIL that the D-Bus protocol allows passing arbitrary arguments in messages of type ERROR. If bluez uses that, then you can use the lower-level API to examine the arguments:
I am using the org.bluez.Device1 D-Bus API:
I do not see any error passing interface listed.
Thanks for your help.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.