On 11/02/13 08:33, Jouni Malinen wrote:
On Fri, Nov 01, 2013 at 02:07:16PM +0100, Arend van Spriel wrote:
On 11/01/2013 12:25 PM, Undekari, Sunil Dutt wrote:
The host driver / firmware performs (initiates) a scan on the STA interface in the process of finding a better BSS to roam. This scan is offloaded to the driver / firmware for a better roam experience.
This scans would definitely affect the p2p connection triggered by the supplicant.
Thus, I was suggesting a way to extend the already existing critical protocol indications to also include p2p protocol/connections, so that drivers can defer the scan's (any off channel operations for that matter) on any other interface during this period.
I got that. What I meant to say is that you can defer the roaming
related scans when cfg80211 does a .add_virtual_intf() call to the
driver and recommence upon .del_virtual_intf(). I guess this
effectively disables roaming, right?
That sounds quite excessive. The case here is a multi-channel
concurrency capable device which has a station connection and
wpa_supplicant is about to go through P2P group formation. I see no
reason to disable roaming, but it would sound useful to avoid doing the
background scans for that at the exact time of the group formation
(couple of seconds in most cases).
This is why I was asking for a more detailed usage scenario. Sunil only
mentioned the term "P2P connection" which seemed to coarse for this API.
So if we are talking about P2P group formation it makes sense.
Currently, there is no way for wpa_supplicant to clearly indicate to the
driver that it is about to run through number of quick operations
(offchannel Action frame exchange for GO Negotiation, single channel
scan, WPS association + EAPOL exchange, data connection association +
4-way handshake). The driver can guess that this is happening (or could
use really ugly hacks to see what Action frames are exchanged and
determine next likely operation based on that) and as such, would not
know how to configure the firmware to avoid background scans for the
station interface during this full sequence.
I wanted this API primarily to avoid drivers doing that kind of hacks so
I agree. It was intended to avoid extra latencies during IP connection
setup, which is probably happening right after the group formation. So I
recommend the connection managers to use this API. I think Dan Williams
did some initial implementation testing in NetworkManager and had some
concerns. I forgot about them completely so not sure how that ended.
While the background scan should in most cases not completely break the
process even with inconvenient timing (or well, hitting one in middle of
the three frame GO Negotiation would have potential to time out that
exchange), it would be nice if this common sequence could be optimized
to avoid extra latencies and to be more robust in general since there is
a 15 second timeout for group formation and quite a bit shorter timeouts
in practice for the individual operations within the sequence.
I guess the decision is for Johannes to take, but I see your point.
Regards,
Arend
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
