I've lost access to two Zyxel NWA55AXE devices after trying to configure mesh WiFi on them with mesh11sd.
I've followed the OpenWrt user guide to set up the first device as a "dumb AP" and to configure a mesh interface, then installed mesh11sd. Everything seemed to be working, but after setting the auto_config option of mesh11sd to 1 as recommended I lost both web and ssh access to the device and cannot even ping it, neither to its IPv4 nor to its IPv6 address (both assigned with DHCP): the IPv4 address gives Destination Port Unreachable and the IPv6 address Destination unreachable: Address unreachable.
Hoping to regain access using mesh11sd connect from another device, I set up the second NWA55AXE in the same way, this time assigning a static IPv4 address and forcing it into portal mode with the portal_detect option of mesh11sd set to 0, assuming this meant that no layer 3 functionality would be lost. I lost access to this device as well.
The devices aren't seriously "bricked", as I can see the mesh and AP SSIDs being broadcasted (although I can't connect to their WiFi either). Unplugging and replugging does not fix the issue. The devices don't have a reset button (brilliant idea) and I couldn't reset them using the Zyxel recovery tools. I'm hoping there's a way to regain access without resorting to the serial port.
###########################################################################################
# portal_detect (optional)
# Ignored if auto_config is disabled.
#
# Default 1
#
# Possible values:
# 0 - Force Portal mode regardless of an upstream connection.
# 1 - Detect if the meshnode is a portal, meaning it has an upstream wan link.
# If the upstream link is active, the router hosting the meshnode will serve ipv4 dhcp into the mesh network.
# If the upstream link is not connected, dhcp will be disabled and the meshnode will function as a layer 2 bridge on the mesh network.
# 2 - Force peer mode, ignoring any upstream wan connection.
# 3 - Force CPE mode (Customer Premises Equipment)
# This is a peer mode but treats the mesh backhaul as an upstream wan connection.
# A nat routed lan is created with its own ipv4 subnet.
#
# Has no effect if auto_config is disabled.
#
#option portal_detect '0'
A partial manual config working with auto_config is an advanced use case. It is really for people who know what they are doing. If you do not know what you are doing (and have not read the documentation), then you will very likely soft brick unless you are lucky.
With auto_config enabled, you do not have to do ANY configuration. You do not even need to enable the wireless. Everything is handled for you - that is the point.
As @_bernd says, you should be able to ssh into the devices using link local addresses. This is what mesh11sd in auto_config mode uses "under the hood" for the mesh11sd connect and mesh11sd copy commands.
I would recommend using the rapid deployment method in the above link to generate the auto_config image and use scp to copy it to each device and sysupgrade -n (don't save anything).
Feel free to ask for help if you do not understand how to proceed.
While it doesn't work with Ethernet, I managed to connect to the WiFi (assigning an IP address manually to my PC) and got a link-local address matching the MAC written on the back of the NWA55AXE. But I can't use it to connect with ssh: no errors, the ssh command just hangs with no output
Sorry for misunderstanding but I'm new to meshing and found the mesh11sd documentation to be a bit confusing, for example
Switching on Auto Configuration is a simple task and is recommended if you are starting from a basic OpenWrt reflash.
Writing this, and at the very beginning of the guide, is probably a bit misleading: I assumed my configuration was basic enough (the device is an AP and I just configured it as such right after flashing OpenWrt) and thus compatible with auto_config 1.
It is hard, even after reading the full documentation and the relevant parts of the config file as I did, to expect that auto_config 1 will so drastically override basic user configuration (even changing the hostname I believe?). But maybe it's just me not understanding mesh networking well enough.
My mesh is going to consist of three/four NWA55AXEs (one/two wired to a NR7101 5G router) to extend my network over a large area without having to run hundreds of meters of cable (for now), but I don't think Rapid Deployment fits my needs, as it also uses auto_config 1 and I want a more native OpenWrt experience, i.e. all APs should have IPv4/6 addresses to be accessible and configurable with LUCI/SSH the traditional way (I plan to use something like OpenWisp for centralized monitoring/configuration). So it's probably better for me to stick to the basic 802.11s guide and leave mesh11sd in manual configuration mode, possibly experimenting with some parameters manually.
It does not mean starting after making a long list of changes including configuring "dumb ap", lots of wireless config changes and who knows what else.
Sorry, but auto_config means AUTOMATIC CONFIGURATION.
It does not mean configure it yourself then switch to an automatic mode that does not do anything.
Perhaps it is a language problem.
"Starting from basic reflash" could not be any clearer in my mind.
I did use %<source_interface_id> . The problem is the device doesn't even appear in the IPv6 neighbors list normally, it only happened once when connecting to it wirelessly and I haven't been able to replicate this again. Also the wireless connection keeps getting deactivated and re-activated. It all seems very random. Ordered a serial cable...
Automatic configuration, sure... of mesh dynamic parameters and a little more maybe... not of my thermostat...
It's no big deal, I'm happy to learn using the serial port at last. I just believe the effects of auto_config could be better documented, that's it.
Gave fixed IPv4 addresses to both the Ethernet and the wireless interface, in the same network I had configured on the NWA55AXE.
ip -6 addr when connected to the NWA55AXE via Ethernet (PoE splitter LAN port):
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 state UNKNOWN qlen 1000
inet6 ::1/128 scope host noprefixroute
valid_lft forever preferred_lft forever
2: enp3s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
inet6 fe80::f585:8295:df92:a2b3/64 scope link noprefixroute
valid_lft forever preferred_lft forever
ip -6 addr when connected to the wireless interface I had configured on the NWA55AXE (when I don't get disconnected):
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 state UNKNOWN qlen 1000
inet6 ::1/128 scope host noprefixroute
valid_lft forever preferred_lft forever
3: wlo1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 state DOWN qlen 1000
inet6 fe80::3d7e:6e84:65bb:bfd2/64 scope link noprefixroute
valid_lft forever preferred_lft forever
wlo1 state alternates between DOWN and UP .
ip -6 neigh show only twice gave me fe80::bad5:26ff:feff:9176 dev enp3s0 lladdr <NWA55AXE_mac_address> router STALE, otherwise fe80::bad5:26ff:feff:9176 dev enp3s0 FAILED or nothing at all.
By the way, among the wireless networks I see from my PC, there is also the mesh interface I had configured via LUCI on the NWA55AXE. If I try connecting to it I get an error 802-11-wireless.mode: connection does not match access point . And this is the device I had configured with portal_detect 0 I believe.
But are you using network manager or any other GUI? For instance NM gave me a hard time too in the past that's why, in such scenarios, I exclude the Ethernet interface from NM and configure it manually with ip to ensure that the interface is not state changing all the time...
You can also flash the neighbor table to ensure a clean start. It's kinda odd that the router is not responding to LLA...
Yes I'm using Fedora KDE's GUI but it's hard for me to believe that's the issue. And only the wireless interface is state changing, not the Ethernet. I am indeed using sudo ip -6 neigh flush all .
I also tried ping6 ff02::1 from my main OpenWrt router and here ip -6 neigh show gives me fe80::bad5:26ff:feff:9176 dev br.1 used 0/0/0 probes 6 FAILED as the relevant entry, or sometimes fe80::bad5:26ff:feff:9176 dev br.1 ref 1 used 0/0/0 probes 6 INCOMPLETE
If you have not done any manual mesh configuration, mesh11sd will do nothing and wait in the background for you to do so.
Switching on Auto Configuration is a simple task and is recommended if you are starting from a basic OpenWrt reflash.
ie you have not done any configuration after flashing the image.
WARNING: If you have done ANY mesh configuration manually, you might cause a soft-brick condition. Pre-configuring before enabling auto_config is for advanced users only. Make sure you know what you are doing!
No, it is not random. When in auto_config mode there is a watchdog running, checking layer 3 connectivity with a portal router ie one with an upstream connection. If a portal connection cannot me made the watchdog will try various methods to establish a connection, including restarting the mesh, scanning for a mesh backhaul channel change, to eventually giving up and rebooting the node.
If you can share the exact wireless and network configuration changes that you made, we can see if there is a simple way for you to gain access again.
Note, the NWA55AXE has only one ethernet port. Often, the OpenWrt default for hardware such as this will be ethernet on wan and wireless on lan. Is this the case here?
Working as designed. Only a mesh node can join a mesh network. Most up to date "Network Managers" are starting to suppress mesh ids in available networks, for example Android and Apple devices already do.
For wireless AP in both bands I just changed country code, channel, bandwidth, TX power, SSID and added WPA3-SAE encryption and fast roaming support (setting a mobility domain and FT over the air), all via LuCI.
For wireless mesh I added a 802.11s interface on the 5GHz band, giving it an ID, adding WPA3-SAE encryption and binding it to LAN. Then I installed mesh11sd and kmod-nft-bridge; I also gave a name to the mesh interface because mesh11sd status could not display all information without it. All via LuCI.
The two NWA55AXEs were correctly associated and could communicate with each other via mesh when mesh11sd was in manual mode.
