[13/19] P2PS: add p2ps_supported_cpt configuration property

From: Max Stepanov <Max.Stepanov@intel.com>

The p2ps_supported_cpt configuration property allows ASP to
specify supported Coordination Protocol Transports (CPT) and their
priorities. The property value is a list of supported ASP trasport
names ordred by their priority. Currently only two transports are
supported: UDP and MAC. The property can be set with ctrl-iface P2P_SET
command: (e.g. P2P_SET p2ps_supported_cpt UDP MAC). By default only UDP
transport is enabled.

The configuration parameter defines two internal p2p properties used
to verify CPT bitmask field of received provision discovery request's
feature capability as well as to select the best matching CPT option
for a provision discovery response.

The supported CPT bitwise mask value is used to verify a feature_cap=<hex>
parameter of P2P_ASP_PROVISION and P2P_ASP_PROVISION_RESP commands.
An error is returned if the parameter value doesn't match a supported
CPT bitwise mask. If this parameter is not specified, the supplicant
uses a supported CPT bitwise mask as CPT value of feature capability
attribute sent in PD request.

Signed-off-by: Max Stepanov <Max.Stepanov@intel.com>
Reviewed-by: Ilan Peer <ilan.peer@intel.com>
---
 src/common/ieee802_11_defs.h    |  1 +
 src/p2p/p2p.c                   | 34 ++++++++++++++++++++
 src/p2p/p2p.h                   | 21 +++++++++++++
 src/p2p/p2p_pd.c                | 56 +++++++++++++++++++++++++++++++--
 wpa_supplicant/ctrl_iface.c     | 69 ++++++++++++++++++++++++++++++++++++++---
 wpa_supplicant/p2p_supplicant.c |  2 ++
 6 files changed, 177 insertions(+), 6 deletions(-)

On Wed, Jun 10, 2015 at 11:43:43AM +0300, Ilan Peer wrote:
> The p2ps_supported_cpt configuration property allows ASP to
> specify supported Coordination Protocol Transports (CPT) and their
> priorities. The property value is a list of supported ASP trasport
> names ordred by their priority. Currently only two transports are
> supported: UDP and MAC. The property can be set with ctrl-iface P2P_SET
> command: (e.g. P2P_SET p2ps_supported_cpt UDP MAC). By default only UDP
> transport is enabled.

This would make the priority list global to the P2P Device, i.e., this
would apply to all services. Would that really cover the cases where
multiple services are available? I would expect that different services
could have different preferences for CPT especially since the current
designs would likely only support the UDP option while some newer
services may end up expecting the MAC option to be used.

Should this be done as a per-service (P2P_SERVICE_ADD,
P2P_ASP_PROVISION_RESP, P2P_ASP_PROVISION) parameter instead of an
extension to the global P2P_SET?

On Tue, June 16, 2015 at 17:10, Jouni Malinen wrote:
>This would make the priority list global to the P2P Device, i.e., this would apply
>to all services. Would that really cover the cases where multiple services are
>available? I would expect that different services could have different
>preferences for CPT especially since the current designs would likely only
>support the UDP option while some newer services may end up expecting the
>MAC option to be used.
>
>Should this be done as a per-service (P2P_SERVICE_ADD,
>P2P_ASP_PROVISION_RESP, P2P_ASP_PROVISION) parameter instead of an
>extension to the global P2P_SET?
>

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".
E.g. in general the supported session coordination protocol relates to a single ASP service, not to services.

By default only UDP transport is enabled, and setting of p2ps_supported_cpt is needed only for new services that may require MAC. Also ASP service may decide which ASP coordination protocol transport to use for a specific service. Both P2P_ASP_PROVISION and P2P_ASP_PROVISION_RESP commands allow ASP to specify 'feature_cap' parameter and explicitly set CPT value of a provision discovery request frame. On the other hand the CPT values of p2ps_supported_cpt are used mainly for provision discovery request verification and CPT value selection returned in a provision discovery response frame.

So, it looks like reasonable to have a set of the supported CPTs as a global ASP related P2P property.

Max

