Comment 5 for bug 1126751

A few points.

First, even if the error returned from crda isn't important the fact that the netlink message gets back a error of EINVAL probably is. Presumably this netlink message is providing the regulatory information requested by the kernel, and thus would be handled by nl80211_set_reg(). Unfortunately there are a lot of reasons this might return EINVAL.

Second, when drivers supply a custom domain this overrides the default user domain for any devices using that driver. bcmdhd _does_ supply a custom domain, so what you see from 'iw reg get' is irrelevant. The custom domain in bcmdhd does encompass all the legal frequencies in the US and EU for both 2.4 and 5 GHz. On my nexus 7 at least the hw doesn't appear to support 5 GHz however. Also, Tony discovered that running 'iw list' gives a better, per-device list of channels available to the devices and their associated flags (also, 'iw phyX info' gives the same information for the specified device).

Third, user hints (the kind given for 'iw wlanX reg set') may be rejected by the kernel for a number of reasons. However, if they are getting as far as calling crda and crda is getting an error when it tries to supply the requested regulatory information, that would also result in the user hint not being applied.

Finally, I'd question whether we really want to set /etc/default/crda. Most of the wireless drivers in the kernel that work well at all are using custom domains that should make them behave appropriately throughout the world. If the value of /etc/default/crda is set incorrectly at boot, or when the machine is used in a country other than that where the original install happened, this could result in transmitting on restricted or disallowed channels.

Oh, one more thing.

> To test, I ssh'd into the phone, installed crda and wireless-reg, became root,
> then exported COUNTRY=US, the two NL env vars referenced in the
> previous comment, then ran /sbin/crda.

This won't work. The kernel is going to reject any information from crda that it didn't request. Which explains the EINVAL in this case at least. Are you getting EINVAL from the kernel in other cases?