Broadcom firmware 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:
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:
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:
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.
| Index entries for this article | |
|---|---|
| Kernel | Device drivers/Wireless networking |
| Kernel | Networking/Wireless |
Posted Sep 24, 2010 10:52 UTC (Fri)
by job (guest, #670)
[Link] (6 responses)
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.
Posted Sep 24, 2010 14:03 UTC (Fri)
by dtlin (subscriber, #36537)
[Link] (5 responses)
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.
Posted Sep 26, 2010 0:48 UTC (Sun)
by gutschke (subscriber, #27910)
[Link] (4 responses)
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.
Posted Sep 26, 2010 7:19 UTC (Sun)
by johill (subscriber, #25196)
[Link] (3 responses)
Posted Sep 27, 2010 5:55 UTC (Mon)
by jzbiciak (guest, #5246)
[Link] (2 responses)
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.
Posted Sep 27, 2010 5:57 UTC (Mon)
by dlang (guest, #313)
[Link] (1 responses)
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.
Posted Sep 27, 2010 6:29 UTC (Mon)
by jzbiciak (guest, #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): (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. ;-)
Posted Sep 24, 2010 21:08 UTC (Fri)
by mb (subscriber, #50428)
[Link] (2 responses)
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.
Posted Sep 26, 2010 9:25 UTC (Sun)
by dwmw2 (subscriber, #2063)
[Link] (1 responses)
Posted Nov 1, 2010 13:27 UTC (Mon)
by dublindec (guest, #70939)
[Link]
Posted Dec 16, 2010 13:37 UTC (Thu)
by lacos (guest, #70616)
[Link]
How does this work?
How does this work?
How does this work?
How does this work?
How does this work?
How does this work?
How does this work?
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.
Broadcom firmware and regulatory compliance
Broadcom firmware and regulatory compliance
"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
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