Broadcom firmware and regulatory compliance [LWN.net]

By Jonathan Corbet
September 22, 2010

Broadcom's recently-announced open source wireless networking driver was a major step forward for a company which has, until now, not been forthcoming when it comes to free support for its wireless products. That driver includes the obligatory firmware blob which has been licensed for free distribution by the company; it is now found in the kernel firmware repository. Broadcom has not freed the firmware for its older drivers, though, leading to discussions on the intersection between kernel development and regulatory compliance.

The lack of freely-distributable firmware for older Broadcom products makes life a bit more difficult for users, who must obtain the firmware separately. When the new firmware was made distributable, David Woodhouse asked the company about the older firmware as well, only to told that it would not be made distributable. As he explained it, Broadcom is afraid that allowing the distribution of that firmware could lead to trouble:

They seem to think that they could be prosecuted even for *enabling* people to use the open source b43 driver, because you have the possibility of hacking that driver not to conform to the regulatory requirements.

The reason why the old firmware is different is simple: the newer firmware, which can only run on newer hardware, has regulatory compliance built into it. The older firmware, instead, depends on the driver in the kernel to ensure that it is not configured to operate in a non-compliant manner.

David is not known for graceful suffering in the presence of (people he sees as) fools. His response was a patch which "credits" Broadcom for enabling the development of the reverse-engineered b43 driver; this "enablement" is said to have come through the provision of binary-only drivers which could be reverse engineered. His goal in writing this patch was described as:

Everything we do in the b43 and b43legacy drivers is enabled by Broadcom's original binary-only drivers. So let's make that 'enablement' by Broadcom's binary drivers clear in our source code -- in the hope that it'll narrow the 'risk gap' that they falsely perceive between open and closed source drivers.

Or failing that, in the hope that it'll give their crack-addled lawyers aneurysms, and they'll hire some saner ones to replace them.

He also expressed a wish that the b43 developers would release more information - obtained from the binary-only drivers - on how to patch those binary drivers to get around various regulatory restrictions. Once again, he feels that this kind of information would help to make it clear that free drivers do not make it any easier to operate the hardware in an illegal manner.

David's position plays well with developers who have no patience for obstacles created by lawyers. There is also a vocal contingent out there which says that Linux has no business telling users how they should use their hardware in any case; if the user wants to configure the hardware in a non-compliant manner, that's the user's problem. In some cases, that user may well have a license which makes it entirely legal to run the hardware outside of the parameters which normally apply to off-the-shelf wireless networking equipment. So regulatory compliance naturally irritates developers who think that the kernel has no business getting in anybody's way in this regard.

Luis Rodriguez, on the other hand, is a strong supporter of regulatory compliance in the Linux kernel; he stepped into the discussion to remind people of the kernel's regulatory statement and to say that there was no real interest in encouraging the violation of spectrum-use regulations with any driver. He added:

The reason why current legislation doesn't seem to make sense is because it does not, but just because a law doesn't make sense it does not enable vendors to ignore it. So the best you can do in the meantime is really be proactive by working on real technical solutions.

We are not dealing with legal issues on Linux, we are dealing with engineering solutions, and trust me, we're light years ahead of other OSes because of this now.

His point is that the kernel's "engineering solution" to the regulatory problem has made it possible for wireless vendors to dip their toes into the open-source water. That, in turn, has helped to move Linux from having poor wireless support to, arguably, having the best support over the course of a few years. It is hard to argue with the success which the wireless developers have had recently; any moves which might endanger that success should be considered carefully, to say the least.

Of course, it would be nicer to do without the proprietary firmware blob altogether. In early 2009, the openfwwf project announced the availability of an open source firmware implementation for Broadcom adapters. Since then, news from that project has been relatively scarce. On September 21, though, Michael Büsch announced the availability of a toolchain for working with the b43 firmware. Using the disassembler and assembler, it is possible to decode the device firmware, make changes, then build a new firmware load. Naturally, one can also build a new firmware implementation from the beginning. With these tools available, we might just get to a point where we can have device firmware without distribution restrictions, and which adds features and flexibility to the device as well.

(Log in to post comments)

How does this work?

Posted Sep 24, 2010 14:03 UTC (Fri) by dtlin (✭ supporter ✭, #36537) [Link]

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?

Posted Sep 26, 2010 0:48 UTC (Sun) by gutschke (subscriber, #27910) [Link]

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.

How does this work?

Posted Sep 26, 2010 7:19 UTC (Sun) by johill (subscriber, #25196) [Link]

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?

Posted Sep 27, 2010 5:55 UTC (Mon) by jzbiciak (✭ supporter ✭, #5246) [Link]

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.

How does this work?

Posted Sep 27, 2010 5:57 UTC (Mon) by dlang (✭ supporter ✭, #313) [Link]

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?

Posted Sep 27, 2010 6:29 UTC (Mon) by jzbiciak (✭ supporter ✭, #5246) [Link]

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. ;-)

Broadcom firmware and regulatory compliance

Posted Sep 26, 2010 9:25 UTC (Sun) by dwmw2 (subscriber, #2063) [Link]

"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.

Broadcom firmware and regulatory compliance

Posted Nov 1, 2010 13:27 UTC (Mon) by dublindec (guest, #70939) [Link]

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.