Mesh11sd auto config experts requested

Installing and Using OpenWrt
1

@bluewavenet has been hard at work improving and debugging the mesh11sd package which automates mesh setups in OpenWrt. It took me quite a while to absorb all the instructions to comprehend what exactly the package is doing.

It's primary use is to automatically configure mesh on OpenWrt. However, if you install it as documented, you lose the ability to further configure the router through the luci interface. It assigns an IP different than the default 192.168.1.1 and if you figure out the new IP you can get ssh / command line access at the new IP.

The issue at this point is... what the heck? How do I configure all the other settings on the router? My best guess is to get everything setup up first, then install mesh11sd and start the service. The package takes over everything and maybe that's not such a good thing. I think I can edit the /etc/config/network and /etc/config/wireless - but the mesh11sd creates additional default network and wireless settings in the /etc/config directory. What to do?

I'd like to know if there's a way to use Luci and the mesh11sd package with just a little less automatic configuration activity. I'm trying it on a TP-Link OnHub router that has three radios and I don't want mesh11sd configuring all three radios to mesh. I like to use it as a wired and wireless router normally, but assign one of the radios to mesh and be able to connect multiple mesh access points on separate routers configured to get their internet connection through the mesh to the lan. Main router with mesh and multiple dumb mesh access points.

The old video on YouTube from OneMarcFifty method seems to work better than the auto-config of mesh11sd. And you don't even need meshsd11 for it to work.

DIY WI-FI MESH with OpenWrt

Hoping there's a way to utilize mesh11sd features with a little more control of the router and radios. I especially like the autoconfigure of all the mesh ids and encryption codes. The author said there is a method to use Luci and mesh11sd, but I don't know what that method is, or how to enable or use it.

Any handholding appreciated.

2

Sorry, but what you need to do is read the documentation!
Documentation is hard to write so I do appreciate you might miss some bits, but then that is what forums are about - to ask and hopefully get answers.

First thing first though, if you only have two or possibly three meshnodes you might get away without using mesh11sd. This is how the very outdated video you linked goes about it.
But even with only 2 nodes, mesh11sd has the potential to achieve considerably better performance because it is able to dynamically tune the numerous mesh parameters that in many cases cannot even be set in the wireless config (or in luci).

Yes, but on a full "mesh" population of mesh nodes running OpenWrt.
The population size can vary from 2 up to something like 254, depending on hardware, traffic density, etc. Larger numbers are catered for too, but lets not get into that for now :wink:

The current version of mesh11sd is 5.0.1 at the time of writing and is available on master/snapshot with a pending PR for 24.10 that is stalled due to issues with the build system for 24.10, so hopefully coming soon. The ipk can be downloaded from Github though if you cannot wait.

By default, yes it generates an ipv4 subnet different from the default 192.168.1.1 to prevent clashes with any upstream that might use the same eg your isp router.
But this can be changed by a simple config setting to make mesh11sd use the default 192.168.1.1 See option portal_use_default_ipv4

That is most easily done using ipv6 instead of ipv4. This is simple to do and, yes you guessed it, it is described in detail in the documentation:
Getting the Portal Node ipv6 address

  1. You can do that in the Firmware Selector, best solution for a "rollout" at a particular venue.
  2. Once you have the mesh running, you can enter a "Luci-able" mode and do what ever you like - even break the mesh if you don't know what you are doing. But that is the beauty of using the Firmware selector to make a basic custom image - you can always do a factory reset back to "just flashed state".
    The "Luci-able" mode is enabled with the command mesh11sd commit_all commit

BUT, it should be noted that all the basic wireless options can be set within the mesh11sd config, eg ssid, encryption type, passkey etc. so in many cases you do not need to do anything to other config files or go into Luci, particularly on the remote nodes.

While we are on the subject of remote nodes, mesh11sd collects data on the usage of the remote node access point connections (aka mesh gate connections). This data is stored on the portal node and can be viewed in json format via the command mesh11sd show_ap_data all

