[PATCH] Add P2P IEs to probe requests only when in P2P

[Jouni Malinen]

On Tue, Aug 14, 2012 at 12:38:13AM +0300, Eyal Shapira wrote:
> 1. Adding P2P+WPS IEs to all probes makes them significantly bigger
> (the actual size is dependent on variable size parameters in the WPS IE
> like model name/device name/model number/manufacturer). On our
> default dev platform it goes from probes of 70 bytes to 250 bytes.
> Given that these go out in 1Mbps multiple times on all channels this
> has an impact
> on power and total scan time. The effect is worse once you're probing multiple
> networks with SSID specific probes (scan_ssid networks) as there are
> more probes in that case.

It should be fine to not include P2P+WPS IE from the Probe Request
frames for specific SSIDs that are known to not be P2P devices. Though,
we do not really have a mechanism in nl80211 for specifying that for a
single scan trigger, so wpa_supplicant would need to split the scans
into separate commands in a way that keeps the non-P2P specific SSID
scan_ssid=1 cases in their own commands. While this would reduce the
channel time a bit, I'm not sure whether this is really worth
complexity, though.

> 2. We've seen some old APs having issues with big probe requests.

Would you be able to identify any of these issues? I've heard of a
single case where a WPS AP has some issues (delayed Probe Response) due
to the WPS element, but that is the only issue I remember having heard
of in this context.

> 3. When multiple interfaces are used (like in Android JB - wlan0 and p2p0)
> since P2P struct is "global" having P2P initialized on one interface (e.g. p2p0)
> affect probes going out on other interfaces
> Does this make sense given the different MACs ?

If there is a specific interface that is used only for non-P2P
operations, it should be fine to leave out the P2P+WPS elements.
However, this is not really supported with cfg80211/mac80211 very
cleanly yet (Johannes has some ongoing work on this with the separate
P2P device instance).

If "different MACs" is referring to different MAC addresses, then yes,
including WPS+P2P makes sense. The key point for me is in whether the
interface (or address, I'd guess) can be used for P2P. In the current
mac80211 behavior, the initial wlan0 interface is used both for non-P2P
STA and P2P device operations while the p2p-wlan0-0 interface is used
only for P2P. With this design, both wlan0 and p2p-wlan0-0 should
include P2P+WPS elements.

> 4. Focusing on Android - we're looking at Galaxy Nexus as the reference behavior
> for STA + P2P. Looks like only probes related to P2P (i.e. once you go into
> WiFi Direct UI and P2P_FIND begins) go out with P2P+WPS IE. Normal STA scans
> don't include the P2P IE. I know it's not necessarily a good argument
> here but still
> worth noting as a reference.

I would say Android is quite a bit opposite of a good example of how to
support P2P properly with cfg80211 and wpa_supplicant.. It is getting
better, but I do not want to repeat the mess with ICS and vendor
specific patches that conflict with upstream design.

That said, if the station interface is indeed separate allocated for
non-P2P use and is separate from the P2P device operations, it sounds
reasonable to consider not including WPS+P2P elements in Probe Request
frames. However, I would like to support this only with a design that
complies with the upstream cfg80211 design for handling the P2P device
operations with a MAC address that does not match with the station
interface MAC address.

> Maybe make this an Android specific patch ?

Absolutely not. Android should not be a special case and it needs to
work in the way as any other Linux-based system would work with
cfg80211. The mess from ICS has cost countless hours in support and in
coming up with pointless workarounds to meet silly product requirements
to match Android design over upstream Linux wireless design when all
this could have been avoided by working properly with upstream in the
first place.

-- 
Jouni Malinen                                            PGP id EFC895FA