Return value from D-Bus Interface.SignalPoll method
Fionn Cleary
fionn.cleary at streamunlimited.com
Wed Mar 10 15:21:47 GMT 2021
Hi,
As part of the new D-Bus additions I posted yesterday I have once again
noticed an oddity in the D-Bus introspection data, in particular the
SignalPoll method. It’s listed as returning "a{sv}", that is, a dict of
string to variants, but if you look at what it actually returns on the
bus it’s a variant containing a "a{sv}", which is a variant, "v":
method call time=1615296463.836190 sender=:1.34 -> destination=fi.w1.wpa_supplicant1 serial=2 path=/fi/w1/wpa_supplicant1/Interfaces/0; interface=fi.w1.wpa_supplicant1.Interface; member=SignalPoll
method return time=1615296463.838788 sender=:1.25 -> destination=:1.34 serial=209 reply_serial=2
variant array [
dict entry(
string "rssi"
variant int32 -55
)
dict entry(
string "linkspeed"
variant int32 65
)
dict entry(
string "noise"
variant int32 -92
)
dict entry(
string "frequency"
variant uint32 2462
)
dict entry(
string "width"
variant string "40 MHz"
)
]
In the Qt code I have which does the SignalPoll I have to manually
update the introspected xml, changing the "a{sv}" to "v" before I can
successfully extract the return value from SignalPoll. If we look at
the relevant code in dbus_new.c (wpas_dbus_handler_signal_poll) it opens
a variant container and then opens a dict inside that:
if (!dbus_message_iter_open_container(&iter, DBUS_TYPE_VARIANT,
"a{sv}", &variant_iter) ||
!wpa_dbus_dict_open_write(&variant_iter, &iter_dict) ||
It would be cleaner to remove the outermost variant, but that would
break users of the existing API, so instead I would suggest changing the
SignalPoll return type to "v". I presume I can’t be the only one who
has had to fight with this, but searching through the list archives for
"SignalPoll" gives me zero hits.
Any thoughts? Changing the introspection data is a one-liner, just want
to see if anybody has any feedback before I post the patch.
Fionn
More information about the Hostap
mailing list