search

openNDS / mesh11sd

Mesh11sd is a dynamic parameter configuration daemon for 802.11s mesh networks.
GNU General Public License v2.0
28 stars 4 forks source link

Installing mesh11sd 3.1.0 causes router lockup #48

Closed nassoor closed 2 months ago

nassoor commented 2 months ago

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
bluewavenet commented 2 months ago

@nassoor

We can look in detail at what is wrong, but for reference, the up to date documentation is here: https://openwrt.org/docs/guide-user/network/wifi/mesh/mesh11sd

First of all, if the router has locked up, how did you get the logread output?

If you are connected by wifi, you will loose your connection as mesh11sd, by default, appends to the ssid configured in the wireless config. By default this is "OpenWrt". Mesh11sd will append to this giving "OpenWrt-2g-xxxx" where xxxx is the last 4 digits of the mac address.

It will be useful to enable debug logging by doing the following:

service mesh11sd stop
mesh11sd debuglevel 3
uci commit mesh11sd
service mesh11sd start; logread -f
nassoor commented 2 months ago

I appreciate you taking the time to debug with me 🙏

First of all, if the router has locked up, how did you get the logread output?

I got it in the 30 second window I mentioned.

If you are connected by wifi

I used a wired connection while I was narrowing down this issue.

Output of the commands:

