Slashdot Mirror


The Battle for Wireless Network Drivers

An anonymous reader points out this Jem Matzan article "about the pain Linux and BSD programmers have in trying to obtain/write device drivers for various wireless cards," writing: This article also has a fairly detailed explanation of how wireless firmwares and drivers work. Two of the manufacturers are actively working with the FOSS community without requiring an NDA."

3 of 163 comments (clear)

  1. As someone that has been there by mycal · · Score: 5, Interesting


    Trying to develop wireless 802.11 interfaces for embedded platforms I agree that it is a total pain in a arse. I even knew people that I worked with before at broadcom and couldn't get them to kick down the Software API. We finally got a Philips BGW200 system working and that wasn't easy either since even after filling out NDAs we got messed around for a few months trying to get the right documentation.

    But now it does seem that Atmel is working with people, and accourding to the article so is raylink.

    What you can do to help is if you have choice, support these guys when you have to buy a wireless adapter even if it is a few bucks more.

    -M

  2. I know what IBM will do. I don't know why. by quiberon2 · · Score: 4, Interesting
    If you want (say) a disk controller subsystem from IBM, then IBM will generelly supply the adapter microcode as 'Object Code Only, All Rights Reserved'; and the device driver as open-source.

    I don't know about redistribution rights; you can always ask.

    If an open-source developer wants to see the source for the adapter microcode, ask about that one too.

  3. There's more needed than just documentation by Freggy · · Score: 4, Interesting
    Still I have the impression that lack of manufacturer willingness to publish documentation, is abused all too often to explain that there are no drivers for Linux, while the reality shows some other interesting facts. Here are some of my experiences I had with wireless in Linux:
    • First I bought a card based on fullmac prism54 chipset. It was known as one of the best supported chipsets in Linux, at the time the only 802.11g driver included in Linux kernel IIRC. It worked fine for basic operation yes, but it did not seem to support WPA. Prism54 development seems to be halted completely already for some time. People are developing the islsm driver which would also support freemac cards, but this is far from usable at the moment.
    • Intel Centrino ipw2200: had this in my laptop. Just installing firmware (which was as easy as adding PLF repository to my Mandriva system and running urpmi ipw2200-firmware) and it worked perfectly, WPA included!
    • Ralink rt2500 based PC card: I bought this again because I knew the manufacturer published documentation. Well, actually there are two drivers. The legacy driver, which should be somewhat stable, but which you cannot use when using multi-processor (dual core, etc), and the new driver which is beta and still unstable. Well, I tried both, but did not succeed in getting my wireless network to work.
    • Broadcom 43xx based PC card: was known at the time as one of the worst chipsets for Linux, because Broadcom was unwilling to publish documentation. Still bought it, because a new reverse engineering project started at that time. Today with kernel 2.6.19, this driver is included in Linux. And it works very good, WPA included. Yes, I had to install firmware by hand by means of bcm-fwcutter.
    So I'm arriving at the bizarre conclusion that for me, the best working wireless chipsets, are these from the category of manufacturers that are not very willing to work together with community. Still, there's a free driver, with only the firmware being proprietary and not freely distributable. Other drivers which should be in the recommended category, failed for me. Some reflections:
    • Good Linux support depends of much more than just the manufacturer publishing documentation. There should be an active community of developers: if that is lacking, even with good documentation, support will remain problematic.
    • Even without documentation it is possible to create good drivers by means of reverse engineering. If a card is popular enough and the right people at the right time start reverse engineering, then this could be a big success.
    • The presence of a proprietary, non-free driver could harm development of a free driver. For example take a look at the nvidia driver. Since a year, there's a reverse-engineering project to create a free dri-driver for nvidia, but it's not advancing at all. I guess lack of developer interest, because there's already the proprietary driver. Also look at ipw2945 driver: OpenBSD proved it can work without the the Intel binary-only daemon, but for Linux, nobody cared to reverse engineer it.