Hi Luis, > -----Original Message----- > From: Luis R. Rodriguez [mailto:mcg...@suse.com] > Sent: Tuesday, February 24, 2015 02:03 > To: Peer, Ilan; Jouni Malinen > Cc: linux-wireless@vger.kernel.org; ArikX Nemtsov > Subject: Re: [PATCH v6 1/2] cfg80211: Add API to change the indoor > regulatory setting > > On Sat, Feb 21, 2015 at 10:57:10PM -0500, Ilan Peer wrote: > > Previously, the indoor setting configuration assumed that as long as a > > station interface is connected, the indoor environment setting does > > not change. However, this assumption is problematic > > as: > > > > - It is possible that a station interface is connected to a mobile > > AP, e.g., softAP or a P2P GO, where it is possible that both the > > station and the mobile AP move out of the indoor environment making > > the indoor setting invalid. In such a case, user space has no way to > > invalidate the setting. > > At the protocol level should we consider the need for a dynamic environment > change? Until then a change of environment likely should implicate an AP > disconnect, which is what Linux does. With your changes in place we could do > something even more graceful should the protocol allow for it. >
Not sure I follow ... > For instance if the regulatory parameters for a country are the same for > indoor and outdoro a change in environment should not require a disconnect. > So you are suggesting to extend the mechanism to also indicate if a teardown of active interfaces is needed or not? And if so, not sure that this should be done by the kernel. > If the change was from a more restrictive environment to a more liberal set of > regulatory settings it could mean increasing TX power of the AP changing to a > channel which perhaps was not allowed before. > I think that such a flow needs to be handled in user-space by hostapd, which can leverage the proper mechanisms to do the change, e.g., eCSA. > If the change was from a less restrictive environment to a more restrictive > environment the AP might want to change channels for instance or reduce TX > power. > Same as above. For example, hostapd handles DFS related channel changes in user space. We also added flows to handle channel switch etc. in wpa_supplicant ... and I need to resubmit them to hostap. > While change in indoor/outdoor might be something silly to consider given > the likelihood of it being a common thing to happen that you change an AP > from indoor / outdoor regularly I'd consider instead the possibility to reuse > such a dynamic environment change notification for purposes of dynamic > environmental adjustments of BSSes. Typically BSSes settings are static but RF > environments change regularly so its silly to expect a BSS and its initial > Automatic Channel Selection algorithm to be corrrect during the lifetime of a > BSS. > > > - A station interface disconnection does not necessarily imply that > > the device is no longer operating in an indoor environment, e.g., > > it is possible that the station interface is roaming but is still > > stays indoor. > > Sure. > > You also fail to explain how we currently provide the indoor thing to the > kernel, I think its worth providing that in the commit log and also explaining > how we don't use the country IE environment thing at all. > I explained some of the use cases in previous patches, e.g., AC power, device type etc. I can add this, but I do not understand how country IE is related here. > > To handle the above, extend the indoor configuration API to allow user > > space to indicate a change of indoor settings, and allow it to > > indicate weather it controls the indoor setting, such that: > > > > 1. If the user space process explicitly indicates that it is going > > to control the indoor setting, do not clear the indoor setting > > internally, unless the socket is released. The user space process > > should use the NL80211_ATTR_SOCKET_OWNER attribute in the command > > to state that it is going to control the indoor setting. > > 2. Reset the indoor setting when restoring the regulatory settings in > > case it is not owned by a user space process. > > > > While at it directly update the indoor setting without wrapping it as > > a regulatory request, to simplify the processing. > > Please wrap that specific change into its own separate commit, it will make it > easier to review the changes and also make this change atomic. > Ok. Thanks, Ilan. -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