root@OpenWrt:~# service mesh11sd start; logread -f
Mon Apr  1 11:38:48 2024 daemon.info mesh11sd[3664]: option enabled [ 1 ]
Mon Apr  1 11:38:48 2024 daemon.info mesh11sd[3664]: option debuglevel [ 3 ]
Mon Apr  1 11:38:48 2024 daemon.info mesh11sd[3664]: option checkinterval [ 10 ]
Mon Apr  1 11:38:48 2024 daemon.info mesh11sd[3664]: option portal_detect [ 1 ]
Mon Apr  1 11:38:48 2024 daemon.info mesh11sd[3664]: option portal_channel [ default ]
Mon Apr  1 11:38:48 2024 daemon.info mesh11sd[3664]: option mesh_path_cost [ 10 ]
Mon Apr  1 11:38:48 2024 daemon.info mesh11sd[3664]: option interface_timeout [ 10 ]
Mon Apr  1 11:38:48 2024 daemon.info mesh11sd[3664]: option auto_config [ 1 ]
Mon Apr  1 11:38:48 2024 daemon.info mesh11sd[3664]: auto_mesh_id hash [ 92d490daf46cfe534c56ddd669297e ]
Mon Apr  1 11:38:48 2024 daemon.info mesh11sd[3664]: option auto_mesh_band [ 2g40 ]
Mon Apr  1 11:38:48 2024 daemon.info mesh11sd[3664]: option auto_mesh_key [ 78c8068012f8481fec118451e1041b3751801a24ab3e222643a0a6a4424b82a1 ]
Mon Apr  1 11:38:48 2024 daemon.info mesh11sd[3664]: option auto_mesh_network [ lan ]
Mon Apr  1 11:38:48 2024 daemon.info mesh11sd[3664]: option auto_mesh_network [ lan ]
Mon Apr  1 11:38:48 2024 daemon.info mesh11sd[3664]: option mesh_basename [ m-11s- ]
Mon Apr  1 11:38:48 2024 daemon.info mesh11sd[3664]: option mesh_gate_enable [ 1 ]
Mon Apr  1 11:38:48 2024 daemon.info mesh11sd[3664]: option ssid_suffix_enable [ 1 ]
Mon Apr  1 11:38:48 2024 daemon.notice mesh11sd[3664]: mesh11sd is in startup
Mon Apr  1 11:38:48 2024 daemon.info mesh11sd[3664]: option mesh_fwding [ 1 ]
Mon Apr  1 11:38:48 2024 daemon.info mesh11sd[3664]: option mesh_rssi_threshold [ -65 ]
Mon Apr  1 11:38:48 2024 daemon.info mesh11sd[3664]: option mesh_gate_announcements [ 1 ]
Mon Apr  1 11:38:48 2024 daemon.info mesh11sd[3664]: option mesh_hwmp_rootmode [ 4 ]
Mon Apr  1 11:38:48 2024 daemon.info mesh11sd[3664]: option mesh_hwmp_rann_interval [ 5000 ]
Mon Apr  1 11:38:48 2024 daemon.info mesh11sd[3664]: option mesh_hwmp_root_interval [ 5000 ]
Mon Apr  1 11:38:48 2024 daemon.info mesh11sd[3664]: option mesh_hwmp_active_path_timeout [ 5000 ]
Mon Apr  1 11:38:48 2024 daemon.info mesh11sd[3664]: option mesh_hwmp_active_path_to_root_timeout [ 6000 ]
Mon Apr  1 11:38:48 2024 daemon.info mesh11sd[3664]: option mesh_max_peer_links [ 16 ]
Mon Apr  1 11:38:49 2024 daemon.notice mesh11sd[3664]: mesh11sd v3.1.0 has started: mesh management mode 1
Mon Apr  1 11:38:49 2024 daemon.info mesh11sd[3664]: No mesh interfaces detected yet.... Attempting auto configure
Mon Apr  1 11:38:49 2024 daemon.debug mesh11sd[3664]: Entering auto config....
Mon Apr  1 11:38:49 2024 daemon.warn mesh11sd[3664]: WARNING - country code not set - interoperability with other mesh nodes may be compromised or fail altogether....
Mon Apr  1 11:38:49 2024 daemon.warn mesh11sd[3664]: WARNING - country code defaulting to [ DFS-ETSI ]....
Mon Apr  1 11:38:49 2024 daemon.warn mesh11sd[3664]: WARNING - country code not set - interoperability with other mesh nodes may be compromised or fail altogether....
Mon Apr  1 11:38:49 2024 daemon.warn mesh11sd[3664]: WARNING - country code defaulting to [ DFS-ETSI ]....
Mon Apr  1 11:38:49 2024 daemon.debug mesh11sd[3664]: In get_portal_state. firstloop=1...
Mon Apr  1 11:38:49 2024 daemon.debug mesh11sd[3664]: In Startup - portal upstream link check - iteration [ 1 ] ....
Mon Apr  1 11:38:50 2024 daemon.debug mesh11sd[3664]: In Startup - portal upstream link check - iteration [ 2 ] ....
Mon Apr  1 11:38:51 2024 daemon.debug mesh11sd[3664]: In Startup - portal upstream link check - iteration [ 3 ] ....
Mon Apr  1 11:38:52 2024 daemon.debug mesh11sd[3664]: In Startup - portal upstream link check - iteration [ 4 ] ....
Mon Apr  1 11:38:53 2024 daemon.debug mesh11sd[3664]: In Startup - portal upstream link check - iteration [ 5 ] ....
Mon Apr  1 11:38:54 2024 daemon.debug mesh11sd[3664]: In Startup - portal upstream link check - iteration [ 6 ] ....
Mon Apr  1 11:38:55 2024 daemon.debug mesh11sd[3664]: In Startup - portal upstream link check - iteration [ 7 ] ....
Mon Apr  1 11:38:56 2024 daemon.debug mesh11sd[3664]: In Startup - portal upstream link check - iteration [ 8 ] ....
Mon Apr  1 11:38:57 2024 daemon.debug mesh11sd[3664]: In Startup - portal upstream link check - iteration [ 9 ] ....
Mon Apr  1 11:38:58 2024 daemon.debug mesh11sd[3664]: In Startup - portal upstream link check - iteration [ 10 ] ....
Mon Apr  1 11:38:59 2024 daemon.debug mesh11sd[3664]: default_gw=....
Mon Apr  1 11:38:59 2024 daemon.debug mesh11sd[3664]: leaving get_portal_state - is_portal=.. gwstatus=.. gw_ip=..
Mon Apr  1 11:38:59 2024 daemon.debug mesh11sd[3664]: auto config complete....
Mon Apr  1 11:38:59 2024 daemon.notice mesh11sd[3664]: Setting mac address of mesh interface m-11s-0 to [ a6:97:33:df:ab:bf ]
Mon Apr  1 11:38:59 2024 daemon.notice mesh11sd[3664]: Setting mac address of mesh interface m-11s-1 to [ a6:97:33:df:ab:bf ]
Mon Apr  1 11:38:59 2024 daemon.debug mesh11sd[3664]: Disconnecting nodes
Mon Apr  1 11:38:59 2024 daemon.notice netifd: radio1 (4260): WARNING: Variable 'data' does not exist or is not an array/object
Mon Apr  1 11:38:59 2024 daemon.notice netifd: radio0 (4259): WARNING: Variable 'data' does not exist or is not an array/object
Mon Apr  1 11:38:59 2024 daemon.debug mesh11sd[3664]: Entering check portal.... lan
Mon Apr  1 11:38:59 2024 daemon.debug mesh11sd[3664]: In get_portal_state. firstloop=0...
Mon Apr  1 11:38:59 2024 daemon.debug mesh11sd[3664]: default_gw=....
Mon Apr  1 11:38:59 2024 daemon.debug mesh11sd[3664]: leaving get_portal_state - is_portal=.. gwstatus=.. gw_ip=..
client_loop: send disconnect: Connection reset by peer

