DBus P2PDevice API
Craig Dowell
craigdo
Tue Sep 20 10:12:58 PDT 2011
Hi All,
I?ve been playing with the 0.8 suppliant code trying to get it
responding over the DBus protocol. I?m a bit confused by the DBus
version of p2p_find.
D-Feet says the P2PDevice Find method takes an ?a{sv}? as a parameter.
I can set the ?Timeout? key and value and watch it get sent to the
supplicant just fine. I looked at the ?RequestedDeviceTypes? key
handling, and its variant value is supposed to be an array of
WPAS_DBUS_TYPE_BINARRAY. WPAS_DBUS_TYPE_BINARRAY is defined as
DBUS_NUMBER_OF_TYPES + 100 which turns out to be 116, which is ascii
?t?. This tells me I should send an array of uint64_t (?at?) in the
variant value. I don?t understand why this is not just defined to be
?t? instead of being based on the number of DBus types by the way (or
?y? which I would actually more expect to see there given what it
apparently does).
If I do send an array of uint64_t, however, the
wpa_dbus_dict_get_entry() in the while loop of
wpas_dbus_handler_p2p_find() balks. This seems to be because
_wpa_dbus_dict_fill_value_from_variant() notices a DBUS_TYPE_ARRAY and
calls _wpa_dbus_dict_entry_get_array() which does not handle arrays of
uint64_t. I don?t see how this can work. Is this a bug or am I missing
something fundamental here?
This is an optional key, that seems to filter down into the requested
device type described in the Wi-Fi P2p Spec Annex B so I think I can
ignore it, but WPAS_DBUS_TYPE_BINARRAY is used in several places so I
thought it would be good to understand what is going on. What is the
purpose of the BINARRAY type? Am I missing something obvious?
Also, from what I can make out from the README-P2P, I would expect Find
to also take a ?type? key with the variant value being a string value
containing either ?social? or ?progressive?, but this seems to be
hardcoded to P2P_FIND_ONLY_SOCIAL in the DBus method handler. Are there
many differences between the wpa_cli interface and the DBus P2PDevice
Interface? Why would they be there?
Thanks in advance,
-- Craig
More information about the Hostap
mailing list