| Message ID | 4FB50716.5090203@tieto.com |
|---|---|
| State | Changes Requested |
| Headers | show |
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.
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
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.
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
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);