This is on a fresh flash with these packages: ath11k-firmware-ipq8074 base-files busybox ca-bundle dnsmasq dropbear e2fsprogs firewall4 fstools ipq-wifi-dynalink_dl-wrx36 kmod-ath11k-ahb kmod-fs-ext4 kmod-gpio-button-hotplug kmod-leds-gpio kmod-nft-offload kmod-phy-aquantia kmod-qca-nss-dp kmod-usb-dwc3 kmod-usb-dwc3-qcom kmod-usb3 libc libgcc libustream-mbedtls logd losetup luci luci-ssl mtd netifd nftables odhcp6c odhcpd-ipv6only opkg ppp ppp-mod-pppoe procd procd-seccomp procd-ujail uboot-envtools uci uclient-fetch urandom-seed urngd wpad-wolfssl nano luci-app-attendedsysupgrade auc kmod-crypto-sha256 kmod-lib-lzo luci-app-opkg kmod-nft-bridge mesh11sd

bluewavenet commented 2 months ago

@nassoor 

Mon Apr  1 11:38:58 2024 daemon.debug mesh11sd[3664]: In Startup - portal upstream link check - iteration [ 10 ] ....
Mon Apr  1 11:38:59 2024 daemon.debug mesh11sd[3664]: default_gw=....

This log is showing you do not have an upstream connection ie you do not have an Internet feed connected. You must connect the wan port of your router to a lan port on your isp router.

Currently, what you are seeing is the router failing to detect the upstream link and configuring itself as a peer node. A peer node will only get an ipv4 address from a portal node. So the ip address (default 192.168.1.1) that you initially used to ssh into the router is no longer valid.

Your router should automatically change back to portal mode, with its default ipv4 address if you plug it in to the isp router.

nassoor commented 2 months ago

On my portal meshnode after upgrading to 3.1.0 and following the upgrading instructions:

