On Wed, Aug 15, 2007 at 12:44:42PM +0200, Johannes Berg wrote: > Agreed as well, the plan for nl80211 was to have the tuple set together. > I quite dislike the idea of this internal "next_mode" state but I > suppose it's the best we have now. I don't linke next_mode either, so if this is combined to a single atomic operation, it would be quite a bit better way to do this. > However, this is the reason David Woodhouse couldn't get his Broadcom > based card to work in B mode, hostapd tried to select a B mode channel > and b43 doesn't offer any since it offers G mode. Should the burden be > on the driver authors here, or should we somehow select a G channel if B > isn't available? I would assume that the quick workaround for this would have been to change the configuration file to use 802.11g instead of the default i802.11b.. Anyway, the design used here does indeed assume that the driver exports all supported mode/channel pairs and in case the hardware card supports 802.11g, the driver would most likely claim support for both 802.11b and 802.11g channels. Adding code for reverting back to 802.11g version would, in theory, be fine for most cases, but it does have some issues.. If I remember correctly, channel 14 may only be used with 802.11b mode in Japan, so the list of 802.11b and 802.11g channels is not the same. In this particular case, though, the workaround of using 802.11g list would not cause a problem (the other direction would potentially have). -- Jouni Malinen PGP id EFC895FA - To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
