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)