Mon Apr  1 14:40:34 2024 daemon.notice mesh11sd[6800]: mesh11sd v3.1.0 has started: mesh management mode 1
Mon Apr  1 14:40:35 2024 daemon.info mesh11sd[6800]: No mesh interfaces detected yet.... Attempting auto configure
Mon Apr  1 14:40:35 2024 daemon.debug mesh11sd[6800]: Entering auto config....
Mon Apr  1 14:40:35 2024 daemon.debug mesh11sd[6800]: In get_portal_state. firstloop=1...
Mon Apr  1 14:40:35 2024 daemon.debug mesh11sd[6800]: default_gw=default via 192.168.1.1 dev wan  src 192.168.1.50 ....
Mon Apr  1 14:40:36 2024 daemon.debug mesh11sd[6800]: leaving get_portal_state - is_portal=.. gwstatus=REACHABLEFAILED.. gw_ip=192.168.1.1..
Mon Apr  1 14:40:36 2024 daemon.debug mesh11sd[6800]: auto config complete....
Mon Apr  1 14:40:36 2024 daemon.notice mesh11sd[6800]: Setting mac address of mesh interface m-11s-0 to [ a6:97:33:df:a4:77 ]
Mon Apr  1 14:40:36 2024 daemon.notice mesh11sd[6800]: Setting mac address of mesh interface m-11s-1 to [ a6:97:33:df:a4:77 ]
Mon Apr  1 14:40:36 2024 daemon.debug mesh11sd[6800]: Disconnecting nodes
Mon Apr  1 14:40:36 2024 daemon.debug mesh11sd[6800]: Entering check portal.... lan
Mon Apr  1 14:40:36 2024 daemon.debug mesh11sd[6800]: In get_portal_state. firstloop=0...
Mon Apr  1 14:40:36 2024 daemon.debug mesh11sd[6800]: default_gw=default via 192.168.1.1 dev wan  src 192.168.1.50 ....
Mon Apr  1 14:40:37 2024 daemon.debug mesh11sd[6800]: leaving get_portal_state - is_portal=.. gwstatus=REACHABLEFAILED.. gw_ip=192.168.1.1..

Same loss of connectivity afterwards.

What's the point of renaming the ssids?

bluewavenet commented 2 months ago

@nassoor

after upgrading to 3.1.0

You upgraded to a previous version?

What's the point of renaming the ssids?

So you will know which meshnode you are connecting to. The default install allows you to have the same flash image on all nodes, if it did not set the ssid they would all be "OpenWrt" and you would have no idea what you had connected to. Of course you can customise after you have the mesh up and running.

You say you used the firmware selector. You would remove wpad-basic-mbedtls and add wpad-mesh-mbedtls Add kmod-nft-bridge Add mesh11sd (this gives v3.1.0, although if you did it just after 23.05.3 came out it may well have still been v2 which would explain why you had to upgrade)

DO NOT add any uci-defaults at this debugging stage.

Reflash your Dynalink DL-WRX36 devices - How many do you have? Connect one to your isp router by ethernet, Dynalink WAN port to isp LAN port.

Power them all up.... Wait a couple of minutes. Look for the ssid of the isp connected node and connect to it.

If you get connected, ssh into a terminal session on it and run: mesh11sd status and mesh11sd stations

and show the outputs here.

bluewavenet commented 2 months ago

@nassoor Ah! Looking again at your logs, I see the problem. Mon Apr 1 14:40:35 2024 daemon.debug mesh11sd[6800]: default_gw=default via 192.168.1.1 dev wan src 192.168.1.50 ....

Your isp router is using the same subnet.

So we can fix this by adding a uci-defaults entry in the firmware selector.

In the uci-defaults box in the firmware selector, add the lines:

uci set network.lan.ipaddr='192.168.10.1'
uci commit network

Don't forget to change the package list as you did before then generate a new image and try again.

nassoor commented 2 months ago

I have two nodes. My last post was about my portal node which is different from my peer node that I made the initial report about.

The wireless goes down after a couple of minutes from powering up.

I changed the ISP router's lan network to 192.168.0.1 to avoid conflicts.

While connected to the second node which has no modified config and the node is connected to the ISP router. I got this log and it keeps going on

As for mesh11sd status:

root@meshnode-abbf:~# mesh11sd  status
{
  "setup":{
    "version":"3.1.0",
    "enabled":"1",
    "procd_status":"running",
    "portal_detect":"1",
    "portal_channel":"default",
    "mesh_basename":"m-11s-",
    "auto_config":"1",
    "auto_mesh_network":"lan",
    "auto_mesh_band":"2g40",
    "auto_mesh_id":"92d490daf46cfe534c56ddd669297e",
    "mesh_gate_enable":"1",
    "txpower":"",
    "mesh_path_cost":"10",
    "checkinterval":"10",
    "interface_timeout":"10",
    "ssid_suffix_enable":"1",
    "debuglevel":"3"
  }
  "interfaces":{
  }
}
bluewavenet commented 2 months ago

@nassoor

My last post was about my portal node which is different from my peer node

Is it different hardware? The setup in the firmware selector would be exactly the same even if they are different hardware.

