David Madore's WebLog: Finally some good news on the DreamPlug/Wifi front

[Index of all entries / Index de toutes les entréesLatest entries / Dernières entréesXML (RSS 1.0) • Recent comments / Commentaires récents]

↓Entry #2025 [older| permalink|newer] / ↓Entrée #2025 [précédente| permalien|suivante] ↓

Finally some good news on the DreamPlug/Wifi front

The story so far: I bought a Marvell DreamPlug in the hope of using it, among other things, as a Wifi access point. The DreamPlug's own Wifi chipset does not work in access point mode, so I bought some Wifi USB dongles with an Atheros AR9271 chipset that reportedly works well under Linux. Which it does, except that I discovered that if the system is rebooted after Wifi driver has been initialized (by loading the kernel modules), then it gets stuck into a mode where it no longer works and the only way to correct this seems to be by physically removing and reinserting the dongle (every other attempt at provoking a USB reset has failed to do anything but perhaps confuse the system).

Well it turns out my analysis was a bit wrong, and the problem isn't as bad as I thought. What causes the dongle to enter this « stuck » state in which it can no longer be used except by unplugging and replugging it is actually if the system is reset after the driver has been initialized (e.g., modprobe ath9k_htc) but before the Wifi interface is activated (e.g., ip link set wlan0 up). Once the interface is activated, even if it is deactivated later on, or if the modules are removed, or even in case of a sudden reboot, whatever, things appear to be fine: trouble only happens if a reboot happens in the window between loading the module and activating the interface. So this is actually very benign: I can make sure I will always activate the interface immediately after loading the modules, and the probability that a reboot will happen just between the two events is almost negligible.

The reason I didn't understand the exact circumstances triggering the bug, of course, is that I made my tests with minimal intervention, i.e., just loading the modules, and I didn't for a second think that activating the Wifi could fix anything. And I have a hard time imagining how that sort of bug could be caused (I guess loading the module does part of the chipset initialization and activating the interface does another part, but why should a reboot create a problem when simply unloading the modules does not?). I still think it's really wrong that this kind of things could happen, it's probably the sign of sloppy writing or general flakiness, but it could also be the hardware that is buggy in various ways (and, of course, tested under a very limited set of conditions, i.e., an Intel-based PC under Windows or Mac OS, definitely not an ARM embedded device). Whether this will ever be fixed is anybody's guess.

Anyway, now I can turn my attention to the software part of the problem, i.e., how I should reconfigure my network to use this DreamPlug thingy as a router.

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

[Index of all entries / Index de toutes les entréesLatest entries / Dernières entréesXML (RSS 1.0) • Recent comments / Commentaires récents]