Slashdot Mirror
Functional Linux 802.11G Centrino Driver Released
sixstring355 writes "Intel has released the first functional version of its Centrino/IPW2200 chipset driver. for Linux (kernel 2.6.4+). Posts to the ipw2100/2200 developer mailing list report connection speeds of 450KB/s. See the feature list for more details."
802.11G should support up to 54Mbps (6.6+MBps), isn't 450KBps (3.6Mbps) a little low. slower than 802.11b
Unfortunately, without WEP it won't be much good for everyday use.
WEP isn't much good for everyday use. WEP creates complexity because you need to deploy keys everywhere, reduces performance -- sometimes by as much as half -- and is very easy to break, so the security it provides is mostly illusion. I'm somewhat of a security expert (as in, it's my day job, and they haven't fired me yet), and I run my home network unencrypted, but with the wireless part firewalled off, with the AP configured to do MAC address filtering and not to broadcast the SSID. That's just about as secure as WEP, is much easier to manage and doesn't slow down my data transfers.
That said, the driver in question uses the HostAP infrastructure, which includes a WPA supplicant, so when the security is all hooked up, it should not only have WEP, but it will also support WPA and WPA2, along with either PSK or any of the zillion EAP authentication methods, for centrally-manageable, strong security.
IMO, the driver's security is perfectly acceptable for home use now, and when they get it all hooked up, it'll be just fine for enterprise use as well. Good stuff!
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
They're bothering with WEP because a lot of people use it and because WEP can be quite useful in many situations, as long as you know its limitations. WEP offers an appropriate level of security for many users.
Security, even wireless security, isn't black and white. It comes in shades of gray (not to mention mauve and chartreuse), and all of them are appropriate for some situation or other.
The point isn't that the firmware is closed, but rather that the firmware A) isn't on the hardware and B) isn't redistributable.
What this means is that ONLY Intel has the capabilities to write this driver. For everyone else it's illegal. No porting to to other operating systems. As a FreeBSD user, this announcment is completely worthless.
Also, it means you can't fix any bugs in the firmware. While this isn't going to be something very many people will be able to do, there are enough of them that we don't have to wait for Intel to get around to it. We don't want to make it play the radio, we only want to fix the inevitable bug that shows up. How long has it been since the release of Centrino and this driver? Do you want to wait that long for each and every bug fix?
Don't blame me, I didn't vote for either of them!
is it good practice to trust WEP at all anyways?
wouldn't it be better to treat the air just as insecure as any connection that would go through networks you know to be tapped?
(ssh tunnels & etc..)
world was created 5 seconds before this post as it is.
God I love the Internet.
There is so much inaccurate crap spewed by condescending assholes who think think it is accurate.
Repeat the following until you understand:
The firmware does not execute on the PC's CPU. The firmware is not a driver a kernel module, or portion thereof. The firmware is executed entirely within WiFi card itself. Therefor it matters not what operating system (FreeBSD, Linux, Windows, BeOS, etc) or CPU architecture (x86, Mips, Sparc, PPC, etc) is used. I'm a double dumb ass for spewing inaccurate information as gospel.
BTW, the license *does* allow for redistribution. Go read the whole thing, not just the small snippet posted in the grandparent.
that's what... 4000kbs? Isn't that within the speed expected from 802.11b?
OK. Let's think about this for a second. You've got Wi-Fi developers who take source code and compile it into Kernal module and such. Then you have Wifi users, who Load kernal modules and use Wifi to access the Internet. For purposes of this discussion, I'm going to imagine that I am a manufacturer of wireless devices. I'm not, but I'm trying to put myself in their position, so I can think this through.
If I was a device manufacturer, and I released my source code that allowed someone to operate my hardware, I could not, by law, put a feature in the code that allows an end user the ability to modify the power output or frequency of the device or allow it to cause interference with other devices.
But, If someone else writes a new unautorized driver for my device that does so, the FCC should hold them responsible for it, not me. Now, The FCC, may or may not see it this way. And it is easier for the FCC to go after the device manufacturer than to go after some 16 year old in Finland who hacks up a modification to a device driver. So, as a manufacturer of a wifi device, I'd want to avoid this risk altogether if I could because battles with the FCC cost losts of money and are generally no fun, and I'd rather spend money developing products and marketing them, and telling the Linux crowd to buy my stuff because I support Linux and such.
So, to avoid this risk altogether, I hide the functionaliy using security through obscurity by putting that part in binary only form, as well as using an end user licensing agreement that says that in order to use the software you agree not to reverse engineer it. Now, let me state, that I am NOT advocating security through obsecurity as being secure. It is not secure. In this case, it is not really important that it is really adding security. What is important is that I am making the pretense of adding security. If I really cared about security, I would be using cryptography. But I don't. Instead, I am using a binary only module, so that later I can defend it in court (if I have to) and talk about how there is no way that someone could have modified the power levels or frequencies unless they referse engineered it (which is explicitly prohibited by the end user license agreement).
The end result is that it will probably delay the 16 year old kid in Finland or somewhere from figuring out how to modify the frequency and power levels by a bit, but when the FCC gets upset, I as the device manufacturer, could plead that I have taken due care to comply with the law and prevent exactly this sort of thing. And that's probably sufficient to avoid liability, which is what's important.
Randy.Flood@RHCE2B.COM