OpenBSD Journal

g2k14: Stefan Sperling on wireless drivers

Contributed by jj on from the internet is just a series of airgaps dept.

I spent most of this hackathon looking at problems in wifi drivers.

I wasn't exactly sure in advance which problems I wanted to work on. So I packed a bunch of hardware, including several USB wifi adapters, (rsu(4), 2x run(4), rum(4), urtwn(4), zyd(4)), some miniPCIe cards (an unsupported cousin of urtwn(4) named Realtek 8188CE, unsupported athn(4) AR9485, bwi(4)), two laptops, and an access point. This left me with more than enough toys for a week.
I also brought a pcengines APU board which was given to me by Remi Locherer and mijenix (thanks!). It had arrived in the mail just a day or two before I started travelling. At the hackathon, kirby@ added some miniPCIe cards to my collection, ath(4) AR5424 and ral(4) RT3090.
I assembled the APU together with florian@ and ended up plugging the ath(4) and ral(4) cards into it first.

AR5424 turned out to be a problematic card ("ath0: unable to reset hardware; hal status ..."). This card has never been working, and searching mailing list archives turns up various reports and attempts of fixing the driver. I ended up hacking the driver for about two days, trying out changes based on information found in Linux and FreeBSD, with hints from reyk@. It turns out this is an 11g only card and should start working once ath(4) 11g mode is fixed (another known issue).

I put ath(4) aside for something more fun. Theo told me of a rather frustrating experience at a conference which had two wifi networks, both using the same SSID and the same encryption key, with one using WEP and the other using WPA. As a small step towards better usability, I made information about wifi encryption ciphers available to userland, and based on this changed ifconfig(8) scan to display the type of encryption used by wireless networks.

While testing my scanning changes I managed to make all USB ports on my laptop unusable by plugging in the zyd(4) device. mpi@ helped me track this down to race conditions in zyd(4)'s register i/o implementation which could end up dead-locking USB kernel threads. This took some time since the device occasionally stopped working entirely for mysterious reasons which we ended up blaming on broken hardware. Quite possibly the bug would not have triggered with a properly working device, though.

I also looked into a problem with bwi(4) which I diagnosed about a month ago. The device cannot do DMA to address ranges above 1GB of memory, so it is quite unhappy in my powerbook G4 with 1.5GB of RAM. claudio@ who had fixed a similar problem in bce(4) years ago helped and tedu@ and miod@ very convincingly made clear that all kernel panics and crashes I was experiencing were due to my local bwi(4) changes alone. I could not get this done at the hackathon and ended up doing some more work on it at home. I now have bwi(4) working on my machine and posted a call for testing and is now committed.

I also helped florian@ and henning@ with IPv6-related things and reviewed/tested workq->taskq conversion diffs from blambert@ who finally fixed that nasty duplicate-address prevention hack in nd6_addr_add() I had added some time ago.

The week was very enjoyable and flew by way too fast. I really didn't feel like leaving when the hackathon was over. Many thanks to Mitja for making this event happen!

(Comments are closed)


Comments
  1. By Anonymous Coward (87.179.81.45) anon@ymous.de on

    Any chance of getting Jumbo Frames support for the Realtek RTL8111E chip on the PcEngine APU in 5.6?

    Comments
    1. Comments
      1. By tbert (tbert) on

        > > Any chance of getting Jumbo Frames support for the Realtek RTL8111E chip on the PcEngine APU in 5.6?
        >
        > No.

        Well, let's expand on that a little bit :)

        The 5.6 release process is slated to begin soon, which means that new development will slow down, and a harried crew will fix as many bugs introduced/uncovered as possible prior to the release being cut.

        That said, it's possible that it makes it into 5.6-current (and thus 5.7) at some point, should stsp@ get the necessary hardware and some time to make it work, if the OP is interested in making sure the first part of that happens.

        Comments
        1. By Anonymous Coward (95.211.98.166) none@none.tld on

          > > > Any chance of getting Jumbo Frames support for the Realtek RTL8111E chip on the PcEngine APU in 5.6?
          > >
          > > No.
          >
          > Well, let's expand on that a little bit :)
          >
          > The 5.6 release process is slated to begin soon, which means that new development will slow down, and a harried crew will fix as many bugs introduced/uncovered as possible prior to the release being cut.
          >
          > That said, it's possible that it makes it into 5.6-current (and thus 5.7) at some point, should stsp@ get the necessary hardware and some time to make it work, if the OP is interested in making sure the first part of that happens.

          He already has the hardware: "I also brought a pcengines APU board which was given to me by Remi Locherer and mijenix (thanks!)."

          Guess all he needs is time now ;)

  2. By Anonymous Coward (24.107.32.160) on

    Any word on if the Realtek 8188CE was made to work? If so this would be most splendid news.

    Comments
    1. By josh (37.130.227.133) on

      > Any word on if the Realtek 8188CE was made to work? If so this would be most splendid news.

      would love to hear about that too?

Credits

Copyright © - Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to as well as images and HTML templates were copied from the fabulous original deadly.org with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]