David Madore's WebLog: Wifi master mode on the DreamPlug, and why I want to murder someone

Index of all entries / Index de toutes les entréesXML (RSS 1.0) • Recent comments / Commentaires récents

Entry #2021 [older|newer] / Entrée #2021 [précédente|suivante]:

(Saturday)

Wifi master mode on the DreamPlug, and why I want to murder someone

My adventures with the DreamPlug seemed suspiciously undisastrous, so I assumed there was something deeply wrong waiting to pounce on me. Indeed.

To explain what it is, I should first emphasize the following simple point about Wifi: a typical Wifi has two kinds of participants: one is called an access point and operates in master (or access point) mode, and basically controls the network, it could be said to be the Wifi server, whereas all other participants are clients and operate in managed (or station) mode. (This is much simplified, as complex networks can also have repeaters, and there are other kinds of networks such as ad hoc or mesh. But your typical Wifi network is as I just said, with the hotspot being the master and all computers connected to it being managed stations.)

Obviously, since I wish to use my DreamPlug as a Wifi server/switch (among other functions), I need master mode to work[#].

Now the bad news in general is that master mode almost never works under Linux. That is, there are dozens of families of Wifi chipsets around, most of them are said to be well supported by Linux, but that is something of a lie: in reality, they are well supported in client mode only, and almost no drivers support master mode. Basically only the Atheros chipsets work really well (ath5k and ath9k) (this page may give a different impression, but in reality nearly all the drivers having a yes in the master mode column are obsolete, not well integrated in the stock kernel, not supporting the present kernel API, or have some other major flaw about them).

This is something I was well aware of. I had done some research before buying the GuruPlugs and DreamPlugs, however, and believed to have learned that master mode was supported on their Wifi chipsets using a free software Linux driver written by Marvell (uap8xxx) which, although of dubious quality, is probably destined to be included in mainline Linux kernels eventually. I can certainly live with a subpar driver for some time. Also, I don't care much that the driver needs an opaque firmware blob to run[#2].

However, here's something I didn't know, and couldn't have discovered because there's almost no indication of it anywhere on the Web: there are two different Marvell Wifi chipsets found on these GuruPlugs and DreamPlugs: the SD8688 and the SD8787. My GuruPlugs have the former while my DreamPlugs have the latter (however, the distribution may not be along the GuruPlug/DreamPlug line in all cases, I don't know). Support for them in Linux is very different. The (older) SD8688 is supported in Wifi client mode using the libertas driver in stock kernels or a driver from Marvell called sd8xxx (whose source code was released); and it is also supported in master mode using the uap8xxx driver from Marvell (whose source code was also released). This is what I had learned and from which I thought it was safe to conclude I could use the Wifi on my DreamPlugs in master mode. The newer SD8787 is not the same chip, and apparently needs different drivers: it is also supported in client mode on stock kernels, the driver being then called mwifiex; however, this driver does not support master mode (just like nearly all Linux Wifi drivers, as I already pointed out). Merely to understand this fact cost me hours of my time, because I had no idea there were two different chipsets involved, and I was lost in a twisty maze of kernel modules whose functions I could not discern.

But then how can the DreamPlug claim to function as a Wifi access point? Now that's the part that really makes me want to murder someone: Marvell wrote a proprietary driver to support Wifi master mode. And apparently these assholes don't intend to release the source code (it seems they must believe that there's some kind of secret to be kept in the source code of a Wifi driver). Even leaving aside any question as to the desirability of free software in principle, their proprietary driver is hopelessly useless, because it works with exactly one kernel version, and that (very old) kernel version has so many known security holes in it that nobody in their right mind would use it on a computer connected to the Internet. Like, you know, a Wifi access point tends to be. I mean, I hate proprietary drivers, but if you're going to write one, you could at least do it the way nVidia does, providing some interface glue around a binary blob so you're not pinning the kernel to exactly one bloody version, especially, you know, one which is pretty much unusable. Oh, and it happens to be named 2.6.33.7-dirty, probably because dirty is exactly what describes the minds of whoever is responsable for such sheer idiocy.

To add insult to injury (I mean, apart from that insult of the kernel being called dirty), the proprietary driver in question, or at least one component of it, has the same name (sd8xxx) as the free driver they wrote for the other of the two chipsets. This means it is almost impossible to know what people are talking about, and very easy to be misled (as I was) into thinking that the DreamPlug supports master mode.

Now I don't know what hope I can have that the situation will evolve. The mwifiex driver (recall that this supports the SD8787 chipset I have, but only in client mode) is being developed by Marvell, so it's not like having two different versions, one with master mode and one without, were not intentional. I can hope that they'll eventually realize that keeping a fucking Wifi driver secret makes no sense whatsoever, but companies are notoriously bad at understanding their own stupidity. I don't know.

I also don't know how difficult it would be, in principle, to produce a driver which supports master mode from one which does not. My naïve view of things is that all a Wifi hardware driver should have to do is provide two functions, send packet and receive packet (OK, make that three with choose channel), and all the stuff about modes, associations, crypto and whatnot, could be handled (in software) in a generic, device-independent way. I'm aware that this is naïve, there's obviously some hardware support for crypto, possibly other stuff like MAC filtering, association lists, or I don't know what. But I still don't know why the hardware driver has to specifically support master mode rather than just accelerating it. Consequently, I have no idea how difficult it is to write that support, assuming, say, you only get to see the hardware specs necessary to write a driver supporting client mode.

In the mean time, it seems I have paid a couple of hundred bucks for a piece of equipment that is completely useless for what I wanted to do with it. Thanks a lot, Marvell!, I'll try to remember that next time I consider buying anything from you or advising someone about your products.

Update (): I decided the simplest way out of my conundrum was to give up on Marvell's crappy chipset and buy a couple of USB Wifi adapters that are known to work well (even in master mode) under Linux.

[#] Actually I'd like even more: I'd like it to be possible to have several virtual Wifi networks on the same channel and access point, so I could have both an open network and an encrypted one with different filtering rules. This is why I can't just take an embedded Wifi access point and plug it into my network. Along with the fact that embedded Wifi access points don't let you fine tune some of the parameters I'd like to fix, like the beacon rate or the rekey interval for group transient (aka broadcast/multicast) keys. But, hey, basic support for master mode would be a good start.

[#2] Depends on what the blob does, of course, but I don't have the same religious principles as Debian or the FSF on that matter: I'm willing to pretend the firmware is just some large data table or a magic number that needs to be inserted into the device for it to function. As long as the firmware doesn't run on my CPU, and activates all functions of the hardware, say.

↑Entry #2021 [older|newer] / ↑Entrée #2021 [précédente|suivante]

Recent entries / Entrées récentesIndex of all entries / Index de toutes les entrées