[PATCH v2 4/4] P2P: Handle driver NOA notification

[Jouni Malinen]

On Wed, Dec 07, 2011 at 08:23:55AM +0100, Janusz Dziedzic wrote:
> In case driver/firmware will not update beacon/probe_response frames
> by itself can just use
> this NOA change/set notification. After that supplicant will set correct IEs.
> Extra start time can be used here to be sure beacon/probe_resp will be
> updated correctly and all clients will sync ...

Wouldn't it be simpler to just do this within the driver? It is trivial
to add NoA to the frame when used and you'll get rid of the extra
latency on going through wpa_supplicant.

> Driver/firmware could menage NOA itselft and report NOA change/set in
> case will not update IEs itself.
> In case will do that internally don't need to call this NOA
> notification. So, nothing will change for drivers/firmware handle this
> internally.

Well, the question here is whether to add the extra complexity into
wpa_supplicant and kernel interface for something that would seem to be
better implemented somewhere else.

> Currently in our environtment we are testing two cases for P2P_GO and NOA:
> 1) when firmware using beacon/probe_resp templates - and in such case
> after we set NOA firmware will update templates and add NOA attr. This
> have one limitation. Supplicant will never get probe_requests and will
> not build p2p_peers table correctly (invite), but there is one pro
> (big pro in case of mobile market) - we will not send probe_requests
> to the driver (firmware will handle this internally) - so our platform
> could be in deep sleep in case no traffic.
> So, probably best here could be implement p2p_find (scan) in GO (but I
> think this is not so trivial) and using this firmware
> beacon/probe_resp templates.

You can reply to the Probe Request frames in firmware, but you will need
to provide notification of receive Probe Request frames (at least some
kind of summary, if you want to reduce frequency of such indications) to
wpa_supplicant to be able to use P2P management code there. In addition,
the firmware will need to be aware of all filtering rules on when to
reply to a Probe Request based on the device information from the
connected P2P clients.

> 2) probe_resp is handled by wpa_supplicant/driver. So we have two
> options here, first catch this probe_resp frames in the driver and add
> NOA attr. Second send NOA notification to wpa_supplicant and update
> probe_Response IEs. I choose second option because supplicant already
> have an API for create/update NOA Attrs. So, was easy to do.
> I also test this with mac80211 driver succesfully.

While this would be possible in theory, it has drawbacks and I'm not
aware of anyone else trying to move to that direction.. All NoA handling
within wpa_supplicant was really meant only for testing purposes. The
driver/firmware is expected to add the NoA attribute based on internal
state.

-- 
Jouni Malinen                                            PGP id EFC895FA