Issues with new D-Bus API

Witold Sowa witold.sowa
Mon Jan 4 15:36:54 PST 2010

Jouni Malinen pisze:
> Do we have a list (or can easily generate it) of information that
> NetworkManager (or ConnMan, etc., for that matter) currently need from
> these IEs?
Looking at NM sources, it seams that it retrieves following information
for WPA and RSN:
- group suite
- list of pairwise suites
- list of key management suites
- preauth capability
and additionally PMKID list for RSN:

Nevertheless, it only make any use of pairwise/group ciphers and key
management settings.

I have no idea what other clients do with IEs.

> I think that at least with WPS, we could start by removing the WPSIE
> property and provide a new property with all IEs so that no information
> is dropped. In addition, we could start adding parsed WPS information
> based on the real need of the users of the D-Bus interface. Since this
> is a new interface, I would do same with WPS/RSN IE, too, i.e., only add
> information that is actually of known use (and provide all IEs for
> unknown future uses now and more properties in the future, when needed).
> The immediate question of WPAIE, RSNIE, and WPSIE can obviously be
> removed by just removing all them and adding a single IE property which
> will always be included (which is fine since there will always be IEs in
> BSS entries). However, the same question will show up with the new
> "more parsed" information, like, WPA/WPA2 cipher suite. How would that
> be presented in the case that the BSS does not use WPA/WPA2 in the first
> place? Not including the property for some BSS objects would sound
> reasonable to me, but then again, I'm not that familiar with common
> D-Bus usage.
Yeah, seams like having some properties not available is unavoidable.
All we can do is to decide how to respond to calls to unavailable
properties. Probably replying with an error would be the best approach.

I propose to add string array Security property to BSS object with two
possible elements "rsn" and "wpa" and add two new interfaces to BSS objects:
fi.w1.wpa_supplicant1.Interface.BSS.RSN (or WPA2)
each containing string array properties KeyManagement, Group, Pairwise
and whatever currently clients need.

In BSSAdded signal second parameter we would call above properties like
WPA.Group and RSN.Group in order to distinguish them.

Any thoughts?

Another unrelated issue:
Would you mind changing fi.w1.wpa_supplicant1.Interface.BSS an
fi.w1.wpa_supplicant1.Interface.Network interface names to
fi.w1.wpa_supplicant1.BSS fi.w1.wpa_supplicant1.Network?


More information about the Hostap mailing list