Patchwork P2P: Fix problem with connecting to non-P2P network in P2P mode

login
register
mail settings
Submitter Klimczewski Marcin
Date May 17, 2012, 2:11 p.m.
Message ID <4FB50716.5090203@tieto.com>
Download mbox | patch
Permalink /patch/159910/
State Changes Requested
Headers show

Comments

Klimczewski Marcin - May 17, 2012, 2:11 p.m.
This patch allows connection to non-P2P network in P2P mode. In P2P 
mode, attempt to connect to non-P2P network always fails due to handling 
scan results in P2P specific way and scan process looping itself. To 
solve it wpas_p2p_stop_find() is called just after invoking scan request.

 From 75ef9fd523266cc1925681a1973e70d014b5df4a Mon Sep 17 00:00:00 2001
From: Marcin Klimczewski <marcin.klimczewski@tieto.com>
Date: Thu, 17 May 2012 12:28:41 +0200
Subject: [PATCH] P2P: Fix problem with connecting to non-P2P network in 
P2P mode

To allow to connect to non-P2P network in P2P mode,
p2p_stop_find is called just after invoking scan request.

Signed-off-by: Marcin Klimczewski <marcin.klimczewski@tieto.com>
---
  wpa_supplicant/scan.c |    2 ++
  1 files changed, 2 insertions(+), 0 deletions(-)

         eloop_cancel_timeout(wpa_supplicant_scan, wpa_s, NULL);
Jouni Malinen - June 24, 2012, 9:48 a.m.
On Thu, May 17, 2012 at 04:11:34PM +0200, Klimczewski Marcin wrote:
> This patch allows connection to non-P2P network in P2P mode. In P2P 
> mode, attempt to connect to non-P2P network always fails due to handling 
> scan results in P2P specific way and scan process looping itself. To 
> solve it wpas_p2p_stop_find() is called just after invoking scan request.

> To allow to connect to non-P2P network in P2P mode,
> p2p_stop_find is called just after invoking scan request.

This looks a bit too low-level location to call wpas_p2p_stop_find(),
i.e., if the P2P device discovery needs to be stopped, that should
probably happen when a connection is being requested in the first place
rather than when a scan request (which may be used for other purposes,
too) is being processed.
Janusz Dziedzic - June 25, 2012, 6:41 a.m.
2012/6/24 Jouni Malinen <j@w1.fi>:
> On Thu, May 17, 2012 at 04:11:34PM +0200, Klimczewski Marcin wrote:
>> This patch allows connection to non-P2P network in P2P mode. In P2P
>> mode, attempt to connect to non-P2P network always fails due to handling
>> scan results in P2P specific way and scan process looping itself. To
>> solve it wpas_p2p_stop_find() is called just after invoking scan request.
>
>> To allow to connect to non-P2P network in P2P mode,
>> p2p_stop_find is called just after invoking scan request.
>
> This looks a bit too low-level location to call wpas_p2p_stop_find(),
> i.e., if the P2P device discovery needs to be stopped, that should
> probably happen when a connection is being requested in the first place
> rather than when a scan request (which may be used for other purposes,
> too) is being processed.
>
Hello Jouni,

This fix solve problem we have during such test case:
1) add and configure network 0
2) run p2p_scan
3) enable_network 0

Seems step-3 don't work because of p2p_scan.
So, the question is if supplicant should stop p2p_scan or this should
be solve in upper layer?

BR
Janusz
Jouni Malinen - June 25, 2012, 8:29 a.m.
On Mon, Jun 25, 2012 at 08:41:23AM +0200, Janusz Dziedzic wrote:
> This fix solve problem we have during such test case:
> 1) add and configure network 0
> 2) run p2p_scan

Do you mean p2p_find?

> 3) enable_network 0
> 
> Seems step-3 don't work because of p2p_scan.
> So, the question is if supplicant should stop p2p_scan or this should
> be solve in upper layer?

p2p_find tries to use all possible time on the radio for P2P device
discovery. As such, it is pretty much exclusive with any other radio
operation.

As far as stopping p2p_find is concerned, that is currently done with
some P2P operations, but those are only done based on explicit control
interface command from an external application. Whether "enable_network
0" should be such command is a question that may not have a clear
answer.. I'm not sure which behavior would be less confusing for
external programs that may expect P2P device discovery to continue.

That said, if we want to disable p2p_find on enable_network command, it
would seem that wpa_supplicant_enable_network() would be the place to do
this.
Janusz Dziedzic - June 25, 2012, 10:50 a.m.
2012/6/25 Jouni Malinen <j@w1.fi>:
> On Mon, Jun 25, 2012 at 08:41:23AM +0200, Janusz Dziedzic wrote:
>> This fix solve problem we have during such test case:
>> 1) add and configure network 0
>> 2) run p2p_scan
>
> Do you mean p2p_find?

yes.

>
>> 3) enable_network 0
>>
>> Seems step-3 don't work because of p2p_scan.
>> So, the question is if supplicant should stop p2p_scan or this should
>> be solve in upper layer?
>
> p2p_find tries to use all possible time on the radio for P2P device
> discovery. As such, it is pretty much exclusive with any other radio
> operation.
>
> As far as stopping p2p_find is concerned, that is currently done with
> some P2P operations, but those are only done based on explicit control
> interface command from an external application. Whether "enable_network
> 0" should be such command is a question that may not have a clear
> answer.. I'm not sure which behavior would be less confusing for
> external programs that may expect P2P device discovery to continue.
>
> That said, if we want to disable p2p_find on enable_network command, it
> would seem that wpa_supplicant_enable_network() would be the place to do
> this.
>

The problem still with other paths that enable network.
select_network 0
reassociate

So, best is to left this for upper layer to decide.
Thanks.

BR
Janusz

Patch

diff --git a/wpa_supplicant/scan.c b/wpa_supplicant/scan.c
index e66eed1..85fcf4d 100644
--- a/wpa_supplicant/scan.c
+++ b/wpa_supplicant/scan.c
@@ -708,6 +708,8 @@  void wpa_supplicant_req_scan(struct wpa_supplicant 
*wpa_s, int sec, int usec)
                 }
         }

+       wpas_p2p_stop_find(wpa_s);
+
         wpa_dbg(wpa_s, MSG_DEBUG, "Setting scan request: %d sec %d usec",
                 sec, usec);