Issues with new D-Bus API

Witold Sowa witold.sowa at gmail.com
Mon Jan 4 00:10:55 EST 2010


Marcel Holtmann pisze:
> Hi guys,
> 
> so I have been hacking on a client using the new D-Bus API and found a
> couple of things that are sort of weird and could be done way simpler.
> Some of them seems just copied from the old API and I think it is time
> to fix this now before we actual get real users of this API.
> 
> 1) DebugParams parameter as a struct is too complex
> 

I have new bunch of patches on my GIT: git://repo.or.cz/hostap-gosc2009.git

One of the patches fixes a bug in DebugLevel setter value type, but it's
irrelevant now since Marcel's patch changes DebugLevel to string (and
that's fine for me).

> 7) Change of BSS properties
> 

I have added a properties change notifications to BSS objects and I
modified code related to PropertiesChanged signal. Till now, every
PropertiesChanged signal contained only one property. Now, we don't send
PropertiesChanged signal explicitly but rather mark property as changed
and then send a signal containing all properties marked as changed in
the object. Signal is actually being sent in three cases as described in
commit message. Changed in properties which are not caused by any DBus
call may be signalized with slight delay (currently up to 5ms) unless we
call wpa_dbus_flush_object_changed_properties() or
wpa_dbus_flush_all_changed_properties() before. Delay is caused by the
timer which makes it possible to wait for other changed properties to be
marked and included into signal. We need to consider which properties
change notification delay is acceptable and which is not and add
appropriate flushing calls after marking properties changed.

> 
> Is anybody really using "MaxRate" property. Wouldn't it better to export
> "Rates" as array of uint16? And if it is sorted the client could easily
> extract the max rate from there.

Done, but there is an array of uint32 since we expose rates in b/s.
uint16 would be too small even if we would expose it in kb/s since
2^16=64000 what is much less than 802.11n rates. The array is sorted
decreasing so the maximal rate is the first rate in the array.
This also fixes a bug with MaxRate. Exposed value was given as
multiplicity of 500000b/s, i.e. as it is stored in IE.

There is one more fix to WPA/RSN/WPS IE getters

Regards,
Witek.


More information about the HostAP mailing list