So, having not read the mesh11sd documentation, you removed the firewall zones, disabled the dhcp and dns servers, created a lan alias.
Then set an option that requires dhcp/dns servers, firewall zones and a wan connection (forcing portal mode), then wonder why it does not work. Given these devices do not have a reset button, you are going to need that serial interface....
I had read your documentation, I am grateful it exists and that your software does. I haven't read the description of all configuration parameters (haven't done that for most programs I use of course) but of the ones that seemed relevant for a beginner. These are the sections of the documentation where the effects of auto_config 1 are described:
Automatic Configuration
Once auto_config is enabled, the mesh11sd package will autoconfigure mesh interfaces for all radios, leaving only one enabled at ant time.
The default radio will be on 2.4 GHz but can be changed by means of a simple config option.
[...]
Mesh11sd will add required wireless mesh configuration autonomously and it can be viewed using the uci utility but will not be present in the /etc/config/wireless file.
If the mesh network interface is defined in the wireless configuration file, mesh11sd will attempt to use it, but be warned, this may have very unpredictable results and is not normally recommended.
[...]
By simply enabling auto_config, mesh11sd will bring up a working meshnode [...]
Default configuration file (/etc/config/mesh11sd):
[...]
# auto_config (optional)
# Enables autonomous dynamic mesh configuration.
# Auto configure mesh interfaces in the wireless configuration.
# Default 0 (disabled). Set to 1 to enable.[...]
From nowhere here can an average OpenWrt user who's just beginning to understand mesh networking assume that basic things like IP connectivity or hostname are going to be tampered with (I could briefly access one AP via LuCI right after setting auto_config 1 and saw a different hostname). At the same time a beginner is led to think that an automatic configuration is better suited for him/her than a manual one.
I just write this in the hope of preventing other people in my situation from making the same mistake. Maybe the docs are indeed perfect and I'm dumber than the "dumb AP" 
. That's fine, I wouldn't have tried this at all if I wasn't willing to go serial if necessary.
I hope we can at least agree on the fact that the dumb Nobel prize here goes to Zyxel for not putting a stupid reset button on this device and thinking you should have Internet connectivity to Nebula for a reset...
Feedback is always useful.
The user guide now reads like so:
Manual or Auto Configuration:
From version 4.0.0 onwards, the default mode after install is for manual configuration.
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!If the mesh network interface is defined in the wireless configuration file, mesh11sd will attempt to use it, but be warned, this may have very unpredictable results and is not normally recommended.
Yes indeed!
It is possible to enhance the mesh11sd watchdog so that instead of eventually rebooting, it could stop the daemon and go back to pre-startup config. This would add a new setup option "reboot_on_error" that would be disabled by default.... Next release maybe.
If you plan to use OpenWISP, you may find interesting this tutorial for setting up an 802.11s Mesh Network with OpenWISP.
It's not exclusive with the use of mesh11sd, that is, you can also use mesh11sd if you need. If you ever need to update the conf of mesh11sd, you can prepare a configuration template for it.
@nemesis Exactly what I had in mind, thanks.
@bluewavenet By the way, if I am correctly interpreting the OpenWrt mesh Wi-Fi guides, mesh11sd with auto_config 0 is still useful if not necessary (loops, "non-mesh backhaul segments", ...) for the setup I described before, even if AP and mesh interfaces are configured manually. And for any manual mesh11sd configuration I should treat all my APs as "Portal+Gateway nodes", since each one of them "hosts a layer 3 routed upstream connection" and "hosts an access point (AP) radio". I.e. I should have, as a minimum, this configuration:
option mesh_fwding '1'
option mesh_connected_to_as '1' # [if link is up]
option mesh_hwmp_rootmode '4'
option mesh_connected_to_gate '1' # [if it also supports an AP]
option mesh_gate_announcements '1' # [if it also supports an AP]
Correct?
Incorrect unfortunately.
From the detailed documentation, you can see there are various meshnode types:
Meshnode Types:
The mesh can have four types of meshnodes.
- Peer Node - the basic mesh peer - capable of mac-routing layer 2 packets in the mesh network.
- Gateway Node - a peer node that also hosts an access point (AP) radio or ethernet connection for normal client devices to connect to. Also known as a gate. A gate can also function as a CPE (Customer [or Client] Premises Equipment), hosting a downstream layer 3 network with its own unique ipv4/6 subnet.
- Gateway Leech Node - a special type of Gateway Node that connects to the mesh backhaul but neither contributes to it nor advertises itself on it.
- Portal Node - a peer node that also hosts a layer 3 routed upstream connection (eg an Internet feed)
It is possible for a Portal node to also be a Gateway node (ie it hosts an AP as well as an upstream connection.
Mesh parameters will be set according to the meshnode type.
mesh_connected_to_as.mesh_connected_to_gate, ie it says "I am a gateway to another downstream network". It will also actively advertise itself as a gateway by setting mesh_gate_announcements.mesh_hwmp_rootmode set to 0 - The node listens only to HWMP, it does not contribute to the mac-routing other than by sending peer requests to potential neighbours.mesh_hwmp_rootmode set to 1 - Reserved, should not be used.mesh_hwmp_rootmode set to 2 - Same as 0, plus replies to peer requests.mesh_hwmp_rootmode set to 3 - Same as 2, plus also periodically broadcasts its layer 2 mac-routing tables. Gives fast convergence at the expense of potentially generating large volumes of background traffic.mesh_hwmp_rootmode set to 4 - Same as 2, plus sends proactive root announcements. Convergence is a little slower than 3 but generates significantly less background traffic.I hope this makes sense! 
Ok, I misinterpreted the definition of "portal". Then I guess my APs are just "gateway nodes" (but not CPEs) and, as a minimum, I'll configure them as indicated in the config file:
# A Gateway Node: offering both backhaul and downstream infrastructure connectivity
# option mesh_fwding '1'
# option mesh_connected_to_as '0'
# option mesh_hwmp_rootmode '2'
# option mesh_connected_to_gate '1'
# option mesh_gate_announcements '1'
To give more context, this is the network plan (the 4/5G Router may also be part of the mesh, in which case it will be a "portal"):
Other question. Is it beneficial to have a mesh connection between two APs that are also wired via Ethernet? And to have mesh networks on both the 2.4 and the 5 GHz band? In such cases, is mesh11sd (or other software) able to determine in real time what the best path is (e.g. choose 5 GHz for higher speed if signal is strong enough and the band is not too crowded, otherwise fall back to 2.4 GHz)?
Succesfully recovered the devices by entering failsafe mode via serial console and performing a soft-reset.
No, in fact it can cause problems. Mesh11sd will prioritise wireless over cable (configured via mesh_path_cost). In your diagram, it is implied that all mesh nodes can connect to all other mesh nodes, but there is no indication of the distribution of these in three dimensions. This can be very important in an indoor situation.
Microwave propagation can be very non-intuitive.
Indoors, there will be both reflections and diffraction to a high degree giving a very complex "map" of signal strengths in 3D. To make things worse, this map has a very time dependent component, caused by domestic things such as your cat walking up the stairs, opening the refrigerator door etc.. I have said this before elsewhere, there is a reason microwave frequencies are used for radar!
Outdoors these problems are largely insignificant, but beware of the large semi-truck passing by causing dropouts in unexpected places!
In addition, almost all countries do not allow outdoor placements of fixed 5GHz wireless devices unless licenced or permit is obtained.
Also, both indoors and outdoors, 5GHz DFS channels cannot be used for mesh, as mesh is incompatible with DFS.
As far as propagation is concerned, 2.4GHz is far superior to 5GHz, with less reflections/diffraction and larger coverage. The downside is bandwidth, but "Wifi6" devices on HE40 can sustain ~500Mb/s on simple devices, or over 1000Mb/s with high end beamforming radios, so is not so bad after all. In addition HE40 at channel 13 (comes out as centre channel 10) is now legal in most countries:
Generally not a good idea as it causes bridge loops that have to be blocked by mesh11sd, just using up bandwidth and cpu in the meshnodes.
In your diagram, you have cable links to two meshnodes. Either just have one, or have the right hand pair on one mesh id, and the left hand pair on another mesh id (ie two separate mesh backhauls).
Yes it will then be a portal, but this will make the switch redundant.
Thanks, this is very useful.
All APs are outside and there are no obstructions between them. APs 1 and 2 are on top of the same building and very close to each other, APs 3 and 4 are on top of two different, lower buildings, ~50m and ~80m apart from the first one (most likely they won't be able to communicate with each other).
Since 5GHz signal looks strong enough between the two furthest APs and since 2.4GHz is needed for its better penetration to reach clients within the buildings, the idea is to use mainly 5GHz for the mesh (but also for clients). I'll have a look at outdoor, non-DFS 5GHz restrictions in my country but the property is quite large and in the open countryside.
So, as you said, the essential would be two separate, single-band (5GHz) mesh backhauls, one between APs 1-3, one between APs 2-4. I may be over-engineering, but my reasoning for imagining a single, dual-band backhaul involving all APs and possibly the router was:
But from what you say this would come at a performance cost that is probably not worth paying
It is not essential but as 1 and 2 are very close to each other, you could eliminate one if them altogether.
You have a problem with outdoor 5GHz though. In the ETSI region (EU), you only have three 5GHz channels for use outdoors and they are limited to short range/very low power and 40MHz bandwidth (channels 151, 159 and 167). Short range is considered to be a few metres eg in your garden at home, not 50/80 metres.
Really, you would be better off using 2.4GHz, HE40 - channel 1 for one mesh, channel 13 for the other. This will be the same bandwidth as what you have available on 5GHz but with no power restrictions as well as better range.
I need both of them to have good Wi-Fi coverage on both sides of the building (without installing a 10m pole...) so I think it makes sense to use them both for meshing as well.
Not sure about this, NWA55AXE datasheet says 575 Mbps for 2.4GHz and 1200Mbps for 5GHz, but I'll run some tests and compare the two options. Regulations are interesting insofar as one can get guidance from them, but what I'm more interested in is whether I'll be actually bothering someone and whether someone will bother me even if I won't be. Seems very unlikely in my specific situation but I'll do more research to make sure.
I could achieve the desired configuration (wired + dual-band wireless mesh) using BATMAN Advanced, thanks to this OpenWrt guide, this youtube video and... a lot of trial and error.
I have a working setup with one Gateway/AP and two APs, all wired and wirelessly connected to the same mesh, with VLANs too. Wired connections are correctly prioritized, bridge loops are avoided with the bridge_loop_avoidance option (I have also STP enabled but don't know if it's really necessary). I don't know if this is the best setup possible in terms of performance, but it makes a lot of sense for the reasons I gave before and it's working well in a testing setup.
I somehow overlooked BATMAN because it is listed after Mesh11sd in the OpenWrt mesh guides. There may be cases where Mesh11sd should be preferred but, at least for a beginner, BATMAN is probably the way to go because of better integration with UCI/LuCI (thus smaller probability of bricking your device as I did), more features, more extensive documentation and widespread use (I could be wrong).
This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.