I run two TP-Link Archer C7 (one v2, one v5) in a mesh constellation.
Before 23.05 I had wpad-wolfssl installed, with 23.05 mbedtls was introduced.
Since then, my mesh connection regularly (18 - 26h) drops, connection is erratical and only a reboot can mitigate the connection problems.
Am I the only one having this issue?
Two meshnodes is hardly a constellation 
Show the output of mesh11sd status
Astronomically speaking, you are right 
mesh11sd is not installed.
The whole mesh is configured statically using LUCI.
What are you interested in?
If it is not installed, expect to see your mesh to be unreliable and to periodically stop altogether.
There are many mesh parameters that are required that cannot be set until the interface is established. One of the functions of mesh11sd is to dynamically set these parameters as required.
In prior releases of OpenWrt, a consequence of bugs elsewhere meant that you could often get away without setting these mesh parameters if the mesh consisted of only 2 nodes. On some brief testing here, I found this lucky combination of bugs allowing a 2 node mesh to establish, seems no longer to work...
I am not saying there is no underlying problem with your actual hardware/firmware/setup but installing mesh11sd would be a good starting point for trying to fix your issue.
You just need to install it, everything should then be autonomous...
Once installed, the device may restart the wireless several times and you will most likely appear to loose contact with the remote node - but after a couple of minutes you should be able to run mesh11sd status on your portal node (the one connected to your Internet feed).
It should give you a json formatted output of the status of the mesh.
Here is an example:
root@mt1333-1:/tmp# mesh11sd status
{
"setup":{
"version":"3.0.0beta",
"enabled":"1",
"procd_status":"running",
"portal_detect":"1",
"mesh_basename":"m-11s-",
"checkinterval":"10",
"interface_timeout":"10",
"debuglevel":"1"
}
"interfaces":{
"m-11s-1":{
"mesh_retry_timeout":"100",
"mesh_confirm_timeout":"100",
"mesh_holding_timeout":"100",
"mesh_max_peer_links":"8",
"mesh_max_retries":"3",
"mesh_ttl":"31",
"mesh_element_ttl":"31",
"mesh_auto_open_plinks":"0",
"mesh_hwmp_max_preq_retries":"4",
"mesh_path_refresh_time":"1000",
"mesh_min_discovery_timeout":"100",
"mesh_hwmp_active_path_timeout":"5000",
"mesh_hwmp_preq_min_interval":"10",
"mesh_hwmp_net_diameter_traversal_time":"50",
"mesh_hwmp_rootmode":"3",
"mesh_hwmp_rann_interval":"5000",
"mesh_gate_announcements":"1",
"mesh_fwding":"1",
"mesh_sync_offset_max_neighor":"50",
"mesh_rssi_threshold":"-70",
"mesh_hwmp_active_path_to_root_timeout":"6000",
"mesh_hwmp_root_interval":"5000",
"mesh_hwmp_confirmation_interval":"2000",
"mesh_power_mode":"active",
"mesh_awake_window":"10",
"mesh_plink_timeout":"0",
"mesh_connected_to_gate":"1",
"mesh_nolearn":"0",
"mesh_connected_to_as":"1",
"mesh_id":"--__",
"device":"radio0",
"channel":"1",
"tx_packets":"169806",
"tx_bytes":"12068837",
"rx_packets":"124729",
"rx_bytes":"6596016",
"active_peers":"1",
"peers":{
"94:83:c4:08:14:83":{
"next_hop":"94:83:c4:08:14:83"
}
}
"active_stations":"0",
"stations":{
}
}
}
}
Thanks for the explanation. However, it was a careful decision not to install mesh11sd. From your Github repo and the source code, the daemon does in-process parameter updates at the cost of additional footprint.
Some may want that convenience, I don't.
iw dev mesh station dump -v gives:
Station 66:e3:27:4f:bb:0f (on mesh)
inactive time: 0 ms
rx bytes: 2159577242
rx packets: 6472720
tx bytes: 691160222
tx packets: 2121906
tx retries: 275289
tx failed: 9
rx drop misc: 142220
signal: -53 [-65, -59, -55] dBm
signal avg: -50 [-64, -59, -55] dBm
Toffset: 821733886499 us
tx bitrate: 975.0 MBit/s VHT-MCS 7 80MHz short GI VHT-NSS 3
tx duration: 112307609 us
rx bitrate: 702.0 MBit/s VHT-MCS 5 80MHz VHT-NSS 3
rx duration: 382473264 us
last ack signal:-95 dBm
avg ack signal: -93 dBm
airtime weight: 256
mesh llid: 0
mesh plid: 0
mesh plink: ESTAB
mesh airtime link metric: 9
mesh connected to gate: no
mesh connected to auth server: no
mesh local PS mode: ACTIVE
mesh peer PS mode: ACTIVE
mesh non-peer PS mode: ACTIVE
authorized: yes
authenticated: yes
associated: yes
preamble: long
WMM/WME: yes
MFP: yes
TDLS peer: no
MSDU:
TID rx tx tx retries tx failed
0 2863503 2095466 0 0
1 16781 372 0 0
2 28221 1405 0 0
3 0 0 0 0
4 1324 4 0 0
5 437 0 0 0
6 58 46 0 0
7 0 0 0 0
8 0 0 0 0
9 0 0 0 0
10 0 0 0 0
11 0 0 0 0
12 0 0 0 0
13 0 0 0 0
14 0 0 0 0
15 0 0 0 0
16 0 24612 0 8
TXQs:
TID qsz-byt qsz-pkt flows drops marks overlmt hashcoltx-bytes tx-packets
0 0 0 2095309 0 0 0 609 689347738 2095466
1 0 0 372 0 0 0 78 36456 372
2 0 0 1405 0 0 0 0 306254 1405
3 0 0 0 0 0 0 0 0
4 0 0 4 0 0 0 0 392 4
5 0 0 0 0 0 0 0 0
6 0 0 46 0 0 0 0 16886 46
7 0 0 0 0 0 0 0 0
8 0 0 0 0 0 0 0 0
9 0 0 0 0 0 0 0 0
10 0 0 0 0 0 0 0 0
11 0 0 0 0 0 0 0 0
12 0 0 0 0 0 0 0 0
13 0 0 0 0 0 0 0 0
14 0 0 0 0 0 0 0 0
15 0 0 0 0 0 0 0 0
DTIM period: 2
beacon interval:100
connected time: 179386 seconds
associated at [boottime]: 56.965s
associated at: 1701680025218 ms
current time: 1701859410544 ms
So what exactly are you looking for?
In that case, expect your mesh to "regularly (18 - 26h) drops, connection is erratical and only a reboot can mitigate the connection problems."
It is tiny, approximately 29KB. If this is too much for your router, then this will be the least of your worries.
Your choice, but be prepared to write your own daemon to set mesh parameters.
Just trying to help.... Good luck writing your mesh parameter daemon.
Hi Rob,
thank you for your reply.
I was pretty impressed by your 1081 lines of code. Very insightful.