opennds/mesh11sd

Mesh11sd is a dynamic parameter configuration daemon for 802.11s mesh networks.

1. The openNDS project

openNDS (open Network Demarcation Service) is a high performance, small footprint, Captive Portal.

It provides a border control gateway between a public local area network and the Internet.

It supports all ranges between small stand alone venues through to large mesh networks with multiple portal entry points.

Both the client driven Captive Portal Detection (CPD) method and gateway driven Captive Portal Identification method (CPI - RFC 8910 and RFC 8908) are supported.

In its default configuration, openNDS offers a dynamically generated and adaptive splash page sequence. Internet access is granted by a click to continue button, accepting Terms of Service. A simple option enables input forms for user login.

The package incorporates the FAS API allowing many flexible customisation options.

The creation of sophisticated third party authentication applications is fully supported.

Internet hosted https portals can be implemented with no security errors, to inspire maximum user confidence.

2. Captive Portal Detection (CPD) and Captive Portal Identification (CPI)

2.1 CPD

Captive Portal Detection (CPD) is a client driven process available on all modern mobile devices, most desktop operating systems and most browsers. The CPD process automatically issues a port 80 request on connection to a network as a means of probing for a captive state.

Sometimes known as a "canary test", this process, driven by the client, has evolved over a number of years to be a reliable de-facto standard. openNDS detects this probing and serves a special "splash" web page sequence to the connecting client device.

2.2 CPI - RFC 8910 and RFC 8908

Captive Portal Identification (CPI) is a Gateway driven process as defined in standards RFC8910 (Captive-Portal Identification in DHCP and Router Advertisements) and RFC8908 (Captive Portal API).

A gateway router informs a connecting client that it is in a captive state by providing a url at which a client can access for authentication.

A client may access this url to be served the same portal "splash" page sequence as it would have in the traditional CPD method.

Alternatively, a client may use this url to access the RFC8908 Captive Portal API, ultimately being served a splash page sequence for authentication.

From openNDS v9.5.0, The CPI method is supported in both forms and enabled by default. It can be disabled as a config option.

Note: Very few client devices support CPI at the time of writing (November 2021)

3. Zero Configuration Click to Continue Default

Immediately after installing, a simple three stage dynamic html splash page sequence is served to connecting clients. Client logins are recorded in a log.

• The first page asks the user to accept the portal Terms of Service.
• The second page welcomes the user.
• Depending on the client device CPD implementation, a third page may be displayed. It confirms the user has access to the Internet.

4. Username/Email-address Login Default. (Enabled in the configuration file)

Very similar to the Click to Continue default, this option has an initial "login page" that presents a form to the user where they must enter a name and email address.

5. Data and Data Rate Quotas

Data volume and data rate thresholds are supported without additional dependencies, independently for both upload and download with configurable default values for all clients, or specific values per client.

If a data volume threshold is exceeded the client will be deauthenticated.

If a rate threshold is exceeded, a dynamic bucket filter is used, per client, to limit data rates at a packet level, either limiting rates close to the threshold or by increasing the bucket size at the expense of increased latency.

Third party traffic control packages can also be used, for example to provide system wide rate ceilings, at the same time as the built in thresholds.

6. Customisation

Many methods of customising openNDS exist:

• simple changes to content using basic html and css edits.
• theme specifications allowing full control of look and feel with the option of configuration defined form fields generating dynamic html.
• full third party development where openNDS is used as the "Engine" behind the most sophisticated Captive Portal systems.

6. The Portal

The portal component of openNDS is its Forward Authentication Service (FAS).

FAS provides user validation/authentication in the form of a set of dynamic web pages.

These web pages may be served by openNDS itself, or served by a third party web server. The third party web server may be located remotely on the Internet, on the local area network or on the openNDS router.

The default "Click to continue" and "Username/Email-address Login" options are examples where openNDS serves the splash page sequence itself.

7. Documentation

For full documentation please see https://opennds.rtfd.io/

You can select either Stable, Latest or the historical documentation of older versions.

---

mesh11sd's Issues

kernel 6.6: mesh11d crashes network after 1 minute (from fresh/reset config)

Hi,

As most are already transitioning to kernel 6.6, mesh11d crashes the network upon reset or new config. This has happened on. my rampis devices (reset config). At first I thought it was due to the kernel 6.6 having issue but after updating my test router using a qualcommax/ipq60xx profile, that is when I found what the issue was via UART console.

The issue is triggered with the following scenario:

• Sysupgrade with setting the clear config
• Doing a reset config (Perform Reset in Luci)

Note: WAN is connected to my primary router with internet connection available. LAN1 connected to my compputer.

Things to notices, LAN connection to the router keeps resetting (I can see via my network details in computer, the LAN connection keeps on disconnecting and reconnecting every 5 to 10 seconds). And after a minute, almost disables the network layer and wrecks havocs to the devices that are connected to the eth ports including the WAN port which also somehow temporarily affects my primary router when it happens.

Below is the log coming from my test router

[   16.716438] br-lan: port 1(lan1) entered blocking state
[   16.716482] br-lan: port 1(lan1) entered disabled state
[   16.720526] nss-dp 3a001000.dp1 lan1: entered allmulticast mode
[   16.726042] nss-dp 3a001000.dp1 lan1: entered promiscuous mode
[   16.751408] br-lan: port 2(lan2) entered blocking state
[   16.751463] br-lan: port 2(lan2) entered disabled state
[   16.755608] nss-dp 3a001200.dp2 lan2: entered allmulticast mode
[   16.760923] nss-dp 3a001200.dp2 lan2: entered promiscuous mode
[   16.778006] br-lan: port 3(lan3) entered blocking state
[   16.778055] br-lan: port 3(lan3) entered disabled state
[   16.782178] nss-dp 3a001400.dp3 lan3: entered allmulticast mode
[   16.787542] nss-dp 3a001400.dp3 lan3: entered promiscuous mode
[   16.799948] br-lan: port 4(lan4) entered blocking state
[   16.799998] br-lan: port 4(lan4) entered disabled state
[   16.804317] nss-dp 3a001600.dp4 lan4: entered allmulticast mode
[   16.809809] nss-dp 3a001600.dp4 lan4: entered promiscuous mode
[   19.400942] mtdblock: MTD device 'rootfs' is NAND, please consider using UBI block devices instead.
[   19.810923] nss-dp 3a001000.dp1 lan1: PHY Link up speed: 1000
[   19.811004] br-lan: port 1(lan1) entered blocking state
[   19.815662] br-lan: port 1(lan1) entered forwarding state
[   19.938914] nss-dp 3a001800.dp5 wan: PHY Link up speed: 1000
[   34.227728] br-lan: port 5(phy0-ap0) entered blocking state
[   34.227766] br-lan: port 5(phy0-ap0) entered disabled state
[   34.232169] ath11k c000000.wifi phy0-ap0: entered allmulticast mode
[   34.237953] ath11k c000000.wifi phy0-ap0: entered promiscuous mode
[   34.295299] br-lan: port 6(m-11s-1) entered blocking state
[   34.295354] br-lan: port 6(m-11s-1) entered disabled state
[   34.299865] ath11k c000000.wifi m-11s-1: entered allmulticast mode
[   34.305511] ath11k c000000.wifi m-11s-1: entered promiscuous mode
[   34.311697] br-lan: port 6(m-11s-1) entered blocking state
[   34.317539] br-lan: port 6(m-11s-1) entered forwarding state
[   34.328752] br-lan: port 6(m-11s-1) entered disabled state
[   34.747754] br-lan: port 5(phy0-ap0) entered blocking state
[   34.747810] br-lan: port 5(phy0-ap0) entered forwarding state
[   47.625753] ath11k c000000.wifi m-11s-1: left allmulticast mode
[   47.625815] ath11k c000000.wifi m-11s-1: left promiscuous mode
[   47.630654] br-lan: port 6(m-11s-1) entered disabled state
[   64.900421] br-lan: port 6(phy1-ap0) entered blocking state
[   64.900471] br-lan: port 6(phy1-ap0) entered disabled state
[   64.904969] ath11k c000000.wifi phy1-ap0: entered allmulticast mode
[   64.910721] ath11k c000000.wifi phy1-ap0: entered promiscuous mode
[   64.992798] br-lan: port 6(phy1-ap0) entered blocking state
[   64.992861] br-lan: port 6(phy1-ap0) entered forwarding state
[   84.873352] br-lan: port 4(lan4) entered disabled state
[   84.939648] br-lan: port 2(lan2) entered disabled state
[   85.009121] br-lan: port 3(lan3) entered disabled state
[   85.077916] nss-dp 3a001000.dp1 lan1: PHY Link is down
[   85.078336] br-lan: port 1(lan1) entered disabled state
[   88.162801] nss-dp 3a001000.dp1 lan1: PHY Link up speed: 1000
[   88.162898] br-lan: port 1(lan1) entered blocking state
[   88.167544] br-lan: port 1(lan1) entered forwarding state
[  127.947092] br-lan: port 5(phy0-ap0) entered disabled state
[  127.948603] ath11k c000000.wifi phy0-ap0: left allmulticast mode
[  127.951500] ath11k c000000.wifi phy0-ap0: left promiscuous mode
[  127.957913] br-lan: port 5(phy0-ap0) entered disabled state

