Slashdot Mirror

← Back to Stories (view on slashdot.org)

Functional Linux 802.11G Centrino Driver Released

Posted by michael on from the linux-inside dept.

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."

36 of 46 comments (clear)

  1. Nice start by viniosity · · Score: 1
    WEP is not completely hooked up yet, so while you can associate with an encrypted AP, you won't be able to communiate (no DHCP, no data, etc.)

    Unfortunately, without WEP (are they shooting for 40bit or 128bit?) it won't be much good for everyday use. Still, a great step in the right direction. Also, headline writer should note that it supports 802.11b as well as 802.11g..

    1. Re:Nice start by swillden · · Score: 5, Insightful

      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.
    2. Re:Nice start by gl4ss · · Score: 1, Insightful

      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.
    3. Re:Nice start by sixstring355 · · Score: 2, Informative

      True, although the IPW2100 chipset driver supports 802.11b and has been functional for a while. This marks the first release of an Intel driver that supports the IPW2200 chipset, which is also the first driver supporting the 802.11g standard in addition to the 802.11b standard.

    4. Re:Nice start by swillden · · Score: 1

      And so will the other countermeasures I mentioned, just about as effectively as WEP, and with less overhead.

      --
      Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
    5. Re:Nice start by Blittzed · · Score: 1

      No offence, but if you think masking an SSID and using MAC filtering is a defence, then you shouldn't be calling yourself a security expert. Masked SSID's can still be sniffed (AirJack), and MAC addresses can be spoofed. Sure maybe not at the same time that you use it, but are you on there permanently connected with that client MAC 24/7? Even if you are, it still won't necessarily protect you. I can use a deauth attack against your client, then spoof your MAC to allow my client to connect to your AP. This is VERY easy to do. If you are not concerned about the fact that anyone can see every bit of traffic on your network, then go for it. If you are concerned about people connecting to your AP and stealing bandwidth, or hacking your box(es)then you are still vulnerable using the methods you have described.

      I would really think about at least using shared key for the authentication phase. Sure it potentially exposes your WEP key, but the time required to hack it will keep most people away. This doesn't slow your connection down, but will prevent unauthorised users from connecting to your AP.

      --
      "They looked deep into my soul and assigned me a number based on the order in which I joined"
    6. Re:Nice start by swillden · · Score: 1

      No offence, but if you think masking an SSID and using MAC filtering is a defence, then you shouldn't be calling yourself a security expert.

      It's an obstacle, not a defense. But, then, so is WEP. Anyone cluefull enough to sniff your SSID and spoof their MAC is cluefull enough to run airsnort, etc., and crack your WEP key. The WEP cracking takes longer, of course, so WEP will probably defeat casual but smart drive-by attackers. Anyone willing to hang around for a while can find you WEP key and anyone who doesn't know how to use a WEP cracking tool wouldn't know how to get past the hidden SSID and MAC filtering.

      In the case of my home network, of course, the real defense is my firewall. I don't care too much if random people can use my cable modem to get to the Internet, but I don't want them on my home network. My WiFi-connected machines use a VPN for that, of course.

      I would really think about at least using shared key for the authentication phase. Sure it potentially exposes your WEP key, but the time required to hack it will keep most people away. This doesn't slow your connection down, but will prevent unauthorised users from connecting to your AP.

      Not a bad idea for a low-security network.

      For a business environment, of course, if you can't use WPA, or a VPN with firewalls on every connected machine, you just shouldn't use WiFi.

      --
      Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
    7. Re:Nice start by Blittzed · · Score: 1

      I agree with you that unless you are rotating your key, either through a centralised key server, or WPA, then wi-fi shouldn't be considered. VPN's however are less secure. Layer 2 vulnerabilities mean that a VPN can be bypassed using tools such as Kracker-Jack. Seen it, done it. Scared some very large organisations IT security managers by showing them...

      --
      "They looked deep into my soul and assigned me a number based on the order in which I joined"
    8. Re:Nice start by swillden · · Score: 1

      VPN's however are less secure. Layer 2 vulnerabilities mean that a VPN can be bypassed using tools such as Kracker-Jack.

      What are you talking about? No decent VPN should make *any* assumptions about the link layer. A VPN has to assume that the packets are traversing networks that are entirely under the control of the attacker. Whatever kind of low-level spoofing you want to try, if the VPN does strong mutual authentication end-to-end, the most you should be able to accomplish is denial of service.

      For example, at home I use a simple ppp over ssh VPN. The server's public key is known to the clients, and vice versa, so there's no possibility of MITM attacks. I suppose some broken VPN variants that only do one-way authentication, or don't use message authentications, could be hijacked. Don't use those.

      Do you have any references about VPNs that are broken this way? I'd be very interested.

      --
      Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
    9. Re:Nice start by Blittzed · · Score: 1
      Sorry, I should have been more specific. Kracker Jack is used to perpetrate a MITM attack, this is how the VPN is circumvented. It goes something like this:

      When a client is using a VPN solution, it sends a modified DHCP request with its public key; the VPN gateway inserts the clients public key into the DNS server; the client requests the gateways public key from the DNS server, client receives the key and the tunnel is then established. Kracker-Jack works by firstly initiating a deauthentication attack against a valid client, forcing the client to re-authenticate (specifically to the device running Kracker-Jack). It then requests and receives the clients' public key form the DNS server. The next step is to initiate a DHCP request with the clients MAC address, as the client did initially, but its uses its own key, which replaces the clients. In the next step, Kracker-Jack initiates secure connections with both server and client, and the client gets a new public key via DNS request (from Kracker-Jack). Tunnels are now setup between the client and Kracker-Jack, and Kracker-Jack and the server: all traffic now passes unencrypted through Kracker-Jack.

      --
      "They looked deep into my soul and assigned me a number based on the order in which I joined"
    10. Re:Nice start by swillden · · Score: 1

      Ick. What VPN is that, and who designed it? There's a reason public keys shouldn't be trusted without some sort of certification or verification...

      --
      Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
  2. rfmon by adamshelley · · Score: 1

    let me know when you have released a ipw2100 driver that does rfmon mod and channel scanning.

    k plz thx.

    1. Re:rfmon by mahdi13 · · Score: 2, Informative

      They do, the latest firmware supports rfmon.
      I haven't tried it in the last couple months since it was first implemented in the ipw2100 driver and firmware, but it worked (with minor packet corruption, I think that has been redueced in the last couple releases)

      --
      "Some things have to be believed to be seen." - Ralph Hodgson
  3. Great! Now what about... by Blakey+Rat · · Score: 1, Funny

    This is great news! Now when are we going to get one for OS X?

    --
    Comment of the year
  4. It's a source code release! by Spoing · · Score: 1
    ...kinda.

    The firmware that runs on the card itself is still a closed source binary. Think of it as the same as a system board BIOS upgrade, though like the microcode updates for your processor it is loaded each time into the chipset before using it. Unlike the processor updates, the chipset firmware is required to use the card -- at all.

    Here's something to fight over, though;

    1. This Software is licensed for use only in conjunction with Intel component products. Use of the Software in conjunction with non-Intel component products is not licensed hereunder.
    2. You may not copy, modify, rent, sell, distribute or transfer any part of the Software except as provided in this Agreement, and you agree to prevent unauthorized copying of the Software.
    3. You may not reverse engineer, decompile, or disassemble the Software.
    4. You may not sublicense the Software.
    5. The Software may contain the software or other property of third party suppliers.
    --
    A firewall can not protect you from yourself. Turn off what you do not need. Do not use the firewall to do your work.
    1. Re:It's a source code release! by Omega+Hacker · · Score: 5, Informative

      > The firmware that runs on the card itself is still a closed source binary.

      Talk about failure to pick your battles. A bit of real-world info: every single WiFi card on the planet has closed-source firmware. No exceptions. The difference is that the Intel 2x00 cards save money on manufacturing (and thus make the cards cheaper for YOU) by not storing the firmware on an extra flash chip on the board itself.

      Take a look at the board of MOST WiFi cards. You will see either 3 or 4 chips (though some new non-PC-compatible "chipsets" manage to totally integrate this into a single chip). Chip #1 is the baseband (MAC). Chip #2 (if not integrated into the MAC, which is a very recent thing) is the radio section (upconverter/downconverter). Chip #3 is the SRAM needed to store in-flight packets. Chip #4 is the flash chip containing the closed-source firmware. The Intel 2x00 cards save money by letting the host processor and infrastructure do what they're really good at: storing and moving data. Instead of loading firmware out of flash, the card waits for the host to load the firmware as the driver boots up.

      No as for the desirability of open-source firmware... If you plan on telling me that you intend to take this open-source firmware and modify it so your card can do different things with its radio, pay me no mind while I laugh in your face.

      I'm developing firmware for a hardware product right now, and can tell you that there is not the slightest chance that anyone outside the designers of the hardware can make firmware do anything other than what it was designed to do.

      First of all you have the hardware itself, which even the software will be useless for as far as getting the slightest clue what's really going on. Second, firmware for such devices, *especially* high-speed devices like WiFi cards, is more timing-critical than you can even begin to imagine. The slightest change will make it cease to work in ways even the original author most likely will not understand (speaking from daily experience here).

      Sorry, but if you want open-source firmware, you're going to have to design your own chip.

      (Not-Disclaimer: I have no relationship with Intel, their product, or this driver project, except that I plan on buying a 2x00 at some point to replace the driverless/worthless BCM4306 card that came with my laptop)

      --
      GStreamer - The only way to stream!
    2. Re:It's a source code release! by JohnGalt00 · · Score: 5, Informative

      Parent is very informative. As extra detail, FCC regulations prohibit open source firmware in 802.11. They require than non-FCC-licensed radio operators (wi-fi users) be unable to modify the device to create interference. This means that because of the FCC regulations, they can't open source the part of the code that controls the radio's power output and frequency. The atheros guys solved this by creating open source code, and then a binary-only hardware abstraction layer. Supposedly there is some under the table work on replacing the HAL with some open source code. Of course, that would be illegal in the US *wink*.

    3. Re:It's a source code release! by Brandybuck · · Score: 1, Insightful

      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!
    4. Re:It's a source code release! by Spoing · · Score: 1

      Thanks for the follow up. It's what I would have written (if I were faster and more clever).

      --
      A firewall can not protect you from yourself. Turn off what you do not need. Do not use the firewall to do your work.
    5. Re:It's a source code release! by Anonymous Coward · · Score: 2, Insightful

      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.

    6. Re:It's a source code release! by nathanh · · Score: 1
      No as for the desirability of open-source firmware... If you plan on telling me that you intend to take this open-source firmware and modify it so your card can do different things with its radio, pay me no mind while I laugh in your face.

      I think you're unfairly trivialising the need for FLOSS friendly firmware.

      The actual problem is that the licensing on the firmware often prevents redistribution. This means you can't just install a distribution like Debian and start using your wireless card. There is an additional user-hostile step to extract the binary firmware from the Vendor Supplied Driver Disc to use with the otherwise FLOSS driver. I'm using a Prism54 chipset that has binary firmware so I speak from my own frustrated experience.

      There is also the issue of bugs in firmware. Consider the recent bugs that several vendors had in their wireless encryption implementations. I might not have the skills to fix those bugs but I know some people do. Hell, some people patched the binary firmware even without access to source code, though their task was obviously harder. I don't want to be stuck in a situation where I'm hoping the vendor cares enough to fix the bugs for me. Especially when the vendor might have a conflict of interest; they want you to purchase their new equipment, not waste their time fixing your existing equipment.

      There is an additional problem for long-term maintenance. What happens when the vendor goes bankrupt (as often happens), their website stops carrying downloadable drivers, and I can't find my Vendor Supplied Driver Disc to extract the firmware. I now have a useless doorstop instead of otherwise useful hardware. Consider this situation that happened to me recently. A decade old system. Poorly maintained. Original software long since lost. The vendor of the SCSI board had gone bankrupt. The system disk had just blown and the backups were useless. The client was in a state of shock; they had 200GB of data (on other disks) that they couldn't access. They couldn't find drivers anywhere. Linux saved their bacon because Linux had FLOSS drivers for a decade old 16-bit ISA SCSI card. In a world with non-redistributable binary firmware, they really would have been screwed.

      So you trivialise the problem as being about wanting to hack on the driver. That's not what I dislike about binary firmwares. I'm considering ease of installation, long-term maintenance, the ability to control the software baseline, and I don't want to be dependent on the future of some two-bit company that might drop support for the product. Intel is unlikely to go bankrupt, but I predict they'll remove the firmware from their website as soon as the current product becomes unprofitable or a successor product is released.

      There are options that the vendors could give me that would make me happy. I don't necessarily want the source code for the firmware. I wouldn't be able to do anything with it anyway. But I do want:

      • Licensing which permits unlimited copying of the firmware, including the ability to bundle it with distributions, no restrictions on charging money for the privilege, and so on.
      • Cleanly documented interface to the firmware so I can use FLOSS drivers running on the host CPU. I don't really care how the firmware works but I do want to know how to use it.
      • A guarantee from the vendor that if they stop supporting the firmware (eg, fixing bugs) then they will release the source code under a FLOSS license so people who are interested can maintain the firmware.

      I don't think any of those wishlist items are unreasonable.

    7. Re:It's a source code release! by Brian+Blessed · · Score: 2, Interesting
      FCC regulations prohibit open source firmware in 802.11

      Is this really true? This comment seems to suggest otherwise:
      Every one of these 802.11b and 802.11a wireless networking cards that I've pried the case from includes a hardware bandpass filter. This is true even for the manufacturers who refused (at first) to repease drivers or specs.

      - Brian
    8. Re:It's a source code release! by ratboy666 · · Score: 1

      "Omega Hacker"

      Of course ONLY you could conceive of the functionality locked within hardware.

      Of course ONLY the manufacturer could supply good firwware for an embeded system.

      Of course we can't imagine the timing requirements.

      What arrogance!

      Let you in on a little secret -- there are better programmers out there.

      Why not loosen up, and try supporting the hacker ethos?

      Ratboy

      --
      Just another "Cubible(sic) Joe" 2 17 3061
    9. Re:It's a source code release! by randyflood · · Score: 2, Insightful

      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
  5. Isn't 450KBps too slow? by cylcyl · · Score: 2, Insightful

    802.11G should support up to 54Mbps (6.6+MBps), isn't 450KBps (3.6Mbps) a little low. slower than 802.11b

    1. Re:Isn't 450KBps too slow? by Anonymous Coward · · Score: 3, Informative

      Ran out of mod points right before modding this down so I'll just respond instead...

      read the feature list listed in the article. It mentions that it only connects in 802.11b mode, 802.11g support is still in the todo section...

  6. TROLL by vasqzr · · Score: 1


    Maybe when you get a Centrino-based laptop that runs OS X

  7. Grr.. by addaon · · Score: 2, Funny

    Always forgetting about us Linux PPC folk! It only supports x86!

    Oh, wait. Never mind.

    --

    I've had this sig for three days.
    1. Re:Grr.. by Nasarius · · Score: 1

      Broadcom really needs to be blackmailed into releasing Linux drivers (or better, the hardware specs). That way we can have Linux drivers for the Airport Extreme and other Broadcom cards. The strange thing is that they have released Linux drivers for some of their Ethernet cards.

      --
      LOAD "SIG",8,1
  8. Re:Why WEP? by David+Byers · · Score: 3, Insightful

    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.

  9. Re:Why WEP? by Curtman · · Score: 1

    Its also worth noting that its possible to set up a VPN on top of WEP, so that once an attacker compromises your WEP security they still have to get inside your ssh tunnel or whatever. Sure WEP isn't very secure, but neither is IPv4, and we get along just fine anyhow most of the time.

  10. 450KB/s by jovlinger · · Score: 2, Insightful

    that's what... 4000kbs? Isn't that within the speed expected from 802.11b?

  11. Linux Installation Reports for Centrinos by wehe · · Score: 4, Informative

    There are many Linux installation reports for Centrino based laptops and notebooks available. The older manuals cover the Centrinos with Banias CPU. But some of the new cover the current Centrino generation with Dothan CPU already.

  12. Re:Wrong section? by Carewolf · · Score: 1

    It is: notice the 4 icons besides the story? They represents the sections this story is in.

  13. The Myth of Easy WEP Cracking by Karpe · · Score: 2, Informative

    Please check out this.

    The fact is that WEP is better than no WEP, that if you use WDS you gotta use WEP instead of WPA because of the MAC addresses, and that you should still use higher level encryption layers anyway for sensitive information.

    Deploying WEP is easy (and I don't even mean using it with the Wireless wizard in XP SP2 that will deploy passwords for you).

  14. Re:This is why Intel, not Broadcom, will rule by mahdi13 · · Score: 1
    What I wanna know is, why the hell do companies like Broadcom still get away with ignoring Linux users? What can we do to pressure them into releasing drivers?!
    Don't buy their products?
    Seriously, if they start to notice that their sales are dropping and they see "Don't buy Broadcom" all over Linux sites...someone there might take the hint...
    --
    "Some things have to be believed to be seen." - Ralph Hodgson