[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-wireless
Subject:    Re: [PATCHv7 0/3] Add DFS master ability
From:       Simon Wunderlich <simon.wunderlich () s2003 ! tu-chemnitz ! de>
Date:       2013-01-31 17:21:54
Message-ID: 20130131172154.GA2018 () pandem0nium
[Download RAW message or body]

On Thu, Jan 31, 2013 at 05:50:44PM +0100, Johannes Berg wrote:
> On Tue, 2013-01-29 at 13:21 +0100, Simon Wunderlich wrote:
> 
> > Right now, channels at least on my machine have the NO IBSS and PASSIVE SCAN
> > flags set, which prevents reg_can_beacon from returning true, even if we do
> > have radar support. This is due to my reg database setting these flags for
> > country code 00, and this is still kept when changing the country code to
> > something else (DE in my case). How should we proceed with this? Shouldn't
> > these flags be removed when selecting a country code?
> 
> I don't think any country sets that, you may be running into that whole
> "regdb intersect" thing ... FWIW the flags are set for 00 since for
> world roaming we don't know if we're in a country that even allows
> transmission on that AP.
> 

Yes, that is certainly the regdb intersect thing - my atheros card is branded to "00", which
is the world country code - I would expect to do anything now, not nothing. :D

I mean, I need to set some country code anyway (at least this will be a requirement
in hostapd), so is this intersection thing really useful for the AP case?

reg_beacon() checks all these flags (NO_IBSS, PASSIVE_SCAN), but it actually should
just care about the radar flag I assume?
BTW, I have not a single country in my regdb list which sets either passive scan or
NO_IBSS (according to regdbdump on my laptop). All non-00 countries only set DFS or
NO_OUTDOOR (and NO-OFDM in japan for channel 14).

> > The channel states are now implemented in cfg80211. Shall we inform userspace
> > about channel changes? If yes, how should we do that? We could add channel states
> > to the channel list, and give "channel list changed" events to userspace as it
> > happens now, or define a new kind of event ("channel-available-again-event").
> > Suggestions welcome. :)
> 
> You already inform it of the changes by the radar event, but it would
> probably also be good to export the state as part of the channel list
> that you get with things like "iw list".

Well I do that when I finish/abort CAC or detect a radar. But I (currently)
don't send an event when changing from unvailable to usable (after non-occupancy
period). I see the options:

 1) add channel-usable-again event to cfg80211_radar_event 
 2) send a "channel list changed" (seems this also sent when the regdb is changed).

Any preferences? Maybe option 1 for completeness?

I wanted to export the state on the channel list anyway. Zefir asked to have the
timestamp there as well (though I don't know what the specific usecase is ...).
Will include that in the next revision.

Cheers,
	Simon

["signature.asc" (application/pgp-signature)]
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[prev in list] [next in list] [prev in thread] [next in thread]