[PATCH] P2P return a successful response for p2p presence request if driver has return noa_len greater than 0
Tue Dec 13 05:35:50 PST 2011
> Yes, we need basic form of presence request handling and in my opinion
> this should be done in supplicant as supplicant already takes care of
> rest of the action frames..
> Now there are some challenges in implementing it in supplicant, and to
> start with, we can simply call handle_presence function from
> supplicant. And let the driver handle it.
> I am fine to implement another function called handle_presence(). Upon
> handle_presence(with client addr). Then driver can take a call what to
> do for revised NOA schedule. A simple driver may decide to disable the
> NOA schedule completely until all the connected clients send a
> presence request with 0 values. Supplicant should here also make sure
> that it calls handle_presence function only when it knows that
> presence request has come from a connected client. Driver need to
> maintain a list of clients who has sent the presence request.
Yes, this sounds reasonable. Not sure how the client disconnect etc.
should be handled though (and I'm not sure if a client can "give up" a
presence request, maybe by sending a new one?)
> But this will also involve adding one notification from driver to
> supplicant which is to update the revised NOA schedule in the beacons
> and probe responses. Or we need not do this, driver can put the
> modified NOA schedule in the beacons and probe responses.
I don't think that's necessary -- we've kept this in the driver (device
in some cases), and it's trivial to do it there, so I see no reason to
let it go through wpa_supplicant.
More information about the Hostap