On Wed, Jul 17, 2013 at 11:47 AM, Peer, Ilan <ilan.peer at intel.com> wrote: > On some day Luis wrote: > >> Based on the documentation I reviewed and your proposal it'd seem to me that >> we can distinguish GO on the upper layers and determine if a channel is DFS or >> not by just the DFS flag. The next hint you'd need is if the GO got regulatory >> information from a master somehow, no? > > This should also be handled by user space, based on the device type/sub type of the local device directly, or > indirectly through other means such a managed interface associating with an AP that it's device type > value is 6 etc. This seems reasonable but we need to also consider state machine changes possible on the channel the GO is on as well and there are different reasons for the channel to change: * beacon hint - nl80211_send_beacon_hint_event() * regulatory change - nl80211_send_reg_change_event() The beacon hint multicast group message sends the channel prior to the beacon hint and after. The regulatory change event currently isn't as atomic and only provides the the fact that regulatory domain state machine has incurred a change. In this case it may make sense to send all wiphy information and have hostapd verify if a change has occurred on the channel. >> That is I am not seeing a need for a new flag at this point in wireless-regdb, >> given also I mentioned another type of case for regulatory hints technically >> possible (cellular base station hints but it seems only allowed with exceptional >> review by the FCC). >> >> I take it what you want to enable here is GO operation on DFS channels and use >> country IEs to determine if you can use GO, but if you do have GO enabled then >> you'd want hooks to not daisy chain, ack? > > Currently, we do not intend to base the relaxation on the country IE directly, Its still a possibility so it should be handled and we should consider it on core regulatory. One possible solution might be to not enable GO unless the the NL80211_ATTR_REG_INITIATOR was something appropriate for the wiphy. > but base it on the fact that if > there is a managed connection to an AP who's not a mobile device (assuming that it is an authorized master), How do you intend on verifying a device that has associated to an AP, that that AP is not a mobile device, ie that it fits this "authorized master" category ? > than the channel used by the managed connection is valid for use (as long as the managed interface > is connected to the AP on the channel). Makes sense. Luis
