Libertas driver needs control for mesh on and off.

[jg]

#5143 documents the need for this change.

Once the firmware supports enabling, disabling the mesh, we need support in the wireless driver for this.

[dwmw2]

I thought we already had that. I have access points which refuse to talk to me when the msh0 interface is alive, and which are fine as long as it's configured down.

We don't actually send mesh packets if the mesh device is logically down, I believe -- and those are what causes the problem, not the beacons... aren't they?

[mbletsas]

David,

In what build do you observe that behavior and with what AP?

M.

[dwmw2]

It's been like that for a long time. With the Buffalo access point which I was using for multicast installation -- last seen in Richard's hands.

[mbletsas]

OK, that takes care things on our side and we don't really have any problems associating with unencrypted lazy-WDS APs (even when the mesh is on).

The big problems start when you have lots of XOs trying to associate with one such AP and become pretty bad when you have multiple XOs and multiple lazy-WDS APs.

M.

[jg]

I can't rate this as a blocker any longer.

But being able to turn off the mesh for debugging strikes me as important hygiene, but isn't on our currently critical path.

[dwmw2]

This now implemented in the upstream driver. There is a lbs_mesh attribute in /sys/class/net/ethX; writing '1' to it will cause the mesh to start and the mshX interface to appear. You can use iwconfig to set the mesh SSID and channel.

The firmware I'm testing with (5.110.21.p21) doesn't seem to include the mesh SSID in its beacons.

[kimquirk]

Fixes to 4470 and WDS are good enough for update1; moving to update2 for mesh on/off feature