P2P: Wait 100 ms if driver fails to start listen operation
Some drivers may accept the remain-on-channel command, but instead of indicating start event for remain-on-channel, just indicate that the operation has been canceled immediately. This could result in continuous loop of search/listen states with very limited time to do anything else in wpa_supplicant if the scan command is also completed quickly (e.g., if the driver is unable to scan other channels than the current operating channel). As a workaround, do not start the next step (search) in P2P device discovery if this type of rejection of listen operation is detected. This gives some more time for wpa_supplicant to handle whatever else may be needed at to be done at the same time and reduces the amount of CPU used in a loop that does not really work correctly from the view point of being discoverable. Signed-hostap: Jouni Malinen <jouni@qca.qualcomm.com> intended-for: hostap-1
This commit is contained in:
parent
fea7c3a055
commit
3fe8b68d63
1 changed files with 12 additions and 0 deletions
|
@ -2922,6 +2922,18 @@ int p2p_listen_end(struct p2p_data *p2p, unsigned int freq)
|
|||
"new one");
|
||||
return 1;
|
||||
}
|
||||
if (p2p->pending_listen_freq) {
|
||||
/*
|
||||
* Better wait a bit if the driver is unable to start
|
||||
* offchannel operation for some reason. p2p_search()
|
||||
* will be started from internal timeout.
|
||||
*/
|
||||
wpa_msg(p2p->cfg->msg_ctx, MSG_DEBUG, "P2P: Listen "
|
||||
"operation did not seem to start - delay "
|
||||
"search phase to avoid busy loop");
|
||||
p2p_set_timeout(p2p, 0, 100000);
|
||||
return 1;
|
||||
}
|
||||
p2p_search(p2p);
|
||||
return 1;
|
||||
}
|
||||
|
|
Loading…
Reference in a new issue