It does not bridge the two nodes together into a single interface - rather it provides an infrastructure at layer 2 for all nodes to communicate.
This infrastructure has nothing to do with IP routing. Every node will have a mesh interface (bridged internally in the simplest case that we are discussing here), and this mesh interface will have a unique mac address. All the nodes in the mesh contribute to the "virtual switch" that is the mesh network.
The mesh network switches layer 2 packets from source to destination node in exactly the same way a real switch does - ie "routing" by mac address.
Much of the confusion arises from terminology. "Routing" does not exclusively mean "IP Routing". The mesh infrastructure does "MAC Routing".
So, if every mesh node is also a DHCP client then if there is a DHCP server somewhere on the mesh network, all the mesh nodes will receive an IP configuration - automatically.
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)?
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 )?
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:
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.
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.
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.
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 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?
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.
