[PATCH] P2P: Prevent p2p connect misuse

[Arend van Spriel]

On 12/03/14 14:19, Michal Kazior wrote:
> On 2 December 2014 at 17:13, Arend van Spriel<arend at broadcom.com>  wrote:
>> On 12/02/14 12:29, Michal Kazior wrote:
>>>
>>> It was possible to request p2p_connect (and possibly other callers like
>>> p2p_prov_disc, and nfc-related stuff) on a different wpa_s context than
>>> its subsequent related events were processed in causing failures.
>>>
>>> For example with dedicated p2pdev wpa_s->create_p2p_iface could be set
>>> on, e.g. wlan1 but later wpas_go_neg_completed() was called for
>>> p2p-dev-wlan1 whose create_p2p_iface was 0. This ended up with wpa_s
>>> trying to use p2p-dev-wlan1 to associate (which isn't even a netdev).
>>>
>>> Steps to reproduce:
>>>
>>>    1. use driver with p2pdev
>>>    2. start wpa_s, let wlan0 connect
>>>    3. wpa_cli -i wlan0 p2p_find
>>>    4. wpa_cli -i wlan0 p2p_connect ..
>>>    5. p2p-dev-wlan0 tries to associate despite it's not even a netdev
>>>
>>> Obviously using p2p commands on non-main/p2p interface seems wrong and
>>> steps (3) and (4) should be using p2p-dev-wlan0 instead. Nevertheless it
>>> makes sense to prevent this misuse and warn the user in a sane way
>>> instead of performing a cascade of strange failures.
>>
>>
>> I thought steps (3) and (4) are global commands and would be forwarded to
>> the (dedicated) p2p management interface.
>
> Apparently that is not the case, at least as far as P2P_CONNECT and
> wpas_p2p_connect() are concerned. I wonder if there are any other
> commands which suffer from this kind of problem (i.e. silently assume
> caller context is the same as event callback context at a later time)?

Apparently;-) Question is what should be the intended behaviour to 
determine how/where to fix these issue(s).

Regards,
Arend