Only way to recover is switching to openwrt failover mode and manually disabling mesh11d from starting up. Even if you reset (power off/on), you won't have time to configure via luci or ssh because the connection on the LAN ports are also resetting.

Why mesh_hwmp_rootmode="2" is used instead of 0?

Hi,

Why do you set all non-portal node to mesh_hwmp_rootmode="2" instead of 0?
What are the advantages? For what I understand, any "simple" node should be a no-root node and only one with "service" (internet) should be PROACTIVE_RANN

Thanks,

/**
 * enum ieee80211_root_mode_identifier - root mesh STA mode identifier
 *
 * These attribute are used by dot11MeshHWMPRootMode to set root mesh STA mode
 *
 * @IEEE80211_ROOTMODE_NO_ROOT: the mesh STA is not a root mesh STA (default)
 * @IEEE80211_ROOTMODE_ROOT: the mesh STA is a root mesh STA if greater than
 *  this value
 * @IEEE80211_PROACTIVE_PREQ_NO_PREP: the mesh STA is a root mesh STA supports
 *  the proactive PREQ with proactive PREP subfield set to 0
 * @IEEE80211_PROACTIVE_PREQ_WITH_PREP: the mesh STA is a root mesh STA
 *  supports the proactive PREQ with proactive PREP subfield set to 1
 * @IEEE80211_PROACTIVE_RANN: the mesh STA is a root mesh STA supports
 *  the proactive RANN
 */
enum ieee80211_root_mode_identifier {
    IEEE80211_ROOTMODE_NO_ROOT = 0,
    IEEE80211_ROOTMODE_ROOT = 1,
    IEEE80211_PROACTIVE_PREQ_NO_PREP = 2,
    IEEE80211_PROACTIVE_PREQ_WITH_PREP = 3,
    IEEE80211_PROACTIVE_RANN = 4,
};

Is it not required to update the mesh11s configuration also to wpa_supplicant.conf ?

Mesh11sd takes care of updating the configuration directly to the driver via "iw" utility, is it not required to update them to wpa_supplicant.conf ?
For eg: configuration like, max_peer_links

WPA2/WPA3 Personal (PSK/SAE) mixed mode wrong value

If I set mesh_gate_encryption to "2", mesh11sd sets the encryption to "sae-mixed+aes". This setting does not exist according to the OpenWrt wiki.

A few questions about optimal setup

My home network topology is like this
NanoPi R2S -> Archer C6 AP -> D-Link Repater AP

NanoPi R2S does routing and the Archer and repeater are setup as dumb ap. So for mesh I installed the necessary packages and manually set up the mesh interfaces in luci in both dumb APs.

Then installed mesh11sd and left it in manual configuration mode.

This is the output of mesh11sd status

On main AP Archer C6

root@AP1:~# mesh11sd status
{
  "setup":{
    "version":"4.0.1",
    "enabled":"1",
    "procd_status":"inactive",
    "portal_detect":"1",
    "portal_detect_threshold":"0",
    "portal_channel":"default",
    "channel_tracking_checkinterval":"30",
    "mesh_basename":"m-11s-",
    "auto_config":"0",
    "auto_mesh_network":"lan",
    "auto_mesh_band":"5g",
    "auto_mesh_id":"92d490daf46cfe534c56ddd669297e",
    "mesh_gate_enable":"1",
    "mesh_leechmode_enable":"0",
    "mesh_gate_encryption":"0",
    "txpower":"20",
    "mesh_path_cost":"10",
    "mesh_path_stabilisation":"1",
    "checkinterval":"10",
    "interface_timeout":"10",
    "ssid_suffix_enable":"1",
    "debuglevel":"1"
  },
  "interfaces":{
    "mesh0":{
      "mesh_retry_timeout":"100",
      "mesh_confirm_timeout":"100",
      "mesh_holding_timeout":"100",
      "mesh_max_peer_links":"99",
      "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":"5000",
      "mesh_hwmp_preq_min_interval":"10",
      "mesh_hwmp_net_diameter_traversal_time":"50",
      "mesh_hwmp_rootmode":"0",
      "mesh_hwmp_rann_interval":"5000",
      "mesh_gate_announcements":"0",
      "mesh_fwding":"1",
      "mesh_sync_offset_max_neighor":"50",
      "mesh_rssi_threshold":"-71",
      "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":"0",
      "mesh_connected_to_gate":"0",
      "mesh_nolearn":"0",
      "mesh_connected_to_as":"0",
      "mesh_id":"my-mesh-id",
      "device":"radio1",
      "channel":"36",
      "tx_packets":"329735",
      "tx_bytes":"410895304",
      "rx_packets":"219007",
      "rx_bytes":"195260609",
      "this_node":"Main AP MAC",
      "active_peers":"1",
      "peers":{
        "Repeater mesh MAC":{
          "next_hop":"Repeater MAC",
          "hop_count":"1",
          "path_change_count":"1",
          "metric":"19"
        }
      },
      "active_stations":"4",
      "stations":{
        "xx:xx:xx:xx:xx:xx":{
          "proxy_node":"xx:xx:xx:xx:xx:xx"
        },
        "xx:xx:xx:xx:xx:xx":{
          "proxy_node":"xx:xx:xx:xx:xx:xx"
        },
        "xx:xx:xx:xx:xx:xx":{
          "proxy_node":"xx:xx:xx:xx:xx:xx"
        },
        "xx:xx:xx:xx:xx:xx":{
          "proxy_node":"xx:xx:xx:xx:xx:xx"
        }
      }
    }
  }
}

