APs do not activate on Archer A7's with mesh11sd

I have a few of these Archers that I've flashed using the "rapid deployment" instructions on the mesh11sd docs. They are connecting to one another as mesh nodes but the gateway AP is not working(SSID does not appear and mesh11sd get_ap_data produces blank output)

These devices have two radios, and my understanding is that under the default config one radio will be dedicated to the mesh backbone and the other will be used for the gateway AP.

Here's my config, nothing fancy

uci set mesh11sd.setup.auto_config='1' # Note: This is set to 0 for Confidence Testing

uci set mesh11sd.setup.auto_mesh_id='*****' # This is a secret mesh ID string of your choice.
uci set mesh11sd.setup.mesh_gate_base_ssid='*****' # This is your AP SSID string
uci set mesh11sd.setup.mesh_gate_encryption='1' # This selects the encryption type to use on your AP
uci set mesh11sd.setup.mesh_gate_key='*****' # This is the WiFi code to use when connecting to your AP
uci set mesh11sd.setup.ssid_suffix_enable='0'

uci set mesh11sd.setup.vtun_enable='0' # I think this disables the guest network?

uci commit mesh11sd

# For security, set your root password:
rootpassword="*****"
/bin/passwd root << EOF
$rootpassword
$rootpassword
EOF

Well, frustratingly, they came up after a reboot. So now I have no clue what was wrong, but I guess something needed to be reloaded.

Edit: scratch that. It's only up on the portal node. The other mesh node is not acting as an AP. It should have the same config so I do not know why it's not acting as a gate.

The default is to have APs on both bands, but that should not cause this problem

At first glance this looks ok. I'll go over it:

Yes, but it is worth noting this is not the broadcast meshid, rather it is used as a seed for generating secure keys to be used for encrypting all traffic on the mesh backhaul. The broadcast meshid (similar to an AP's SSID but for mesh nodes) will be a long hex hash, looking something like this:
934c91daf46cfe53c456fdd639257a

This sets AP encryption to 1. From the docs/original config file:

	# Set to 0 (none/owe-transition), 1 (sae, aka wpa3), 2 (sae-mixed, aka wpa2/wpa3), 3 (psk2, aka wpa2)
	# or 4 (Opportunistic Wireless Encryption - owe)

so here you have chosen wpa3 encryption type.

Here you have turned off the ssid suffix. This suffix adds a unique identifier to a common ssid and here you are disabling it. The default is enabled and identifies AP band and mesh node identity, basically so you know what you are connecting to.
When enabled, typically, the ssids you will see will be of the form:
OpenWrt-5g-8ecb
In this example:

  1. OpenWrt is the mesh_gate_base_ssid
  2. 5g is the band ie 5GHz the AP is operating on
  3. 8ecb is the mesh node identifier, usually, or close to, the last 4 hex digits of the node's mac address.

This turns off the vxlan point to multi-point tunnel.
This tunnel is by default used for the "guest" network, so yes you are correct, this in effect does disable the default guest network.

So far, so good.

Well, let's check that.

I assume you have SSH access to the portal node ie the node that has the upstream Internet feed connected to its wan port.

Log in with an SSH terminal session and run the command:
mesh11sd connect

You should get an output listing all the active mesh nodes the portal can see.
Here is what I get on my test mesh network:

root@meshnode-8ecb:~# mesh11sd connect
===========================================================================
 Connect a remote terminal session on a remote meshnode
    Usage: mesh11sd connect [remote_meshnode_macaddress]

 Building node list * * * * * * 

 If the node you are looking for is not in the list - re-run this command.
====================================================================================================================
 The following meshnodes are available for remote connection:
94-83-c4-2e-f9-d1 [ ipaddress: fe80::9683:c4ff:fe2e:f9d1] [ web_ui: https://[fd46:cfe5:34c5:0:9683:c4ff:fe2e:f9d1] ]
e4-95-6e-4a-43-e5 [ ipaddress: fe80::e695:6eff:fe4a:43e5] [ web_ui: https://[fd46:cfe5:34c5:0:e695:6eff:fe4a:43e5] ]
94-83-c4-2c-c5-25 [ ipaddress: fe80::9683:c4ff:fe2c:c525] [ web_ui: https://[fd46:cfe5:34c5:0:9683:c4ff:fe2c:c525] ]
94-83-c4-13-58-bd [ ipaddress: fe80::9683:c4ff:fe13:58bd] [ web_ui: https://[fd46:cfe5:34c5:0:9683:c4ff:fe13:58bd] ]
94-83-c4-5c-2a-52 [ ipaddress: fe80::9683:c4ff:fe5c:2a52] [ web_ui: https://[fd46:cfe5:34c5:0:9683:c4ff:fe5c:2a52] ]
94-83-c4-5c-25-6d [ ipaddress: fe80::9683:c4ff:fe5c:256d] [ web_ui: https://[fd46:cfe5:34c5::c6b] ]
e4-95-6e-42-23-4f [ ipaddress: fe80::e695:6eff:fe42:234f] [ web_ui: https://[fd46:cfe5:34c5:0:e695:6eff:fe42:234f] ]
====================================================================================================================

root@meshnode-8ecb:~# 

You probably won't see the web_ui address part unless you are using the v6-beta version of mesh11sd from Github.

If I wanted to connect to the node 94-83-c4-2e-f9-d1, I would execute the command:
mesh11sd connect 94-83-c4-2e-f9-d1

We want to connect to one of your nodes so we can check what is happening.