> -----Original Message-----
> From: hostap-bounces@lists.shmoo.com [mailto:hostap-
> bounces@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

>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.

Agree. Please notice that this flow supposes to work on a seeker side handling a follow on PD request and not having per service CPT preferences. 


>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.

Assume we have per service CPT preference on an advertiser side. How should a seeker (making a final decision) select CPT bit for a follow on PD response if a follow on PD request contains a number of CPT bit options in a feature capability field? Definitely the seeker selection may not match an advertiser per service preference. My point is that perhaps we may need both per service CPT and a global CPT preference lists to cover your requirement. Per service CPT preference list is supposed to be used by an advertiser handling a direct PD request. (To be precise a per service CPT preference usage is restricted only for service advertisements having auto_accept == true and config_methods != KEYPAD.) A global CPT preference list supposed to be used in other cases, e.g. by advertisers when per service preference list is not defined or by seekers on follow-on PD request.

What do you think?


>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;
>+		}
>+	}

The first byte is defined as Coordination Protocol Transport Bitmask field, so, PD responder sets only one single bit selecting the transport.
The rest of the feature capability fields are explicitly set to zero a line before this loop:

	os_memset(resp_cap, 0, P2PS_FEATURE_CAPAB_LEN);

I think this function and P2PS_FEATURE_CAPAB_LEN has to be updated when new fields in feature capability to be added.

Thanks,
Max

> -----Original Message-----
> From: Stepanov, Max [mailto:Max.Stepanov@intel.com]


> Assume we have per service CPT preference on an advertiser side. How should
> a seeker (making a final decision) select CPT bit for a follow on PD response if a
> follow on PD request contains a number of CPT bit options in a feature
> capability field? Definitely the seeker selection may not match an advertiser
> per service preference. My point is that perhaps we may need both per service
> CPT and a global CPT preference lists to cover your requirement. Per service
> CPT preference list is supposed to be used by an advertiser handling a direct PD
> request. (To be precise a per service CPT preference usage is restricted only for
> service advertisements having auto_accept == true and config_methods !=
> KEYPAD.) A global CPT preference list supposed to be used in other cases, e.g.
> by advertisers when per service preference list is not defined or by seekers on
> follow-on PD request.
> 
> What do you think?


I think P2P_ASP_PROVISIONING command can be used to provide the cpt to be used for responding to a follow-on PD req by seeker.

Let me write down my proposal on this.There are two cases:
1. auto_accept == true
     Seeker sends "cpt configured through P2P_ASP_PROVISIOING command" in PD request. Advertiser uses "cpt configured through P2P_SERVICE_ADD command" to choose (based on intersection with whatever received in PD req) a transport mode and sends it in PD response.

2. auto_acceot==false
     Seeker sends "cpt configured through P2P_ASP_PROVISIOING command" in PD request. Advertiser uses "cpt configured through P2P_SERVICE_ADD command" to choose (based on intersection with whatever received in PD req) a transport mode and sends it in PD response(though this will not be used for service establishment). Advertiser reports the received feat_capa to the ASP sitting on top of it.
    The Advertiser's ASP will configure the preferred cpt through P2P_ASP_PROVISIONING_RESP command which should be sent in follow-on PD req. The seeker can choose one transport mode to be used with that service instance based on the intersection of cpt received in follow-on PD request and the cpt configured earlier through P2P_ASP_PROVISIONING command (this can be saved in p2ps_prov structure until then).

Let me know if you see some problem with the above.

Thanks,
Vamsi

>-----Original Message-----
>From: Vamsi, Krishna [mailto:vamsin@qti.qualcomm.com]
>1. auto_accept == true
>     Seeker sends "cpt configured through P2P_ASP_PROVISIOING command"
>in PD request. Advertiser uses "cpt configured through P2P_SERVICE_ADD
>command" to choose (based on intersection with whatever received in PD
>req) a transport mode and sends it in PD response.
>
>2. auto_acceot==false
>     Seeker sends "cpt configured through P2P_ASP_PROVISIOING command"
>in PD request. Advertiser uses "cpt configured through P2P_SERVICE_ADD
>command" to choose (based on intersection with whatever received in PD
>req) a transport mode and sends it in PD response(though this will not be
>used for service establishment). Advertiser reports the received feat_capa to
>the ASP sitting on top of it.
>    The Advertiser's ASP will configure the preferred cpt through
>P2P_ASP_PROVISIONING_RESP command which should be sent in follow-on
>PD req. The seeker can choose one transport mode to be used with that
>service instance based on the intersection of cpt received in follow-on PD
>request and the cpt configured earlier through P2P_ASP_PROVISIONING
>command (this can be saved in p2ps_prov structure until then).
>
>Let me know if you see some problem with the above.

It looks reasonable to me. I'll change my implementation and let you know.

Thanks,
Max