Stories
Slash Boxes
Comments
Search

News for nerds, stuff that matters

Slashdot Log In

Log In

Create Account  |  Retrieve Password

OpenBSD Ahead of Linux for Wi-Fi Drivers

Posted by timothy on Mon Jun 12, 2006 03:12 PM
from the alle-menschen-sind-auslaender-fast-ueberall dept.
Wireless Networking Operating Systems Software Hardware BSD Linux
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.'"
+ -
story
This discussion has been archived. No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

OpenBSD Ahead of Linux for Wi-Fi Drivers 50 Comments More /

 Full
 Abbreviated
 Hidden
More
Loading... please wait.

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

    by jawtheshark (198669) * <slashdot.jawtheshark@com> on Monday June 12 2006, @03: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, @03: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:5, Informative)

        by Anonymous Coward on Monday June 12 2006, @06: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.
          • This whole "you could be sued for reverse engineering" thing is a load of crap. Who in reality has been sued for reverse engineering? Even in the US you are allowed to reverse engineer for interoperability purposes. You can be sued for infringing on a patent, but that's not specific to reverse engineering.

            • Well I don't know if it's a load of crap. A quick search turns up a couple cases: Blizzard v. BNETD [eff.org] and Mattel sued the makers of cphack [wired.com] (over some kind of censorship software).

              This how-to [advogato.org] implies that reverse engineering "for purposes of interoperability" is legal in many places, but that's just one reason people reverse engineer stuff. With legal limits on what and when you can reverse engineer products, it's definitely possible to be sued for it. And successfully sued if you're violating the law (wheth
    • 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.
        • If you use the rt2500 cvs driver it works great even on smp systems for Linux. I was using the rt2x00 becuase until late May the rt2500 driver would lockup SMP systems and Fedora only has SMP kernels for the x86_64 systems now. I don't use the rt2x00 driver anymore because it has some problems. However, I have not lookedinto it for about a month. Just go to http://rt2x00.serialmonkey.com/wiki/index.php/Down loads [serialmonkey.com] and grap the latest rt2500 nightly tarball. Also if you don't want it to mess up the fglrx dri
    • 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.
      • I know you mean this as a joke, but no.... it isn't. I have a 80 square metre apartment made of concrete and the signal of my Linksys WPA is weak 5 metres away in the living room. The sweex adapter gets high noise and low signal.... Both in Windows XP and FreeBSD.

        This is not the fault of the operating systems, it's the concrete.... One doesn't have to be a genius to figure that out.

        My parents have a wooden house and the same Linksys WPA. With my network adapter I can go anywhere and have a perfect

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

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

            by mike_the_kid (58164) on Monday June 12 2006, @11:05PM (#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, @03: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.

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

    by Homology (639438) on Monday June 12 2006, @03: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, @03: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, @03: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.
    • 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

  • 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, @03: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.
          • 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

            • 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
    • 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, @05:15PM (#15520089) 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.
      • AC wrote: What would end the argument, Bruce is open-source hardware.

        Yes, that would be excellent. How do we get there? OpenCores.org has the start. However, all of the gate-arrays that they have to work with have a proprietary bitstream format and thus they require proprietary tools to program them. We need an Open Source gate-array to facilitate Open Source hardware. Initial full-custom full-wafer mass fabrication cost is about $1 Million. At that point, you can get the parts down to a reasonable price. You can do small runs in MOSIS (or whatever they have these days) to make sure the design works before you go that far.

        I figure this is at least $2 Million to get done. We need good hardware designers and people to help write the grant. If I can hook up with such people, I'll do whatever I can to help. I don't have the hardware expertise to lead this, or I'd already be started. Any volunteers? I'm quite serious.

        Bruce

        • We need an Open Source gate-array to facilitate Open Source hardware. Initial full-custom full-wafer mass fabrication cost is about $1 Million.

          Please don't forget the software, as most intelligence for programmable logic is contained there. Developing a wafer for an FPGA is easy compared to writing synthesis/P&R software for it. Automatic place and route is a really hard problem [wikipedia.org].

          I figure this is at least $2 Million to get done.

          I'd double that, and allocate most of it to synthesis/P&R software. Altho

            • Hm. There are two issues here and I'm a bit confused regarding which you mean.

              Place-and-route for the logic to load into the device.

              My impression is that Open Source does exist to do at least part of this job. I don't know how good it is.

              I know of free (libre) VHDL synthesis software targetting silicon (eg. Alliance [lip6.fr]), but I'm not aware of similarly licensed P&R software targetting programmable logic. And even if it were to exist, because the problem is so very hard I don't think it's going to be any goo

        • OpenCores isn't the only open hardware group. Check out www.opengraphics.org, particularly the OGD1 section. Real hardware engineers are making real hardware, and they're making it OPEN (and libre).
          • I think that their site is actually http://www.opengraphicsproject.org/ [opengraphicsproject.org]

            Does anyone know if there are any plans/projects out there to build an actual free HDL synthesizer? Something that can go from the Verilog or VHDL to a netlist? It seems that's kind of key to all of the "open source hardware" projects; without one it's like the FSF in 1986, before gcc. You can write all the code you want but doing anything with it requires finding someone with the right commercial software.

            The concept of 'hacking hardwar

        • Open Source Hardware (Score:5, Interesting)

          by jd (1658) <imipak.yahoo@com> on Monday June 12 2006, @05:12PM (#15520069) Homepage Journal
          I do believe that this is the correct direction and that OpenCores has a lot of very useful material. There are programs for hardware analysis and design, but you are correct that there's a LOT more to hardware than just that. Even with high-end commercial applications, it is not easy - the software can easily fail to calculate the power loads, for example, leading to both over-hot regions and under-powered sections.


          But calculating these values isn't enough if you're designing anything of high complexity. You then really need CFD software to model how the heat will flow around your design. It's easy to build something that is quite incapable of remaining within temperature limits.


          When building network interfaces, other problems creep in. You have no control over whatever you connect your device to (wirelessly or wired) and so must provide suitable tolerences. You also have potential problems from interference generated from within the device itself. A wireless network card that jams itself is of very little use.


          I'm not saying this is impossible - the University of Manchester uses Open Source tools for designing async microprocessors which are suitable for cell phones, so obviously it's possible. It has been done. The problem is in moving from "possible" to "practical". That is an area that looks interesting and - as programmable computable devices become more powerful - more open to experimentation.


          One of the problems with commodity hardware is that the only reason it is cheap and useful as a commodity is that it is ultra-generalized and therefore inefficient at any given task. As such, it should be very easy to design things which are more specialized and more efficient, even without a multi-billion dollar budget. Most of that budget is going to be in cramming all possible features onto as little silicon as possible without causing a meltdown. Microcomputers were buildable because no individual user really needed the full power of a mainframe. I could easily see the next stage being people designing components and cards that aren't perhaps equal to AMD's or Intel's latest mega-product but which are perfectly good for a special-purpose embedded device.


          Is this likely? I don't see why not. The 65I02 is a popular microcontroller. Yes, that is a more modern 6502 processor, and 6502s are NOT rocket-science. Open Cores is already well past the simple design of a 6502, and probably more than capable of designing fairly decent control systems with Open Source tools alone. Once you get a cottage industry going with Open Source hardware, then more advanced tools will inevitably follow.

      • What would end the argument, Bruce is open-source hardware.

        I take it you mean as in programmable logic? That's not much of a solution either. You still need good documentation, as reverse-engineering VHDL/Verilog code is hard (speaking from experience here).

        What's maybe interesting to note here is that most asian hardware manufacturers are rather open about their hardware documentation, notably ralink and realtek [theaimsgroup.com]. Companies like intel and texas instruments still don't want to cooperate. Something to keep in

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

    by grub (11606) <slashdot@grub.net> on Monday June 12 2006, @03: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, @03: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 :)

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

    by Lumpy (12016) on Monday June 12 2006, @03: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?
    • 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
          • You sure are. You're not allowed to remove their copyright or their list of conditions, but there's nothing in the license that says you can't add more, even ones that negate theirs.

            Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:

            * Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.
            * R

  • Open Secrets (Score:5, Insightful)

    by Doc Ruby (173196) on Monday June 12 2006, @03: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?
    • 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.
        • 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...

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

    by schweini (607711) on Monday June 12 2006, @04: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?

    • I think the problem is that the BSD code may not be considered "clean room" by the Linux people, hence it's "dirty" (not my opinion) and not to be touched. You can probably trace a lot of this obsession to the SCO lawsuit.
      • I think the problem is that the BSD code may not be considered "clean room" by the Linux people, hence it's "dirty" (not my opinion) and not to be touched. You can probably trace a lot of this obsession to the SCO lawsuit.

        But developing Linux drivers with documentation under NDA is popular, though.

          • > Drivers developed under the constraints of an NDA are usually released as blob, no? Not always. There are several drivers in the Linux kernel with docs under NDA. UltraSPARC III support, for instance. Drivers written with docs under a NDA are the open source equivalent of a blob.

    • Re:This seems bogus (Score:4, Interesting)

      by aristotle-dude (626586) on Monday June 12 2006, @03:25PM (#15519316)
      I think it is a combination of laziness and philosophical issues. Linux is being held back by both unfortunately.
    • Yeah, because all the BSDs and Linux have identical kernel interfaces, PCI subsystems, DMA handlers, etc. A simple ./configure; make install is all that separates OpenBSD's kernel from 2.6.15, after all.

      In reality, on the other hand, the reverse engineered drivers can serve as excellent documentation for how the same logic can be implemented in another OS, but that's about as close as it's likely to get.

      • i've taken a large linux driver and gotten it running in free with no
        source changes by defining the linux interfaces as macros and
        inlines. i think the only thing that didn't just fall out was
        the bit-sense of PAGE_MASK.

        i don't see any reason why you couldn't do the same thing in the
        other direction.

All trademarks and copyrights on this page are owned by their respective owners. Comments are owned by the Poster. The Rest © 1997-2009 Geeknet, Inc.