bluewavenet commented 2 months ago

@nassoor There is something missing that is expected in the logs. For example I get:

Tue Apr  2 11:51:10 2024 daemon.notice wpa_supplicant[1042]: m-11s-0: interface state UNINITIALIZED->ENABLED
Tue Apr  2 11:51:10 2024 daemon.notice wpa_supplicant[1042]: m-11s-0: AP-ENABLED
Tue Apr  2 11:51:10 2024 daemon.notice wpa_supplicant[1042]: m-11s-0: joining mesh 92d490daf46cfe534c56ddd669297e
Tue Apr  2 11:51:10 2024 daemon.notice netifd: Network device 'm-11s-0' link is up
Tue Apr  2 11:51:10 2024 kern.info kernel: [80439.064181] IPv6: ADDRCONF(NETDEV_CHANGE): m-11s-0: link becomes ready

Sure, I am on different hardware, but you should see very similar logging.

Instead, you get:

Tue Apr  2 10:45:21 2024 daemon.notice netifd: radio0 (14994): Command failed: ubus call hostapd config_set { "phy": "phy0", "config":"/var/run/hostapd-phy0.conf", "prev_config": "/var/run/hostapd-phy0.conf.prev"} (Request timed out)
Tue Apr  2 10:45:21 2024 daemon.notice netifd: radio0 (14994): Device setup failed: HOSTAPD_START_FAILED

I am wondering if ath11k does not support mesh correctly?

Show the output of: iw list | grep -A 4 "valid interface combinations"

nassoor commented 2 months ago

Some clarification points:

It seems that I got it working and managed to change the ID and key on both nodes

Some questions:

bluewavenet commented 2 months ago

@nassoor

The wireless issue was caused by one of the snapshots, updating to a more recent one solved it.

Excellent!

How do disable the renaming of client SSIDs?

This is in setup, option ssid_suffix_enable. See: https://openwrt.org/docs/guide-user/network/wifi/mesh/mesh11sd#setup_options

Turn it off by doing:

service mesh11sd stop
uci set mesh11sd.setup.ssid_suffix_enable='0'
uci commit mesh11sd
service mesh11sd start; exit

Be warned, you will loose the connection for a few seconds as mesh11sd restarts. Depending on the terminal software you are using, the terminal window might lock up, so the exit is added to the end of the service start command.

How can I shorten the time it takes for the mesh to converge? Will manual mode help?

It should only take a few seconds, especially with just two nodes. Manual mode works the same way, so no advantage.

You can check what is going on assuming you have debuglevel set to 3.

  1. Turn them both off.
  2. Turn on the "router" node ie the one with the ethernet link to the isp router.
  3. ssh into it
  4. Run mesh11sd debuglevel 3 (assuming you do not have it in the setup already).
  5. Run logread -f
  6. Turn on the second node.
  7. Watch the log output on the logread screen.

The usual thing that can cause delays in converging are low signal levels, making a remote node retry several times before the receiving node sees a high enough rssi (Received Signal Strength Indicator). You can check signal strengths by stopping the logread output and running: mesh11sd stations

Moving locations a bit, or even just adjusting external antennas (if fitted) can fix the problem. If it persists, you can tune the rssi_threshold and transmit power (tx power). Non-intuitively, often, reducing transmit power can give much better results. This is because multipath reflections of the microwave signal can be reduced with a reduced tx power.

This tuning can be done from the mesh11sd command line, but we can look at that if we need to later.

nassoor commented 2 months ago

Thank you for helping me through this. I believe that my issue was that I didn't upgrade both routers to v3 at the same time, and I will admit that my assumptions about how mesh11sd works were inaccurate.

One thing that I am not sure I understand the rationale of is how disruptive the act of installing the package is. Having my connection disrupted and seeing my wifi networks with extra characters was a surprise to me. Maybe that should be indicated in the documentation. Or maybe make mesh11sd disabled by default until the user issues a service mesh11sd enable && service mesh11sd start

Another thing I struggled to find until you pointed it out was the ssid_suffix_enableoption. It was the first thing I wanted to disable as soon as I confirmed that the mesh is stable. I think the documentation would benefit from a more detailed description like this one:

