WPS-enabled Bss and other WPS related questions

[Jouni Malinen]

On Thu, Dec 02, 2010 at 02:43:57PM +0200, Tomasz Bursztyka wrote:
> I am currently figuring out which Bss provide WPS, and current situation 
> seems to be to parse IEs buffer in Bss properties. No mention of wps is 
> made anywhere else. Is that normal or am I missing something?

I cannot really claim to be too familiar with the D-Bus interface, but
that seems to be matching with the current definition.

> If parsing IEs is the only solution that's fine but:
> - old dbus api used to provide "wpsie" for a bss and that was quite easy 
> then to know wether or not a bss provided wps.
> - would it be then relevant to reintroduce such property? (I could do 
> the patch)

Since we do expose some more parsed information for WPA and WPA2 (RSN),
I would guess it would be reasonable to introduce something similar for
WPS, too. However, exposing a "wpsie" would be incorrect and not
acceptable since there may be multiple WPS IEs in Beacon/Probe Response
frames. I would be fine with exposing an array of WPS attributes or even
more parsed information from some key attributes if desired.

> Also, Start() method from WPS interface provides association with (or 
> not) bssid argument. It tends to be less obvious to use than by ssid. If 
> I have 2 ap sharing same ssid, the two ones providing wps, then the 
> easiest is to ask Start() without any bssid (since I might not be aware 
> of their respective bssid). What if we could request Start() with an 
> ssid argument, to filter out bss by ssid? If such argument would be 
> provided with a bssid then only the bssid would matter and it would 
> ignore the ssid, if ssid would be alone then we would filter out Bss 
> based on that ssid.

In most uses of WPS, I would not expect the AP to be specified. The
BSSID parameter is really only used when acting in Registrar role (i.e.,
using AP's PIN to learn current configuration or to reconfigure the AP).
I do not really want to use a non-unique identifier like SSID for the
configuration part.

> Do you think it would be relevant to get such optional argument? (I 
> could provide the patch also)

Please note that this would also need changes in the WPS scanning code
to be able to use the SSID-based selection. I'm not really sure of the
use case that would benefit from SSID-based selection, though. For most
cases, user should not need to select the AP in the first place and if
you end up selecting something, the BSSID should already be known..

-- 
Jouni Malinen                                            PGP id EFC895FA