So you are explaining the mesh network is, by analogy, as though the mesh nodes have a cabled connection (e.g. Ethernet) to the same switch (and also serving as switches for any clients connected to one or another)?
Yes, that is the simplest and most useful way to think of it.
1 Like
Any idea why mesh has been broken on snapshots for months on the RT3200? Basically what happens is that one mesh node stays apparently connected to mesh but transmit rate plummets down. And that mesh node becomes inaccessible until main router is rebooted.
The short answer is "no". I have no idea.
This is the nature of snapshots and is very particularly true for this particular device.
I assume you have set the required parameters for the mesh as indicated earlier (particularly mesh_gate_announcements and mesh_rssi_threshold)
From your screenshot it looks like you probably have a poor signal to noise ratio on the mesh link.
I also assume only your main router is an RT3200 and you use something else for your mesh nodes?
Try connecting a mesh node by ethernet to the RT3200 (disabling mesh on the RT3200 first).
Do your mesh nodes then work correctly ( assuming you have more than 1 of course )?
1 Like
Thanks for your thoughts and suggestions.
Three mesh nodes that are all RT3200. It worked perfectly for many months with snapshot upgrades and then something broke. I just left parameters as default. I think by default announcements is set true but threshold might be zero? Would that explain the issue?
WDS works fine. Here are the signal strengths today:
So both below 60, which I think is fine? I get very high throughout like > 300 Mbit/s.
I think the default is off, but you can check using the iw utility.
It might be. The default is 0, which means "no restriction, try to connect even on a bad link"
Current snapshot works on other platforms so it is probably just the drivers used on this one. Like I said, this is the nature of snapshots - the developers working on this device will get round to 802.11s support in due course I am sure, given that you have reported it.
2 Likes
Following my new understanding from the clarifications and corrections given by @bluewavenet, I am now approaching a proper deployment, with basic mesh functionality in place.
A glaring problem is that somehow DHCP clients are getting a IPv6 address for the DNS server, in addition to the correct DNS server, given as a IPv4 address, registered on the DHCP server on a non-OpenWrt router behind the wireless mess network. I have disabled DHCP for the bridge interface on the base, through Luci, and for IPv6 settings have disabled Router Advertisement-Service, DHCPv6-Service, and NDP-Proxy.
The bridge on the other mesh point has dynamic settings.
Linux clients seem to be resolving addresses correctly, but Android clients are not resolving local assignments.
This will be nothing to do with your mesh as it is only concerned with layer 2.
It will be due to the configuration of your DHCP server. It is giving out the ipv6 dns server to use.
Assuming you do not actually have an ipv6 feed, the ipv6 dns server will not be accessible.
It is the DHCP server you need to fix.
Some Android devices default to useing ipv6 if it is apparently available but do not fall back to ipv4 if the ipv6 turns out to be not functional.
1 Like
As you suggest is sensible, but it is unclear what difference in the AP would expose such a problem on the DHCP server, which has not recently changed.
As far as I know the DHCP server is not including any IPv6 DNS fields in the lease. It may be doing so, but even so, why is the client behaving differently due to the new AP provisioning?
Simple mesh nodes should not be running a dhcp server nor a dns server. Are you sure you have these disabled on the mesh nodes? The default OpenWrt image will have both enabled.
1 Like
The additional mesh point is operating as a DHCP client.
On my Linux client, the graphical front end to Network Manager provides two distinct options for dynamic IPv6, called Automatic, and Automatic, DHCP only. The former is default, but when I select the latter instead, and recreate the connection, the IPv6 DNS is not added.
Some strategy other than DHCP must be resolving these addresses. I have no experience with IPv6, and wonder what might be the strategy, and how to disable it.
I recommend you read this guide, because it will answer the questions you are asking:
I think my current configuration has been consistent with the recommendations in the article.
1 Like
I confirmed by packet capture on the client that the mesh node is returning a DHCPv6 reply. All the interfaces on the node are either DHCP clients themselves, or have the server disabled, including all the of the options for IPv6, such as RA.
It is quite frustrating. The node should not be serving any DHCP responses. How might I determine why it is doing so?
I would not always consider 802.11s because on low-capacity devices, using WPA3 can consume much more resources than WDS with WPA2.
There could be some truth in that, but I'm not sure about the "much more" part.
I have not found it significant anyway. Certainly on a 32Mb ram device you cannot run encrypted mesh reliably, but it is a long time since I tried, probably OpenWrt 18.x.x.
1 Like
If the source address was the mesh node, then it is running DHCP.
Try the following commands on the mesh node(s):
service dnsmasq disable
service dnsmasq stop
service odhcpd disable
service odhcpd stop
Currently on an Archer C60 and CPE210 with snapshots I get about 20 Mbps between them using 802.11s. With WDS 60 Mbps approx.
1 Like