Follow Slashdot stories on Twitter

 


Forgot your password?
Close
typodupeerror
×

OpenBSD Ahead of Linux for Wi-Fi Drivers 256

Posted by timothy from the alle-menschen-sind-auslaender-fast-ueberall dept.
algae writes "It looks like some kernel developers have noticed that the OpenBSD project is including reverse-engineered drivers for wireless ethernet cards while Linux is still using binary blobs. A large part of the issue is that much OpenBSD development takes place abroad, where having to do clean-room reverse-engineering isn't as important." From the article: "Christoph Hellwig took another stance, 'please don't let this reverse engineering idiocy hinder wireless driver adoption, we're already falling far behind openbsd who are very successfully reverse engineering lots of wireless chipsets.'"
This discussion has been archived. No new comments can be posted.

OpenBSD Ahead of Linux for Wi-Fi Drivers More

OpenBSD Ahead of Linux for Wi-Fi Drivers

Comments Filter:

  • Ha, wireless BSD (Score:5, Informative)

    by jawtheshark ( 198669 ) * <slashdot@nosPAm.jawtheshark.com> on Monday June 12, 2006 @04:13PM (#15519242) Homepage Journal

    I just started using FreeBSD 6.1 recently and I was surpised about the ease of setting it up. (Still not for the faint of heart, but Windows isn't either. If you want a nice custom setup that does what you want, you need a lot of time in Windows). My primary laptop is a P-III 600MHz with 512Meg RAM. An old fucker I bought for peanuts. It didn't have a network interface, so I added a Sweex wireless adapter [sweex.nl]. It shows up in both FreeBSD as Windows under RaLink 2500. (Note that Sweex is a cheapass brand, but for another product I had *excellent* support by email with them)

    Linux.... Nothing... No out of the box recognition.

    OpenBSD also recognised it but doesn't support WPA-PSK which I do require. FreeBSD supports WPA-PSK. I've been an OpenBSD fanboy for a long time, but I like FreeBSD equally now. Linux... well, somehow I have problems with most distributions. Either philosophical problems or technical problems :-) With *BSD, I have neither.

    • Re:Ha, wireless BSD (Score:5, Interesting)

      by ArbitraryConstant ( 763964 ) on Monday June 12, 2006 @04:33PM (#15519366) Homepage
      I went to a presentation by the OpenBSD developers during their Hack-a-thon, and they indicated that WPA was not a very high priority for them. They prefer to do authentication with auth-pf, and if encryption is needed they prefer to use VPNs. It does make it a PITA if you want to use a network you have no control over, but the OpenBSD crowd are like that sometimes.

      • Re:Ha, wireless BSD (Score:2, Informative)

        by jawtheshark ( 198669 ) *

        It does make it a PITA if you want to use a network you have no control over, but the OpenBSD crowd are like that sometimes.

        Yes, it does... but it still won't keep me from financing them. They have an excellent server platform and I just delegate the wireless functions to embedded devices. It just keeps me from becoming a desktop/laptop OpenBSD user, but I don't think that it's their target.

        • Yup. Where they're good, they're great, and where they haven't bothered to give something attention they're crap. It doesn't keep it from being a good OS, or a pleasure to work with when you work with it, it just means it can't do everything and you have to be prepared to use something else when it's not well suited.

      • Re:Ha, wireless BSD (Score:5, Informative)

        by Anonymous Coward on Monday June 12, 2006 @07:50PM (#15520592)
        The intro to this article is utter crap. OpenBSD does meticulous clean-room reverse engineering -- usually using two people (one to document function, the other to write the driver). They are, as always, completely anally retentive about license and legal issues. The submitter apparently didn't read the article - it is Linux, not OpenBSD, that may have issues about where it gets driver info -- the Slashdot submission has this completely wrong and should be corrected (just read the article!). The articles says *nothing* about where OpenBSD development takes place or its reverse enginnering process. This statement is an assertion of the article submitter, and very misleading.

    • Re:Ha, wireless BSD (Score:3, Informative)

      by bersl2 ( 689221 )
      rt2x00 is on the way to future kernel inclusion. In the meantime, the drivers derived from Ralink's code, which is in turn derived from their NDIS sources, are more than usable.
    • There's a Sourceforge project for that exact card: http://sourceforge.net/projects/rt2400 [sourceforge.net], whose code is included by the Ubuntu team an worked my Ralink 2500 mini-pci straight out of the box. Unfortunately, the code support for USB'd devices is coming along rather than solid.

    • Re:Ha, wireless BSD (Score:3, Informative)

      by MrHanky ( 141717 )
      I've used an rt2500 based WLAN-card on Linux, several months (a year?) ago. It worked well, but the driver was based on vendor supplied code that didn't integrate well with the rest of the kernel (duplication of effort, etc). That's why it isn't included in Linus's tree. But in the case of Ralink wireless chipsets, you actually get some vendor support for Linux, with actual working GPL code. I'm pretty sure the driver is included in Ubuntu 6.06.
    • ...linux supports thousands of other devices that BSDs doesn't support. Seriously, why a "openbsd ahead of Linux" story written in this way? It looks like some people love to start flamewars between linux and BSD communities or what? Linux developers are just as interested in getting opensource drivers just as the next guy. We're all in the same ship.

      • Re:in other news... (Score:3, Insightful)

        by kv9 ( 697238 )
        ...linux supports thousands of other devices that BSDs doesn't support.

        very good. we need opensource supporting all sorts of hardware. only this discussion is in regards to WiFi support.

        Linux developers are just as interested in getting opensource drivers just as the next guy. We're all in the same ship.

        i don't see where the flame is. the OpenBSD folks want open unencumbered drivers (hence the 3.9 blob theme [openbsd.org]) while the Linux folks have NDIS wrappers, blobs and other such hacks. it's fact. no need to get

        • OpenBSD folks want open unencumbered drivers (hence the 3.9 blob theme) while the Linux folks have NDIS wrappers, blobs and other such hacks. it's fact.

          There is no single standard `OpenBSD folk' and no single standard `Linux folk'. Both camps are made up of large numbers of people who each want something different.

          Of course, OpenBSD is a much smaller market than the Linux market, which is probably part of why binary blobs just aren't availble for it at all -- the hardware developers just ignore Ope

          • Re:in other news... (Score:5, Insightful)

            by mike_the_kid ( 58164 ) on Tuesday June 13, 2006 @12:05AM (#15521701) Journal
            Of course, OpenBSD is a much smaller market than the Linux market, which is probably part of why binary blobs just aren't availble for it at all -- the hardware developers just ignore OpenBSD entirely rather than throwing them a bone in the form of a binary blob.


            OpenBSD doesn't have any blobs because the project's leaders will not consider using them. What's the point of having an open source, audited, secure operating system if you allow arbitrary blocks of binary code into the kernel?

            The reason OpenBSD doesn't have blobs is not because of their size -- they could port FreeBSD blobs in easilly. The reason is that the project is focused on quality. Their view is that quality and openness go hand in hand. Can't have one without the other. See this interview with Damien Bergamini, who implemented a driver for the Intel 3945 802.11abg NIC without any of Intel's blobs. [kerneltrap.org] The OpenBSD driver is considerably fewer lines of code than Intel's. Because its simpler, its easier to audit, and easier to find bugs in. Of course, you can't find any bugs in Intel's driver because you can't see the source code. Not because the Intel driver is bug free.

  • Take Action (Score:3, Insightful)

    by neonprimetime ( 528653 ) on Monday June 12, 2006 @04:16PM (#15519257)
    Far too many people have a careless 'U.S.A. laws suck, merge it anyway' attitude

    Sometimes, like at this point, it's the right attitude. They better take action soon, or openbsd will make them look like a joke.
    • Sometimes, like at this point, it's the right attitude. They better take action soon, or openbsd will make them look like a joke.

      Oh, puh-leez. You think Red Hat & SuSE are going to drop Linux and pick up OpenBSD, just because OBSD has better wireless support?
    • As a US-based user, I think that attitude is sometimes the correct one. It may preclude them from getting corporate funding here, but it won't stop a lot of users from running it.

      I've thought for a while that it would be nice if somebody based in a nice, free jurisdiction (Sealand or similar) put together a "Functional Linux" disto. Something that ignored all the artificial, non-technical barriers that make Linux a bit of a PITA to install. Built in MPEG encode and decode. Built in eBook decryption. Built i

    • Re:Take Action (Score:2, Insightful)

      by herodiade42 ( 974875 )
      > Far too many people have a careless 'U.S.A. laws suck, merge it anyway' attitude
      Sometimes, like at this point, it's the right attitude.

      I second this. IP owner are kinda terrorists (presuring gvt agencies, senates, parliaments, etc), and succeed well in spreading fear. There's lot of irrational going on this matter:
      • There's already drivers reverse engenered & implemented by the same person on the Linux kernel. Accepting this one would be consitent. What's so special with wireless ?
      • For mo

  • OpenBSD supported wireless chipsets (Score:5, Informative)

    by Homology ( 639438 ) on Monday June 12, 2006 @04:16PM (#15519258)
    can be found by reading the man pages [openbsd.org]

  • You heard it here first... (Score:5, Funny)

    by Weaselmancer ( 533834 ) on Monday June 12, 2006 @04:17PM (#15519266)

    Linux is dead. Now, when will BSD be ready for the desktop?

  • yay for BSD (Score:4, Interesting)

    by Umbral Blot ( 737704 ) on Monday June 12, 2006 @04:17PM (#15519269) Homepage
    Well as the article itself says the clean room method isn't required by law. It would seem to make sense then to drop it until it is required by law, or alternately host your distribution overseas and have the developers working on the drivers be non-US residents as well, so that you are less vulnerable to US law. Wi-Fi problems are one of the reasons this laptop doesn't run Linux, although BSD is sounding cooler and cooler.
    • And by routing all traffic through this proxy in international waters, all otherwise illegal MP3s become less vulnerable to US law! Score!

    • Re:yay for BSD (Score:3, Interesting)

      by try_anything ( 880404 )
      IANAL, but my impression is that no one claims that clean room reverse engineering has ever been required by law anywhere at any time. The clean room method is designed not merely to comply with the law but to be a convincing demonstration that the requirements of the law have been met. Abiding by the law is one thing; being able to cheaply and confidently defend yourself in court against a well-funded attack is another thing entirely.

      (Further, if clean room engineering is the de facto standard for docu

  • You can help end this argument (Score:5, Insightful)

    by Bruce Perens ( 3872 ) * <bruce@perens.com> on Monday June 12, 2006 @04:19PM (#15519283) Homepage Journal
    BLOBs are bad, and their legality in the kernel is questionable. Of course really free drivers that let us extend devices are better.

    Leaving BLOBs in the kernel might just mean you have different plaintiffs than if you used a reverse-engineered driver.

    However, full clean-room reverse-engineering a free driver with full source code, rather than one that you have to disassemble and figure out, is a reasonably easy task. And, we have to write a Linux driver anyway. So, find one friend to work with and get started.

    One person must not write any kernel code concerned with the driver. That person must read the existing driver, document the hardware, and publish the document. The document should not reproduce algorithms in the existing driver unless they are integral to driving the device and there isn't another way to do it.

    A second person must not look at the existing driver. This person reads the document and writes a new driver.

    Keep notes about the entire process. You could someday have to testify that you did it the right way.

    Bruce

    • Re:You can help end this argument (Score:5, Interesting)

      by Homology ( 639438 ) on Monday June 12, 2006 @04:38PM (#15519426)
      > BLOBs are bad, and their legality in the kernel is questionable.
      > Of course really free drivers that let us extend devices are better.

      It would be helpful if the Linux developers would be more supportive
      of OpenBSDs work on getting hardware manufactures to release
      documentation that is not under a NDA. When OpenBSD had the campaign
      for release of wi-fi chipset docs, it seemed that the Linux developers where
      sitting on the fence.
        • That was impression during that time, though Raadt was later
          on giving public recognition for this (2004 FSF Award). I do
          not imply that Linux developers does not care in general.

          • Re:You can help end this argument (Score:5, Informative)

            by Bruce Perens ( 3872 ) * <bruce@perens.com> on Monday June 12, 2006 @05:05PM (#15519639) Homepage Journal
            I remember being copied on some of the discussion between Theo de Raadt and Richard Stallman. I think what happened is that Theo started out to get BSD-licensed BLOBs from manufacturers. And then, perhaps even through discussion with Richard, Theo was convinced that BLOBs were bad even if they were BSD-licensed. There was also some discussion from Theo about the fact that FSF and Richard hadn't ever supported Theo's work. And at some point they must have worked all of this out.

            But FSF aren't the Linux developers. If you ask them, they will be very adamant about that.

            Bruce

            • BLOB != firmware

              i can hardly imagine theo was ever supportive of the idea of shipping a bsd-licensed blob with openbsd
            • No, the problem he is talking about was not with Stallman.
              In fact there were two differents campaigns goals, about two very different kinds of "blobs":
              • For obtaining the right to redistribute firmwares with the system. With recent wireless chipsets, the firmware is often loaded in the hardware at runtime, so it should be provided separetly (a scale economy compared to providing a flash memory onboard). So even BSD or MIT licences were acceptables here: the firmware is to be loaded and executed on the ch
    • I realize, of course, that many companies supply proprietary Linux drivers, but will not release the source. They don't want to support the Linux code, and they may have 3rd party licensing arrangements that prevent them from opening the source. In many cases though, they are not making money off the driver. TurboPrint drivers are a notable exception.

      In the cases where they are not directly selling a driver, you may be able to get written permission to reverse-engineer the company's binary driver. Even
    • As far as I can tell, the new Slashdot software does not prevent the joke posting from coming before the one with substance. :-(
    • Yes in an ideal world. WiFi devices have an additional problem. They must be certified by the FCC. A lot of the devices now use a software defined radio. That is great since it brings down the cost of the card and makes it more flexible. The problem is that if the end user has access to the interface in theory the end use could enable the device to broadcast out of the legal limits. The FCC would fail to certify that device.
      Yes you could make cards that enforce the legal limits of power and frequency but th
      • I have looked at the FCC rule-making and do not see that it prevents Open Source drivers, regardless of the hardware. Those drivers should enforce operation within the part 15 regulations, unless they are being operated by a licensed Radio Amateur. We do have open drivers for a number of cards, and FCC has never made an issue of it.

        Bruce

    • HCL: A strategy to get off the driver treadmill (Score:5, Interesting)

      by Burz ( 138833 ) on Monday June 12, 2006 @06:15PM (#15520089) Homepage Journal
      1) Form a consortium of major Linux vendors to build and maintain an exhaustive but relatively friendly Hardware Compatability List (HCL).

      2) Spread the word that if users don't consult the HCL before purchasing new hardware, they risk a lot of compatability headaches.

      3) Invite hardware OEMs to participate directly in maintaining their corner of the HCL. Under each model listing, provide a button to send user feedback (or petition) to the hardware vendor.

      4) Watch as hardware vendors begin to take Linux drivers much more seriously, due to constant and coordinated pressure from consumers. Vendors will get a clear message that the days of the haphazard "plug-n-wish" habit are over, since users will avoid buying their products of questionble compatability in the first place.

      OS vendors must work to keep their patrons informed about hardware suitability. There is no other way around it in the near-mid term, and we will never get to the point where most OEMs automatically accommodate Linux unless a sturdy bridge is built to organize and convey the users' purchasing interests.
      • So far in this thread, this is the only post that actually makes sense.

        Just two flies in this otherwise tasty bowl of soup though.

        1. The makers haven't the manpower to do anything but wholesale deletion of the messages that would be generated by such a setup. They would be forced to resort to that because their mail servers hard drives will be filled to 100% with unread messages eventually. I have serious doubts that very many of them would even have multlingual employees who could translate our rantings

    • Re: (Score:3, Interesting)

      by account_deleted ( 4530225 )
      Comment removed based on user account deletion

  • Blob is bad! (Score:3, Insightful)

    by grub ( 11606 ) <slashdot@grub.net> on Monday June 12, 2006 @04:21PM (#15519292) Homepage Journal

    I really hope the OpenBSD group's steadfast stance on "blob" is maintained. The Linux guys, who overall don't seem to mind blob, sound like they're starting to see the light. In the end it can only be good for all open source, not just OpenBSD.

    • Re:Blob is bad! (Score:5, Informative)

      by Anonymous Coward on Monday June 12, 2006 @04:48PM (#15519498)
      Openbsd is going to maintain the anti-blob. I was down a wireless security with openbsd talk in Calgary after the hackathon last week which Theo attended and you can be sure OpenBSD will maintain the anti-blob. The discussion about blobs centred around what has been said before on openbsd.org. OpenBSD is first and foremost about security in its default state. You can't include arbitrary code that you don't compile yourself in such a system, you can't verify that's it doing what it says its doing. Further more Asian developers are more then happy to hand over all the required spec documents to get wider support for their wireless chipset. American companies however are going the otherway and would rather build drivers for each system the feel is important enough to warrent them.

      I'm sure they have their reasons but at the end of the day their way attempt at full circle development control will probably back fire. In an attempt to maintain a clean intellectual property enviroment where every participant is governed by NDA's and priorities are set by Mama corporate they have traded in creditabilty and grass root adoption. Whether this will ultimately cause them bottom line trama will be determined later in life. But one must only look at the economic trend in america as a whole to take a guess as to where this is going.

      America is becoming a service industry economy and losing its development and manufacturing roots, those jobs are being shipped oversea to asian companies that care more about making product then protecting copy rights. The cards that history played out however means that America still has trillions in wealth and the world's economies will continue to market heavily to americans to buy their products. Until that money dries up and their attention turns elsewhere. Once that occurs you won't see Toyota putting plants in Indiana to demonstrate how many local jobs it produces. It will put them in South America where the labour is half the price.

      As I see this is just another example of how American values of fairness, quality, openess and honesty have been lost in the boardroom and consequently the world is turning elsewhere.

      Hillbilly1980(damnit what's my password)

    • I find the title of your comment to be offensive :)

  • Bootable Distro? (Score:2, Interesting)

    by deadhammer ( 576762 )
    Fantastic, I just read through the supported chipsets and my laptop's onboard chipset is on there. So now I want to test it. Are there any decent bootable CD distros (Knoppix style) of OpenBSD that I could simply download and play with? If so I'd be more than interested in getting Windows off of it and cruising with BSD.

  • confused... (Score:3, Interesting)

    by Lumpy ( 12016 ) on Monday June 12, 2006 @04:28PM (#15519336) Homepage
    So what exactly is stopping them from download ing the BSD drivers and making a linux driver from the BSD sourcecode?

    Is there some kind of problem with that?
    • Skill.
      Not that it's -extremely- hard. But few code monkeys can do it right while maintaining the high kernel code quality standards.

    • Re:confused... (Score:3, Insightful)

      by DragonWriter ( 970822 )
      Well, presumably, if the (paraphrased) "much BSD development is done where the law doesn't demand clean-room reverse engineering" statement really is a valid difference between OpenBSD and Linux, the legally (in some parts of the world, presumably where much Linux development is done) tainted OpenBSD drivers would remain tainted, and thus Linux developers in those parts of the world would face legal jeopardy for porting them.

      Of course, if this is really the reason, the OpenBSD drivers are probably illegal f
      • In which case, clean room the OpenBSD driver - the hard work (reverse engineering) has been done - use the OpenBSD sourcecode and docs to write a spec, then have someone else implement the spec. The OpenBSD source can speed up the clean room process.
        • As I understand it, writing the spec from the illegal source code might itself be a further violation (implementing the spec wouldn't).

          So, so long as the person writing the spec is in a "safe" jurisdiction, and the person implementing it, if not in a "safe" jurisdiction, didn't coordinate with them (which might be illegal in their "unsafe" jurisdiction), then this is probably legal.

  • Open Secrets (Score:5, Insightful)

    by Doc Ruby ( 173196 ) on Monday June 12, 2006 @04:33PM (#15519371) Homepage Journal
    If those OpenBSD drivers are under the BSD license, doesn't that mean anyone (except the very few under some kind of other legal constraint for some other reason) with the chops can port them to Linux? And those chops don't have to be as tight as the original BSD coders. Shouldn't the lead be very short-lived?

    • Re:Open Secrets (Score:3, Informative)

      by evilviper ( 135110 )
      Shouldn't the lead be very short-lived?

      No. Finding someone "with the chops" and interest simply isn't easy. There are simply tons of projects in the open source world that would be done very quickly if someone with the skills would do it. Instead, you have to wait around for someone with skill to get that particular itch.
      • Well, not to mention that it's pretty difficult to write and debug drivers for hardware that you don't own.
        Even if you found someone who'd be willing to work on them, chances are they won't have examples of every different wireless card available for testing. However, one-by-one, I think yes, the lead-time could easily shrink. But chances are you'd have to find a new developer for each wireless chipset, unless you're willing to donate hardware.

        (It would be cool if there was some kind of pool resource that p
      • Yet the much smaller BSD developer community has enough people with even rarer skills?

        And even if so, doesn't that demolish the excuse that Linux lacks drivers because of proprietary tech blocking the path? Rather, the reason is that Linux developers just don't produce the drivers they could.

        I don't believe either of those propositions. That's why I believe the BSD lead will be short-lived.

        • Re:Open Secrets (Score:3, Insightful)

          by evilviper ( 135110 )
          Yet the much smaller BSD developer community has enough people with even rarer skills?

          No, it's that this has been an "itch" in the OpenBSD community for quite a while now. Linux developers simply chose to focus their attention elsewhere, since their wireless cards were working fine...
      • Instead, you have to wait around for someone with skill to get that particular itch.

        Or for someone with the bucks to pay someone to scratch their itch.

  • ndiswrapper for *BSD? (Score:3, Interesting)

    by schweini ( 607711 ) on Monday June 12, 2006 @05:11PM (#15519682)
    i just finished fighting with my PCMCIA WiFi card and ndiswrapper and wpa_supplicant, becasue they only choose to work when they feel like it - everything from Segmentation Faults to perfected working happens from time to time - I guess it's because of the voodoo invloved in making a windows driver run on linux, so i guess i shouldnt complain. but it still begs the question why there's no "ndiswrapper for *BSD drivers", or something along those lines. AFAIK, windows drivers have to have a rather rigid interface (NDIS?), and this might not be the case for the BSDs, but i'd still guess that it should be easier to build a wrapper for other open-source drivers than for windows drivers?
  • can they also do it with video cards? I'd love to see the day when I can use an open source nv driver and still have a usably fast rxvt.

Slashdot Top Deals

The use of money is all the advantage there is to having money. -- B. Franklin

Close