The ipw3945 project
The ipw3945 project currently has a developer release of the driver, with a stable version expected within a few weeks. This release supports all of the basic features one would expect, with some additional features (quality of service, for example) "not officially supported." It should, in other words, be enough to allow use of the device.
It would seem that there is little to complain about here. But there is this little paragraph from the announcement:
The requirement for a binary-only blob brought out some concerns from developers who think that the regulatory-agency requirement has been overblown, and that it is not actually necessary to lock down the code in this way. Others disagree, noting that regulations in many parts of the world are quite strict with regard to allowing any user modification of hardware which can transmit. It is probably true that, in order to be able to offer this product in many parts of the world, Intel must lock down much of this logic in binary-only code.
Given that, however, Intel has chosen an interesting way to go about it. The closed code is not part of the driver itself; it is a daemon which runs entirely in user space. The driver itself is fully free software. So there is no non-free code going into the kernel, which is surely a step in the right direction.
The regulatory daemon controls the hardware by way of a special file exported through sysfs. The driver then interprets those commands - which enable or disable specific channels, set maximum power values, and so on - and programs the hardware accordingly. A quick look at the (15,000-line) driver source is sufficient to find the code which actually controls the transmitter's parameters.
So, in other words, this arrangement has not actually locked down much of anything. The daemon comes with the usual "thou shalt not reverse engineer" provisions, but there are people in parts of the world who can safely ignore that requirement. It would seem that little work beyond running the daemon under strace would be required. It might also be possible to write a replacement just by studying the driver code, without looking at the Intel-supplied daemon at all. One way or another, it seems likely that a free replacement for the regulatory daemon will come along, sooner or (not much) later.
Index entries for this article | |
---|---|
Kernel | Device drivers/Wireless networking |
Posted Mar 2, 2006 10:07 UTC (Thu)
by eskild (guest, #1556)
[Link] (7 responses)
The main issue is simply that we cannot see/feel radio waves. Thus, we cannot intuitively determine whether we're creating problems for others. It's much simpler if somebody is actually stumbling in the mess of cat-5 cables we've strewn all over the floor.
Here's to hoping.
Posted Mar 2, 2006 11:30 UTC (Thu)
by cate (subscriber, #1359)
[Link] (3 responses)
Anyway, the frequency and max power should be standardized. When I move abroad with my laptop, I never tell my laptop that I'm in an other nation. (I think I cannot do it).
Posted Mar 2, 2006 11:40 UTC (Thu)
by gypsumfantastic (guest, #31134)
[Link]
1) The microcode blob is not part of the kernel or its device infrastructure, and is not maintained by the kernel developers. It's simply using the kernel as a piggy-back loader mechanism to get the device started. To me, it's no more or less irrelevant than the absence of source code to my PC BIOS.
2) The daemon is easily reversed-engineered, barring legal restrictions. And the legal restrictions probably aren't Intel's fault, or if they are, it's the fault of the legal department covering their asses a bit too much. But covering asses is what legal departments do.
Posted Mar 2, 2006 13:41 UTC (Thu)
by nix (subscriber, #2304)
[Link]
Posted Mar 2, 2006 15:12 UTC (Thu)
by danm628 (guest, #5995)
[Link]
Newer devices support 802.11d which allows a 802.11 STA to receive regulatory settings from a 802.11 AP. So your notebook will automatically conform to the regulatory domain defined by the AP.
Posted Mar 2, 2006 11:33 UTC (Thu)
by gypsumfantastic (guest, #31134)
[Link] (2 responses)
Still, if there are regulatory and contractual reasons why Intel cannot release the source from this code, providing it notably as a user-space daemon with an implicit "please us strace to provide a GPL replacement" seems a neat little hack around these restrictions.
I assume that issue of microkernel blobs being distributed with (not LINKED with) the kernel is now a non-issue? Except maybe Debian, I dunno.
Intel are playing pretty nicely on the driver front of late, wireless and graphics, and are to be commended, up to a point. No, I'm not gonna get all Stallman on anybody's ass. Sometimes a sense of pragmatism should prevail, and when it comes to having a working wireless, I'm prepared to make that concession.
Posted Mar 2, 2006 14:55 UTC (Thu)
by kmccarty (subscriber, #12085)
[Link] (1 responses)
I assume that issue of microkernel blobs being distributed with (not LINKED with) the kernel is now a non-issue? Except maybe Debian, I dunno. Even in Debian, people appear to be perfectly happy to include these firmware binary blobs in non-free, as long as the license to distribute them makes sense. (For instance, a binary blob licensed under GPL is useless since the GPL specifically requires such binaries to be accompanied with "the complete corresponding machine-readable source code" when distributed. A BSD-type license would be OK though.) The only major remaining issue seems to be how to make these non-free packages available to the Debian Installer in cases where they are needed by required hardware.
Posted Mar 2, 2006 21:22 UTC (Thu)
by iabervon (subscriber, #722)
[Link]
Posted Mar 2, 2006 21:42 UTC (Thu)
by iabervon (subscriber, #722)
[Link] (1 responses)
Alternatively, it could be GPL, but have a "distribute but don't modify" file with the actual rules (and check its hash to make sure it hasn't been modified accidentally). That shouldn't be an issue, since all GPL packages include at least one file that people aren't allowed to change...
Posted Mar 4, 2006 1:24 UTC (Sat)
by giraffedata (guest, #1954)
[Link]
I assume Intel's goal is to prevent intentional setting of illegal parameters rather than just accidental. And that Intel is required to by law. I further assume that the user space daemon uses some kind of encrypted channel that makes it virtually impossible to command the device to change these settings if you don't have the daemon source code.
As a user of the wireless adapter, I'd rather have the power to make illegal settings, and other benefits of open source and open everything else.
But as a user of the airwaves, I don't want any other Intel customer to have that power. And I'm quite willing to trade all that openness to get it, because it's a lot easier for me to keep Intel honest than to keep thousands of Intel customers honest.
Posted Mar 3, 2006 20:49 UTC (Fri)
by GreyWizard (guest, #1026)
[Link]
Posted Mar 4, 2006 18:30 UTC (Sat)
by job (guest, #670)
[Link]
Posted Mar 4, 2006 19:01 UTC (Sat)
by Baylink (guest, #755)
[Link] (1 responses)
If we don't shut up about it, the *governments* will hear about it too, and tell Intel that's not good enough.
So shush. :-)
("with amazing push-button shushing action!")
Posted Mar 25, 2006 17:38 UTC (Sat)
by rwmj (subscriber, #5474)
[Link]
Rich.
Posted Mar 7, 2006 9:46 UTC (Tue)
by addw (guest, #1771)
[Link]
If different versions of the program are sold in different countries, it won't be long before someone puts the program from country X up on some ftp server.
OK: I am not suggesting that one regularily do this since the regulations are for good reason, but at time it could be useful -- eg when working in your large but isolated country farmhouse.
This would seem to be one of those cases where the software community can prove its, for lack of a better term, "ethical values" by *not* messing with key parameters. The radio frequency restrictions in different parts of the world usually exist for good reasons, such as not interfering with other devices, and it would be problematic if someone released software that violates local requirements/restrictions, just because they'd then be able to play some game or browse the internet from further away.The ipw3945 project
I want a open source driver. I want to see the code. I want to see what restriction apply in my country.The ipw3945 project
If the code contains a warning: "Check with your country rules, before to modify this parameters", it is fine for me, but why hide all the thing?
As far as I can tell, the "driver" is open source. Admittedly there is a microcode blob (not part of the kernel at all, thus not linked), and an easily-straced daemon which is non-free, but this doesn't seem especially onerous at all because;The ipw3945 project
The ipw3945 project
I want to see what restriction apply in my country.
For that, you surely want to look at the appropriate regulations/laws, not at (possibly buggy) code, whether free or not.
There are several reasons your notebook's WiFi link works in multiple countries. The simplest reason is that most countries use the same 2.4GHz IFM band, so the odds are that your device overlaps the allowed spectrum in the country you are visiting. This is why most older devices work when in different countries. Of course there is no check that the device complies to local regulations. All countries (or most -- there may be an exception I don't know about) use the same band but they do have differences in the size of the band and the allowed transmit power levels.The ipw3945 project
That's all very well, but one might hope that "we" could be trusted, or at least the distros and kernel devs could be trusted by Intel, not to screw around with the spectrum in this way.The ipw3945 project
The ipw3945 project
I'm amused by the idea of having it on the card's driver disk. I mean, it has to be there for the Windows drivers, and they could just split it out into a separate file in some useful standard format (like ihex). Of course, that's kind of annoying (since you'd have to swap CDs mid-install), but I like the idea of needing a binary file that can be used on any platform, architecture, etc.The ipw3945 project
It seems to me that Intel ought to release the daemon under the GPL, using the provision that a modified version may be required to report that it is modified, and have the kernel driver check that the daemon isn't modified. Of course, since the kernel driver is also open source, it could be modified to expect the modified version of the daemon, but someone would have to be intentionally messing with stuff at that point (and they could just make the driver not worry about regulatory stuff).The ipw3945 project
The ipw3945 project
Is there some hardware-related reason to enforce regulatory constraints in a fundamentally untrustworthy userspace environment than to do the same on the firmware of the device itself? Any inputs that would be hard to gather from there could surely be passed along by the driver or a free software userspace daemon.Why do this outside the device?
What problem exactly does this solve? I'm trusted to not run the user space daemon for foreign areas (I suppose this daemon will be available for download from Intel?), but somehow I'm not trusted with running a free user space daemon as there is a risk I might patch and recompile. I think for most users running the wrong daemon is the simpler step.The ipw3945 project
Intel heard the government regulations, winked at us, and gave us an answer we can live with.Shut up, already, willya guys?
This really isn't a good answer. The government shouldn't treat me like a little child - they're my servants answerable to me.Shut up, already, willya guys?
If I really wanted to use the highest power/... what is to stop me from telling the user space program that it is in country X -- where X is the one that allows maximum power ?The ipw3945 project