"No physical wireless interfaces found" might be a clue!
Then there are these that might be interesting:
"No physical wireless interfaces found" might be a clue!
Then there are these that might be interesting:
After a reboot (using the on/off button) I can again log in without the connection being disconnected:
root@OpenWrt:~# uci show wireless
wireless.radio0=wifi-device
wireless.radio0.type='mac80211'
wireless.radio0.path='platform/soc/a000000.wifi'
wireless.radio0.band='2g'
wireless.radio0.channel='1'
wireless.radio0.htmode='VHT20'
wireless.radio0.disabled='1'
wireless.default_radio0=wifi-iface
wireless.default_radio0.device='radio0'
wireless.default_radio0.network='lan'
wireless.default_radio0.mode='ap'
wireless.default_radio0.ssid='OpenWrt'
wireless.default_radio0.encryption='none'
wireless.radio1=wifi-device
wireless.radio1.type='mac80211'
wireless.radio1.path='platform/soc/a800000.wifi'
wireless.radio1.band='5g'
wireless.radio1.channel='36'
wireless.radio1.htmode='VHT80'
wireless.radio1.disabled='1'
wireless.default_radio1=wifi-iface
wireless.default_radio1.device='radio1'
wireless.default_radio1.network='lan'
wireless.default_radio1.mode='ap'
wireless.default_radio1.ssid='OpenWrt'
wireless.default_radio1.encryption='none'
root@OpenWrt:~#
root@OpenWrt:~#
root@OpenWrt:~# uci show network
network.loopback=interface
network.loopback.device='lo'
network.loopback.proto='static'
network.loopback.ipaddr='127.0.0.1'
network.loopback.netmask='255.0.0.0'
network.globals=globals
network.globals.ula_prefix='fda3:4618:c2ce::/48'
network.globals.packet_steering='1'
network.globals.dhcp_default_duid='0004d6e46044c03e4372b844c99d18562897'
network.@device[0]=device
network.@device[0].name='br-lan'
network.@device[0].type='bridge'
network.@device[0].ports='lan1' 'lan2' 'lan3' 'lan4'
network.lan=interface
network.lan.device='br-lan'
network.lan.proto='static'
network.lan.ipaddr='192.168.4.1'
network.lan.netmask='255.255.255.0'
network.lan.ip6assign='60'
network.lan.multipath='off'
network.wan=interface
network.wan.device='wan'
network.wan.proto='dhcp'
network.wan6=interface
network.wan6.device='wan'
network.wan6.proto='dhcpv6'
root@OpenWrt:~#
If I repeat this with the HiWiFi router then:
$ ssh root@fe80::d6ee:7ff:fe59:65ae%enp2s0
root@fe80::d6ee:7ff:fe59:65ae%enp2s0's password:
BusyBox v1.37.0 (2026-03-25 20:09:53 UTC) built-in shell (ash)
_______ ________ __
| |.-----.-----.-----.| | | |.----.| |_
| - || _ | -__| || | | || _|| _|
|_______|| __|_____|__|__||________||__| |____|
|__| W I R E L E S S F R E E D O M
-----------------------------------------------------
OpenWrt 25.12.2, r32802-f505120278 Dave's Guitar
-----------------------------------------------------
OpenWrt recently switched to the "apk" package manager!
OPKG Command APK Equivalent Description
------------------------------------------------------------------
opkg install <pkg> apk add <pkg> Install a package
opkg remove <pkg> apk del <pkg> Remove a package
opkg upgrade apk upgrade Upgrade all packages
opkg files <pkg> apk info -L <pkg> List package contents
opkg list-installed apk info List installed packages
opkg update apk update Update package lists
opkg search <pkg> apk search <pkg> Search for packages
------------------------------------------------------------------
For more information visit:
https://openwrt.org/docs/guide-user/additional-software/opkg-to-apk-cheatsheet
root@OpenWrt:~# uci show wireless
wireless.radio0=wifi-device
wireless.radio0.type='mac80211'
wireless.radio0.path='1e140000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0'
wireless.radio0.band='2g'
wireless.radio0.channel='1'
wireless.radio0.htmode='HT20'
wireless.radio0.disabled='1'
wireless.default_radio0=wifi-iface
wireless.default_radio0.device='radio0'
wireless.default_radio0.network='lan'
wireless.default_radio0.mode='ap'
wireless.default_radio0.ssid='OpenWrt'
wireless.default_radio0.encryption='none'
wireless.radio1=wifi-device
wireless.radio1.type='mac80211'
wireless.radio1.path='1e140000.pcie/pci0000:00/0000:00:01.0/0000:02:00.0'
wireless.radio1.band='5g'
wireless.radio1.channel='36'
wireless.radio1.htmode='VHT80'
wireless.radio1.disabled='1'
wireless.default_radio1=wifi-iface
wireless.default_radio1.device='radio1'
wireless.default_radio1.network='lan'
wireless.default_radio1.mode='ap'
wireless.default_radio1.ssid='OpenWrt'
wireless.default_radio1.encryption='none'
root@OpenWrt:~#
root@OpenWrt:~#
root@OpenWrt:~# uci show network
network.loopback=interface
network.loopback.device='lo'
network.loopback.proto='static'
network.loopback.ipaddr='127.0.0.1'
network.loopback.netmask='255.0.0.0'
network.globals=globals
network.globals.ula_prefix='fdce:cf49:48dd::/48'
network.globals.packet_steering='1'
network.globals.dhcp_default_duid='00043406860a53f44e0684377d97f7f5e8c5'
network.@device[0]=device
network.@device[0].name='br-lan'
network.@device[0].type='bridge'
network.@device[0].ports='lan1' 'lan2' 'lan3'
network.@device[1]=device
network.@device[1].name='lan1'
network.@device[1].macaddr='d4:ee:07:59:65:ae'
network.@device[2]=device
network.@device[2].name='lan2'
network.@device[2].macaddr='d4:ee:07:59:65:ae'
network.@device[3]=device
network.@device[3].name='lan3'
network.@device[3].macaddr='d4:ee:07:59:65:ae'
network.lan=interface
network.lan.device='br-lan'
network.lan.proto='static'
network.lan.ipaddr='192.168.3.1'
network.lan.netmask='255.255.255.0'
network.lan.ip6assign='60'
network.lan.multipath='off'
network.@device[4]=device
network.@device[4].name='wan'
network.@device[4].macaddr='d4:ee:07:59:65:af'
network.wan=interface
network.wan.device='wan'
network.wan.proto='dhcp'
network.wan.peerdns='0'
network.wan.dns='1.1.1.1' '9.9.9.9' '1.1.1.1' '9.9.9.9'
network.wan6=interface
network.wan6.device='wan'
network.wan6.proto='dhcpv6'
network.wan6.reqaddress='try'
network.wan6.reqprefix='auto'
network.wan6.norelease='1'
network.wan6.peerdns='0'
network.wan6.dns='1.1.1.1' '9.9.9.9'
root@OpenWrt:~#
root@OpenWrt:~# mesh11sd auto_config test; exit
This will test autoconfiguration.
Rebooting will revert the test autoconfiguration.
Do you want to continue? [yes/no]
yes
Connection to fe80::d6ee:7ff:fe59:65ae%enp2s0 closed.
~$
In a new SSH terminal (continued in following post as character limit exceeded)
...
.. continuing from last post for the HiWiFi:
~$ ssh root@fe80::d6ee:7ff:fe59:65ae%enp2s0
root@fe80::d6ee:7ff:fe59:65ae%enp2s0's password:
BusyBox v1.37.0 (2026-03-25 20:09:53 UTC) built-in shell (ash)
_______ ________ __
| |.-----.-----.-----.| | | |.----.| |_
| - || _ | -__| || | | || _|| _|
|_______|| __|_____|__|__||________||__| |____|
|__| W I R E L E S S F R E E D O M
-----------------------------------------------------
OpenWrt 25.12.2, r32802-f505120278 Dave's Guitar
-----------------------------------------------------
OpenWrt recently switched to the "apk" package manager!
OPKG Command APK Equivalent Description
------------------------------------------------------------------
opkg install <pkg> apk add <pkg> Install a package
opkg remove <pkg> apk del <pkg> Remove a package
opkg upgrade apk upgrade Upgrade all packages
opkg files <pkg> apk info -L <pkg> List package contents
opkg list-installed apk info List installed packages
opkg update apk update Update package lists
opkg search <pkg> apk search <pkg> Search for packages
------------------------------------------------------------------
For more information visit:
https://openwrt.org/docs/guide-user/additional-software/opkg-to-apk-cheatsheet
root@OpenWrt:~# mesh11sd read_log
Sat Apr 18 08:39:06 UTC 2026 daemon.info mesh11sd[10407]: [13] option interface_timeout [ 10 ]
Sat Apr 18 08:39:06 UTC 2026 daemon.info mesh11sd[10407]: [14] option auto_config [ 0 ]
Sat Apr 18 08:39:06 UTC 2026 daemon.info mesh11sd[10407]: [15] auto_mesh_id hash [ 17397f4d6566ada576edf425141d62 ]
Sat Apr 18 08:39:07 UTC 2026 daemon.info mesh11sd[10407]: [16] option auto_mesh_band [ 2g40 ]
Sat Apr 18 08:39:07 UTC 2026 daemon.info mesh11sd[10407]: [17] option portal_channel [ default ]
Sat Apr 18 08:39:07 UTC 2026 daemon.info mesh11sd[10407]: [18] option mesh_phy_index [ ]
Sat Apr 18 08:39:07 UTC 2026 daemon.info mesh11sd[10407]: [19] option auto_mesh_key [ 0a11cb6374a73405ed231ff27b2323db97eb081bb3580e8cf14a38dbf23ac2d1 ]
Sat Apr 18 08:39:17 UTC 2026 daemon.debug mesh11sd[10407]: [20] br-lan is not up - giving up for now.
Sat Apr 18 08:39:17 UTC 2026 daemon.info mesh11sd[10407]: [21] option auto_mesh_network [ lan ]
Sat Apr 18 08:39:17 UTC 2026 daemon.info mesh11sd[10407]: [22] option mesh_basename [ m-11s- ]
Sat Apr 18 08:39:17 UTC 2026 daemon.info mesh11sd[10407]: [23] option mesh_gate_base_ssid [ test-Access_nomap ]
Sat Apr 18 08:39:17 UTC 2026 daemon.info mesh11sd[10407]: [24] option mesh_gate_encryption [ 1 ]
Sat Apr 18 08:39:17 UTC 2026 daemon.info mesh11sd[10407]: [25] option mesh_gate_key [ Test-Key_23 ]
Sat Apr 18 08:39:17 UTC 2026 daemon.info mesh11sd[10407]: [26] option ssid_suffix_enable [ 1 ]
Sat Apr 18 08:39:18 UTC 2026 daemon.info mesh11sd[10407]: [27] option vtun_enable [ 1 ]
Sat Apr 18 08:39:18 UTC 2026 daemon.info mesh11sd[10407]: [28] option tun_id [ 69 ]
Sat Apr 18 08:39:18 UTC 2026 daemon.debug mesh11sd[10407]: [29] Validated ipv4 address [ 192.168.53.1 ] using seed value [ 0a11cb6374a73405ed231ff27b2323db97eb081bb3580e8cf14a38dbf23ac2d1 ]
Sat Apr 18 08:39:18 UTC 2026 daemon.info mesh11sd[10407]: [30] option vtun_ip [ 192.168.53.1 ]
Sat Apr 18 08:39:18 UTC 2026 daemon.info mesh11sd[10407]: [31] option vtun_mask [ 255.255.255.0 ]
Sat Apr 18 08:39:18 UTC 2026 daemon.info mesh11sd[10407]: [32] option vtun_gate_encryption [ 4 ]
Sat Apr 18 08:39:18 UTC 2026 daemon.info mesh11sd[10407]: [33] option vtun_gate_key [ owe_null_key ]
Sat Apr 18 08:39:18 UTC 2026 daemon.info mesh11sd[10407]: [34] option vtun_base_ssid [ VTunnel ]
Sat Apr 18 08:39:18 UTC 2026 daemon.info mesh11sd[10407]: [35] option vtun_path_cost [ 10 ]
Sat Apr 18 08:39:18 UTC 2026 daemon.info mesh11sd[10407]: [36] option mesh_gate_enable [ 1 ]
Sat Apr 18 08:39:18 UTC 2026 daemon.info mesh11sd[10407]: [37] option mesh_leechmode_enable [ 0 ]
Sat Apr 18 08:39:18 UTC 2026 daemon.info mesh11sd[10407]: [38] option watchdog_nonvolatile_log [ 0 ]
Sat Apr 18 08:39:18 UTC 2026 daemon.info mesh11sd[10407]: [39] option mesh_path_stabilisation [ 0 ]
Sat Apr 18 08:39:18 UTC 2026 daemon.info mesh11sd[10407]: [40] option reactive_path_stabilisation_threshold [ 5 ]
Sat Apr 18 08:39:18 UTC 2026 daemon.info mesh11sd[10407]: [41] option mesh_mac_forced_forwarding [ 1 ]
Sat Apr 18 08:39:18 UTC 2026 daemon.info mesh11sd[10407]: [42] option gateway_proxy_arp [ 1 ]
Sat Apr 18 08:39:18 UTC 2026 daemon.info mesh11sd[10407]: [43] option reboot_on_error [ 1 ]
Sat Apr 18 08:39:18 UTC 2026 daemon.info mesh11sd[10407]: [44] option stop_on_error [ 0 ]
Sat Apr 18 08:39:18 UTC 2026 daemon.info mesh11sd[10407]: [45] option apmond_enable [ 1 ]
Sat Apr 18 08:39:18 UTC 2026 daemon.info mesh11sd[10407]: [46] option apmond_cgi_dir [ /www/cgi-bin/ ]
Sat Apr 18 08:39:18 UTC 2026 daemon.info mesh11sd[10407]: [47] option mesh_backhaul_led [ auto ]
Sat Apr 18 08:39:18 UTC 2026 daemon.info mesh11sd[10407]: [48] option manage_opennds_startup [ 1 ]
Sat Apr 18 08:39:19 UTC 2026 daemon.info mesh11sd[10407]: [49] option use_default_beacon_interval is [ disabled ]
Sat Apr 18 08:39:19 UTC 2026 daemon.info mesh11sd[10407]: [50] option mesh_dtim_period [ 2 ]
Sat Apr 18 08:39:19 UTC 2026 daemon.info mesh11sd[10407]: [51] option mesh_node_mobility_level [ 1 ]
Sat Apr 18 08:39:19 UTC 2026 daemon.info mesh11sd[10407]: [52] option cpe_mode [ nat66 ]
Sat Apr 18 08:39:19 UTC 2026 daemon.info mesh11sd[10407]: [53] option apmon_verbose_debug_enable [ 0 ]
Sat Apr 18 08:39:19 UTC 2026 daemon.info mesh11sd[10407]: [54] option odhcpd_log_level [ 3 ]
Sat Apr 18 08:39:20 UTC 2026 daemon.notice mesh11sd[10407]: [55] mesh11sd is in startup
Sat Apr 18 08:39:30 UTC 2026 daemon.debug mesh11sd[10407]: [56] br-lan is not up - giving up for now.
Sat Apr 18 08:39:32 UTC 2026 daemon.debug mesh11sd[10407]: [57] Kernel version: Major [ 6 ], Minor [ 12 ], Patch [ 74 ]
Sat Apr 18 08:39:32 UTC 2026 daemon.info mesh11sd[10407]: [58] option mesh_fwding [ 1 ]
Sat Apr 18 08:39:32 UTC 2026 daemon.info mesh11sd[10407]: [59] option mesh_retry_timeout [ 255 ]
Sat Apr 18 08:39:32 UTC 2026 daemon.info mesh11sd[10407]: [60] option mesh_confirm_timeout [ 255 ]
Sat Apr 18 08:39:33 UTC 2026 daemon.info mesh11sd[10407]: [61] option mesh_holding_timeout [ 255 ]
Sat Apr 18 08:39:33 UTC 2026 daemon.info mesh11sd[10407]: [62] option mesh_rssi_threshold [ -63 ]
Sat Apr 18 08:39:33 UTC 2026 daemon.info mesh11sd[10407]: [63] option mesh_gate_announcements [ 1 ]
Sat Apr 18 08:39:33 UTC 2026 daemon.info mesh11sd[10407]: [64] option mesh_hwmp_rootmode [ 0 ]
Sat Apr 18 08:39:33 UTC 2026 daemon.info mesh11sd[10407]: [65] option mesh_hwmp_root_interval [ 5000 ]
Sat Apr 18 08:39:33 UTC 2026 daemon.info mesh11sd[10407]: [66] option mesh_hwmp_active_path_to_root_timeout [ 6000 ]
Sat Apr 18 08:39:33 UTC 2026 daemon.info mesh11sd[10407]: [67] option mesh_max_peer_links [ 16 ]
Sat Apr 18 08:39:33 UTC 2026 daemon.info mesh11sd[10407]: [68] option mesh_plink_timeout [ 500 ]
Sat Apr 18 08:39:43 UTC 2026 daemon.debug mesh11sd[10407]: [69] br-lan is not up - giving up for now.
Sat Apr 18 08:39:53 UTC 2026 daemon.debug mesh11sd[10407]: [70] br-lan is not up - giving up for now.
Sat Apr 18 08:39:54 UTC 2026 daemon.info mesh11sd[10407]: [71] No mesh interfaces detected yet.... Attempting auto configure
Sat Apr 18 08:39:54 UTC 2026 daemon.err mesh11sd[10407]: [72] auto_config is disabled. Please configure a mesh interface or enable auto_config....
Sat Apr 18 08:40:14 UTC 2026 daemon.debug mesh11sd[10407]: [73] br-lan is not up - giving up for now.
Sat Apr 18 08:40:25 UTC 2026 daemon.debug mesh11sd[10407]: [74] br-lan is not up - giving up for now.
Sat Apr 18 08:40:25 UTC 2026 daemon.debug mesh11sd[10407]: [75] Checking mesh_hwmp_rootmode
Sat Apr 18 08:40:36 UTC 2026 daemon.info mesh11sd[12268]: [3] option log_mountpoint [ /tmp ]
Sat Apr 18 08:40:36 UTC 2026 daemon.info mesh11sd[12268]: [4] option max_log_entries [ 500 ]
Sat Apr 18 08:40:36 UTC 2026 daemon.info mesh11sd[12268]: [5] option debuglevel [ 3 ]
Sat Apr 18 08:40:36 UTC 2026 daemon.info mesh11sd[12268]: [6] option checkinterval [ 10 ]
Sat Apr 18 08:40:36 UTC 2026 daemon.info mesh11sd[12268]: [7] option commit_all [ 0 ]
Sat Apr 18 08:40:36 UTC 2026 daemon.info mesh11sd[12268]: [8] option portal_detect [ 1 ]
Sat Apr 18 08:40:36 UTC 2026 daemon.info mesh11sd[12268]: [9] option portal_use_default_ipv4 [ 0 ]
Sat Apr 18 08:40:36 UTC 2026 daemon.info mesh11sd[12268]: [10] option channel_tracking_checkinterval [ 26 ]
Sat Apr 18 08:40:36 UTC 2026 daemon.info mesh11sd[12268]: [11] option portal_detect_threshold [ 5 ]
Sat Apr 18 08:40:36 UTC 2026 daemon.info mesh11sd[12268]: [12] option mesh_path_cost [ 65525 ]
Sat Apr 18 08:40:36 UTC 2026 daemon.info mesh11sd[12268]: [13] option interface_timeout [ 10 ]
Sat Apr 18 08:40:36 UTC 2026 daemon.info mesh11sd[12268]: [14] option auto_config [ 0 ]
Sat Apr 18 08:40:36 UTC 2026 daemon.info mesh11sd[12268]: [15] auto_mesh_id hash [ 17397f4d6566ada576edf425141d62 ]
Sat Apr 18 08:40:36 UTC 2026 daemon.info mesh11sd[12268]: [16] option auto_mesh_band [ 2g40 ]
Sat Apr 18 08:40:36 UTC 2026 daemon.info mesh11sd[12268]: [17] option portal_channel [ default ]
Sat Apr 18 08:40:36 UTC 2026 daemon.info mesh11sd[12268]: [18] option mesh_phy_index [ ]
Sat Apr 18 08:40:36 UTC 2026 daemon.info mesh11sd[12268]: [19] option auto_mesh_key [ 0a11cb6374a73405ed231ff27b2323db97eb081bb3580e8cf14a38dbf23ac2d1 ]
Sat Apr 18 08:40:47 UTC 2026 daemon.debug mesh11sd[12268]: [20] br-lan is not up - giving up for now.
Sat Apr 18 08:40:47 UTC 2026 daemon.info mesh11sd[12268]: [21] option auto_mesh_network [ lan ]
Sat Apr 18 08:40:47 UTC 2026 daemon.info mesh11sd[12268]: [22] option mesh_basename [ m-11s- ]
Sat Apr 18 08:40:47 UTC 2026 daemon.info mesh11sd[12268]: [23] option mesh_gate_base_ssid [ test-Access_nomap ]
Sat Apr 18 08:40:47 UTC 2026 daemon.info mesh11sd[12268]: [24] option mesh_gate_encryption [ 1 ]
Sat Apr 18 08:40:47 UTC 2026 daemon.info mesh11sd[12268]: [25] option mesh_gate_key [ Test-Key_23 ]
Sat Apr 18 08:40:47 UTC 2026 daemon.info mesh11sd[12268]: [26] option ssid_suffix_enable [ 1 ]
Sat Apr 18 08:40:47 UTC 2026 daemon.info mesh11sd[12268]: [27] option vtun_enable [ 1 ]
Sat Apr 18 08:40:47 UTC 2026 daemon.info mesh11sd[12268]: [28] option tun_id [ 69 ]
Sat Apr 18 08:40:47 UTC 2026 daemon.debug mesh11sd[12268]: [29] Validated ipv4 address [ 192.168.53.1 ] using seed value [ 0a11cb6374a73405ed231ff27b2323db97eb081bb3580e8cf14a38dbf23ac2d1 ]
Sat Apr 18 08:40:47 UTC 2026 daemon.info mesh11sd[12268]: [30] option vtun_ip [ 192.168.53.1 ]
Sat Apr 18 08:40:47 UTC 2026 daemon.info mesh11sd[12268]: [31] option vtun_mask [ 255.255.255.0 ]
Sat Apr 18 08:40:47 UTC 2026 daemon.info mesh11sd[12268]: [32] option vtun_gate_encryption [ 4 ]
Sat Apr 18 08:40:47 UTC 2026 daemon.info mesh11sd[12268]: [33] option vtun_gate_key [ owe_null_key ]
Sat Apr 18 08:40:48 UTC 2026 daemon.info mesh11sd[12268]: [34] option vtun_base_ssid [ VTunnel ]
Sat Apr 18 08:40:48 UTC 2026 daemon.info mesh11sd[12268]: [35] option vtun_path_cost [ 10 ]
Sat Apr 18 08:40:48 UTC 2026 daemon.info mesh11sd[12268]: [36] option mesh_gate_enable [ 1 ]
Sat Apr 18 08:40:48 UTC 2026 daemon.info mesh11sd[12268]: [37] option mesh_leechmode_enable [ 0 ]
Sat Apr 18 08:40:48 UTC 2026 daemon.info mesh11sd[12268]: [38] option watchdog_nonvolatile_log [ 0 ]
Sat Apr 18 08:40:48 UTC 2026 daemon.info mesh11sd[12268]: [39] option mesh_path_stabilisation [ 0 ]
Sat Apr 18 08:40:48 UTC 2026 daemon.info mesh11sd[12268]: [40] option reactive_path_stabilisation_threshold [ 5 ]
Sat Apr 18 08:40:48 UTC 2026 daemon.info mesh11sd[12268]: [41] option mesh_mac_forced_forwarding [ 1 ]
Sat Apr 18 08:40:48 UTC 2026 daemon.info mesh11sd[12268]: [42] option gateway_proxy_arp [ 1 ]
Sat Apr 18 08:40:48 UTC 2026 daemon.info mesh11sd[12268]: [43] option reboot_on_error [ 1 ]
Sat Apr 18 08:40:48 UTC 2026 daemon.info mesh11sd[12268]: [44] option stop_on_error [ 0 ]
Sat Apr 18 08:40:48 UTC 2026 daemon.info mesh11sd[12268]: [45] option apmond_enable [ 1 ]
Sat Apr 18 08:40:48 UTC 2026 daemon.info mesh11sd[12268]: [46] option apmond_cgi_dir [ /www/cgi-bin/ ]
Sat Apr 18 08:40:48 UTC 2026 daemon.info mesh11sd[12268]: [47] option mesh_backhaul_led [ auto ]
Sat Apr 18 08:40:48 UTC 2026 daemon.info mesh11sd[12268]: [48] option manage_opennds_startup [ 1 ]
Sat Apr 18 08:40:48 UTC 2026 daemon.info mesh11sd[12268]: [49] option use_default_beacon_interval is [ disabled ]
Sat Apr 18 08:40:48 UTC 2026 daemon.info mesh11sd[12268]: [50] option mesh_dtim_period [ 2 ]
Sat Apr 18 08:40:48 UTC 2026 daemon.info mesh11sd[12268]: [51] option mesh_node_mobility_level [ 1 ]
Sat Apr 18 08:40:48 UTC 2026 daemon.info mesh11sd[12268]: [52] option cpe_mode [ nat66 ]
Sat Apr 18 08:40:48 UTC 2026 daemon.info mesh11sd[12268]: [53] option apmon_verbose_debug_enable [ 0 ]
Sat Apr 18 08:40:48 UTC 2026 daemon.info mesh11sd[12268]: [54] option odhcpd_log_level [ 3 ]
Sat Apr 18 08:40:49 UTC 2026 daemon.notice mesh11sd[12268]: [55] mesh11sd is in startup
Sat Apr 18 08:41:00 UTC 2026 daemon.debug mesh11sd[12268]: [56] br-lan is not up - giving up for now.
Sat Apr 18 08:41:02 UTC 2026 daemon.debug mesh11sd[12268]: [57] Kernel version: Major [ 6 ], Minor [ 12 ], Patch [ 74 ]
Sat Apr 18 08:41:02 UTC 2026 daemon.info mesh11sd[12268]: [58] option mesh_fwding [ 1 ]
Sat Apr 18 08:41:02 UTC 2026 daemon.info mesh11sd[12268]: [59] option mesh_retry_timeout [ 255 ]
Sat Apr 18 08:41:02 UTC 2026 daemon.info mesh11sd[12268]: [60] option mesh_confirm_timeout [ 255 ]
Sat Apr 18 08:41:02 UTC 2026 daemon.info mesh11sd[12268]: [61] option mesh_holding_timeout [ 255 ]
Sat Apr 18 08:41:02 UTC 2026 daemon.info mesh11sd[12268]: [62] option mesh_rssi_threshold [ -63 ]
Sat Apr 18 08:41:02 UTC 2026 daemon.info mesh11sd[12268]: [63] option mesh_gate_announcements [ 1 ]
Sat Apr 18 08:41:02 UTC 2026 daemon.info mesh11sd[12268]: [64] option mesh_hwmp_rootmode [ 0 ]
Sat Apr 18 08:41:02 UTC 2026 daemon.info mesh11sd[12268]: [65] option mesh_hwmp_root_interval [ 5000 ]
Sat Apr 18 08:41:02 UTC 2026 daemon.info mesh11sd[12268]: [66] option mesh_hwmp_active_path_to_root_timeout [ 6000 ]
Sat Apr 18 08:41:02 UTC 2026 daemon.info mesh11sd[12268]: [67] option mesh_max_peer_links [ 16 ]
Sat Apr 18 08:41:02 UTC 2026 daemon.info mesh11sd[12268]: [68] option mesh_plink_timeout [ 500 ]
Sat Apr 18 08:41:13 UTC 2026 daemon.debug mesh11sd[12268]: [69] br-lan is not up - giving up for now.
Sat Apr 18 08:41:23 UTC 2026 daemon.debug mesh11sd[12268]: [70] br-lan is not up - giving up for now.
Sat Apr 18 08:41:23 UTC 2026 daemon.info mesh11sd[12268]: [71] No mesh interfaces detected yet.... Attempting auto configure
Sat Apr 18 08:41:23 UTC 2026 daemon.err mesh11sd[12268]: [72] auto_config is disabled. Please configure a mesh interface or enable auto_config....
Sat Apr 18 08:41:44 UTC 2026 daemon.debug mesh11sd[12268]: [73] br-lan is not up - giving up for now.
Sat Apr 18 08:41:55 UTC 2026 daemon.debug mesh11sd[12268]: [74] br-lan is not up - giving up for now.
Sat Apr 18 08:41:55 UTC 2026 daemon.debug mesh11sd[12268]: [75] Checking mesh_hwmp_rootmode
Sat Apr 18 08:42:05 UTC 2026 daemon.info mesh11sd[14129]: [3] option log_mountpoint [ /tmp ]
Sat Apr 18 08:42:05 UTC 2026 daemon.info mesh11sd[14129]: [4] option max_log_entries [ 500 ]
Sat Apr 18 08:42:05 UTC 2026 daemon.info mesh11sd[14129]: [5] option debuglevel [ 3 ]
Sat Apr 18 08:42:05 UTC 2026 daemon.info mesh11sd[14129]: [6] option checkinterval [ 10 ]
Sat Apr 18 08:42:05 UTC 2026 daemon.info mesh11sd[14129]: [7] option commit_all [ 0 ]
Sat Apr 18 08:42:05 UTC 2026 daemon.info mesh11sd[14129]: [8] option portal_detect [ 1 ]
Sat Apr 18 08:42:05 UTC 2026 daemon.info mesh11sd[14129]: [9] option portal_use_default_ipv4 [ 0 ]
Sat Apr 18 08:42:05 UTC 2026 daemon.info mesh11sd[14129]: [10] option channel_tracking_checkinterval [ 26 ]
Sat Apr 18 08:42:06 UTC 2026 daemon.info mesh11sd[14129]: [11] option portal_detect_threshold [ 5 ]
Sat Apr 18 08:42:06 UTC 2026 daemon.info mesh11sd[14129]: [12] option mesh_path_cost [ 65525 ]
Sat Apr 18 08:42:06 UTC 2026 daemon.info mesh11sd[14129]: [13] option interface_timeout [ 10 ]
Sat Apr 18 08:42:06 UTC 2026 daemon.info mesh11sd[14129]: [14] option auto_config [ 0 ]
Sat Apr 18 08:42:06 UTC 2026 daemon.info mesh11sd[14129]: [15] auto_mesh_id hash [ 17397f4d6566ada576edf425141d62 ]
Sat Apr 18 08:42:06 UTC 2026 daemon.info mesh11sd[14129]: [16] option auto_mesh_band [ 2g40 ]
Sat Apr 18 08:42:06 UTC 2026 daemon.info mesh11sd[14129]: [17] option portal_channel [ default ]
Sat Apr 18 08:42:06 UTC 2026 daemon.info mesh11sd[14129]: [18] option mesh_phy_index [ ]
Sat Apr 18 08:42:06 UTC 2026 daemon.info mesh11sd[14129]: [19] option auto_mesh_key [ 0a11cb6374a73405ed231ff27b2323db97eb081bb3580e8cf14a38dbf23ac2d1 ]
Sat Apr 18 08:42:16 UTC 2026 daemon.debug mesh11sd[14129]: [20] br-lan is not up - giving up for now.
Sat Apr 18 08:42:16 UTC 2026 daemon.info mesh11sd[14129]: [21] option auto_mesh_network [ lan ]
Sat Apr 18 08:42:16 UTC 2026 daemon.info mesh11sd[14129]: [22] option mesh_basename [ m-11s- ]
Sat Apr 18 08:42:16 UTC 2026 daemon.info mesh11sd[14129]: [23] option mesh_gate_base_ssid [ test-Access_nomap ]
Sat Apr 18 08:42:17 UTC 2026 daemon.info mesh11sd[14129]: [24] option mesh_gate_encryption [ 1 ]
Sat Apr 18 08:42:17 UTC 2026 daemon.info mesh11sd[14129]: [25] option mesh_gate_key [ Test-Key_23 ]
Sat Apr 18 08:42:17 UTC 2026 daemon.info mesh11sd[14129]: [26] option ssid_suffix_enable [ 1 ]
Sat Apr 18 08:42:17 UTC 2026 daemon.info mesh11sd[14129]: [27] option vtun_enable [ 1 ]
Sat Apr 18 08:42:17 UTC 2026 daemon.info mesh11sd[14129]: [28] option tun_id [ 69 ]
Sat Apr 18 08:42:17 UTC 2026 daemon.debug mesh11sd[14129]: [29] Validated ipv4 address [ 192.168.53.1 ] using seed value [ 0a11cb6374a73405ed231ff27b2323db97eb081bb3580e8cf14a38dbf23ac2d1 ]
Sat Apr 18 08:42:17 UTC 2026 daemon.info mesh11sd[14129]: [30] option vtun_ip [ 192.168.53.1 ]
Sat Apr 18 08:42:17 UTC 2026 daemon.info mesh11sd[14129]: [31] option vtun_mask [ 255.255.255.0 ]
Sat Apr 18 08:42:17 UTC 2026 daemon.info mesh11sd[14129]: [32] option vtun_gate_encryption [ 4 ]
Sat Apr 18 08:42:17 UTC 2026 daemon.info mesh11sd[14129]: [33] option vtun_gate_key [ owe_null_key ]
Sat Apr 18 08:42:17 UTC 2026 daemon.info mesh11sd[14129]: [34] option vtun_base_ssid [ VTunnel ]
Sat Apr 18 08:42:17 UTC 2026 daemon.info mesh11sd[14129]: [35] option vtun_path_cost [ 10 ]
Sat Apr 18 08:42:17 UTC 2026 daemon.info mesh11sd[14129]: [36] option mesh_gate_enable [ 1 ]
Sat Apr 18 08:42:17 UTC 2026 daemon.info mesh11sd[14129]: [37] option mesh_leechmode_enable [ 0 ]
Sat Apr 18 08:42:17 UTC 2026 daemon.info mesh11sd[14129]: [38] option watchdog_nonvolatile_log [ 0 ]
Sat Apr 18 08:42:17 UTC 2026 daemon.info mesh11sd[14129]: [39] option mesh_path_stabilisation [ 0 ]
Sat Apr 18 08:42:17 UTC 2026 daemon.info mesh11sd[14129]: [40] option reactive_path_stabilisation_threshold [ 5 ]
Sat Apr 18 08:42:17 UTC 2026 daemon.info mesh11sd[14129]: [41] option mesh_mac_forced_forwarding [ 1 ]
Sat Apr 18 08:42:17 UTC 2026 daemon.info mesh11sd[14129]: [42] option gateway_proxy_arp [ 1 ]
Sat Apr 18 08:42:18 UTC 2026 daemon.info mesh11sd[14129]: [43] option reboot_on_error [ 1 ]
Sat Apr 18 08:42:18 UTC 2026 daemon.info mesh11sd[14129]: [44] option stop_on_error [ 0 ]
Sat Apr 18 08:42:18 UTC 2026 daemon.info mesh11sd[14129]: [45] option apmond_enable [ 1 ]
Sat Apr 18 08:42:18 UTC 2026 daemon.info mesh11sd[14129]: [46] option apmond_cgi_dir [ /www/cgi-bin/ ]
Sat Apr 18 08:42:18 UTC 2026 daemon.info mesh11sd[14129]: [47] option mesh_backhaul_led [ auto ]
Sat Apr 18 08:42:18 UTC 2026 daemon.info mesh11sd[14129]: [48] option manage_opennds_startup [ 1 ]
Sat Apr 18 08:42:18 UTC 2026 daemon.info mesh11sd[14129]: [49] option use_default_beacon_interval is [ disabled ]
Sat Apr 18 08:42:18 UTC 2026 daemon.info mesh11sd[14129]: [50] option mesh_dtim_period [ 2 ]
Sat Apr 18 08:42:18 UTC 2026 daemon.info mesh11sd[14129]: [51] option mesh_node_mobility_level [ 1 ]
Sat Apr 18 08:42:18 UTC 2026 daemon.info mesh11sd[14129]: [52] option cpe_mode [ nat66 ]
Sat Apr 18 08:42:18 UTC 2026 daemon.info mesh11sd[14129]: [53] option apmon_verbose_debug_enable [ 0 ]
Sat Apr 18 08:42:18 UTC 2026 daemon.info mesh11sd[14129]: [54] option odhcpd_log_level [ 3 ]
Sat Apr 18 08:42:19 UTC 2026 daemon.notice mesh11sd[14129]: [55] mesh11sd is in startup
Sat Apr 18 08:42:29 UTC 2026 daemon.debug mesh11sd[14129]: [56] br-lan is not up - giving up for now.
Sat Apr 18 08:42:31 UTC 2026 daemon.debug mesh11sd[14129]: [57] Kernel version: Major [ 6 ], Minor [ 12 ], Patch [ 74 ]
Sat Apr 18 08:42:31 UTC 2026 daemon.info mesh11sd[14129]: [58] option mesh_fwding [ 1 ]
Sat Apr 18 08:42:31 UTC 2026 daemon.info mesh11sd[14129]: [59] option mesh_retry_timeout [ 255 ]
Sat Apr 18 08:42:32 UTC 2026 daemon.info mesh11sd[14129]: [60] option mesh_confirm_timeout [ 255 ]
Sat Apr 18 08:42:32 UTC 2026 daemon.info mesh11sd[14129]: [61] option mesh_holding_timeout [ 255 ]
Sat Apr 18 08:42:32 UTC 2026 daemon.info mesh11sd[14129]: [62] option mesh_rssi_threshold [ -63 ]
Sat Apr 18 08:42:32 UTC 2026 daemon.info mesh11sd[14129]: [63] option mesh_gate_announcements [ 1 ]
Sat Apr 18 08:42:32 UTC 2026 daemon.info mesh11sd[14129]: [64] option mesh_hwmp_rootmode [ 0 ]
Sat Apr 18 08:42:32 UTC 2026 daemon.info mesh11sd[14129]: [65] option mesh_hwmp_root_interval [ 5000 ]
Sat Apr 18 08:42:32 UTC 2026 daemon.info mesh11sd[14129]: [66] option mesh_hwmp_active_path_to_root_timeout [ 6000 ]
Sat Apr 18 08:42:32 UTC 2026 daemon.info mesh11sd[14129]: [67] option mesh_max_peer_links [ 16 ]
Sat Apr 18 08:42:32 UTC 2026 daemon.info mesh11sd[14129]: [68] option mesh_plink_timeout [ 500 ]
Sat Apr 18 08:42:42 UTC 2026 daemon.debug mesh11sd[14129]: [69] br-lan is not up - giving up for now.
Sat Apr 18 08:42:53 UTC 2026 daemon.debug mesh11sd[14129]: [70] br-lan is not up - giving up for now.
Sat Apr 18 08:42:53 UTC 2026 daemon.info mesh11sd[14129]: [71] No mesh interfaces detected yet.... Attempting auto configure
Sat Apr 18 08:42:53 UTC 2026 daemon.err mesh11sd[14129]: [72] auto_config is disabled. Please configure a mesh interface or enable auto_config....
Sat Apr 18 08:43:14 UTC 2026 daemon.debug mesh11sd[14129]: [73] br-lan is not up - giving up for now.
Sat Apr 18 08:43:24 UTC 2026 daemon.debug mesh11sd[14129]: [74] br-lan is not up - giving up for now.
Sat Apr 18 08:43:25 UTC 2026 daemon.debug mesh11sd[14129]: [75] Checking mesh_hwmp_rootmode
Sat Apr 18 08:43:35 UTC 2026 daemon.info mesh11sd[16023]: [3] option log_mountpoint [ /tmp ]
Sat Apr 18 08:43:35 UTC 2026 daemon.info mesh11sd[16023]: [4] option max_log_entries [ 500 ]
Sat Apr 18 08:43:35 UTC 2026 daemon.info mesh11sd[16023]: [5] option debuglevel [ 3 ]
Sat Apr 18 08:43:35 UTC 2026 daemon.info mesh11sd[16023]: [6] option checkinterval [ 10 ]
Sat Apr 18 08:43:35 UTC 2026 daemon.info mesh11sd[16023]: [7] option commit_all [ 0 ]
Sat Apr 18 08:43:35 UTC 2026 daemon.info mesh11sd[16023]: [8] option portal_detect [ 1 ]
Sat Apr 18 08:43:35 UTC 2026 daemon.info mesh11sd[16023]: [9] option portal_use_default_ipv4 [ 0 ]
Sat Apr 18 08:43:35 UTC 2026 daemon.info mesh11sd[16023]: [10] option channel_tracking_checkinterval [ 26 ]
Sat Apr 18 08:43:35 UTC 2026 daemon.info mesh11sd[16023]: [11] option portal_detect_threshold [ 5 ]
Sat Apr 18 08:43:35 UTC 2026 daemon.info mesh11sd[16023]: [12] option mesh_path_cost [ 65525 ]
Sat Apr 18 08:43:35 UTC 2026 daemon.info mesh11sd[16023]: [13] option interface_timeout [ 10 ]
Sat Apr 18 08:43:36 UTC 2026 daemon.info mesh11sd[16023]: [14] option auto_config [ 0 ]
Which looks rather different from the log of the Asus.
Is it possible that the Asus with 128MB RAM (and 2+128MB NAND) is having memory problems, whereas the HiWiFi has 256MB RAM (and 128 NAND) has sufficient memory? (Would the "smallbuffers" package help the Asus if this is the problem?)
No, 128MB ram is more than enough.
No, this will most likely conflict with the mesh11sd buffers management.
I did ask before:
But looking at just your network config, it seems you have made some significant changes.
It looks very probable that you have made changes somewhere that clash with mesh11sd resulting in the bridge failing to come up.
There is a reason I asked you not to make ANY changes to the image defaults.
Sure, you can customise things later, but here we are trying to get you going with a basic system.
I feel you are "over thinking" and trying to do things now that you would like to see later - please don't!
FYI I am aware of numerous people using this Asus model with no problems whatsoever.
We should revert to making custom flash images using the Firmware selector, otherwise we will just continue to waste our time......
OK, no problems trying a custom flash image. I presume the custom flash image created by the Firmware selector can be flashed using Luci.
I am not conscious of any changes subsequent to a reset using firstboot except as described above.
That's great news. Presumably, they used a custom flash image?
Custom Flash image
The original package list for the image was:
apk-mbedtls ath10k-board-qca4019 ath10k-firmware-qca4019-ct base-files ca-bundle dnsmasq dropbear firewall4 fstools kmod-ath10k-ct kmod-gpio-button-hotplug kmod-leds-gpio kmod-nft-offload kmod-usb-dwc3 kmod-usb-dwc3-qcom kmod-usb3 libc libgcc libustream-mbedtls logd mtd netifd nftables odhcp6c odhcpd-ipv6only ppp ppp-mod-pppoe procd-ujail uboot-envtools uci uclient-fetch urandom-seed urngd -wpad-basic-mbedtls -kmod-ath10k-ct kmod-ath10k-ct-smallbuffers kmod-usb-ledtrig-usbport -luci luci-app-attendedsysupgrade wpad-mbedtls luci-ssl luci-app-commands ip-full kmod-nft-bridge vxlan mesh11sd
modified to remove the ath10k-ct drivers and also kmod-ath10k-smallbuffers as follows
apk-mbedtls ath10k-board-qca4019 ath10k-firmware-qca4019 base-files ca-bundle dnsmasq dropbear firewall4 fstools kmod-ath10k kmod-gpio-button-hotplug kmod-leds-gpio kmod-nft-offload kmod-usb-dwc3 kmod-usb-dwc3-qcom kmod-usb3 libc libgcc libustream-mbedtls logd mtd netifd nftables odhcp6c odhcpd-ipv6only ppp ppp-mod-pppoe procd-ujail uboot-envtools uci uclient-fetch urandom-seed urngd -wpad-basic-mbedtls -kmod-ath10k kmod-usb-ledtrig-usbport -luci luci-app-attendedsysupgrade wpad-mbedtls luci-ssl luci-app-commands ip-full kmod-nft-bridge vxlan mesh11sd
I'll post the result.
This is what the Firmware Selector page should look like for the Asus:
Note1: ct drivers negated and mesh11sd and its dependencies added
Note2: uci defaults section MUST be filled in as shown
For copy/paste, here is the Installed packages list:
apk-mbedtls ath10k-board-qca4019 -ath10k-firmware-qca4019-ct ath10k-firmware-qca4019 base-files ca-bundle dnsmasq dropbear firewall4 fstools -kmod-ath10k-ct kmod-ath10k kmod-gpio-button-hotplug kmod-leds-gpio kmod-nft-offload kmod-usb-dwc3 kmod-usb-dwc3-qcom kmod-usb3 libc libgcc libustream-mbedtls logd mtd netifd nftables odhcp6c odhcpd-ipv6only ppp ppp-mod-pppoe procd-ujail uboot-envtools uci uclient-fetch urandom-seed urngd -wpad-basic-mbedtls wpad-mbedtls -kmod-ath10k-ct -kmod-ath10k-ct-smallbuffers kmod-usb-ledtrig-usbport luci-ssl luci-app-attendedsysupgrade ip-full vxlan kmod-nft-bridge luci-app-commands mesh11sd
and the uci-defaults:
uci set mesh11sd.setup.auto_config='1'
uci set mesh11sd.setup.debuglevel='3'
uci commit mesh11sd
This is what the Firmware Selector page for the HiWiFi should look like:
Again, for copy/paste purposes, Installed Packages will be:
apk-mbedtls base-files ca-bundle dnsmasq dropbear firewall4 fstools kmod-crypto-hw-eip93 kmod-gpio-button-hotplug kmod-leds-gpio kmod-nft-offload libc libgcc libustream-mbedtls logd mtd netifd nftables odhcp6c odhcpd-ipv6only ppp ppp-mod-pppoe procd-ujail uboot-envtools uci uclient-fetch urandom-seed urngd -wpad-basic-mbedtls wpad-mbedtls kmod-mt7603 kmod-mt76x2 kmod-usb3 -uboot-envtools luci-ssl luci-app-attendedsysupgrade ip-full vxlan kmod-nft-bridge luci-app-commands mesh11sd
and uci-defaults (yes, it is the same as the Asus)
uci set mesh11sd.setup.auto_config='1'
uci set mesh11sd.setup.debuglevel='3'
uci commit mesh11sd
This will use all the default settings for best performance.
Before any customisation (eg the SSIDs you want to see etc), lets get this working, then we can come back to it as required.
Once you have built and flashed these images, pick one of the devices, say the Asus.
Connect by ethernet from its WAN port to the upstream "LAN" ie your old testing router or the ONT.
Power both up.
That's it, nothing else to do, no ssh to set anything up, no confidence test, no nothing. It is autonomous and will do it for you.
It might take a few minutes to get going but you should see SSIDs like MeshGate-xxxx and VTunnel-xxxx appearing. The led should go from steady to heartbeat once the backhaul is active.
Try connecting to one of these SSIDs (if you have an old device it might fail because it is using Opportunistic Wireless Encryption (OWE) and older devices do not know what that is).
With luck it will all be working........
Thank you. I'll try it soon.
Presumably, once mesh11sd is running I can stop it using service mesh11sd stop and have a normal OpenWRT system prompt. If required, in the absence of Luci a new image can then presumably be achieved via SSH with:
service mesh11sd stop
cd /tmp
wget https://downloads.openwrt.org/releases/X.Y.Z/targets/<target>/openwrt-X.Y.Z-<target>-sysupgrade.bin
sha256sum openwrt-*.bin # compare to checksum from download site
sysupgrade -n /tmp/openwrt-*.bin # to discard current configuration
reboot
What do you mean by this?
Why do you think mesh11sd gives you a different system prompt?
When you say "system prompt" do you really mean the Luci login web page?
To try and clarify better, I will re-iterate/re-write things I have said before:
Mesh11sd autonomously manages the mesh backhaul.
To do this, sin simple terms it does two things:
As you can see from these two points, the setup of the mesh is dynamic and is rebuilt on every reboot.
Luci however, only understands static configurations written to files in /etc/config/
It will not even see stuff that Mesh11sd has done, and any changes done by Luci will very likely break the mesh, at best, but at worst can soft brick the device.
So by default Mesh11sd disables Luci, replacing it with a MeshNode status page.
Now, in a "home network" scenario, your meshnodes and access points will not change their locations, signal strengths, traffic loads etc.
In such a situation, my point 1 above will generate the same settings, so as long as there are no significant changes in your network, you can safely tell mesh11sd to remember the setup it has generated and re-enable Luci.
The things Mesh11sd does in my point 2 must still continue to be done, autonomously and dynamically.
If you do "service mesh11sd stop", the mesh will continue to run, but will in the best scenario, slowly degrade in performance and eventually cease to function.
Yes, but doing it the way you have suggested will replace the custom image you generated.
To get a new custom image installed, generate with Firmware Selector, download to your computer, use the scp command to copy from your computer to the meshnode, instead of using wget directly from the downloads.openwrt.org site.
Using one of your ipv6 addresses you use for ssh as an example, the following would be an example of using scp.
On your computer:
scp -O /path/to/downloads/my-custom-image root@[fe80::d6ee:7ff:fe59:65ae%enp2s0]:/tmp
Lets get the basic mesh running before trying anything fancy!
Thanks. I'm just being cautious wanting to know beforehand how to recover in case of problems. Hopefully, not necessary.
I understand that in the firmware selector it is not necessary to put the hyphen "-" before the package name to remove it, but that removing it from that line is enough to prevent it from being included in the custom build.
Yes, that seems to be (mostly) correct. The Firmware Selector uses some extra logic over the Imagegenerator it is based on. Is it always correct? I don't know but it does no harm to absolutely make sure by adding the "-", so I always do.
Unless it is also a default dependency of some other package.
Not too long ago it would go wrong for example if you specified iptables-nft but another package had just "iptables" listed as a dependency in its makefile. The result was "impossible selection" or similar if I remember correctly (the default was iptables-zz-legacy). I am pretty sure this is fixed elsewhere now, but nevertheless.... Call this example an edge case if you will, but I always wonder if there are more examples. In my opinion, based on past experience, it just saves time, eliminating potential issues before they occur. But then that is just me ![]()
Some people might prefer using Imagebuilder locally, then you do need to use the "-" regardless.
OK. Both the Asus and the HiWiFi routers have been flashed, and the LEDs for both are double flashing i.e. double flash then a pause before repeating. This is presumably the "heartbeat" pattern you mentioned. There are also multiple Meshgate-XXX and VTunnel-XXX SSIDs visible, although the number of these is varying (presumably as the system is self-calibrating). Access is gained using SSH and the same IPv6 address as earlier. This is now looking promising.
Yes, it means the backhaul is up and active. This is the kernel heartbeat flash. The higher the rate of flashing, the busier the cpu is - just like us ![]()
After a few minutes of booting up, each node will have one each of these.
In those few minutes, yes they might come and go as the mesh links establish, but thereafter will be steady.
Yes.
SSH to the one connected upstream (aka the mesh portal).
Run the command:
mesh11sd connect
You should see the other (peer) node listed.
Connect to it using the listed mac address (has the colons removed for ease of double-click to copy)
mesh11sd connect <mac-address>
You should also be able to right click the web-ui url to open the peer node's status page in your browser.
Here is what it looks like on my test network:
root@meshnode-8ecb:/tmp# mesh11sd connect
===========================================================================
Connect a remote terminal session on a remote meshnode
Usage: mesh11sd connect [remote_meshnode_macaddress]
Building node list * * * * * *
If the node you are looking for is not in the list - re-run this command.
====================================================================================================================
The following meshnodes are available for remote connection:
94-83-c4-5c-25-6e [ ipaddress: fe80::9683:c4ff:fe5c:256e] [ web_ui: https://[fd46:cfe5:34c5:ddd6:9683:c4ff:fe5c:256e] ]
94-83-c4-5c-2a-52 [ ipaddress: fe80::9683:c4ff:fe5c:2a52] [ web_ui: https://[fd46:cfe5:34c5:ddd6:9683:c4ff:fe5c:2a52] ]
94-83-c4-2c-c5-24 [ ipaddress: fe80::9683:c4ff:fe2c:c524] [ web_ui: https://[fd46:cfe5:34c5:ddd6:9683:c4ff:fe2c:c524] ]
94-83-c4-81-7a-66 [ ipaddress: fe80::9683:c4ff:fe81:7a66] [ web_ui: https://[fd46:cfe5:34c5:ddd6:9683:c4ff:fe81:7a66] ]
94-83-c4-2e-f9-d1 [ ipaddress: fe80::9683:c4ff:fe2e:f9d1] [ web_ui: https://[fd46:cfe5:34c5:ddd6:9683:c4ff:fe2e:f9d1] ]
94-83-c4-13-58-bd [ ipaddress: fe80::9683:c4ff:fe13:58bd] [ web_ui: https://[fd46:cfe5:34c5:ddd6:9683:c4ff:fe13:58bd] ]
====================================================================================================================
root@meshnode-8ecb:/tmp#
Have you tried connecting to any of the SSIDs?
Remember they are all running OWE by default (Opportunistic Wireless Encryption). All up to date devices are ok with this, but older ones may not be.
You can also try connecting your computer to the remote peer node via ethernet - any one of the lan ports. It should get ipv4 and ipv6 addresses in the normal way and have Internet access.
If you have old devices that cannot connect, this will almost certainly be due to those devices not supporting OWE (most newer ones do).
Regardless, it is a simple mesh11sd config to change to a more traditional encryption.
Lots of config settings for access points are available in the mesh11sd config - don't try to set them in the wireless config!
Mesh11sd has the Apmon daemon embedded in its code, and the mesh creates a central database of the statistics from every mesh-gate (aka access points).
You can view this in json format via the mesh11sd show_ap_data command.
Of course, if an AP has not had any connections, the database for that node will be empty, so you need to connect something first ![]()
If you want to add more meshnodes, it is as simple as generating a custom flash image in exactly the same way as you did for these two nodes, then power up - nothing else needed.
You can even add more nodes using an ethernet connection to any other node. In this case the ethernet connection is detected and given priority in the mac-routing, automatically falling back to mesh backhaul if the cable is disconnected.
First I connected the Asus to the internet via the router with the wireless link to the dumb router on the ONT. The connection to the internet was possible but very slow to establish and not stable. Similarly an SSH connection required patience to establish and use. The LED was double flashing at double quick speed. (A human heart wouldn't survive that for long before giving up.) The Asus does not seem to like this connection when trying to be the mesh master.
Next the Asus-WAN was connected directly by cable to the LAN of the dumb router (which is connected to the ONT). This worked immediately and the LED flashes with a comfortable rhythm. The mobile phone connects to the SSID easily and download speed very good when standing less than a meter away.
The router took a full 15 to 20 minutes to establish a wireless internet connection from when the Asus was connected by cable to the dumb router. The entire time the LED beat red with a comfortable rhythm.
Once the internet connection was established then it appears to be stable with the speed appears to be slower than the wireless connection when using the travel router (which might be due to the different router models rather than the mesh). The mobile phone can connect to the SSIDs, and the PC can connect to the LAN.
I'll spend a day or so trying this new system out.
Is it possible to connect via wifi to the dumb router rather than by cable?
It would be good to give detail about what the "dumb router" is and how it is configured (and what do you actually mean by "dumb router" ).
This indicates something wrong with the upstream connection.
Typically, around 60 seconds after the heartbeat starts, all should be stable.
If the upstream connection is intermittent, the portal (the one you are calling master) will try to find a mesh peer with a better upstream connection and if this is happening it will of course look unstable. So we really do need to look at that "dumb router".
This can happen when the routing table on your computer is in need of a refresh after the portal has, for example, been rebooted.
You can force a refresh with a "disable/enable" of the computer ethernet. After a few seconds the routing table will update and ssh will work, without having to wait.
Wait!! In your "What did not work" paragraph, you said "I connected the Asus to the internet via the router with the wireless link to the dumb router on the ONT. "
How is that different to how you first tried?
To re-iterate: The portal (The Asus in this case) MUST have its WAN port connected to the upstream Internet connection, what ever that is - your dumb router or the ont itself.
If you had connected the upstream via an Asus LAN port, the symptoms you describe would be very much expected. The portal would check the WAN port looking for the upstream, eventually switching to peer mode. It would then start scanning the backhaul for another portal that might have an active upstream. Then it would timeout again, starting the whole cycle again.
So I am guessing that initially, you did indeed have an Asus LAN port connected to the "dumb router".... ?? This would explain the issue....
This is a Mesh Peer - the term "satellite" seems to be used in proprietary systems that use a form of WDS and are not mesh in the true sense at all.
I would indeed expect very unstable connection if the portal was not connected correctly.
The heartbeat indicates the layer 2 backhaul is up, but the portal, with a lan connection, would not be providing the necessary layer 3 infrastructure. At best it would be bridging to the "dumb router" with regular resets.
Stable Layer 3 from the portal will have come up shortly after you connected the Asus WAN port to upstream. So yes...
The hardware for both of these is pretty old and limited to "wifi5" at best.
Mesh11sd will detect this and configure for the most robust and reliable connection.
By default I would expect a default TheoreticalMaxMbps of 300Mb/s.
Reducing robustness as well as range it might be possible to see a 868Mb/s TheoreticalMaxMbps.
This will depend on many factors, eg the construction of the building as well as cpu speeds.
For example AX devices can achieve in "maximum robustness" mode, 600Mb/s for mimo 2x2 (two antennas) or 1200Mb/s for mimo 4x4 (four antennas).
You can check the node capabilities with the following command:
mesh11sd wifi_chipset_detect
The question to seriously consider is "Is 300Mb/s backhaul good enough for my use case".
If the answer is "No" then you are left with potential compromises in robustnesss/coverage, or obtaining some up to date wifi6/AX hardware.
Well yes, but probably, once you are happy with your working mesh, just replace the "dumb router" with your Asus portal - wan to ont.
Remember there are many permutations of config options to consider if you really need to - but that could be very confusing unless you know what you are doing.
We are making steady progress while keeping it simple which will improve your knowledge very quickly.
You should look at the outputs I have mentioned earlier as well as others, eg:
mesh11sd status
mesh11sd connect
mesh11sd wifi_chipset_detect
mesh11sd show_ap_data
mesh11sd read_log -f
For the read_log output I am assuming you set debuglevel to 3 in the Firmware selector.
But you can change it at any time with:
mesh11sd debuglevel 3
You can set levels 0, 1, 2 or 3; 3 being the most verbose.
Feel free to ask questions!
We recently traded speed for $, so have a relatively low cost, endless data, fibre connection with 100Mbps now. It's OK most of the time but can get a bit tedious with large downloads. I'll expect to have a cable soon to my room but the rest of the property will use the wifi mesh. We can get by with 30Mbps over wifi when travelling but I'd hope for more over the mesh. So for us stability and reliability is more important than.[quote="bluewavenet, post:38, topic:248863"]
You can check the node capabilities with the following command:
[/quote]
This gave for the HiWiFi HC5962 as follows:
$ ssh root@fe80::d6ee:7ff:fe59:65ae%enp2s0
root@fe80::d6ee:7ff:fe59:65ae%enp2s0's password:
BusyBox v1.37.0 (2026-04-22 18:41:29 UTC) built-in shell (ash)
_______ ________ __
| |.-----.-----.-----.| | | |.----.| |_
| - || _ | -__| || | | || _|| _|
|_______|| __|_____|__|__||________||__| |____|
|__| W I R E L E S S F R E E D O M
-----------------------------------------------------
OpenWrt 25.12.2, r32802-f505120278 Dave's Guitar
-----------------------------------------------------
OpenWrt recently switched to the "apk" package manager!
OPKG Command APK Equivalent Description
------------------------------------------------------------------
opkg install <pkg> apk add <pkg> Install a package
opkg remove <pkg> apk del <pkg> Remove a package
opkg upgrade apk upgrade Upgrade all packages
opkg files <pkg> apk info -L <pkg> List package contents
opkg list-installed apk info List installed packages
opkg update apk update Update package lists
opkg search <pkg> apk search <pkg> Search for packages
------------------------------------------------------------------
For more information visit:
https://openwrt.org/docs/guide-user/additional-software/opkg-to-apk-cheatsheet
root@meshnode-65ae:~# mesh11sd wifi_chipset_detect
{
"System@d4:ee:07:59:65:af": {
"Distribution": "OpenWrt",
"Release": "25.12.2",
"Revision": "r32802-f505120278",
"Target": "ramips/mt7621",
"Architecture": "mipsel_24kc",
"Description": "OpenWrt 25.12.2 r32802-f505120278",
"Device": "HiWiFi HC5962",
"phy": {
"phy0": {
"Chipset": "MediaTek MT7603E (2.4 GHz)",
"Bands": [
"2.4GHz"
],
"Standards": [
"802.11n"
],
"MeshPoint": "802.11s",
"Wi-FiGeneration": "Wi-Fi 4",
"MIMO": "2x2",
"MaxChannelWidth": "40 MHz",
"ChannelWidthCap": false,
"Antennas": "2x2",
"TheoreticalMaxMbps": "300",
"TXQS": true,
"AIRTIME_FAIRNESS": true,
"AQL_Extended": true,
"AQL_Runtime": true,
"Driver": "mt7603e"
},
"phy1": {
"Chipset": "MediaTek MT76x2E (5 GHz)",
"Bands": [
"5GHz"
],
"Standards": [
"802.11ac",
"802.11n"
],
"MeshPoint": "802.11s",
"Wi-FiGeneration": "Wi-Fi 5",
"MIMO": "2x2",
"MaxChannelWidth": "80 MHz",
"ChannelWidthCap": true,
"Antennas": "2x2",
"TheoreticalMaxMbps": "868",
"TXQS": true,
"AIRTIME_FAIRNESS": true,
"AQL_Extended": true,
"AQL_Runtime": true,
"Driver": "mt76x2e"
}
}
}
}
root@meshnode-65ae:~#
The "dumb" router is a rebranded Arcadyan VRV9517 R01 provided years ago by an ISP. It's running its stock firmware.
The connection which didn't work was described above a few days ago. Briefly: ONT->Aradyan->wireless connection->Travel Router(receiver)->LAN-cable->Asus WAN. I've been using this wireless connection in the new house to connect my desktop to the internet until the Cat6 cable is installed (next week?). Its been steady, generally reliable, and manages upwards of 30Mbps for the desktop. However, when the WAN of the mesh master/Asus was also
connected via cable to the LAN the connection was slow and unstable, as described. This was no longer a problem once connected to the Arcadyan directly by cable.
1) Passwords for the wifi connections.
The "OWE by default (Opportunistic Wireless Encryption)" is a great way to test the configuration but I'd prefer password protection. How do I configure password protection?
2) Trialing for a while in "production".
3) Connect to the ONT.
After trialing the mesh for a while I'd prefer to connect the Asus directly to the ONT. I should be able to connect by cable directly, correct?
Simple.
From the documentation:
- mesh_gate_encryption (optional).
Determines whether this node's gate (Access Point) will be a encrypted.
Default: 0 (disabled).
Set to:
0 (none/owe-transition).
1 (sae, aka wpa3).
2 (sae-mixed, aka wpa2/wpa3).
3 (psk2, aka wpa2).
4 (Opportunistic Wireless Encryption - owe).- 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.
Lets say you want wpa3, that is option 1
To set these, SSH in turn to each meshnode, starting with the remote peer, and do:
service mesh11sd stop
uci set mesh11sd.setup.mesh_gate_encryption='1'
uci set mesh11sd.setup.mesh_gate_key='laugh-each-day'
uci commit mesh11sd
reboot;exit
Obviously set the key to your desired value.
It is important to stop mesh11sd and commit the changes and then reboot.
Once the device had booted back up and the heartbeat is back, try connecting again. This time you will have to enter the key value.
It will be a similar process to set other parameters eg the base SSID, but one thing at a time.
We can do this next, once you have tested the "wifi-password" and are happy with it.
You can probably see where this is going, all these extras can be baked into the Firmware Selector image (in the uci-defaults text box). Maybe, before you "go into production", you could rebuild the images with everything added, then keep the images as the perfect backup!