On Repeater

root@AP2:~# mesh11sd status
{
  "setup":{
    "version":"4.0.1",
    "enabled":"1",
    "procd_status":"running",
    "portal_detect":"1",
    "portal_detect_threshold":"0",
    "portal_channel":"default",
    "channel_tracking_checkinterval":"30",
    "mesh_basename":"m-11s-",
    "auto_config":"0",
    "auto_mesh_network":"lan",
    "auto_mesh_band":"5g",
    "auto_mesh_id":"92d490daf46cfe534c56ddd669297e",
    "mesh_gate_enable":"1",
    "mesh_leechmode_enable":"0",
    "mesh_gate_encryption":"0",
    "txpower":"18",
    "mesh_path_cost":"10",
    "mesh_path_stabilisation":"1",
    "checkinterval":"10",
    "interface_timeout":"10",
    "ssid_suffix_enable":"1",
    "debuglevel":"1"
  },
  "interfaces":{
    "mesh0":{
      "mesh_retry_timeout":"100",
      "mesh_confirm_timeout":"100",
      "mesh_holding_timeout":"100",
      "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":"5000",
      "mesh_hwmp_preq_min_interval":"10",
      "mesh_hwmp_net_diameter_traversal_time":"50",
      "mesh_hwmp_rootmode":"4",
      "mesh_hwmp_rann_interval":"5000",
      "mesh_gate_announcements":"1",
      "mesh_fwding":"1",
      "mesh_sync_offset_max_neighor":"50",
      "mesh_rssi_threshold":"-71",
      "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":"0",
      "mesh_connected_to_gate":"1",
      "mesh_nolearn":"0",
      "mesh_connected_to_as":"0",
      "mesh_id":"my-mesh-id",
      "device":"radio1",
      "channel":"auto",
      "tx_packets":"222645",
      "tx_bytes":"205363737",
      "rx_packets":"333008",
      "rx_bytes":"396905151",
      "this_node":"Repeater mesh MAC",
      "active_peers":"1",
      "peers":{
        "Main AP mesh MAC":{
          "next_hop":"Main AP MAC",
          "hop_count":"1",
          "path_change_count":"1",
          "metric":"120"
        }
      },
      "active_stations":"5",
      "stations":{
        "xx:xx:xx:xx:xx:xx":{
          "proxy_node":"xx:xx:xx:xx:xx:xx"
        },
        "xx:xx:xx:xx:xx:xx":{
          "proxy_node":"xx:xx:xx:xx:xx:xx"
        },
        "xx:xx:xx:xx:xx:xx":{
          "proxy_node":"xx:xx:xx:xx:xx:xx"
        },
        "xx:xx:xx:xx:xx:xx":{
          "proxy_node":"xx:xx:xx:xx:xx:xx"
        },
        "xx:xx:xx:xx:xx:xx":{
          "proxy_node":"xx:xx:xx:xx:xx:xx"
        }
      }
    }
  }
}

I’ve omitted some information for privacy reasons.

This mesh setup is working flawlessly for me, only wanted to confirm if it’s setup the right way.

check_portal always disables dhcp on standard routers

I've just started using mesh11sd 2.0.0 on openwrt and it looks like check_portal never detects a portal (at least on normal routers) so then dhcp is disabled on the router and since this is the default setting it can cause problems for clients on a default install. The master version of script looks like it also might have this problem.

This is caused by the line: wan_ip=$(echo "$default_gw" | awk -F" " '{printf "%s", $7}') which doesn't seem to be correct. Here are two examples where this line fails for the 7th string which then also causes is_portal=$(ip addr | grep "$wan_ip") to end up with an empty string:
default via <the_isp_gw> dev pppoe-wanppp proto static
default dev qmimux0 proto static scope link src <the_wan_ip> metric 1

Changing awk to use the 9th parameter would fix the problem for the second default route example, but for the first default route example, a different method would need to be used to lookup the wan ip.

Is this a bug or do captive portals configure things a bit differently?

mesh11sd spams log on deactivated wifi interfaces

Hi,
i installed mesh11sd on my router which has two wifi devices (5g and 2.4g).
The 2.4g has one mesh defined nothing else. The 5g is deactivated.

The result is that mesh11sd writes all the time in the logs following:

Thu Jun 30 12:27:48 2022 daemon.notice mesh11sd[17048]: wlan1 is not up - giving up for now. Thu Jun 30 12:28:10 2022 daemon.notice mesh11sd[17048]: wlan1 is not up - giving up for now. Thu Jun 30 12:28:32 2022 daemon.notice mesh11sd[17048]: wlan1 is not up - giving up for now. Thu Jun 30 12:28:53 2022 daemon.notice mesh11sd[17048]: wlan1 is not up - giving up for now. Thu Jun 30 12:29:15 2022 daemon.notice mesh11sd[17048]: wlan1 is not up - giving up for now. Thu Jun 30 12:29:36 2022 daemon.notice mesh11sd[17048]: wlan1 is not up - giving up for now.

I would suggest a check of the interfaces if they are a mesh point.
Or some config options which interfaces should get monitored.

Stations but no peers - no `mesh11sd connect` options

Hey!

As a preface, I'll openly admit I'm new to both OpenWrt and mesh systems, and I'm not quite sure if this is more of an OpenWRT or mesh11sd specific issue. Feel free to send me off back to the forums - though I think you'd be the person to respond there either way after reading a lot of the relevant threads.

With that said, I'm setting up an 802.11s mesh with Asus Lyra MAP-AC2200 nodes. Quite old, but seem to work fine and I had a manual config working~, but saw adamant suggestions about using mesh11sd instead. Since then, I've been in hell trying to get something to stabilize. Right now, I've got something that at least connects, when the nodes are sitting next to each other. However, they don't appear to peer (?) correctly, and I'm not quite sure what that means -- something related to HWMP?

This indicates that some configuration is still wrong; and I'm not quite sure why. This is most (maybe?) relevant config from the nodes...

Node 0

node-0  # uci show mesh11sd
mesh11sd.setup=mesh11sd
mesh11sd.setup.auto_mesh_band='5g'
mesh11sd.setup.auto_mesh_id='bbbb'
mesh11sd.setup.auto_mesh_key='aaaa'
mesh11sd.setup.auto_config='1'
mesh11sd.setup.ssid_suffix_enable='0'
mesh11sd.setup.debuglevel='3'

