[RFC] P2P: Handling single channel concurrency

[Jouni Malinen]

On Mon, Jan 16, 2012 at 11:11:39AM -0800, Jithu Jance wrote:
> I made some changes to the previously sent patch and is attached below. Kindly review the same.

Thanks! There was some whitespace corruption in the patch, but I think
I managed to get the changes correctly. I split the patch into four
pieces for easier review and did some cleanup. Please check the attached
files.

> A new config param "prioritize" has been added to provide the default user preference setting. If it is not used, then event is
> indicated to application/above framework to take appropriate action.

Adding a mechanism to figure out which interface is preferred is fine,
but I'm not sure this configuration parameter is the best way of doing
this. I added the other wpa_s pointer as an argument to the
wpas_is_interface_prioritized() function to allow somewhat more complex
mechanism to be implemented if desired. In addition, I changed
wpa_s->conf->prioritize to wpa_s->parent->conf->prioritize so that this
parameter is used consistently from a single configuration file in P2P
use cases. Though, this may not be correct for cases where multiple
interfaces are started from command line. See concurrent-1.patch for
these.

Is fixed ifname configuration the best way of configuring the
preference? I was thinking more of a new ctrl_iface command that could
be used on any interface (say, "SET_PREFERRED"). I guess the same could
be handled with the prioritize field ("SET prioritize wlan3" on the
parent interface), but this information should really be in struct
wpa_global and not in struct wpa_config (and in there, it could be a
pointer to the preferred wpa_s rather than having to store an interface
name and that SET_PREFERRED would be used to set/change this).

> I also added a new event to indicate that a STATION
> connection is in conflict with a P2P connection. If prioritize=<iface> is set for STA interface, then it will disconnect P2P and then
> proceed with STA connection. If it is not set, then it will indicate user application of the frequency conflict.

OK. This is in concurrent-4.patch. I moved the no-priority-set part into
wpas_is_interface_prioritized() to provide a cleaner separation between
the P2P code and interface preferences.

It looks like this patch may have somewhat strange behavior for the case
where a P2P client interface is using wpa_supplicant-controlled
"roaming", i.e., changing frequencies to follow the GO that is doing a
channel switch. In that case, we should allow the association request
even if the interface is not marked prioritized since that association
operation itself is going to resolve the frequency conflict.

> In scenarios where a STA connection already exists and a P2P join is attempted on a different channel, I am failing the P2P connection when frequency
> conflict is detected. I have appended a reason code to GROUP-FORMATION-FAILURE to indicate that this is a case of frequency conflict. I know that
> changing an external event is dangerous. But was doubtful on whether to add another specific event to handle this case. so i just appended a reason code to
> the existing event. Please advise whether it is better to add another event or handle it in some other way.

This sounds fine (concurrent-2.patch).


Have you looked at more details on how to implement the new driver
operation (concurrent-3.patch) with cfg80211/nl80211?

How would station mode roaming cases handled, e.g., what if the driver
were to indicate that it reassociated a legacy STA interface on another
channel? Do we need code for that in wpa_supplicant or is the
expectation here that the driver would stop any conflicting interface in
such a case (e.g., indicate a GO interface cannot operate anymore)? I'm
not sure how exactly to coordinate a operating channel move in this type
of case when legacy STA interface would like to move to another
frequency and a GO interface is running.

-- 
Jouni Malinen                                            PGP id EFC895FA
-------------- next part --------------
A non-text attachment was scrubbed...
Name: concurrent-1.patch
Type: text/x-diff
Size: 5074 bytes
Desc: not available
Url : http://lists.shmoo.com/pipermail/hostap/attachments/20120205/2c85f485/attachment-0004.patch 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: concurrent-2.patch
Type: text/x-diff
Size: 1118 bytes
Desc: not available
Url : http://lists.shmoo.com/pipermail/hostap/attachments/20120205/2c85f485/attachment-0005.patch 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: concurrent-3.patch
Type: text/x-diff
Size: 1438 bytes
Desc: not available
Url : http://lists.shmoo.com/pipermail/hostap/attachments/20120205/2c85f485/attachment-0006.patch 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: concurrent-4.patch
Type: text/x-diff
Size: 4980 bytes
Desc: not available
Url : http://lists.shmoo.com/pipermail/hostap/attachments/20120205/2c85f485/attachment-0007.patch