[RFC] P2P: Handling single channel concurrency
Jithu Jance
jithujance
Mon Feb 6 17:23:48 PST 2012
Thanks Jouni for your email. Pls find my comments inline.
> 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 was also thinking of something that can be set in wpa_global. I will
update this part.
> 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.
This is mentioned in the case 3(a) below. If the interface is GO and
channel switch is supported,
we would move the GO (only a hook is provided at this point) and allow the
assoc to proceed.
> Have you looked at more details on how to implement the new driver
> operation (concurrent-3.patch) with cfg80211/nl80211?
I am yet to start on this part.
> 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 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
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.
Two more changes from my side which are not in the current set of patches.
a) I later felt that providing network_id would be better than providing
ssid and bssid during WPA_EVENT_FREQ_CONFLICT.
+???????????wpa_msg(wpa_s, MSG_INFO, WPA_EVENT_FREQ_CONFLICT
+???????????????" ssid=%s bssid=" MACSTR,
+???????????????wpa_ssid_txt(ssid->ssid, ssid->ssid_len),
+???????????????MAC2STR(wpa_s->pending_bssid));
changed to
+???????????wpa_msg(wpa_s, MSG_INFO, WPA_EVENT_FREQ_CONFLICT
" id=%d", ssid->id);.
b) I have added a new reason code to P2P_GROUP_REMOVE
reason=FREQ_CONFLICT. This is useful when a p2p group gets removed when STA
connection has more priority.
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.
1. We got a STA connection already. Now a P2P Join is requested.
Action: Check whether there is the GO to which Join is requested on a
different channel. If
channel is different, announce GROUP-FORMATION-FAILURE with reason as
freq_conflict. Let
the application decide further. This is handled by concurrent-2.patch
2. We got a STA connection already. Now a P2P GO Nego connection is
requested. The supplicant
automatically tries to start the new connection on the shared channel.
There can be failures
a) The go nego requesting device may not support the channel.
b) The other device doesn't support channel (due to a shared interface
on someother channel).
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.
3. We got a P2P Connection present and now a STA association is attempted.
This could include
supplicant based roaming. It would be difficult to make a run-time based
decision. So basically,
the decision will be done based on the pre-set connection priority
(whether STA or P2P connection
has the priority).
a) If the P2P interface is a GO, then try moving the GO to the STA
channel (there by avoiding the conflict).
b) If GO channel switch is not supported or if the interface is a
P2P-client, then we need to terminate
one of the connection.
c) If STA has priority, the P2P connection is terminated indicating that
it is caused due to frequency
conflict.
d) If P2P connection has priority, the STA ssid is disabled and upper
framework is notified about that.
Now the application/framwork can decide whether to terminate P2P in
favor or STA or leave it like that.
e) If the priority is not set, the default behavior is to notify the
upper application or framework. The supplicant
won't do any policing.
Status: These 4a to 4e cases are hanlded by concurrent-4.patch.
4. supplicant gets the STA connected event while we already have a p2p
connection on some other channel
(roaming handled by driver/firmware).
Status: Not yet handled.
In short, the Action Items for me.
1. Move prioritize setting to wpa_global
2. Handle cases where we get STA CONNECTED event while we have a
p2p_interface.
I will get back to you again after making the above two changes.
The rest probably we can take care as second step.
1) The concurrent-3.patch expansion [go_switch_channel].
- Jithu Jance
On Sun, Feb 5, 2012 at 4:36 PM, Jouni Malinen <j at w1.fi> wrote:
> 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
>
> _______________________________________________
> HostAP mailing list
> HostAP at lists.shmoo.com
> http://lists.shmoo.com/mailman/listinfo/hostap
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.shmoo.com/pipermail/hostap/attachments/20120207/35ee90d6/attachment-0001.htm
More information about the Hostap
mailing list