haikuware bounty

I've been working on getting WPA encryption to work on Haiku. While I haven't been able to invest as much time as I hoped for before, I made a bit of progress that at least justifies a small status update.

The first part of WPA related work has actually happened while I was working on the network stack for Haiku Inc., as it was not possible to inject packets into the network - while you could easily monitor all incoming packets, there was no mechanism to send packets for arbitrary protocols. I've extended the AF_LINK protocol to be able to deliver that mechanism.

Then I started the actual work on porting wpa_supplicant, the standard tool for allowing WPA/WPA2 encryption almost everywhere. Since we're using the net80211 WLAN stack as part of our FreeBSD driver compatibility layer, a lot of code from the existing BSD driver backend could be used. There are actually only two differences between Haiku, and your favorite BSD for this kind of work:

• ioctl() needs a length parameter that tells the kernel how large the structure passed in is. In BSD this information is encrypted in the control constant, but this is not the case for Haiku. While the BSD way is certainly more convenient, Haiku's solution is safer and more flexible.
• the BSDs are using AF_ROUTE sockets to pass network notifications to the interested user software. In Haiku, we already have a system wide interprocess messaging service, and this is what is therefore used there. The only downside of this approach is that the API is C++ only which is probably something that won't be accepted upstream.

After I had the driver backend ported, the next thing was to implement the level 2 packet support, as the wpa_supplicant needs a way to receive, and send packets outside of the usual protocols. This part is now using the AF_LINK method I described above, although there seems to be a problem left that I need to look into: select() always reports the socket readable. For now, due to the event based implementation of the wpa_supplicant, this is only causing a bit more CPU usage than you would want to have. I am not sure there is anything actually relying on receiving something yet (or if it works, as nothing has been sent or received so far).

Once I had the wpa_supplicant working in theory, more problems surfaced, though, as usual. One is that the FreeBSD driver layer does not receive a few ioctl() calls that need to be forwarded to it in the use case of wpa_supplicant. That one only took a bit of debugging, and I've added a quick hack that forwards the needed calls for now; since I'm not happy with that yet, I haven't committed the changes yet.

A more serious problem was that Colin did an iterative port of the net80211 stack: he added/implemented only the parts that were needed at the time. It seems that WPA needs a bit more parts; so far I've only added the xauth module which allowed me to actually receive node association events from the the stack. After that, it still fails for some reason, but I haven't figured out why.

I will only be able to work a few hours per week in the next weeks, so I hope I'll get something useful done until the deadline is hit. In any case, once I have the wpa_supplicant working, I will commit what I have done so far - since the wpa_supplicant currently needs private Haiku headers, and the changes I'm planning on doing are unlikely to be accepted upstream, I will probably end up adding all of its sources to the Haiku repository. Once I have WPA working, I will continue with extending the existing configuration tools to support WLAN as well. This will also cause further integration of the wpa_supplicant, it will probably end up being an add-on for the net_server.

Screenshot of working WiFi prototype

On the screenshot, you see Firefox surfing www.haiku-os.org and downloading a 100 MiB file from my ftp server in parallel. The terminal is showing the result of the ifconfig command for my WiFi-card.

I managed to port the FreeBSD WiFi-stack, utilizing Haiku's FreeBSD compatibility layer. Thus I could use the WiFi-card driver for my atheros chipset from FreeBSD without any major changes to its codebase (I had to move some interrupt handler code into driver-specific glue code).

The driver-binary has a size of 500 KiB, due to compiling the WiFi-stack into a static library and statically linking it and the FreeBSD compat layer with the driver. Update: The sources are up in the haiku-wifi repository on www.osdrawer.net (read "For the bravery" down the line for more info on how to get it).

I know I have been very quiet for a while in regards to my Haiku WebKit port, but that is because I've been in a long session of coding. I am happy to report that this weekend I finally got WebCore compiling for Haiku:

Link ../../../generated/objects/haiku/x86/release/WebKit/WebCore/libwebcore.so 
Chmod1 ../../../generated/objects/haiku/x86/release/WebKit/WebCore/libwebcore.so 
SetType1 ../../../generated/objects/haiku/x86/release/WebKit/WebCore/libwebcore.so 
MimeSet1 ../../../generated/objects/haiku/x86/release/WebKit/WebCore/libwebcore.so 
SetVersion1 ../../../generated/objects/haiku/x86/release/WebKit/WebCore/libwebcore.so 

So what does this mean? Does it mean the port is now complete? Unfortunately, no it doesn't.

There are still some "stubbed out" classes in the Haiku platform code in WebCore, which means they don't do anything and just exist to make the code compile. Fortunately I have coded a lot of the needed platform files, but the ones which are stubbed out are some of the more complicated ones.

But I am very eager to finally get a simple web launcher running on Haiku to test the port, so I plan to work on this project after work this next week. For those not aware my (self-assigned) deadline for the WebKit Port Bounty on Haikuware is November 15th, which is this next Thursday. I think this deadline was a good motivator so I am glad I have it, but I don't think the port will be rock solid and "complete" by then. Keep in mind that the Qt port of WebKit is also missing a lot and has been worked on by many developers for more than a year. In addition WebKit originally came from KHTML which was a Qt-based HTML engine, so they have another advantage in that the design is Qt-friendly. Even the Windows port which is done by Apple employees who are experts on WebKit is still missing things that the main Mac OS X port has.

I don't say all this as some big excuse. I just want people to realize this is quite a big project and involves my learning the design of WebKit as well as aspects of the Haiku API I am not aware of. Plus as I have discussed before I have had to set up a new cross-compiler environment, port and then build four external libraries WebKit needs (CURL, ICU, SQLite, and libxml2), and write new Jamfiles for JavaScriptCore and WebCore so they can be built with the Haiku build system. I have also added missing features to Haiku that WebKit needed. In the end I think I will be a much better developer after doing all this, but it does involve a lot of work. I expect that once I get over this first hump of the main work for the port, other people will be able (and hopefully willing) to help. I do know at least one Haiku developer who has interest in helping a bit.

So what do I plan to deliver to satisfy the bounty? Well I have started working on "HaikuLauncher", inspired by the QtLauncher, which will be a very basic browser shell to drive the WebKit engine. I would like this to be able to load a web page and render it properly. Beyond that I'm not guaranteeing anything, at least for another few months until I can write a full browser (which is outside the scope of the bounty.)

Given this I hope the folks who contributed to the bounty can feel satisfied that their money was well spent.