It will only use one, defaulting to 2.4GHz (by now you should know where to find how to set the config for this :stuck_out_tongue_winking_eye: )

The problem wit three radios is that, in the pre wifi6+ wifi7 world, only one 5GHz radio can be used in a mesh network due to DFS restrictions - you cannot use a DFS channel for mesh backhaul - the backhaul triggers a DFS false detection.

In addition one of the 5GHz radios is usually a low spec with poor antennas designed for scanning for proprietary non-standard "mesh" devices from the same manufacturer. Not much use for anything in many cases.

That is exactly what the auto_config in mesh11sd does. The one you connect by ethernet to upstream will automatically turn itself into a "Main router with mesh".
All others will turn themselves into mesh connected "dumb" access points.

Of course if you switch on that above mentioned "Luci-able" mode, you disable the bit that allows a node to detect if it has an upstream ethernet, so your portal node will be stuck as a portal node. You can of course switch off "Luci-able" mode if you so desire (yes, see mesh11sd revert_all revert in the docs :slight_smile: )

It is all designed to be very simple, both for the beginner and for the professional doing a large rollout.

There is even a portal bridge mode for cases where you just want to add on a mesh extension to an existing network.

Here is a list of the major features in version 5.0.0 onwards:

  1. Auto configuration of 802.11s mesh backhaul
  2. Optional Bridge Portal mode supporting VLAN trunking over the mesh backhaul.
  3. Optional Trunk Peer Mode providing ethernet downstream VLAN support.
  4. Optional Customer/Client Premises Mode (CPE)
  5. Default support for Opportunistic Wireless Encryption (OWE), with OWE Transition.
  6. Optional portal node to multi point peer group, enabling "guest" networking over mesh backhaul without the need for setting up a VLAN.
  7. Centralised Access Point usage database, enabling connected client statistics to be viewed.

Note: By default, a separate guest type network is provided over the mesh backhaul, without the need for vlans.

The only problem is that people expect it to be hard, using Luci, editing configs etc etc. where in truth it can be very simple.

2 Likes
3

I read the documentation in full and installed it right, it just didn't work the way I expected -- but it worked. I do like some of the details in this message and there's much here that isn't covered in the documentation. I'm just used to tweaking every little thing and fine tuning and adding extra packages and setting up a VPN connection I can turn on and off. I never expected essentially a closed system I can't tweak for other router features. I didn't expect that I'd have to figure everything I wanted set to be done by configuring the firmware precisely in advance.

I'm going to keep trying and I'll try to write up some instructions to help others who might be having trouble. I'm getting to be a tiny bit more advanced than average and I'm certain most users won't figure out what all it does and is supposed to do and how to end up with the mesh system you had in mind when you started.

Setting it up manually, I got the configuration to work the way I wanted, but it was a long process. The low spec 5ghz radio is providing full speed through the mesh, so it's actually fine. That might even be what Google used it for? Don't know.

Also, I'm building firmware from source code and I haven't learned how to incorporate a first run script when doing it that way. I just ran the first run script commands from the command line right after the initial boot up connecting via ssh and Ethernet cable. I'm amazed at what you've done here. I had to unlearn things to figure it all out though.

I'm interested in learning about DFS restrictions - I didn't know that and I just got lucky that the way I configured my router didn't trigger a DFS false detection.

My mesh nodes are just Raspberry Pi's. The built in radio won't work with mesh so I used wifi dongles that I already had for testing and those worked.

I'm going to start my project again and keep in mind everything you've said here and see what happens. Seems like you are truly attempting to think of everything. The project is very ambitious.

2 Likes
4

This is great feedback, it all helps with updating the documentation.

For more in depth discussion you could open a support issue on Github. There you might get other team members popping up and possibly community members as well.
Github mesh11sd issues

Excellent! We can pull it all together and add it to the docs or even a new wiki page. "Mesh Tips and Hints" maybe :smiley:

This link is a good place to start:

See:
Uci Defaults Script

5

