OpenBSD Activism Shows Drivers Can Be Freed 213
grey continues "This means that currently, these wireless NIC's don't work out of the box on OSS install or boot media. In just the first 4 days, hundreds of users wrote and called vendors, and already 2 vendors freed their firmware, and several others are in discussions with Theo de Raadt about taking similar steps.
We need your help! TI has still not responded at all. You can call or write to Bill Carney, - Director of Business Development of TI's WNBU to add to the approximately 400 well written messages the OpenBSD community has already sent to TI. We hope that you'll help, and if you do please keep messages polite and to the point. Please remember, we are not asking for the vendors to open source their firmware under the GPL or BSD licenses (though we wouldn't complain if they did). Instead, ask if they would simply email Theo to open discussions on licensing their firmware binaries under terms that allow for free redistribution. If changed, these firmware binaries would then be able to be included with OSS software and function with existing BSD and GPL licensed device drivers from the start.
You can find other contacts for target vendors here, here, here, and here, and it can't hurt to sign this petition. These changes aide all OSS efforts, not just OpenBSD. As you can see from the OpenBSD community's results already, contacting these vendors really does make a difference. We're sure that with the numbers of OSS minded readers in the Slashdot community you can really help with the heavy lifting where fewer numbers of BSD users have already begun to succeed, and all Open Source Software users will benefit."
Re:Salient point: (Score:3, Informative)
Re:Why NOT? (Score:3, Informative)
firmware are not the crown jewels (Score:5, Informative)
If you've dealt with traditional firmware it's called "firm" because it's usually written to a flash memory of some sort on the device (be it CD Burner, NIC, etc.) in this case these vendors are cheaping out on an inexpensive piece of flash memory, and instead designing the 'firmware' to be loaded by the driver, thus unless the driver loads it each time the computer is turned on, then it disappears, it is not static. As such, it makes the hardware utterly useless unless you not only have a device driver, but also this firmware binary loaded. If they had spend a few cents extra and invested in a flash chip that moved with the hardware, this wouldn't be an issue. Instead, they've turned a hardware design issue into a software problem, and if they don't allow for that firmware blob to be redistributed with software drivers (be they proprietary or otherwise) from other vendors - the hardware is useless.
Rather than making a strawman argument about this issue which you didn't take the time to fully understand despite the large amount of text and background links in the story, it would really help everyone if people would write the vendors in question and ask for them to make a minor change. No one is asking them to open their designs a la opencores.org, merely license their firmware blobs in such a way that the firmware can be shipped with other Operating systems that -already- have OSS drivers.
(Going to write and call now instead of waste more breath on slashdot responses)
is it just me.... (Score:3, Informative)
It's like they haven't been listening to the trolls [wikipedia.org] at [hiro-tan.org] all [daemonnews.org]
--
I write stuff [livejournal.com], but not that well and not that often...
Re:Why NOT? (Score:4, Informative)
Re:Why NOT? (Score:4, Informative)
These other drivers are hidden because companies have just always done it that way. Why should they change things? It's always worked before. They don't realize that the community will help them greatly if they open things up a bit. It's old-world versus new-world, and it's just taking some time to get old-world to come around.
Re:Theo (Score:3, Informative)
Re:Why NOT? (Score:5, Informative)
A: In the case of wireless, the FCC plays a part.
An 802.11 Wireless Card is a software controlled radio, and must be licensed per FCC regs (in the USA, your country's rules might be different). Since the 802.11 PHY operates over several channels within the specified band, it must be able to select and switch between these channels via software, and to adjust its transmit power for optimum performance based on the changes in temperature of the transmitter, and changes in the frequency, among other things.
But different regulatory domains (countries) allow different channels within the bands, meaning a card in the US may be able to operate on a channel in the B band which is not licensed for another country, or vice versa. This is particularly true in the A band, where a whole middle "chunk" is not legal for use in the US.
Bottom line is that in order for the producer to get a license for the radio (and trust me, you do NOT want it to be the case that you, the operator, have to secure that license), he is NOT ALLOWED to expose the controls for power, et al, to the end user.
Now, if the driver / firmware (distinction / similarity discussed elsewhere in the thread) is open source, then by definition the controls in question are exposed to the end user. There would be nothing to prevent an end user from operating his card at a higher than legal power, or outside the legal freqs for the local regulatory domain.
NOW, all that being said, that is not to say that SOME hardware manufacturers haven't tried to do the right thing, and strike a compromise.
The MAD-WiFi Project http://sourceforge.net/projects/madwifi [sourceforge.net], (FAQ here [clara.co.uk]) produces an open driver for the cards with Atheros chipsets. The bulk of the code is open, and under a good license. To meet the FCC requirements, they implement the "required to be secret" controls in a binary-only Hardware Abstraction Layer (HAL), but the rest of the code is open, free for you to read and modify.
And it works. I'm typing this through a Netgear card, running the MAD-WiFi driver (with TKIP encryption, IEEE 802.11i 4-way handshake and authentication handled by wpa_supplicant) on Gentoo Linux.
Credit is due to Sam Lefler and most importantly to Greg Chesson (of Atheros). Yes, it's that [google.com] Greg Chesson, the same one mentioned of late by Rob Pike in his recent ./ interview.
Note that, AFAICT, all of this happened without Theo de Raadt pimping around or making an ass of himself, as he is want to do. Disclaimer: I lost patience with Theo and TheoBSD a long time ago.
Re:Why NOT? (Score:5, Informative)
Bittorrent is no different than, say, HTTP when it comes to this sort of thing.
If you're bittorrenting down a ISO from, say, the Knoppix official tracker - You know it's fine - same as if you downloaded it by HTTP from the same site.
Now if you're randomly downloading stuff from Hack-My-Computer.com, that's a different issue.
Firmware is not drivers (Score:5, Informative)
In any case, these aren't programs for your computer, and it is merely a matter of convenience that they aren't sealed into the device at the factory (so you can update them without sending the device back). It doesn't make any more sense to want the source for the firmware for your NIC than it would be to ask for the source to the firmware for your microwave.
Previously, the firmware was only available from the manufacturers directly, and licensed such that you weren't supposed to redistribute it. OpenBSD people complained that making people go online to update their NIC so that it works is a bit annoying, and that they'd like to be able to get it from OpenBSD, whose CD they would be getting and who would be happy to download the firmware for them.
Re:Don't help distribute problems. (Score:2, Informative)
What Theo and the community want is the right to distribute the firmware with the driver so it works right out of the install. There isn't anything wrong with this.
Re:Why NOT? (Score:2, Informative)
Re:Why NOT? (Score:2, Informative)
Re:Theo's rewriting history on this one. (Score:1, Informative)
Re:FCC red herring (Score:4, Informative)
I am not making this crap up, nor am I quoting from some trade rag, journal or online posting. I've spent the last several years as an active, voting participant in IEEE 802.11, sitting in the room with the engineers who design these chipsets and radios. If only one of them, from one company, had explained things this way, it would be one thing. But the reality is that this is the story from all of the mainstream chipset / radio vendors, and it's validated by the other folks in the room who specialize in regulatory issues.
Re:Why NOT? (Score:3, Informative)
OpenBSD (and others) simply want to be able to freely distribute the firmware with OpenBSD (or other OSS) freely.
The request is *not* to open up the firmware like your message suggests. Again, since you missed it the first time, the request is *not* to open up the firmware like your message suggests.
Maybe the average slashdot reader does not have a long enough attention span to follow such logic through, but this is honestly important not to just OpenBSD, but all OSS in general.
--codguy
Re:Why NOT? (Score:1, Informative)
It does work. Mostly. Except that it seems to crash about 1/3 of the time on resume from APM sleep....Funny that that problem never occurs with the entirely open source 802.11b card drivers I have used in the past.
Re:SDR FUD (Score:2, Informative)
It is not true that WiFi card makers are not allowed, under U.S. regulations, to expose the transmit power control, tuning, etc., to the user. People who say so, even people at Atheros who say so, are mistaken or lying. (As one FCC lawyer told me in the mealy-mouthed language of Washington, D.C., "it sounds to me like they are being less than forthright.")
And yes, I am quite aware of the FCC's SDR rules. Why, I have even read them, which is more than virtually anybody else who is commenting has done! A maker certifies their product under the SDR rules *at their own option*, and then (and only then) do they accept certain strictures (they have to take measures to protect against tampering) in exchange for a streamlined re-certification process. AFAICT from the FCC certifications database, NO WIFI RADIO, least of all any Atheros-based radio, has been certified under the SDR rules. The rules simply *do not apply* in WiFi space.
(Now, it is likely that the rules in Europe are stricter than in the United States. Still, Atheros will send you a copy of the U.S. SDR rules if you ask about the regulatory issue.)
Incidentally, every single WiFi radio in existence is software-defined under the FCC's broad definition. Some of them nevertheless have open-source drivers that let you adjust the tuning and power control by getting directly at the hardware. See, for instance, the open-source ADMtek drivers for BSD and for Linux. I wrote the former driver, and I didn't have to break U.S. law to do it. And the manufacturer supports new development on the driver.
Finally, I will just add that the FCC has traditionally not required even a modicum of tamper-proofing on Part 15 devices. Their long-standing position has been that a device need only protect consumers from *inadvertently* or *casually* tuning a channel they're not entitled to use, or setting an illegal power level, in order to qualify for certification. Furthermore, the FCC seems to be aware that determined radio hackers with malicious mis-use in mind will not be stopped. Hacking a wireless driver for illegal channels or transmit powers is not the "casual" or "inadvertent" consumer activity that the device certification process is designed to prevent.
I think the real reason Atheros and other WiFi chipmakers are not opening things up is that they want to protect their intellectual property. Someone at Atheros has told me that is a key reason. I doubt that there are major innovations in the software interface (register set, descriptor ring format, blah blah) that give deserve protection because they give them a competitive advantage, but this wouldn't be the first time that a chipmaker saw it that way.
You might ask, why does it matter whether the software interface concealed by the HAL is opened up? First, so that radio experimenters and open source developers can innovate with WiFi at their own pace and according to their own agenda. Second, because the HAL documentation is virtually non-existent, and nobody is going to write it. Third, (Theo will appreciate this) so we can audit the code (which runs w/ all the privileges on your Linux/BSD system!) for bugs. Fourth, so that we can fix the bugs---and there *are* bugs.