[PATCH] P2P: Prevent p2p connect misuse

[Arend van Spriel]

On 12/03/14 15:14, Arend van Spriel wrote:
> 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).

Would it be better to call the p2p_ctrl_*() functions with 
wpa_s->global->p2p_init_wpa_s. At least p2p_ctrl_find() and probably 
p2p_ctrl_connect(). Or should it be decided at another level in the 
supplicant.

Regards,
Arend

> Regards,
> Arend
> _______________________________________________
> HostAP mailing list
> HostAP at lists.shmoo.com
> http://lists.shmoo.com/mailman/listinfo/hostap