node-0 # mesh11sd status
{
  "setup":{
    "version":"4.0.1",
    "enabled":"1",
    "procd_status":"running",
    "portal_detect":"1",
    "portal_detect_threshold":"0",
    "portal_channel":"default",
    "channel_tracking_checkinterval":"30",
    "mesh_basename":"m-11s-",
    "auto_config":"1",
    "auto_mesh_network":"lan",
    "auto_mesh_band":"5g",
    "auto_mesh_id":"360c5420260e3e90c9c0f07aba7723",
    "mesh_gate_enable":"1",
    "mesh_leechmode_enable":"0",
    "mesh_gate_encryption":"0",
    "txpower":"23",
    "mesh_path_cost":"10",
    "mesh_path_stabilisation":"1",
    "checkinterval":"10",
    "interface_timeout":"10",
    "ssid_suffix_enable":"0",
    "debuglevel":"3"
  },
  "interfaces":{
    "m-11s-0":{
      "mesh_retry_timeout":"100",
      "mesh_confirm_timeout":"100",
      "mesh_holding_timeout":"100",
      "mesh_max_peer_links":"99",
      "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":"5000",
      "mesh_hwmp_preq_min_interval":"10",
      "mesh_hwmp_net_diameter_traversal_time":"50",
      "mesh_hwmp_rootmode":"0",
      "mesh_hwmp_rann_interval":"5000",
      "mesh_gate_announcements":"0",
      "mesh_fwding":"1",
      "mesh_sync_offset_max_neighor":"50",
      "mesh_rssi_threshold":"-65",
      "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":"0",
      "mesh_connected_to_gate":"0",
      "mesh_nolearn":"0",
      "mesh_connected_to_as":"0",
      "mesh_id":"360c5420260e3e90c9c0f07aba7723",
      "device":"radio0",
      "channel":"36",
      "tx_packets":"12",
      "tx_bytes":"1408",
      "rx_packets":"1967",
      "rx_bytes":"149783",
      "this_node":"ba:00:78:20:d1:a2",
      "active_peers":"0",
      "peers":{
      },
      "active_stations":"1",
      "stations":{
        "0e:39:25:70:84:a4":{
          "proxy_node":"82:57:41:5b:3f:b1"
        }
      }
    }
  }
}

node-0 # iw dev
phy#2
        Interface phy2-ap0
                ifindex 31
                wdev 0x200000007
                addr 0e:0a:6e:9a:c1:8e
                ssid AABB2_5G
                type AP
                channel 140 (5700 MHz), width: 80 MHz, center1: 5690 MHz
                txpower 26.00 dBm
                multicast TXQ:
                        qsz-byt qsz-pkt flows   drops   marks   overlmt hashcol tx-bytes        tx-packets
                        0       0       0       0       0       0       0       0               0
phy#1
        Interface phy1-ap0
                ifindex 29
                wdev 0x100000007
                addr 0e:0a:6e:99:c1:8e
                ssid AABB2
                type AP
                channel 11 (2462 MHz), width: 20 MHz, center1: 2462 MHz
                txpower 20.00 dBm
                multicast TXQ:
                        qsz-byt qsz-pkt flows   drops   marks   overlmt hashcol tx-bytes        tx-packets
                        0       0       0       0       0       0       0       0               0
phy#0
        Interface m-11s-0
                ifindex 28
                wdev 0x7
                addr 96:3a:c4:90:ac:9c
                type mesh point
                channel 36 (5180 MHz), width: 80 MHz, center1: 5210 MHz
                txpower 23.00 dBm
                multicast TXQ:
                        qsz-byt qsz-pkt flows   drops   marks   overlmt hashcol tx-bytes        tx-packets
                        0       0       2182    0       0       0       0       205809          2182

node-0 # iw dev m-11s-0 station dump
Station 82:57:41:5b:3f:b1 (on m-11s-0)   -- NOTE: This is node-1
        inactive time:  70 ms
        rx bytes:       4462037
        rx packets:     46231
        tx bytes:       4718
        tx packets:     35
        tx retries:     0
        tx failed:      0
        rx drop misc:   4
        signal:         -21 [-22, -30, -95, -95] dBm
        signal avg:     -21 [-22, -30, -95, -95] dBm
        Toffset:        18446744072275494727 us
        tx bitrate:     6.0 MBit/s
        tx duration:    0 us
        rx bitrate:     6.0 MBit/s
        rx duration:    513500 us
        airtime weight: 256
        mesh llid:      0
        mesh plid:      0
        mesh plink:     ESTAB
        mesh airtime link metric: 8193
        mesh connected to gate: no
        mesh connected to auth server:  no
        mesh local PS mode:     ACTIVE
        mesh peer PS mode:      UNKNOWN
        mesh non-peer PS mode:  ACTIVE
        authorized:     yes
        authenticated:  yes
        associated:     yes
        preamble:       long
        WMM/WME:        yes
        MFP:            yes
        TDLS peer:      no
        DTIM period:    2
        beacon interval:100
        connected time: 2251 seconds
        associated at [boottime]:       2954.318s
        associated at:  1718654597593 ms
        current time:   1718656808135 ms
Station 7a:7d:27:d7:e8:02 (on m-11s-0)
        inactive time:  150620 ms
        rx bytes:       296354
        rx packets:     3100
        tx bytes:       632
        tx packets:     3
        tx retries:     0
        tx failed:      0
        rx drop misc:   151
        signal:         -66 [-73, -67, -95, -95] dBm
        signal avg:     -66 [-73, -67, -95, -95] dBm
        Toffset:        133652100 us
        tx bitrate:     6.0 MBit/s
        tx duration:    0 us
        rx bitrate:     6.0 MBit/s
        rx duration:    26792 us
        airtime weight: 256
        mesh llid:      0
        mesh plid:      0
        mesh plink:     ESTAB
        mesh airtime link metric: 8193
        mesh connected to gate: no
        mesh connected to auth server:  no
        mesh local PS mode:     ACTIVE
        mesh peer PS mode:      UNKNOWN
        mesh non-peer PS mode:  ACTIVE
        authorized:     yes
        authenticated:  yes
        associated:     yes
        preamble:       long
        WMM/WME:        yes
        MFP:            yes
        TDLS peer:      no
        DTIM period:    2
        beacon interval:100
        connected time: 150 seconds
        associated at [boottime]:       5014.117s
        associated at:  1718656657393 ms
        current time:   1718656808136 ms

node-0 # cat /etc/config/wireless

config wifi-device 'radio0'
        option type 'mac80211'
        option path 'soc/40000000.pci/pci0000:00/0000:00:00.0/0000:01:00.0'
        option channel '36'
        option band '5g'
        option htmode 'VHT80'
        option disabled '0'
        option country 'SE'
        option log_level '0'

config wifi-device 'radio1'
        option type 'mac80211'
        option path 'platform/soc/a000000.wifi'
        option channel 'auto'
        option band '2g'
        option htmode 'HT20'
        option disabled '0'
        option country 'SE'
        option log_level '0'

config wifi-iface 'default_radio1'
        option device 'radio1'
        option network 'lan'
        option mode 'ap'
        option ssid 'asdqwe'
        option encryption 'psk2'
        option key 'qweqwe'
        option macaddr '0e:0a:6e:99:c1:8e'
        option disabled '0'

config wifi-device 'radio2'
        option type 'mac80211'
        option path 'platform/soc/a800000.wifi'
        option channel 'auto'
        option band '5g'
        option htmode 'VHT80'
        option disabled '0'
        option country 'SE'
        option log_level '0'

config wifi-iface 'default_radio2'
        option device 'radio2'
        option network 'lan'
        option mode 'ap'
        option ssid 'asdqwe_5G'
        option encryption 'psk2'
        option key 'qweqwe'
        option macaddr '0e:0a:6e:9a:c1:8e'
        option disabled '0'

config wifi-iface 'm11s0'
        option device 'radio0'
        option mode 'mesh'
        option encryption 'sae'
        option mesh_id '360c5420260e3e90c9c0f07aba7723'
        option key '<snip>'
        option network 'lan'
        option ifname 'm-11s-0'
        option mesh_rssi_threshold '-65'
        option disabled '0'
        option macaddr '96:3a:c4:90:ac:9c'

config wifi-iface 'm11s1'
        option device 'radio1'
        option mode 'mesh'
        option encryption 'sae'
        option mesh_id '360c5420260e3e90c9c0f07aba7723'
        option key '<snip>'
        option network 'lan'
        option ifname 'm-11s-1'
        option mesh_rssi_threshold '-65'
        option disabled '1'
        option macaddr '96:3a:c4:90:ac:9c'

