Network Manager should not bring up the mesh automatically.

[jg]

Instead, it must require the user to select a mesh channel.

Similarly, the user may explicitly choose to disconnect from the mesh.

#5143 gives the reason for this change. #5144 documents the firmware change needed #5145 documents the Linux driver change required #5147 documents the UI changes needed.

[marco]

I discussed this with Dan in irc. I'm going to summarize the plan here.

Current automatic logic in NM:

1. use the mesh device, find a server on channel 1, then try channel 6, then 11
2. if that fails, let the infrastructure ethX interface try to connect to a known WiFi? AP
3. if that fails, start looking for XO mesh portals
4. if that fails, just activate the mesh on channel 1

Current manual login in NM (triggered by SetActiveDevice? when the user click on a mesh icon):

1. look for school server on that channel
2. look for an XO portal on that channel
3. standalone mesh on channel 1

The plan is to disable automatic connection altogether and keep the same logic for manual connection. Additionally, once the driver interface allows it, NM will turn the mesh on when it activates the device in stage 1, and turn the mesh off when it deactivates the device.

[gnu]

If clicking on Mesh Circle 6 results in "standalone mesh on channel 1", wouldn't that be a problem?

Better defined new behavior:

• At startup, do nothing by default.
  • If a previous configuration is saved, then attempt to re-establish that configuration.

• When a mesh circle is clicked on:
  • Disassociate with any access point.
  • enable mesh on that channel
  • Look for school server on that channel; if none,
  • Look for XO portal on that channel; if none,
  • Retain a standalone mesh on that channel

• When an access point is clicked on:
  • disable mesh
  • Try to associate to that AP.
  • If that fails, disable normal wireless and mesh.

• When a new "No wireless" icon is clicked on:
  • Disable mesh, disable normal wireless.

This would also fix #1406 (airplane mode). And it would make the inscrutable Network Manager much more straightforward for users. (Except that this doesn't document what happens when a wired Ethernet shows up.)

[marco]

Replying to gnu:

If clicking on Mesh Circle 6 results in "standalone mesh on channel 1", wouldn't that be a problem?

Yeah, I think it should use channel 6.

* When a new "No wireless" icon is clicked on: * Disable mesh, disable normal wireless.

The icon in the mesh view represent objects (access point, activity, buddy), they are not action buttons, so I don't think it would be appropriate there. We plan to add a preference in the control center for this.

[mbletsas]

* When a new "No wireless" icon is clicked on: * Disable mesh, disable normal wireless.

The icon in the mesh view represent objects (access point, activity, buddy), they are not action buttons, so I don't think it would be appropriate there. We plan to add a preference in the control center for this.

Well, yes and no. The current mesh icons don't really represent objects since they do not appear if there is mesh traffic sensed in that channel (the reason that we added the mesh beacons), they always appear and they represent a trigger for an action ("join mesh at channel X").

We have to keep in mind the mesh implementation semantics:

We have two logical interfaces and only one radio. (in the basic case, this changes if we add an external one - let's leave this out at this stage). This means that every time we start one interface at channel X, the other is bound to the same channel.

We are keeping the mesh frame forwarding functionality running all the time (unless we explicitly need to turn it off).

So when we associate with an AP using eth0, we are automatically forwarding mesh frames on the same channel (regardless of whether we use msh0 or not).

If we explicitly start msh0 on a given channel, then we can automatically set eth0 to ad-hoc mode on the same channel (or even associate with an AP in that same channel)

So when we click on an AP, we don't have to disable the mesh, we just move its operation to whatever channel the AP happens to be. If the MPP functionality is enabled we also become a mesh portal for that channel.

If we click on a mesh icon the situation is a bit more complicated. If we are associated with an AP (let's forget the ad-hoc case for now) that's on the same channel with the intended mesh channel, nothing needs to happen at the radio level (we are already operating there anyway), we just need to go through the IP config dance (there is where preferences can play an important role). If it is a different channel, then the association has to stop before we move to the new mesh channel.

[marco]

Replying to mbletsas:

Well, yes and no. The current mesh icons don't really represent objects since they do not appear if there is mesh traffic sensed in that channel (the reason that we added the mesh beacons), they always appear and they represent a trigger for an action ("join mesh at channel X").

It's true that the channel icons are somewhat a special case compared to the other icons the view. Still you have on object "mesh channel X" and an action on it, "join". In fact the icon which represent them is the circle one, as for the access points, and not an join action icon like you would expect on an action button.

[kimquirk]

With recent discussions and thoughts on the WDS workaround, it has been decided that we don't want to disable mesh on start up. So this bug will be closed.