P2P Adding interval parameter to set_noa and also update beacon after noa params are applied in the driver

Jouni Malinen j at w1.fi
Wed Oct 12 17:34:45 EDT 2011


On Fri, Oct 07, 2011 at 03:56:52AM -0700, Neeraj Kumar Garg wrote:
> Could you please let us know your thoughts on implementation of power-save? We see two issues with present implementation. 
> 1) interval param is not implemented for function p2p_set_noa.
> 2) After noa attribute or ps mode (ctwindow, legacy_ps) is updated to the driver, p2p_group_notif_noa should get called for updating the P2P IE in beacons.

What kind of use case are you looking for with this? The set_noa
driver_ops is really aimed for testing purposes only and the set of
parameters there seemed to be enough to cover the most common test
cases. For any more realistic production use, there is an assumption
that NoA parameters are maintained and decided somewhere in the
driver/firmware. This would also include updated the P2P IE(s) in Beacon
and Probe Response frames.

I'm not against considering changes to allow wpa_supplicant to do
somewhat more in this, but I'm not sure whether it is really realistic
to push all NoA attribute control into user space. It could be helpful
if you could provide some description of the architecture you would use
for P2P GO PS between various components in the system.

> diff --git a/src/p2p/p2p_group.c b/src/p2p/p2p_group.c
> @@ -642,7 +642,7 @@ u8 p2p_group_presence_req(struct p2p_group *group,
>  			    curr_noa_len);
>  
>  	/* TODO: properly process request and store copy */
> -	if (curr_noa_len > 0)
> +	if (curr_noa_len < 0)
>  		return P2P_SC_FAIL_UNABLE_TO_ACCOMMODATE;
>  
>  	return P2P_SC_SUCCESS;

What is the purpose of this change? The Presence Request processing here
is obviously quite bogus, but I don't see how this would make it any
better.

-- 
Jouni Malinen                                            PGP id EFC895FA


More information about the HostAP mailing list