On Wed, May 4, 2011 at 7:42 AM, Felix Fietkau [off-list ref] wrote:

On 2011-05-04 1:57 AM, Javier Cardona wrote:

quoted

Mesh beaconing on ath9k was broken by this commit:

commit 4801416c76a3a355076d6d371c00270dfe332e1c
Author: Ben Greear[off-list ref]
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@agilemesh.com
Signed-off-by: Javier Cardona<redacted>

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