Re: Problems with regulatory domain support and BCM43224

[Seth Forshee <seth.forshee@canonical.com>]

Adding some Cc's.

On Wed, Mar 07, 2012 at 01:40:01PM -0600, Seth Forshee wrote:
> I set up an AP recently in the 5 GHz band and noticed that a MacBook Air
> with BCM43224 wireless can't see it. iw shows that the 5260-5700 MHz
> frequency range is disabled. I compared this to an Intel Centrino 6205
> card which shows passive scanning is allowed in this range. Both show
> that they're using the world regulatory domain, and I can get the
> BCM43224 to see my AP when I force the domain to US.
> 
> I've been going through the regulatory code trying to understand what's
> happening, and while I haven't fully grokked it yet it seems to me the
> difference is that iwlwifi is setting WIPHY_FLAG_CUSTOM_REGULATORY and
> brcmsmac is not. iwlwifi isn't supplying a regulatory hint, and mac80211
> doesn't end up applying any regulatory settings due to the flag.
> brcmsmac supplies a hint using the country code it reads from its srom,
> "X0" (which Google tells me is an interim code that Apple uses while the
> actual country code is unknown). Since this code is bogus the world
> domain gets applied.
> 
> mac80211 doesn't appear to update the regulatory domain from the beacons
> unless connected to an AP that happens to be providing the country IE,
> so we're left in the unfortunate situation of being unable to scan
> certain frequencies unless the user connects to such an AP or sets the
> domain manually.

As I understand it, the DFS channels aren't included in the world domain
because Linux does not yet fully support DFS. But I can then specify a
domain that's known to require DFS on these channels, and they are
enabled. This seems illogical. If passive scanning is okay when we know
DFS is required, why can't it be enabled in the world domain when we
simply don't know if it's required?

Thanks,
Seth