On Wed, Feb 25, 2015 at 02:30:40PM +0000, Peer, Ilan wrote: > Hi Luis, > > > -----Original Message----- > > From: Luis R. Rodriguez [mailto:mcgrof@xxxxxxxx] > > Sent: Tuesday, February 24, 2015 02:03 > > To: Peer, Ilan; Jouni Malinen > > Cc: linux-wireless@xxxxxxxxxxxxxxx; 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 ... OK right now we should disconnect if there are some regulatory params that do not agree. This event will also ony happen *rarely*. Even though this happens rarely I can find use for forcing this to happen in a not so rare case to help optimize RF spectrum use dynamically, if the protocol had a way to communicate a desired change in environment this could be reused for a dynaic RF spectrum change in environment. > > 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 AP *knew* a change in environment (now forget indoor/outdoor as that is rare today) was not disruptive this could be information that the STAs can get to use to evaluate and make a better decision as to whether or not it did need to tear down or not. > > 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. Right but that's the AP, how would the STAs get that information? This is why I mentioned the idea of a possible protocol enhancement to let the AP inform STAs of an environmental change. The AP *could* feed more than just the boring parameters we're used to. Its OK this is just an idea, ignore it. > > 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. OK.. > > 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. Mention it and the country IE is important given its the other place folks expect it to be deduced from -- and we don't use it at all. Without that information folks can assume we do unless they are familiar with the code. It provides useful context for your change, even for me! Luis -- 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