Those links to the List of WLAN channels and the Uci Defaults Script were just what I needed. I'm just getting more and more knowledge and details and I'm starting to understand what I'm doing a little better.

One thing I'd change is the example first boot script for clarity:

uci set mesh11sd.setup.auto_config='1'
uci set mesh11sd.setup.auto_mesh_id='MyUniqueMeshID123'
uci set mesh11sd.setup.mesh_gate_base_ssid='MyHomeNetwork'
uci set mesh11sd.setup.mesh_gate_encryption='1'
uci set mesh11sd.setup.mesh_gate_key='MySecurePassword123'
uci commit mesh11sd
uci commit network

# Set root password
rootpassword="myrootpassword"
/bin/passwd root << EOF
$rootpassword
$rootpassword
EOF

Explanation of the variables in the first run script

auto_mesh_id

Purpose: This is used as a seed to generate a unique mesh ID for your network.

Typical Content: A random string of at least 9 characters. This ensures that only nodes with the same mesh ID can join your mesh network.

mesh_gate_base_ssid

Purpose: Sets the base SSID for all Mesh Gate Access Points.

Typical Content: Your desired WiFi network name.

mesh_gate_encryption

Purpose: Determines the encryption type for the mesh gate.

Typical Content: An integer value representing the encryption type:
0: None/OWE Transition
1: SAE (WPA3)
2: SAE-Mixed (WPA2/WPA3)
3: PSK2 (WPA2)
4: Opportunistic Wireless Encryption (OWE)

mesh_gate_key

Purpose: Sets the WiFi password for the mesh gate.

Typical Content: Your desired WiFi password.

Ensure that the auto_mesh_id is the same on all nodes to maintain a cohesive mesh network.

The mesh_gate_base_ssid and mesh_gate_key should be set according to your desired network name and password.

The encryption type (mesh_gate_encryption) should be chosen based on your security requirements and device capabilities.

Then I'd add a little explanation of what happens next:

If you create a firmware with all the extra packages needed and listed in the documentation, when the router boots, it will automatically configure your two antenna router to work normally on all the wired wan and lan ports. By default, the 2Ghz radio will be automatically configured as a mesh backhaul providing wireless lan connectivity to any other AP routers setup identically. The second radio in your router, i.e., the 5 Ghz radio will provide normal wifi using the SSID you specified in the startup script. The configurations takes a few minutes. You won't have access to luci after it boots up.