config wifi-iface 'm11s2'
        option device 'radio2'
        option mode 'mesh'
        option encryption 'sae'
        option mesh_id '360c5420260e3e90c9c0f07aba7723'
        option key '<snip>'
        option network 'lan'
        option ifname 'm-11s-2'
        option mesh_rssi_threshold '-65'
        option disabled '1'
        option macaddr '96:3a:c4:90:ac:9c'

Node 1

node-1 # uci show mesh11sd
mesh11sd.setup=mesh11sd
mesh11sd.setup.auto_mesh_band='5g'
mesh11sd.setup.auto_mesh_id='bbbb'
mesh11sd.setup.auto_mesh_key='aaaa'
mesh11sd.setup.auto_config='1'
mesh11sd.setup.ssid_suffix_enable='0'
mesh11sd.setup.debuglevel='3'

node-1 {
  "setup":{
    "version":"4.0.1",
    "enabled":"1",
    "procd_status":"running",
    "portal_detect":"1",
    "portal_detect_threshold":"0",
    "portal_channel":"default",
    "channel_tracking_checkinterval":"30",
    "mesh_basename":"m-11s-",
    "auto_config":"1",
    "auto_mesh_network":"lan",
    "auto_mesh_band":"5g",
    "auto_mesh_id":"360c5420260e3e90c9c0f07aba7723",
    "mesh_gate_enable":"1",
    "mesh_leechmode_enable":"0",
    "mesh_gate_encryption":"0",
    "txpower":"23",
    "mesh_path_cost":"10",
    "mesh_path_stabilisation":"1",
    "checkinterval":"10",
    "interface_timeout":"10",
    "ssid_suffix_enable":"0",
    "debuglevel":"3"
  },
  "interfaces":{
    "m-11s-0":{
      "mesh_retry_timeout":"100",
      "mesh_confirm_timeout":"100",
      "mesh_holding_timeout":"100",
      "mesh_max_peer_links":"99",
      "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":"5000",
      "mesh_hwmp_preq_min_interval":"10",
      "mesh_hwmp_net_diameter_traversal_time":"50",
      "mesh_hwmp_rootmode":"0",
      "mesh_hwmp_rann_interval":"5000",
      "mesh_gate_announcements":"0",
      "mesh_fwding":"1",
      "mesh_sync_offset_max_neighor":"50",
      "mesh_rssi_threshold":"-65",
      "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":"0",
      "mesh_connected_to_gate":"0",
      "mesh_nolearn":"0",
      "mesh_connected_to_as":"0",
      "mesh_id":"360c5420260e3e90c9c0f07aba7723",
      "device":"radio0",
      "channel":"36",
      "tx_packets":"2005",
      "tx_bytes":"192985",
      "rx_packets":"0",
      "rx_bytes":"0",
      "this_node":"0e:39:25:70:84:a4",
      "active_peers":"0",
      "peers":{
      },
      "active_stations":"0",
      "stations":{
      }
    }
  }
}

node-1 # iw dev
phy#2
        Interface phy2-ap0
                ifindex 19
                wdev 0x200000004
                addr 0e:39:25:72:84:a4
                ssid AABB2_5G
                type AP
                channel 140 (5700 MHz), width: 80 MHz, center1: 5690 MHz
                txpower 26.00 dBm
                multicast TXQ:
                        qsz-byt qsz-pkt flows   drops   marks   overlmt hashcol tx-bytes        tx-packets
                        0       0       0       0       0       0       0       0               0
phy#1
        Interface phy1-ap0
                ifindex 18
                wdev 0x100000005
                addr 0e:39:25:71:84:a4
                ssid AABB2
                type AP
                channel 11 (2462 MHz), width: 20 MHz, center1: 2462 MHz
                txpower 20.00 dBm
                multicast TXQ:
                        qsz-byt qsz-pkt flows   drops   marks   overlmt hashcol tx-bytes        tx-packets
                        0       0       0       0       0       0       0       0               0
phy#0
        Interface m-11s-0
                ifindex 20
                wdev 0x5
                addr 82:57:41:5b:3f:b1
                type mesh point
                channel 36 (5180 MHz), width: 80 MHz, center1: 5210 MHz
                txpower 23.00 dBm
                multicast TXQ:
                        qsz-byt qsz-pkt flows   drops   marks   overlmt hashcol tx-bytes        tx-packets
                        0       0       2144    0       0       0       0       202827          2144

node-1 # cat /etc/config/wireless

config wifi-device 'radio0'
        option type 'mac80211'
        option path 'soc/40000000.pci/pci0000:00/0000:00:00.0/0000:01:00.0'
        option channel '36'
        option band '5g'
        option htmode 'VHT80'
        option cell_density '0'
        option disabled '0'
        option country 'SE'
        option log_level '0'

config wifi-device 'radio1'
        option type 'mac80211'
        option path 'platform/soc/a000000.wifi'
        option channel 'auto'
        option band '2g'
        option htmode 'HT20'
        option disabled '0'
        option country 'SE'
        option log_level '0'

config wifi-iface 'default_radio1'
        option device 'radio1'
        option network 'lan'
        option mode 'ap'
        option ssid 'asdqwe'
        option encryption 'psk2'
        option disabled '0'
        option key 'asdasd'
        option macaddr '7a:24:1c:80:7a:79'

config wifi-device 'radio2'
        option type 'mac80211'
        option path 'platform/soc/a800000.wifi'
        option channel 'auto'
        option band '5g'
        option htmode 'VHT80'
        option disabled '0'
        option country 'SE'
        option log_level '0'

config wifi-iface 'default_radio2'
        option device 'radio2'
        option network 'lan'
        option mode 'ap'
        option ssid 'asdqwe_5G'
        option encryption 'psk2'
        option disabled '0'
        option key 'asdasd'
        option macaddr '7a:24:1c:81:7a:79'

config wifi-iface 'm11s0'
        option device 'radio0'
        option mode 'mesh'
        option encryption 'sae'
        option mesh_id '360c5420260e3e90c9c0f07aba7723'
        option key '<snip>'
        option network 'lan'
        option ifname 'm-11s-0'
        option mesh_rssi_threshold '-65'
        option disabled '0'
        option macaddr '82:57:41:5b:3f:b1'

config wifi-iface 'm11s1'
        option device 'radio1'
        option mode 'mesh'
        option encryption 'sae'
        option mesh_id '360c5420260e3e90c9c0f07aba7723'
        option key '<snip>'
        option network 'lan'
        option ifname 'm-11s-1'
        option mesh_rssi_threshold '-65'
        option disabled '1'
        option macaddr '82:57:41:5b:3f:b1'

config wifi-iface 'm11s2'
        option device 'radio2'
        option mode 'mesh'
        option encryption 'sae'
        option mesh_id '360c5420260e3e90c9c0f07aba7723'
        option key '<snip>'
        option network 'lan'
        option ifname 'm-11s-2'
        option mesh_rssi_threshold '-65'
        option disabled '1'
        option macaddr '82:57:41:5b:3f:b1'

As far as I can tell from reading the code; having no peers is the reason commands like mesh11sd connect etc do not work. When generating the above status for node-1 it does have a WAN connection, but disconnecting that doesn't fix anything. Not quite sure how to debug this as when I remove the WAN connection on the satellites I can't check config or logs, so I'm stumbling in the dark.

