wpa_supplicant and WPS config methods vs P2P config methods

[Jouni Malinen]

On Mon, Sep 07, 2015 at 02:32:58PM +0000, Atul Joshi wrote:
> On Fri, Aug 28, 2015 at 10:06:50AM +0000, Atul Joshi wrote:
> > Wpa supplicant has a CLI command SET config_methods to set WPS config methods but the config methods within P2P device info attribute are taken from p2p_supplicant.conf this can lead to discrepancy in config method advertisement.

> 1441633801.223853: nl80211: proberesp_ies - hexdump(len=160): 7f 08 04 00 00 00 00 00 00 40 dd 6c 00 50 f2 04 10 4a 00 01 10 10 44 00 01 02 10 3b 00 01 03 10 47 00 10 00 50 f2 12 34 56 78 90 12 34 56 78 90 12 34 56 10 21 00 01 20 10 23 00 09 4d 6f 72 70 68 65 75 73 32 10 24 00 01 20 10 42 00 05 31 32 33 34 35 10 54 00 08 00 0a 00 50 f2 04 00 04 10 11 00 05 43 53 52 47 4f 10 08 00 02 00 00 10 49 00 06 00 37 2a 00 01 20 dd 26 50 6f 9a 09 02 02 00 25 89 0d 1a 00 00 02 5b 03 12 50 11 88 00 0a 00 50 f2 04 00 04 00 10 11 00 05 43 53 52 47 4f
> 
> Here we can see that 0d 1a 00 00 02 5b 03 12 50 11 88  last 2 octets are config methods.

So this is the Config Methods field in the P2P Device Info attribute in
the P2P Probe Response frame from the GO. This Config Methods fields is
filled in my p2p_buf_add_device_info() with peer == NULL which will
either use the configured config_methods (if set) masked with the
defaults or defaults (if not set).

The current default config method value for this specific field is
0x1188 which is the value that shows up in this example. That would seem
to indicate that in your test run, the defaults were set. In this
specific case, the configuration command was "SET config_methods pbc"
which is invalid. The correct one would have been "SET config_methods
push_button". Due to the way this string gets parsed currently, invalid
entries are ignored and if there are no valid values, 0 is returned from
wps_config_methods_str2bin(). This ends up meaning same as use the
defaults..

While it would be possible to add additional validation steps for
parsing config_methods SET command, I'm a bit hesitant on doing that
after the current parser having been used for more than five years..
Especially as this would apply to reading the string from an old
configuration file is concerned, stricter validation could result in
wpa_supplicant refusing to start if there is invalid configuration
values present somewhere.


> Also I can see that irrespective of which methods are configured, we process Provision Discovery Request from peer, by comparing with  hardcoded config methods
> 
> In file p2p_pd.c in function  p2p_process_prov_disc_req we compare
>                 if (!(msg.wps_config_methods &
>                       (WPS_CONFIG_DISPLAY | WPS_CONFIG_KEYPAD |
>                        WPS_CONFIG_PUSHBUTTON | WPS_CONFIG_P2PS))) {
>                                 p2p_dbg(p2p, "Unsupported Config Methods in Provision Discovery Request");
>                                 goto out;
>                 }
> 
> Thus for P2P case, we always consider all P2P config methods supported.

That's not completely accurate. For the P2P _provision discovery_ case,
the configured parameter is not used. This does not include all Config
Methods (and that list is somewhat more dynamic with the current
wpa_supplicant version). In any case, this sounds quite independent
question and is not relevant to your previous message that talked about
p2p_supplicant.conf vs. SET config_methods difference.

P2P PD is somewhat of a special case for config methods.. There are
rules that expect the recipient to event ignore the response completely
(e.g., join-a-group case) and I'm not sure it would make much sense to
constraint this based on the current config_method configuration
especially taken into account the last five years of use with the
current design..

If some addition constraints on PD Request processing is desired, that
may, in practice, need a new configuration parameter to allow such an
extension to be done without breaking existing use cases. For that to
happen, I'd need to get a clear description of the high level use case
where such an extra constraint would be of benefit and also a
description on how common deployed devices would likely behave if they
were to receive PD Response with config methods 0 rather than the value
they may have expected.

-- 
Jouni Malinen                                            PGP id EFC895FA