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.