It also seems like if I want to run the mesh portal as an L2 bridge only with my real router, I won't be able to reach the nodes at all, which maybe isn't as much of an issue once things are actually stable. I'm not sure if this is part of the problems I'm having, as I've changed the firewall rules to admin the nodes from the WAN port.

Happy to provide any extra info needed, and test any suggestions!

check_gate and check_portal improvements

I've recently noticed unstabilities and slowdowns in a SOHO mesh envirentment. Then I modified /usr/sban/mesh11sd, and the whole mesh has run for a week with no glitchs. So Here to share what I've found.

All code is from 3.0.0beta, earlier versions may share the same problems.

check_gate() {
  is_gate=$(iw dev | grep -w "type AP")
...
}

Since in practice almost all mesh nodes are APs as well, this line of code seems to lack the best judgement to give value to is_gate. Maybe "ip route" is a better approach. See below.

check_portal() {
...
  proto=$(uci get network.lan.proto)
  default_gw=$(ip route | grep "default via")
  authoritative=$(uci get dhcp.@dnsmasq[0].authoritative 2>/dev/null | awk '{printf "%d", $1}')
  
  if [ -z "$default_gw" ]; then
    is_portal=""
  else
    gw_ip=$(echo "$default_gw" | awk -F" " '{printf "%s", $3}')
    wan_ip=$(echo "$default_gw" | awk -F" " '{printf "%s", $7}')
    is_portal=$(ip addr | grep "$wan_ip")
  fi
...
}

check_portal() has multiple problems.

1. $proto and $gw_ip are never used. Maybe they are leftovers?

2. On a dumb AP, $default_gw is never empty, thus $is_portal is never empty, but $is_portal should be emty on a dumb AP. On one of My dumb AP node:

ip route | grep "default via"
default via 192.168.1.1 dev br-lan

3. Because $default_gw could be something like 'default via 192.168.1.1 dev br-lan', there is no field 7, Thus $wan_ip is always empty, thus $is_portal is the whole output of "ip addr", which is clearly not this code's intention.

So, mesh11sd ver 3.0.0beta fails to detect gate and portal correctly. It sets all dumb AP nodes to gate and portal, renders the whole mesh unstable and unusable.

Here is my temporary remedy:

#proto=$(uci get network.lan.proto)
#default_gw=$(ip route | grep "default via")
#authoritative=$(uci get dhcp.@dnsmasq[0].authoritative 2>/dev/null | awk '{printf "%d", $1}')
#
#if [ -z "$default_gw" ]; then
#  is_portal=""
#else
#  gw_ip=$(echo "$default_gw" | awk -F" " '{printf "%s", $3}')
#  wan_ip=$(echo "$default_gw" | awk -F" " '{printf "%s", $7}')
#  is_portal=$(ip addr | grep "$wan_ip")
#fi

is_portal=''
default_gw=$(ip route | grep -m 1 -F 'default via' | cut -d ' ' -f 5)
# $default_gw is "br-lan" or "pppoe-wan", etc
if [ "$default_gw" != 'br-lan' ]; then
	is_portal='1'
fi

if [ -z "$is_portal" ]; then
  # This IS NOT a layer 3 mesh portal
  uci set mesh11sd.mesh_params.mesh_connected_to_as='0'
  uci set mesh11sd.mesh_params.mesh_connected_to_gate='0'
...
else
  # This IS a layer 3 mesh portal
  uci set mesh11sd.mesh_params.mesh_connected_to_as='1'
  uci set mesh11sd.mesh_params.mesh_connected_to_gate='1'
  
...

#   check_gate
    sleep $checkinterval

I also removed all lines that re-configure network and dnsmasq. They are the things that should not be tempered with lightly. Because dnsmasq may not even be enabled and running on a dumb AP. We must assume it's un-configured and avoid starting it.

For ver 3.0.0beta, also set portal_detect to 1 in file /etc/config/mesh11sd.

Once we modified /usr/sbin/mesh11sd, we stop it and start again. then verify if we are good.
On router:

uci show mesh11sd

mesh11sd.mesh_params.mesh_connected_to_as='1'
mesh11sd.mesh_params.mesh_connected_to_gate='1'

On a mesh node, dumb AP:

uci show mesh11sd

mesh11sd.mesh_params.mesh_connected_to_as='0'
mesh11sd.mesh_params.mesh_connected_to_gate='0'

Now we have a stable mesh.

Suggestions for further improvements:

1. Read mesh_connected_to_as and mesh_connected_to_gate from the config file. If the user set these parameters explicitly, respect them and skip auto-detection.

2. Rewrite code for $is_portal. Consider using my method or more reliable method.

3. If the user demands auto-config, only reconfigure dnsmasq if it's enabled. If it's disabled, only config wireless, but not dnsmasq.

4. If portal_detect is set to 0, the default, in config file, assume the node is non-portal instead of is-portal. Because there are (much) more non-portal nodes than portal nodes. And we can assume a portal is well configured, any necessary parameters are set explicitly, but a non-portal node may use more defaults.

802.11s DFS

Hello my experiments date back several years ago with 802.11s and I stopped that DFS channels could not be used.......Obviously I compiled a version that removed the DFS block which is a drastic and not legal solution. DFS problem fixed? Do radios change frequency when a radar is detected?

Installing mesh11sd 3.1.0 causes router lockup

Steps to reproduce:

1. Install mesh11sd using opkg or the firmware selector for snapshot or 23.05.3 images.
2. If the package was installed from opkg the router freezes immediately. If it was integrated using the firmware selector the router locks up after ~30 seconds from powering up.

Hardware: Dynalink DL-WRX36

Output of logread -f after boot:

root@Node2:~# logread -f
Sat Mar 23 01:10:05 2024 daemon.info dnsmasq[1]: read /etc/hosts - 12 names
Sat Mar 23 01:10:05 2024 daemon.info dnsmasq[1]: read /tmp/hosts/dhcp.cfg01411c - 4 names
Sat Mar 23 01:10:05 2024 daemon.info dnsmasq[1]: read /tmp/hosts/odhcpd - 0 names
Sat Mar 23 01:10:05 2024 daemon.info dnsmasq-dhcp[1]: read /etc/ethers - 0 addresses
Sat Mar 23 01:10:05 2024 daemon.notice mesh11sd[2236]: Setting mac address of mesh interface m-11s-0 to [ a6:97:33:df:ab:bf ]
Sat Mar 23 01:10:05 2024 daemon.notice mesh11sd[2236]: Setting mac address of mesh interface m-11s-1 to [ a6:97:33:df:ab:bf ]
Sat Mar 23 01:10:05 2024 daemon.notice netifd: radio0 (3466): WARNING: Variable 'data' does not exist or is not an array/object
Sat Mar 23 01:10:05 2024 daemon.notice netifd: radio1 (3467): WARNING: Variable 'data' does not exist or is not an array/object
client_loop: send disconnect: Connection reset by peer

uci set mesh11sd.setup.enabled=0 does not stop the mesh11sd daemon

The config enable option present in mesh11sd makes no impact on the mesh11sd daemon.