To add an access point to your mesh network, simply do the same thing on the second or third access point router. Make sure the first router is up and working. The second router upon booting will detect the first mesh router, and automatically configure the 2Ghz radio to connect to the mesh for wireless lan and automatically configure the 5 Ghz radio in the second router to provide wifi using the same SSID as the first router - no wired wan connection required. The lan ports on the second router will work as if they were lan ports on the original router. (It's possible to also configure the wan port as an additional lan port later if you want)

Repeat the process on a third access point, and so on to create your mesh.

Link to Full Documentation

--

I may not have this exactly right, but this is what I got from our back and forth.

6

Getting close :sunglasses:

From the documentation:

	###########################################################################################
	# auto_mesh_id (optional)
	#
	# Configure the mesh_id of the wireless interface(s) when auto_config is enabled
	# Default --__
	#
	# This string will be hashed to produce a secure mesh id
	# If set, it must also be set to the same value on every mesh node
	#
	#option auto_mesh_id 'MyMeshID'

So auto_mesh_id is not the same as the mesh_id seen in the wireless config.
The default auto_mesh_id (two dashes, two underscores) is used as a seed to generate the mesh_id. Using a uci command to look at it:

root@meshnode-8ecb:~# uci get wireless.m11s0.mesh_id
92d490daf46cfe534c56ddd669297e
root@meshnode-8ecb:~#

Similarly, a secure mesh key is generated:

root@meshnode-8ecb:~# uci get wireless.m11s0.key
78c8068012f8481fec118451e1041b3751801a24ab3e222643a0a6a4424b82a1
root@meshnode-8ecb:~#

You can make the key generation even more convoluted (more secure) by configuring auto_mesh_key

	###########################################################################################
	# auto_mesh_key (optional)
	#
	# Defaults to a sha256 key to be automatically used on all members of this mesh when auto_config is enabled
	# Generates a secure sha256 key from the string value set in this option.
	#
	# If set, it must also be set to the same value on every mesh node
	#
	#option auto_mesh_key 'MySecretKey'

Note also, changing auto_mesh_id will result in a different mesh key being generated.
All this automates the generation of mesh id/key pairs, which have to be the same on all mesh nodes on a given backhaul.

Setting ssids and wifi encryption keys.

	###########################################################################################
	# mesh_gate_key (optional)
	# Determines the encryption key for this node's gate.
	#
	# Default: not set (encryption disabled)
	# Set to a secret string value to use for encrypting the node's gate
	# Ignored if mesh_gate_encryption is set to 0 or 4
	#
	# Example - set a key string
	#option mesh_gate_key 'mysecretencryptionkey'

	###########################################################################################
	# mesh_gate_base_ssid
	#
	# Sets the mesh gate base ssid string
	#	If ssid_suffix_enable is set to 0, must be a maximum of 30 characters in length
	#	If ssid_suffix_enable is set to 1, must be a maximum of 22 characters in length
	#	Excess characters will be truncated
	#
	# Default - uses the ssid string set in the wireless config
	#
	#
	# When set, overrides the ssid string set in the wireless config
	#
	# Example:
	#option mesh_gate_base_ssid 'OfficeNetwork'

and

	###########################################################################################
	# vtun_gate_key (optional)
	#
	# Note: All vtun options require the ip-full and vxlan packages to be installed, otherwise the options will be ignored
	#
	# Sets the vxtunnel gate encryption key to be used on node gates (access points) connected to the vxtunnel.
	#	Must be a minimum of 8 characters in length
	#
	# Default: not set
	#
	#option vtun_gate_key 'mysecretkey'

	###########################################################################################
	# vtun_base_ssid (optional)
	#
	# Note: All vtun options require the ip-full and vxlan packages to be installed, otherwise the options will be ignored
	#
	# Sets the vxtunnel base ssid string
	#	If ssid_suffix_enable is set to 0, must be a maximum of 30 characters in length
	#	If ssid_suffix_enable is set to 1, must be a maximum of 22 characters in length
	#	Excess characters will be truncated
	#
	# Default: Guest
	#
	#option vtun_base_ssid 'CustomerNetwork'

Note: If all your devices are the same type eg Rpi in your case, then you only need to make one firmware. Then whichever device has the upstream ethernet will automatically configure itself as a mesh portal ipv4 router - because it detects the upstream connection and changes its mode. The other devices will configure themselves as mesh backhaul connected "dumb aps".

7

Still trying stuff to see what works.

1 Like
8

Don't @ me too much for this... I'm trying to work this out but I'm close to abandoning all hope to get it working. Here's what I'm trying to do. Perhaps you can suggest a strategy.

I have two obsolete OnHub routers, an Asus version, and a TP-Link version.

I want to setup the TP-Link as the router connected to the ISP, and use the Asus as an extension of the TP-Link all using the same subnet. I want Wifi access on radio0 2g with SSID 'example2g' and radio1 SSID 'example5g' and use radio2 as the mesh backhaul to connect the two. Despite all the warnings of limitations and low specs - the radio2 delivers full speed as an AP or a client in my home when I set it up that way. The radio2 can do either 2g or 5g.

I'd like to setup the system the way I want with Luci and the mesh11sd service disabled and no firstboot script in place. I want to start mesh11sd service after I setup radio0 and radio1 on both routers, then invoke the relevant parts of the script from the command line and restart the mesh11sd service with no setup of the radio2 at all and see what mesh11sd auto configures from that point. Or maybe set the auto config to '0' and see what happens. Maybe I need to set some options before restarting the service to make sure it uses 5g as documented?

As some point, I want to be able to turn on and off OpenVPN on the router with the upstream wired Internet connection, and reconfigure the wan port on the access point into a second lan port.

Maybe the mesh is just overcomplicating things and I should just use fast roaming or WDS - or even find the old Android app and revert the OnHubs to Google software and abandon VPN functions in the firmware.

Your patience is probably at an end with me... just writing it all down here for reference.

9

Did this not work?

10

Sorry, but you seem to be going out of your way to make what is a simple task as complicated as you possibly can. @@@ :wink:

If they have 16MB of flash and 128MB ram or more, there should be no problem.

Yup, that is what auto_config does.

The third radio is low spec and is designed purely for scanning for other OnHub devices, not for use as an AP or mesh backhaul. On top of this, the 5GHz band does not have clear channels for two separate radios without using DFS and DFS in not useable for mesh for reasons discussed previously (false detections making the device drop out of the backhaul for minutes at a time).

If you are an advanced user with a lot of knowledge of mesh networking, you can do this, and mesh11sd provides modes to allow it - BUT it is not done by turning auto_config off!

Why? There is no reason to do this and unless you REALLY know what you are doing, this is asking for trouble. Everything "wireless" can be set via the mesh11sd config making the whole process VERY easy.

This is easy too. Once the mesh is running as you want, you tell mesh11sd on the portal (main router) to commit its config to /etc/config files, thus re-enabling Luci.

Your mention of "fast roaming" is very worrying at this stage.
See point 3 in the Footnotes

I hope I am not @ you to much. Technical documentation can be hard to understand when it is something new. It is certainly hard to write.
But I do have some patience because in return I get valuable feedback from all this.

2 Likes
11

I think my failures are all due to the DFS issues which I thought I'd solved. What is mesh11sd going to do with the third radio? (radio2). When that limited radio is used as an AP or a client it gets full speed and doesn't appear to be limited as it seems. I also think you were correct the Google used some proprietary mesh system on that antenna and got around the DFS issues that way. Because of the half-duplex nature of wifi, they could not use either of the main antennas for two purposes. Radio2 can do either 2g or 5g. Maybe it was completely out of band?

I'm starting from scratch on both routers and I can't get it going following the script precisely. How long should the auto config take on the main router? I'm trying to unlearn everything I've learned about OpenWrt to make this work.

12

Seconds for the mesh interface to come up. It can take a couple of minutes for the next mesh node to be seen, depending on many factors.

You don't have to unlearn anything. Mesh11sd does all the hard work of configuring, then does mesh specific things not covered by any conventional config.

It is a normal wireless chip but only has an internal antenna usually. It is NOT used as an AP in the OnHub firmware. It is used passively to scan both 2.4GHz and 5GHz bands for other OnHubs. Usually if you want to scan a band, you have to turn off the AP function while scanning. The OnHub "mesh" is really just a point to point WDS-like system and not a mesh at all.

DFS:

No they didn't. It is used for scanning only, as mentiond above.
If you try to use a DFS channel for an 802.11s mesh, it will invariably "false radar detect" other nodes and shut down the backhaul.

2 Likes
13

I don't think radar detection can be confused with another Wi-Fi network. I guess that's covered.

14

I restored the Google firmware to test and configured it with an old Android app that still works to do this. The Google Mesh is on the 5g band and it's on the same channel as the 5g access point. In my test, both were on channel 149. Can OpenWrt's mesh system do that? Does mesh11SD configure it that way sometimes?

The auto-config just doesn't seem to handle the OnHubs correctly. It does create a wireless network and adds a 5g suffix to the SSID in the startup script, but no connectivity via the regular wireless SSID or wired through the lan port. The Raspberry Pi APs with a supported 5g dongles likewise get a mesh connection which cuts out repeatedly but has some brief connectivity so maybe the DFS issue is happening there too. In my attempts, there is intermittent connectivity through the mesh to the access points. It's just not usable.

I've tried reversing things and use the Raspberry Pi as the main router and the OnHub as the mesh AP, but the single Ethernet on RP is by default a lan port, not a wan port upon startup and I have to configure it to be a wan port, delete the /etc/config/wireless stuff, reboot and run the first run script from the command line but the auto config can't handle that either. No connectivity from the wireless SSID or through the mesh.

My little situation seems hopeless. My hardware is not right for this setup and I'm just going to settle for a WDS access point and WDS clients or just setup relayd/luci-proto-relay which I probably should have done in the first place. Just wanted to learn something new and make the Google hardware work more like it used to.

15

By the "Google mesh", I assume you mean radio 2?
If so this is the passive "scanning" radio used for identifying other OnHubs.

Yes that is a non dfs channel.

Unless otherwise specified, it will use the default channel (36 for HT20, 38 for HT40, 42 for HT80).
Channel 149 is also a non dfs channel in many countries, but not all (149 for HT 20, 151 for HT40, 155 for HT80).
I don't think you have said what country you are in.

In your attempts you seem to be obsessed with using the scanning radio as the mesh interface. Have you tried with the full, unmodified auto_config install?

Why? The "first- boot" script MUST be run automatically as the device "FIRST BOOTS" - hence the name. It MUST run BEFORE any of the network interfaces are brought up. That is the whole point of it.

Please do. Then you can try someone else's patience.

16

I mean the Mesh system Google firmware uses when you're not using OpenWrt. The manufacturer's firmware creates the mesh network on channel 149 AND it creates the 5g wireless network (radio1) on channel 149 too. I can't test to see what radio2 is doing, but you've been right about everything so far, so you're obviously correct here. I do not know if mesh11sd tries to do anything with radio2.

The Raspberry Pi is not compatible with mesh11sd due to hardware limitations the first boot script can't change. I've messed up my Asus OnHub - it won't flash firmware anymore so I'm out of testing options anyway.

My problems are my own fault, not yours. You've helped me a lot and I appreciate the time. Perhaps a hardware compatibility list or minimum router specifications checklist would help others? You probably already did it and I missed it. You are very thorough. Taking on a "I thought of everything" project like this isn't easy. There's always something.

17

Yep. I've F'd up on that too. But... since you can't yet install the 5.0.x version with the firmware selector and have to install it after the fact, that's a hard issue to address for users. Can you write a script to run after you've installed the package? Something that stops the service, zeros all the affected/needed post boot settings, installs the first run script and reboots the router so it runs that first boot script?

18

Install the version available, with auto_config set to 0 so it does not do anything but the config gets set up by the uci defaults.

Then download v5 from Github and install.

Yes it is a pain that backporting is blocked at the moment - hopefully fixed soon.

Download from here:
version 5.0.1

1 Like
19

I'm looking at the bright side. I'm just going to run CAT6 wiring through my crawl space to connect the two routers with wire and do fast roaming.

The Mesh setup is trying my patience too. I can't see too many people using mesh11sd as is. The complete takeover of the router's totality of configuration settings is the deal breaker. The automatic nature of it adds a lot, but it subtracts even more from the OpenWrt experience. You've thrown too much into the kitchen sink.

20

Before @bluewavenet replies with bees in their bonnet, I'll say this:

A 2 node network is just as well served by a WDS link as it by a mesh. Or if you need VLANs, a point-to-point wireless connection of whatever flavour with an IP-IP, GRE, GRETAP, or other tunnel on top with the VLANs on top of that.

Where mesh11sd stands up is within automatically configured, multiple-node (double or more figures) where the wireless APs are pretty well left to do what they're doing. SME, education, corporate networks are perfect examples of where mesh11sd will work and give you the benefits it offers, because the APs there aren't trying to be routers and firewalls and mail and web and VOIP and whatever else servers - they have one job to do, and that's it.

TL;DR: mesh11sd isn't really suited to networks where there's only two nodes, and really not suited to networks where there's only two nodes and the network admin wants everything to be "just as they like it".

3 Likes