[PATCH 13/19] P2PS: add p2ps_supported_cpt configuration property

Vamsi, Krishna vamsin at qti.qualcomm.com
Wed Jun 17 06:30:18 EDT 2015



> -----Original Message-----
> From: hostap-bounces at lists.shmoo.com [mailto:hostap-
> bounces at lists.shmoo.com] On Behalf Of Stepanov, Max
> 
> Good question. According to WFDS spec: " The ASP on a device communicates
> with the ASP on a peer device to manage ASP sessions between the two
> devices".

The above snippet mostly applies to the value that should be sent in PD request. The value in PD request indicates all the modes supported by an ASP in general. But PD response is supposed to have a single transport bit set and that mode should be used for that service, which means the responder should/can select the preferred transport mode for that service. 

Now coming to your patch, it talks about setting supported features as well as the priority between them. The overall supported features can be global while the priority between them can be specific to each service. As the spec is providing flexibility to choose different transports let us not limit this in supplicant. I suggest giving the configuration flexibility as much as possible to the ASP, which is supposed to be implemented on top of supplicant.

Another thing, looking at the way p2p_match_feat_cap() is implemented, I would like to bring to your notice the point that "feature capability" is not only meant for transport modes but for any kind of ASP features. Writing the below logic so generic may not good hold for future. In general its good practice/mandate to set all the reserved fields to zero.

+	for (i = 0; p2p->cfg->p2ps_asp_cpt_priority[i]; i++) {
+		if (p2p->cfg->p2ps_asp_cpt_priority[i] & req_cap[0]) {
+			resp_cap[0] = p2p->cfg->p2ps_asp_cpt_priority[i];
+			break;
+		}
+	}

Thanks,
Vamsi


More information about the HostAP mailing list