Expected output:
uci set mesh11sd.setup.enabled=0
uci commit
mesh11sd status
{
"setup":{
"version":"1.2.0",
"enabled":"1",
"service":"Inactive",

Actual output:
uci set mesh11sd.setup.enabled=0
uci commit
mesh11sd status
{
"setup":{
"version":"1.2.0",
"enabled":"1",
"service":"running", ==> This is not right

Multi-hops mesh channel switching

Multi-hops mesh channel switching Is it supported? or is it possible to implement it?

Improving Documentation and better understanding it

Hello,

I've been trying to get mesh11sd working (but all hell breaks loose when I turn it on... the br-lan ridge keeps getting reinitialized)

So here are some "definitions" and what I understand of 802.11s meshes and their mesh nodes

--- = wired connection
s s s = 802.11s mesh connection
ax ac n g b = standard wifi connection

[ ] = optional

 Upstream >>> Portal [Gateway] Node [>>> Downstream]
                    |
                    |         Peer Node     Peer Node    Gateway Node >>> Downstream
                    |s s s s s s s|s s s s s s s|s s s s s s s s|
                    |                           |
                    |         Peer Node         |
                    |s s s s s s s|s s s s s s s|
                                  |
                                  |      Gateway Node >>> Downstream
                                  |s s s s s s s|

Upstream can be:

• [ISP|---][---|Router|---|] on different ip network than mesh (i.e. Non ridged Portal Node that hosts DHCP server for the mesh nodes and their Downstream)]

ISP|---Public ipv4/ipv6---|Portal Node|s s s s s 192.168.3.0/24

Router|--- 192.168.1.0/24---|Portal Node|s s s s s 192.168.2.0/24

• [ISP|---][---|Router|---] on the same ip network and hosting DHCP for the mesh nodes and their downstream (i.e. portal wired to Upstream through its br-lan interface i.e. Bridged Portal Node]

                                  Portal Node (10.0.0.2)
ISP CGNAT (10.0.0.1)|--- 10.0.0.0/24 ---|
                                        |s s s 10.0.0.0/24 s s s

                                     Portal Node (192.168.2.2)
Router (192.168.2.1)|--- 192.168.2.0/24 ---|
                                           |s s s 192.168.2.0/24 s s s

• ?

Downstream can be:

• Wireless Clients or Wired clients|routers on different ip network if Gateway Node is non bridged

s s s|(192.168.1.4) Gateway Node (192.168.2.1)|ax ac n g b 192.168.2.0/24 ax ac n g b|wifi Client (192.168.2.2)
                                              |--- 192.168.2.0/24 ---|(192.168.2.3) wired Client

• Wireless Clients or Wired clients|routers on same ip network if Gateway Node is bridged

             Gateway Node (192.168.2.4)
192.168.2.0/24 s s s|
                    |ax ac n g b 192.168.2.0/24 ax ac n g b|wifi Client (192.168.2.5)
                    |--- 192.168.2.0/24 ---|(192.168.2.6) wired Client

• ?

I've been trying to understand the documentation of the setup section and get the feeling (but maybe I haven't understood in which case the documentation is less dummy proof than I hoped ;-):

• if auto_config=1
  • if portal_detect=1 mesh11sd works for 3 cases:

    1. Non bridged Portal [Gateway] Node (i.e. with internet (or upstream) on wan interface (plugged in wan device) and with br-lan containing a wireless device in 802.11s mode, [a lan device,] [a wireless devices in AP mode]. For portal nodes mesh11sd will set up dhcp v4 server handing out ipv4 to the devices on the mesh (or connected through AP or ethernet cables to the gateway nodes of the mesh

                                                               [|ax ac n g b 192.168.1.0/24 ax ac n g b|Wifi Device (192.168.1.5)]
                                                                |
ISP|---Public ipv4/ipv6---|(public ip) Portal Node (192.168.1.1)|s s s 192.168.1.0/24 s s s|(192.168.1.2) Peer Node
                                                                |s s s 192.168.1.0/24 s s s|(192.168.1.3) Gateway Node
                                                                |
                                                               [|--- 192.168.1.0/24 ---|(192.168.1.4)Ethernet Device]
                                                               [|--- 192.168.1.0/24 ---|(192.168.1.6)Ethernet Device]

    2. Peer Node (i.e. with just a wireless device in 802.11s mode)

                                                  Peer Node (192.168.2.2)    Peer Node (192.168.2.3)
Portal Node (192.168.2.1)| s s s 192.168.2.0/24 s s s |s s s 192.168.2.0/24 s s s|s s s 192.168.2.0/24 s s s|(192.168.2.4) GateWay Node
                                                      |
                                                      |
                                                      | s s s 192.168.2.0/24 s s s |(192.168.2.5) Gateway Node

    3. Bridged Gateway Node (i.e. with a wireless device in AP mode and/or with others devices plugged into its lan device ports and with br-lan interface containing lan device, wireless device in AP mode and wireless device in 802.11s mode)

                                                  Peer Node (192.168.2.2)  GateWay Node (192.168.2.3)
Portal Node (192.168.2.1)| s s s 192.168.2.0/24 s s s |s s s 192.168.2.0/24 s s s|
                         |                                                       |ax ac n g b 192.168.2.0/24 ax ac n g b|(192.168.2.5) wifi client
                         |                                                       |
                         |                    Gateway Node (192.168.2.4)         |--- 192.168.2.0/24 ---|(192.162.2.6) wired Client
                         | s s s 192.168.2.0/24 s s s|
                                                     |ax ac n g b 192.168.2.0/24 ax ac n g b|(192.168.2.5) wifi client
                                                     |
                                                     |--- 192.168.2.0/24 ---|(192.162.2.6) wired Client

• if portal_detect=0 mesh11sd should to handle a Bridged Portal [Gateway] Node (ie. portal node where wan device, lan device and all wirelesss devices are bridged in br-lan interface and all DHCP (v4 or v6) and IPV6 RA is turned off (as in a dumb AP)

                                   Portal Node (192.168.1.2)
Router(192.168.1.1)|--- 192.168.1.0/24---|
                                         |s s s 192.168.1.0/24 s s s|(192.168.1.3) Peer Node
                                         |s s s 192.168.1.0/24 s s s|(192.168.1.4) Gateway Node
                                         |
                                         |ax ac n g b 192.168.1.0/24 ax ac n g b|(192.168.1.5) Wifi Device
                                         |
                                         |--- 192.168.1.0/24 ---|(192.168.1.6)Ethernet Device
                                         |--- 192.168.1.0/24 ---|(192.168.1.7)Ethernet Device

• mesh11sd will use the parameters imposed in its mesh_params configuration file (or their default values)
• if auto_config=0 meshsd will only dynamiccally verify and set the parameters defined in the mesh_params section of the configuration file (or their default values if not defined)

Concerning the mesh_params from reading the openwrt formums and your recommednations/answers to others I've understood that:

• all mesh nodes should have
  • mesh_gate_announcements=1
  • mesh_rssi_threshold seet to something reasonnable (and not 0)
  • mesh_fwding=1
• a Portal [Gateway] Node should have
  • mesh_hwmp_rootmode=4
  • mesh_connected_to_as=1
  • [mesh_connected_to_gate=1]
• a Gateway Node should have
  • mesh_hwmp_rootmode=0
  • mesh_connected_to_gate=1
• a Peer Nodes have
  • mesh_hwmp_rootmode=2

I'm not sure I understand what a root mesh is... is it just a portal

Please feel free to correct my misunderstandings, and if ever I understood things feel free to reuse (my dummy wordings and examples) in the documentation

Now back to my case...
I'm testing 2 Linksys A03 (using non-ct ath10k driver and firmawares (as per the instrucitons) on self built openwrt-25.03 branch (so as to have access to all channels patch that is not in 23.05.3)

• The first as a Bridged Portal Gateway Node, so using
  • auto_config=0
  • portal_detect=0
  • mesh_gate_announcements=1
  • mesh_rssi_threshold=-80
  • mesh_fwding=1
  • mesh_hwmp_rootmode=4
  • mesh_connected_to_as=1
  • mesh_connected_to_gate=1
• The second as a Bridged Gateway Node, so using
  • auto_config=0 [could have used 1 but am staying coherent with the other in terms of auto configuration)
  • portal_detect=1
  • mesh_gate_announcements=1
  • mesh_rssi_threshold=-80
  • mesh_fwding=1
  • mesh_hwmp_rootmode=4
  • mesh_connected_to_gate=1

As soon as I start mesh11sd on any node (including both) the connection keeps going
Seeing disconnects for "reason 55" and the holme bridge being taken down and then brought ack up
Seeing alos messages that nft-bridge module is not installed although it is !!!

Problem with clients acknowledging DHCP addresses

I've previously had a mesh11sd installation working fine - I've since upgraded my images to a later version and installed mesh11sd (4.0.1). However, clients fail to accept a DHCP address, leading to the pool being exhausted.

I'm a bit lost as to why this is happening. Here's the logs - note while anonymised, these are different clients and mac addresses.

Jun 17 10:09:47 fw0 dhcpd[36298]: DHCPOFFER on XXX.XXX.XXX.XXX to XX:XX:XX:XX:XX:XX via vlan210
Jun 17 10:09:48 fw0 dhcpd[36298]: DHCPREQUEST for XXX.XXX.XXX.XXX from XX:XX:XX:XX:XX:XX via vlan210
Jun 17 10:09:48 fw0 dhcpd[36298]: DHCPACK on XXX.XXX.XXX.XXX to XX:XX:XX:XX:XX:XX via vlan210
Jun 17 10:09:53 fw0 dhcpd[36298]: DHCPDECLINE on XXX.XXX.XXX.XXX from XX:XX:XX:XX:XX:XX via vlan210
Jun 17 10:09:53 fw0 dhcpd[36298]: Abandoning IP address XXX.XXX.XXX.XXX for 86400 seconds: declined.
Jun 17 10:10:02 fw0 dhcpd[36298]: DHCPDISCOVER from XX:XX:XX:XX:XX:XX via vlan200
Jun 17 10:10:02 fw0 dhcpd[36298]: DHCPOFFER on XXX.XXX.XXX.XXX to XX:XX:XX:XX:XX:XX via vlan200
Jun 17 10:10:02 fw0 dhcpd[36298]: DHCPREQUEST for XXX.XXX.XXX.XXX from XX:XX:XX:XX:XX:XX via vlan200
Jun 17 10:10:02 fw0 dhcpd[36298]: DHCPACK on XXX.XXX.XXX.XXX to XX:XX:XX:XX:XX:XX via vlan200
Jun 17 10:10:03 fw0 dhcpd[36298]: DHCPDISCOVER from XX:XX:XX:XX:XX:XX via vlan210
Jun 17 10:10:04 fw0 dhcpd[36298]: DHCPOFFER on XXX.XXX.XXX.XXX to XX:XX:XX:XX:XX:XX via vlan210
Jun 17 10:10:05 fw0 dhcpd[36298]: DHCPREQUEST for XXX.XXX.XXX.XXX from XX:XX:XX:XX:XX:XX via vlan210
Jun 17 10:10:05 fw0 dhcpd[36298]: DHCPACK on XXX.XXX.XXX.XXX to XX:XX:XX:XX:XX:XX via vlan210
Jun 17 10:10:10 fw0 dhcpd[36298]: DHCPDECLINE on XXX.XXX.XXX.XXX from XX:XX:XX:XX:XX:XX via vlan210
Jun 17 10:10:10 fw0 dhcpd[36298]: Abandoning IP address XXX.XXX.XXX.XXX for 86400 seconds: declined.
Jun 17 10:10:20 fw0 dhcpd[36298]: DHCPDISCOVER from XX:XX:XX:XX:XX:XX via vlan210
Jun 17 10:10:21 fw0 dhcpd[36298]: DHCPOFFER on XXX.XXX.XXX.XXX to XX:XX:XX:XX:XX:XX via vlan210
Jun 17 10:10:22 fw0 dhcpd[36298]: DHCPREQUEST for XXX.XXX.XXX.XXX from XX:XX:XX:XX:XX:XX via vlan210
Jun 17 10:10:22 fw0 dhcpd[36298]: DHCPACK on XXX.XXX.XXX.XXX to XX:XX:XX:XX:XX:XX via vlan210
Jun 17 10:10:27 fw0 dhcpd[36298]: DHCPDECLINE on XXX.XXX.XXX.XXX from XX:XX:XX:XX:XX:XX via vlan210
Jun 17 10:10:27 fw0 dhcpd[36298]: Abandoning IP address XXX.XXX.XXX.XXX for 86400 seconds: declined.
Jun 17 10:10:37 fw0 dhcpd[36298]: DHCPDISCOVER from XX:XX:XX:XX:XX:XX via vlan210
Jun 17 10:10:38 fw0 dhcpd[36298]: DHCPOFFER on XXX.XXX.XXX.XXX to XX:XX:XX:XX:XX:XX via vlan210
Jun 17 10:10:39 fw0 dhcpd[36298]: DHCPREQUEST for XXX.XXX.XXX.XXX from XX:XX:XX:XX:XX:XX via vlan210
Jun 17 10:10:39 fw0 dhcpd[36298]: DHCPACK on XXX.XXX.XXX.XXX to XX:XX:XX:XX:XX:XX via vlan210
Jun 17 10:10:45 fw0 dhcpd[36298]: DHCPDECLINE on XXX.XXX.XXX.XXX from XX:XX:XX:XX:XX:XX via vlan210
Jun 17 10:10:45 fw0 dhcpd[36298]: Abandoning IP address XXX.XXX.XXX.XXX for 86400 seconds: declined.
Jun 17 10:10:55 fw0 dhcpd[36298]: DHCPDISCOVER from XX:XX:XX:XX:XX:XX via vlan210
Jun 17 10:10:56 fw0 dhcpd[36298]: DHCPOFFER on XXX.XXX.XXX.XXX to XX:XX:XX:XX:XX:XX via vlan210
Jun 17 10:10:57 fw0 dhcpd[36298]: DHCPREQUEST for XXX.XXX.XXX.XXX from XX:XX:XX:XX:XX:XX via vlan210
Jun 17 10:10:57 fw0 dhcpd[36298]: DHCPACK on XXX.XXX.XXX.XXX to XX:XX:XX:XX:XX:XX via vlan210
Jun 17 10:10:59 fw0 dhcpd[36298]: DHCPDECLINE on XXX.XXX.XXX.XXX from XX:XX:XX:XX:XX:XX via vlan210
Jun 17 10:10:59 fw0 dhcpd[36298]: Abandoning IP address XXX.XXX.XXX.XXX for 86400 seconds: declined.

This happens after package installation - without any configuration taking place. Indeed, after upgrading previously (using an already installed mesh11sd configuration) it happened then too. I stripped out all the mesh config, built new images, and started from scratch with the same results.

Any ideas of how to debug this happily accepted!