On Wed, May 4, 2011 at 7:42 AM, Felix Fietkau <nbd@xxxxxxxxxxx> wrote: > On 2011-05-04 1:57 AM, Javier Cardona wrote: >> >> Mesh beaconing on ath9k was broken by this commit: >> >> commit 4801416c76a3a355076d6d371c00270dfe332e1c >> Author: Ben Greear<greearb@xxxxxxxxxxxxxxx> >> Date: Sat Jan 15 19:13:48 2011 +0000 >> >> This patch assigns the right opmode when the device is used in mesh >> mode. >> >> Reported-by: Fabrice Deyber fabricedeyber@xxxxxxxxxxxxx >> Signed-off-by: Javier Cardona<javier@xxxxxxxxxxx> > > Any idea why exactly ath9k needs to use this opmode? If I understand the > specs correctly, 802.11s does not use distributed beacons like ad-hoc mode, > so theoretically it should be fine with using the AP iftype. > If beacons don't work at all in this opmode for 802.11s then this patch may > just be covering up an underlying bug rather than fixing the real issue. Older versions of the 11s draft let implementers decide whether mesh nodes would beacon in ad-hoc or AP mode. Apparently on ath9k ad-hoc mode was chosen when the earlier mesh draft was implemented. The current version of the draft defines a different beaconing mode specific for mesh. This is very unlikely to change since 11s has already passed sponsor ballot. My suggestion would be to keep using ad-hoc style beaconing in ath9k for mesh and to leave the opmode around for when mesh-specific beaconing is implemented in the driver. But I know little about ath9k. If someone can suggest a better way to "unbreak" mesh beaconing I'll be equally happy. Thanks! Javier -- 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
