<div><br></div><div><div>Thanks Jouni for your email. Pls find my comments inline.</div><div><br></div><div>> I was thinking more of a new ctrl_iface command that could<br>> be used on any interface (say, "SET_PREFERRED"). I guess the same could<br>
> be handled with the prioritize field ("SET prioritize wlan3" on the<br>> parent interface), but this information should really be in struct<br>> wpa_global and not in struct wpa_config (and in there, it could be a<br>
> pointer to the preferred wpa_s rather than having to store an interface<br>> name and that SET_PREFERRED would be used to set/change this).</div><div><br></div><div>I was also thinking of something that can be set in wpa_global. I will update this part.</div>
<div><br></div><div>> It looks like this patch may have somewhat strange behavior for the case<br>> where a P2P client interface is using wpa_supplicant-controlled<br>> "roaming", i.e., changing frequencies to follow the GO that is doing a<br>
> channel switch. In that case, we should allow the association request<br>> even if the interface is not marked prioritized since that association<br>> operation itself is going to resolve the frequency conflict.</div>
<div>This is mentioned in the case 3(a) below. If the interface is GO and channel switch is supported,</div><div>we would move the GO (only a hook is provided at this point) and allow the assoc to proceed.</div><div><br>
</div>
<div>> Have you looked at more details on how to implement the new driver<br>> operation (concurrent-3.patch) with cfg80211/nl80211?</div><div>I am yet to start on this part.</div><div><br></div><div><br></div><div>
> How would station mode roaming cases handled, e.g., what if the driver<br>> were to indicate that it reassociated a legacy STA interface on another<br>> channel? Do we need code for that in wpa_supplicant or is the<br>
> expectation here that the driver would stop any conflicting interface in<br>> such a case (e.g., indicate a GO interface cannot operate anymore)?</div><div>I am expecting the driver not to attempt a connection, if another interface is connected on a different channel (and FW roaming is supported). But again, this is debatable. Some drivers might</div>
<div>by default give preference to STA operation. We might need to handle cases where supplicant gets the STA connected event while we already have a p2p connection on some other channel. Probably in this case, we can just do a p2p_group_remove with reason=freq_conflict. </div>
<div><br></div><div>Two more changes from my side which are not in the current set of patches.</div><div><div><div>a) I later felt that providing network_id would be better than providing ssid and bssid during WPA_EVENT_FREQ_CONFLICT. </div>
<div>+▷⋅⋅▷⋅⋅⋅▷⋅⋅⋅wpa_msg(wpa_s, MSG_INFO, WPA_EVENT_FREQ_CONFLICT</div><div>+▷⋅⋅▷⋅⋅⋅▷⋅⋅⋅▷⋅⋅⋅" ssid=%s bssid=" MACSTR,</div><div>+▷⋅⋅▷⋅⋅⋅▷⋅⋅⋅▷⋅⋅⋅wpa_ssid_txt(ssid->ssid, ssid->ssid_len),</div><div>+▷⋅⋅▷⋅⋅⋅▷⋅⋅⋅▷⋅⋅⋅MAC2STR(wpa_s->pending_bssid));</div>
<div><br></div><div>changed to</div><div><br></div><div>+▷⋅⋅▷⋅⋅⋅▷⋅⋅⋅wpa_msg(wpa_s, MSG_INFO, WPA_EVENT_FREQ_CONFLICT</div><div><span style="white-space:pre-wrap"> </span>" id=%d", ssid->id);.</div></div><div>
<br></div>b) I have added a new reason code to P2P_GROUP_REMOVE</div><div>reason=FREQ_CONFLICT. This is useful when a p2p group gets removed when STA connection has more priority.</div><div><br></div><div><br></div><div>Let me put the scenarios which we want to address and what have so far been handled by the current patches. Please add to this, if i missed any.</div>
<div><br></div><div>1. We got a STA connection already. Now a P2P Join is requested.</div>
<div>Action: Check whether there is the GO to which Join is requested on a different channel. If </div><div> channel is different, announce GROUP-FORMATION-FAILURE with reason as freq_conflict. Let</div><div> the application decide further. This is handled by concurrent-2.patch</div>
<div><br></div><div>2. We got a STA connection already. Now a P2P GO Nego connection is requested. The supplicant</div><div> automatically tries to start the new connection on the shared channel. </div><div><br></div><div>
There can be failures</div><div> a) The go nego requesting device may not support the channel.</div><div> b) The other device doesn't support channel (due to a shared interface on someother channel).</div><div>
<br></div><div> If GO negotiation fails with status 7, it could be caused due to freq conflict. I think status code is good enough for application to know that it is a channel problem. </div><div><br></div><div>3. We got a P2P Connection present and now a STA association is attempted. This could include </div>
<div> supplicant based roaming. It would be difficult to make a run-time based decision. So basically,</div><div> the decision will be done based on the pre-set connection priority (whether STA or P2P connection</div>
<div> has the priority).</div><div><br></div><div> a) If the P2P interface is a GO, then try moving the GO to the STA channel (there by avoiding the conflict).</div><div> </div><div><span style="white-space:pre-wrap"> b) </span>If GO channel switch is not supported or if the interface is a P2P-client, then we need to terminate</div>
<div> one of the connection. </div><div><br></div><div> c) If STA has priority, the P2P connection is terminated indicating that it is caused due to frequency </div><div> conflict. </div><div><br></div><div>
d) If P2P connection has priority, the STA ssid is disabled and upper framework is notified about that.</div>
<div> Now the application/framwork can decide whether to terminate P2P in favor or STA or leave it like that.</div><div><br></div><div> e) If the priority is not set, the default behavior is to notify the upper application or framework. The supplicant</div>
<div> won't do any policing.</div><div><br></div><div> Status: These 4a to 4e cases are hanlded by concurrent-4.patch. </div><div><br></div><div>4. supplicant gets the STA connected event while we already have a p2p connection on some other channel </div>
<div> (roaming handled by driver/firmware).</div><div><br></div><div>Status: Not yet handled.</div><div><br></div></div><div><br></div><div><br></div><div>In short, the Action Items for me.</div><div>1. Move prioritize setting to wpa_global</div>
<div>2. Handle cases where we get STA CONNECTED event while we have a p2p_interface.</div><div><br></div><div>I will get back to you again after making the above two changes.</div>
<div><br></div><div>The rest probably we can take care as second step.</div><div>1) The concurrent-3.patch expansion [go_switch_channel].</div><div><br></div><div><br></div><div><br></div><div><br></div><div>- Jithu Jance</div>
<br><br><div class="gmail_quote">On Sun, Feb 5, 2012 at 4:36 PM, Jouni Malinen <span dir="ltr"><<a href="mailto:j@w1.fi" target="_blank">j@w1.fi</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>On Mon, Jan 16, 2012 at 11:11:39AM -0800, Jithu Jance wrote:<br>
> I made some changes to the previously sent patch and is attached below. Kindly review the same.<br>
<br>
</div>Thanks! There was some whitespace corruption in the patch, but I think<br>
I managed to get the changes correctly. I split the patch into four<br>
pieces for easier review and did some cleanup. Please check the attached<br>
files.<br>
<div><br>
> A new config param "prioritize" has been added to provide the default user preference setting. If it is not used, then event is<br>
> indicated to application/above framework to take appropriate action.<br>
<br>
</div>Adding a mechanism to figure out which interface is preferred is fine,<br>
but I'm not sure this configuration parameter is the best way of doing<br>
this. I added the other wpa_s pointer as an argument to the<br>
wpas_is_interface_prioritized() function to allow somewhat more complex<br>
mechanism to be implemented if desired. In addition, I changed<br>
wpa_s->conf->prioritize to wpa_s->parent->conf->prioritize so that this<br>
parameter is used consistently from a single configuration file in P2P<br>
use cases. Though, this may not be correct for cases where multiple<br>
interfaces are started from command line. See concurrent-1.patch for<br>
these.<br>
<br>
Is fixed ifname configuration the best way of configuring the<br>
preference? I was thinking more of a new ctrl_iface command that could<br>
be used on any interface (say, "SET_PREFERRED"). I guess the same could<br>
be handled with the prioritize field ("SET prioritize wlan3" on the<br>
parent interface), but this information should really be in struct<br>
wpa_global and not in struct wpa_config (and in there, it could be a<br>
pointer to the preferred wpa_s rather than having to store an interface<br>
name and that SET_PREFERRED would be used to set/change this).<br>
<div><br>
> I also added a new event to indicate that a STATION<br>
> connection is in conflict with a P2P connection. If prioritize=<iface> is set for STA interface, then it will disconnect P2P and then<br>
> proceed with STA connection. If it is not set, then it will indicate user application of the frequency conflict.<br>
<br>
</div>OK. This is in concurrent-4.patch. I moved the no-priority-set part into<br>
wpas_is_interface_prioritized() to provide a cleaner separation between<br>
the P2P code and interface preferences.<br>
<br>
It looks like this patch may have somewhat strange behavior for the case<br>
where a P2P client interface is using wpa_supplicant-controlled<br>
"roaming", i.e., changing frequencies to follow the GO that is doing a<br>
channel switch. In that case, we should allow the association request<br>
even if the interface is not marked prioritized since that association<br>
operation itself is going to resolve the frequency conflict.<br>
<div><br>
> 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<br>
> 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<br>
> 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<br>
> the existing event. Please advise whether it is better to add another event or handle it in some other way.<br>
<br>
</div>This sounds fine (concurrent-2.patch).<br>
<br>
<br>
Have you looked at more details on how to implement the new driver<br>
operation (concurrent-3.patch) with cfg80211/nl80211?<br>
<br>
How would station mode roaming cases handled, e.g., what if the driver<br>
were to indicate that it reassociated a legacy STA interface on another<br>
channel? Do we need code for that in wpa_supplicant or is the<br>
expectation here that the driver would stop any conflicting interface in<br>
such a case (e.g., indicate a GO interface cannot operate anymore)? I'm<br>
not sure how exactly to coordinate a operating channel move in this type<br>
of case when legacy STA interface would like to move to another<br>
frequency and a GO interface is running.<br>
<div><div><br>
--<br>
Jouni Malinen PGP id EFC895FA<br>
</div></div><br>_______________________________________________<br>
HostAP mailing list<br>
<a href="mailto:HostAP@lists.shmoo.com" target="_blank">HostAP@lists.shmoo.com</a><br>
<a href="http://lists.shmoo.com/mailman/listinfo/hostap" target="_blank">http://lists.shmoo.com/mailman/listinfo/hostap</a><br>
<br></blockquote></div><br>