802.11s operational parameters required to be set after the interface has come up

Installing and Using OpenWrt Network and Wireless Configuration
1

Hi,

I'm trying to understand how 802.11s meshes operate. On the wiki, it's stated that

An 802.11s interface requires numerous operational parameters to be set AFTER the interface has come up and established itself as a part of the mesh.

but mesh11sd deals with a lot of different stuff unrelated to 802.11s, for example, setting up vxlan VPN. It's not clear what is needed for 802.11s and what isn't.

Can anyone say which operational parameters must be set after an 802.11s interface has come up?

Thanks,

rah

2

Most of them.
The default 802.11s support in OpenWrt gives the minimum required for a reliable "wireless extender" functionality ie two nodes.
The default will try to accommodate more nodes but as soon as more than one path is possible ie with 3 or more nodes it rapidly degenerates into mush.

To understand what is going on, there are a few things you need to know:

  1. The 802.11s standard defines a wireless frame type that has bit fields to support a mesh-mac-routing protocol working at network layer 2. This is VERY different to the other usual 802.11x standards that support access points, client-stations, fast roaming etc.
  2. The 802.11s standard also defines the above mentioned mesh-mac-routing protocol. This is called "Hybrid Wireless Mesh Protocol", HWMP. The HWMP layer2 routing tables are a dynamic distributed database of nodes, hops, paths, and path metrics.
  3. Items 1 and 2 above, are built in to the Linux kernel (that includes OpenWrt).
  4. OpenWrt used the Unified Configuration Interface (UCI) for defining its static and non volatile configurations, stored in files stored in flash memory (eg /etc/config/network etc). The default configurations can be changed by using the uci command, by using the Luci GUI, or by editing the config files directly.
  5. When OpenWrt boots, each module or package is set up depending on these static UCI config files.
  6. Most of the 802.11s mesh parameters are potentially dynamic things that can be changed on the fly to manage the operational aspects of the HWMP. These dynamic parameters are applied via the kernel to the already running mesh vif (virtual interface).
    Here is the problem - the content of the uci configuration files is applied by OpenWrt in preparation for starting something, in this case a wireless vif. But the mesh parameters can only be applied AFTER the vif is up and running.
  7. Just to confuse the issue SOME other mesh parameters CAN sometimes be set in the static uci wireless config. In all cases mesh_forwarding and mesh_rssi_threshold can be set here. For SOME wireless drivers, other parameters MAY also be settable here, but there is no documented list I have ever found. The driver must have some built in mechanism built in to apply after the vif is up. The only ones I have seen are in OpenWrt forks using chip manufacturers closed source drivers/APIs, so generally ruled out in mainstream OpenWrt.
  8. To make it work here, you need some mesh management service. The two most common are Mesh11sd (100% pure 802.11s as far as mesh backhaul is concerned) and Batman (very much does its own thing).

I hope this clarifies things for you, but please ask any questions you may have.

Not really, it just does the hard work setting up basic layer 3 for you, be it as a beginner or a professional engineer doing a rollout.

The vxlan part is not a VPN at all. Rather it is a virtual point to multi-point "tunnel" between all participating nodes and provides a virtual ethernet network (think virtual layer 2 switch) capable of supporting anything ethernet can eg VLANs.

For completeness, here is an example snippet from the mesh11sd status command, listing all the instantaneous values of the mesh parameters:

  "mesh_interfaces":{
    "m-11s-0":{
      "mesh_retry_timeout":"255",
      "mesh_confirm_timeout":"255",
      "mesh_holding_timeout":"255",
      "mesh_max_peer_links":"16",
      "mesh_max_retries":"3",
      "mesh_ttl":"31",
      "mesh_element_ttl":"31",
      "mesh_auto_open_plinks":"0",
      "mesh_hwmp_max_preq_retries":"4",
      "mesh_path_refresh_time":"1000",
      "mesh_min_discovery_timeout":"100",
      "mesh_hwmp_active_path_timeout":"1465",
      "mesh_hwmp_preq_min_interval":"586",
      "mesh_hwmp_net_diameter_traversal_time":"50",
      "mesh_hwmp_rootmode":"4",
      "mesh_hwmp_rann_interval":"1953",
      "mesh_gate_announcements":"1",
      "mesh_fwding":"1",
      "mesh_sync_offset_max_neighor":"50",
      "mesh_rssi_threshold":"-68",
      "mesh_hwmp_active_path_to_root_timeout":"6000",
      "mesh_hwmp_root_interval":"5000",
      "mesh_hwmp_confirmation_interval":"2000",
      "mesh_power_mode":"active",
      "mesh_awake_window":"10",
      "mesh_plink_timeout":"500",
      "mesh_connected_to_gate":"1",
      "mesh_nolearn":"0",
      "mesh_connected_to_as":"1",
      "mesh_rts_threshold":"500",
      "mesh_queue_limit":"1000",
      "mesh_ddr_scheduler_quantum":"3000",
      "mesh_airtime_queue_limit":"2000",
1 Like
3

Sorry friend, this is just repeating documentation, it's of no help.

Alas, this is the same hand-waving as in the documentation, which I came here to clarify :slight_smile:

Which as I understand it, is nothing to do with 802.11s. I don't need anything helping me to set up layer 3, I can do that myself. To me, mesh11sd's non-802.11s offerings get in the way and confuse matters. I just want a functional 802.11s mesh that I configure myself. But as you say, it seems Linux can't cope with 802.11s without some userspace daemon to manage it. So in lieu of proper kernel support, ideally what I want is a daemon which does one thing and does it well: 802.11s, nothing else.

Thanks, this is more useful but unfortunately it's not clear (1) whether these are parameters which mesh11sd itself modifies, (2) which of the parameters are required to be set dynamically in order for a mesh to function and (3) what each does.

4

You could try actually reading it and asking specific questions if you do not understand.

It modifies them.

All of them to some degree depending on the conditions in which a node finds itself.

Edit: this is slightly out of date - update coming soon.

Probably because I wrote said documentation.

Turn off all the stuff you do not want (in the mesh11sd config).

5

Please be more polite especially if you get help from maintainers directly.