LWN: Comments on "Broadcom firmware and regulatory compliance"

Broadcom firmware and regulatory compliance

lacos — Thu, 16 Dec 2010 13:37:00 +0000

developers who have no patience for obstacles created by lawyers

You could argue that the GPL is one such obstacle, so the above generic expression is double-edged. Law, just like wireless parameters, is not "bad" in itself; it depends on what it is used for.

Broadcom firmware and regulatory compliance

dublindec — Mon, 01 Nov 2010 13:27:48 +0000

The Broadcom card in my MacBook Pro regularly has its country code set (by other people's routers) to the wrong country code. I have no way of returning it to the correct code. How does that help with compliance? It just excludes me from networks in the UK which use channels 12 and 13. Madness.

How does this work?

jzbiciak — Mon, 27 Sep 2010 06:29:33 +0000

Fair enough and a good point I hadn't considered.

On further reflection, it seems like a computer operating in something resembling a infrastructure mode client would have little reason to transmit until it saw something that gave it an idea of what frequencies and powers were appropriate.

And, since I'm actually allergic to too much idle speculation[*] without a good dose of raw facts, I actually had a go at looking up the relevant standard. Indeed, the actual default is "passive scanning" (highlighted below):

9.9.1 Operation upon entering a regulatory domain

A STA that is enabled for operation across regulatory domains shall default to passive scanning when it has lost connectivity with its ESS. Passive scanning is performed using only the receive capabilities of the station and is, thus, compatible with regulatory requirements. The timeout for determining the loss of connectivity is system dependent and beyond the scope of this standard.

When a STA enters a regulatory domain, it shall passively scan to learn at least one valid channel, i.e., a channel upon which it detects IEEE Std 802.11 frames. The Beacon frame contains information on the country code, the maximum allowable transmit power, and the channels to be used for the regulatory domain. Optionally, the Beacon frame may also include, on a periodic basis, the regulatory information that would be returned in a Probe Response frame. Once the STA has acquired the information so that it is able to meet the transmit requirements of the regulatory domain, it shall transmit a Probe Request to an AP to gain the additional regulatory domain information contained in the Probe Response frame, unless the information was previously received in a Beacon fame. The STA then has sufficient information available to configure its PHY for operation in the regulatory domain.

(Quoted from here.)

So, I guess that's the ultimate way to not break any transmit laws... transmit nothing until you hear a valid local transmission.

[*] That's not to say I haven't been guilty of such in the past, nor does it say I won't be guilty of it in the future. ;-)

How does this work?

dlang — Mon, 27 Sep 2010 05:57:46 +0000

the biggest problem isn't the power level (as you point out it's easy to do something that's safe everywhere)

the problem is what frequencies are you allowed to transmit on. guess wrong and you will never talk on the same frequency as the access point, or you could start interfering with other things and get into more trouble.

How does this work?

jzbiciak — Mon, 27 Sep 2010 05:55:05 +0000

Right, but if there are no other WiFi devices around, presumably the card would fall back into a much more passive mode that's likely to be in the intersection of all domain's requirements. ie. I doubt it'd come out with guns-a-blazin', pumping out 10W until it got a friendly tap on the shoulder that told it "Hey, you're only allowed 100mW peak around these parts."

Rather, if the supported regulatory domains had maximum transmit powers of, say, 120mW, 100mW and 80mW, in the absence of any guidance to the contrary, I'd imagine it'd stick to under-80mW until it got a whiff of what regulatory environment it was in.

After all, when you drive on a new local road you've never driven, do you floor it and go 65MPH until you see a speed limit sign telling you it's 30MPH? (100km/h and 50km/h if you prefer.) Somehow I doubt it. You probably look at the other cars and see what range of speeds they're going, and if there's no other traffic, you probably make an educated guess what an appropriate speed would be.

Broadcom firmware and regulatory compliance

dwmw2 — Sun, 26 Sep 2010 09:25:18 +0000

"So we're currently at a point where Broadcom's latest freely distributable wireless firmware is easily modifiable by anyone. I think that harms Broadcom's argument for not releasing older firmware due to regulatory issues."

Indeed. Broadcom's position on the whole regulatory thing seems to be entirely based on inconsistent paranoid fantasies, and we should be using all means at our disposal to demonstrate the idiocy of their position.

How does this work?

johill — Sun, 26 Sep 2010 07:19:23 +0000

Err, no, regulatory restrictions aren't in place to stop wifi devices from interfering with each other (after all, they use carrier sensing and all play nice with each other) -- they are in place to avoid interfering with, to take a recent example, weather radars.

How does this work?

gutschke — Sun, 26 Sep 2010 00:48:31 +0000

I would assume that most modern drivers support 802.11d. I believe it was standardized in 2007. It is supposed to automatically pick the correct regulatory domain based on information broadcast by all the other WiFi users in your vicinity.

In typical urban settings, you can probably see around 50 WiFi devices at any given time. So, this should work pretty reliably. And if you find yourself sufficiently removed from any other WiFi devices, then presumably it wouldn't matter all that much if you pick the wrong regulatory domain as there won't be anybody around that you could interfere with.

Broadcom firmware and regulatory compliance

mb — Fri, 24 Sep 2010 21:08:54 +0000

> On September 21, though, Michael Büsch announced the availability of a toolchain for working with the b43 firmware.

Well, we already released a toolchain that works with b43 firmware several years ago. That is what openfwwf was based on.

The new announcement was a new version of that toolchain which also works on the recently released firmware for the new brcm80211 driver. (brcm80211 devices have some differences in the instruction set and format).

So we're currently at a point where Broadcom's latest freely distributable wireless firmware is easily modifiable by anyone. I think that harms Broadcom's argument for not releasing older firmware due to regulatory issues. Technically the new firmware is not really safer than the old one.

How does this work?

dtlin — Fri, 24 Sep 2010 14:03:26 +0000

Regulatory - Linux Wireless

In the past, this was set by option ieee80211_regdom to the cfg80211 module. More recently, this is now configured through the new nl80211 interface, e.g. iw reg.

I live in the US and most everything defaults to US regulations, so I haven't dug into how distributions handle this.

How does this work?

job — Fri, 24 Sep 2010 10:52:28 +0000

How do these drivers handle the different regulatory requirements in different jurisdictions? I can not recall entering my location when installing a recent distribution with wifi support, and if this system respects these requirements it must surely know what they _are_?

AFAIK simple things such as what frequency bands are used differ between EU, the US, and Japan for example. If the user is limited to the lowest common denominator, he/she may not even be able to connect to the local wifi which may be on a band not allowed somewhere else.