Advertisement
GStreamer Conference 2013, 22-23 Oct, Edinburgh
GStreamer, Embedded Linux, Android, VoD, Smooth Streaming, DRM, RTSP, HEVC, PulseAudio, OpenGL. Register now to attend.
Weekly Edition
Return to the Kernel page
| |||||||||||||
The ipw3945 project
While there are a number of hopeful developments around the support of
wireless network cards in Linux, that support remains one of the larger
roadblocks for many users. It is thus always a welcome thing when a major
manufacturer announces Linux support - and the beginnings of a working
driver - for their products. So when Intel recently announced a
project to support its 3945ABG wireless adapters, there was a certain
amount of celebration. There was also come criticism, however, which
highlights an ongoing issue with wireless support under Linux.
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:
In order to meet the requirements of all geographies into which our
adapters ship (over 100 countries) we have placed the regulatory
enforcement logic into a user space daemon that we provide as a
binary under the same license agreement as the microcode. We
provide that binary pre-compiled as both a 32-bit and 64-bit
application. The daemon utilizes a sysfs interface exposed by the
driver in order to communicate with the hardware and configure the
required regulatory parameters.
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. (Log in to post comments)
The ipw3945 project Posted Mar 2, 2006 10:07 UTC (Thu) by eskild (subscriber, #1556) [Link] 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 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.
The ipw3945 project Posted Mar 2, 2006 11:30 UTC (Thu) by cate (subscriber, #1359) [Link] I want a open source driver. I want to see the code. I want to see what restriction apply in my country.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?
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).
The ipw3945 project Posted Mar 2, 2006 11:40 UTC (Thu) by gypsumfantastic (guest, #31134) [Link] 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;
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.
The ipw3945 project Posted Mar 2, 2006 13:41 UTC (Thu) by nix (subscriber, #2304) [Link] 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.
The ipw3945 project Posted Mar 2, 2006 15:12 UTC (Thu) by danm628 (subscriber, #5995) [Link] 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.
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.
The ipw3945 project Posted Mar 2, 2006 11:33 UTC (Thu) by gypsumfantastic (guest, #31134) [Link] 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.
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.
The ipw3945 project Posted Mar 2, 2006 14:55 UTC (Thu) by kmccarty (subscriber, #12085) [Link] 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.
The ipw3945 project Posted Mar 2, 2006 21:22 UTC (Thu) by iabervon (subscriber, #722) [Link] 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 Posted Mar 2, 2006 21:42 UTC (Thu) by iabervon (subscriber, #722) [Link] 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).
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...
The ipw3945 project Posted Mar 4, 2006 1:24 UTC (Sat) by giraffedata (subscriber, #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.
Why do this outside the device? Posted Mar 3, 2006 20:49 UTC (Fri) by GreyWizard (guest, #1026) [Link] 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.
The ipw3945 project Posted Mar 4, 2006 18:30 UTC (Sat) by job (guest, #670) [Link] 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.
Shut up, already, willya guys? Posted Mar 4, 2006 19:01 UTC (Sat) by Baylink (subscriber, #755) [Link] Intel heard the government regulations, winked at us, and gave us an answer we can live with.
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!")
Shut up, already, willya guys? Posted Mar 25, 2006 17:38 UTC (Sat) by rwmj (subscriber, #5474) [Link] This really isn't a good answer. The government shouldn't treat me like a little child - they're my servants answerable to me.
Rich.
The ipw3945 project Posted Mar 7, 2006 9:46 UTC (Tue) by addw (guest, #1771) [Link] 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 ?
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.
|
|||||||||||||