Adds a 4 character suffix to existing SSIDs Renames the existing wireless network SSIDs by appending 4 characters to help differentiate between stations during setup. The 4 characters are the last 4 digits of the mac address of the mesh interface. Note: set to 0 to disable it after completing your setup. Default: 1 (enabled)

It should also be included as a step in the configuration section.

As an alternative to the above, we could include a guide like this one, and I can help with that if needed.

bluewavenet commented 2 months ago

@nassoor

Your feedback is valuable and you do make some good points. Your offer to help produce documentation would be very welcome, particularly a guide to customisation of the autonomous mode would be very useful.

Your usage case is one way to view things, but the package design comes from a different direction - ie venue or community mesh backhaul provision.

It is flexible enough to cater for both viewpoints and everything in between.

One thing that I am not sure I understand the rationale of is how disruptive the act of installing the package is

The package is designed in default mode to provide a fully autonomous meshnode without any complicated configuration required, with the ability to turn off the autonomous auto config mode where an advanced user wants to do something non-standard.

As it stands, the same firmware image configuration can be rolled out to any number of devices (you just need to flash the firmware to match the hardware).

The ssid suffix is not added just for convenience during rollout, but is a function required for many venue or community wide mesh implementations.

Note: set to 0 to disable it after completing your setup.

This is making the assumption that the only use for the package is in a small domestic type of environment. It would better read as: Note: set to 0 to disable it if not required.

Your example of the "Wireless Access Point", is horrendously complicated and tries to guide people with little knowledge of the subject into provisioning a setup that is anything but the extremely badly named "Dumb Ap". There are never ending streams of people struggling with it, so no I do not think it would be a good idea to provide such a guide for mesh11sd.

Yes, the documentation could be improved, no doubt.

My point is, there are two major aspects.

  1. Autonomous meshnode configuration. No manual intervention is required for a large mesh backhaul to self build. Great flexibility is provided for customisation if and when required.
  2. Manual configuration can be selected. This requires in depth knowledge of network configurations as well as a great deal of knowledge of how mesh networks function. This is aimed at the advanced user who wants to override many or all aspects of the autonomous system.

The documentation should emphasise these two aspects in much more detail.

My guess is that your use case would be best served by using aspect 1, the autonomous system, and then apply the comprehensive customisation options to tune exactly to your requirement.

As I said, your offer to help produce documentation would be very welcome, particularly a guide to customisation of the autonomous mode would be very useful.

Sections 4 and 5 list the many options: https://openwrt.org/docs/guide-user/network/wifi/mesh/mesh11sd#setup_options

There are many options as you can see, such as the radio band to use, the radio channel, the mesh id and many more.

nassoor commented 2 months ago

I agree that the dumb ap guide is not the highest quality guide out there but I wanted an example and I had the tab open 😁 What I wanted to show is a step by step guide that explains what each step does. Without oversimplifying, or exhaustively explaining every available option.

How do want me to submit suggestions to the documentation? Is a pull request here good for you? or should I submit to the wiki directly?

I am curious, in what scenario is the SSID suffix option useful for daily use?

bluewavenet commented 2 months ago

@nassoor

How do want me to submit suggestions to the documentation?

Pull request please.

I am curious, in what scenario is the SSID suffix option useful for daily use?

Many scenarios. eg:

  1. A large building - as roaming is unreliable at best and 802.11s is incompatible with 802.11r on the same physical radio.
  2. Wisp like situation where the mesh provides a community backbone. A CPE (Customer Premises Equipment) then picks up the local meshnode's AP and provides wifi coverage inside the customer's premises.

These are the two most common scenarios.

bluewavenet commented 2 months ago

@nassoor FYI: Version 3.1.1 is released. It is not yet available on the OpenWrt package feeds, it will take a couple of days to appear there. You can however download the ipk from here: https://github.com/openNDS/mesh11sd/releases/tag/v3.1.1

I have also created a docs folder and archived the OpenWrt mesh11sd user guide to there - it is in dokuwiki format. This should help with improving the documentation ;-)