TP-LINK Archer C2600 primary router running 24.10.1 loses WAN (wan, wan6) connectivity after some hours of normal operation. What do I need to capture to diagnose this next time?
Details:
This device has run many versions of OpenWRT for many years and has worked almost perfectly. The sysupgrade from 23.05.5 to 24.10.1 required fresh configuration, which I made almost identical to the previous one, but with a few differences including a new wan6 with ISP upstream.
The observed symptom is that all clients' Internet access works normally for some time - usually hours, then stops. The device is still up and running and in LuCi the Interfaces page looks normal with WAN devices (wan IPv4 DHCP, wan6 IPv6 DHCP, he6 IPv6 6in4 tunnel) showing assigned addresses, but while packets are transmitted (TX), none are received (RX) and when restarted the interface has no address. After a reboot, all interfaces are up and running normally.
When this happens again, what do I need to capture in order to diagnose this problem? My RTFM and STFW efforts so far have not yet provided the right clues.
I don't want to fill this post with irrelevancies and preemptive answers to questions, but here is a lightly redacted system log tail immediately following WAN loss and network configuration.
Sun Jun 15 21:25:44 2025 kern.info kernel: [ 0.000000] Booting Linux on physical CPU 0x0
...
Mon Jun 16 07:43:07 2025 kern.info kernel: [ 122.255578] br-lan: left allmulticast mode
Mon Jun 16 07:43:08 2025 kern.info kernel: [ 122.328868] br-lan: entered allmulticast mode
Mon Jun 16 07:43:08 2025 user.notice firewall: Reloading firewall due to ifup of Rlyeh (br-rlyeh)
Mon Jun 16 07:43:08 2025 daemon.notice netifd: radio0 (4789): sh: acs_survey: out of range
Mon Jun 16 07:43:08 2025 daemon.notice netifd: radio0 (4789): sh: acs_survey: out of range
Mon Jun 16 07:43:09 2025 daemon.notice wpa_supplicant[1341]: Set new config for phy phy0
Mon Jun 16 07:43:09 2025 daemon.notice hostapd: Set new config for phy phy0: /var/run/hostapd-phy0.conf
Mon Jun 16 07:43:09 2025 daemon.notice hostapd: Reloaded settings for phy phy0
Mon Jun 16 07:43:09 2025 daemon.notice wpa_supplicant[1341]: Set new config for phy phy1
Mon Jun 16 07:43:09 2025 daemon.notice hostapd: Set new config for phy phy1: /var/run/hostapd-phy1.conf
Mon Jun 16 07:43:09 2025 daemon.notice hostapd: Reloaded settings for phy phy1
Mon Jun 16 07:43:09 2025 daemon.notice netifd: radio0 (4789): command failed: No such device (-19)
Mon Jun 16 07:43:09 2025 daemon.notice netifd: Wireless device 'radio0' is now up
Mon Jun 16 07:43:09 2025 daemon.notice netifd: Wireless device 'radio1' is now up
Mon Jun 16 07:43:09 2025 daemon.notice netifd: radio1 (4792): command failed: No such device (-19)
Mon Jun 16 07:43:09 2025 daemon.info dnsmasq[1]: exiting on receipt of SIGTERM
Mon Jun 16 07:43:09 2025 daemon.err procd: Got unexpected signal 1
Mon Jun 16 07:43:09 2025 daemon.info dnsmasq[1]: started, version 2.90 cachesize 1000
Mon Jun 16 07:43:09 2025 daemon.info dnsmasq[1]: compile time options: IPv6 GNU-getopt no-DBus UBus no-i18n no-IDN DHCP no-DHCPv6 no-Lua TFTP no-conntrack no-ipset no-nftset no-auth no-cryptohash no-DNSSEC no-ID loop-detect inotify dumpfile
Mon Jun 16 07:43:09 2025 daemon.info dnsmasq[1]: UBus support enabled: connected to system bus
Mon Jun 16 07:43:09 2025 daemon.info dnsmasq[1]: using only locally-known addresses for test
Mon Jun 16 07:43:09 2025 daemon.info dnsmasq[1]: using only locally-known addresses for onion
Mon Jun 16 07:43:09 2025 daemon.info dnsmasq[1]: using only locally-known addresses for localhost
Mon Jun 16 07:43:09 2025 daemon.info dnsmasq[1]: using only locally-known addresses for local
Mon Jun 16 07:43:09 2025 daemon.info dnsmasq[1]: using only locally-known addresses for invalid
Mon Jun 16 07:43:09 2025 daemon.info dnsmasq[1]: using only locally-known addresses for bind
Mon Jun 16 07:43:09 2025 daemon.info dnsmasq[1]: reading /tmp/resolv.conf.d/resolv.conf.auto
Mon Jun 16 07:43:09 2025 daemon.info dnsmasq[1]: using nameserver 149.112.112.11#53
Mon Jun 16 07:43:09 2025 daemon.info dnsmasq[1]: using nameserver 9.9.9.11#53
Mon Jun 16 07:43:09 2025 daemon.info dnsmasq[1]: using nameserver 149.112.112.11#53
Mon Jun 16 07:43:09 2025 daemon.info dnsmasq[1]: using nameserver 9.9.9.11#53
Mon Jun 16 07:43:09 2025 daemon.info dnsmasq[1]: using nameserver 149.112.112.11#53
Mon Jun 16 07:43:09 2025 daemon.info dnsmasq[1]: using nameserver 9.9.9.11#53
Mon Jun 16 07:43:09 2025 daemon.info dnsmasq[1]: using nameserver 2620:fe::fe:11#53
Mon Jun 16 07:43:09 2025 daemon.info dnsmasq[1]: using nameserver 2620:fe::11#53
Mon Jun 16 07:43:09 2025 daemon.info dnsmasq[1]: using only locally-known addresses for test
Mon Jun 16 07:43:09 2025 daemon.info dnsmasq[1]: using only locally-known addresses for onion
Mon Jun 16 07:43:09 2025 daemon.info dnsmasq[1]: using only locally-known addresses for localhost
Mon Jun 16 07:43:09 2025 daemon.info dnsmasq[1]: using only locally-known addresses for local
Mon Jun 16 07:43:09 2025 daemon.info dnsmasq[1]: using only locally-known addresses for invalid
Mon Jun 16 07:43:09 2025 daemon.info dnsmasq[1]: using only locally-known addresses for bind
Mon Jun 16 07:43:09 2025 daemon.info dnsmasq[1]: read /etc/hosts - 12 names
Mon Jun 16 07:43:09 2025 daemon.info dnsmasq[1]: read /tmp/hosts/dhcp.cfg01411c - 29 names
Mon Jun 16 07:43:09 2025 daemon.info dnsmasq[1]: read /tmp/hosts/odhcpd - 6 names
Mon Jun 16 07:43:11 2025 daemon.info dnsmasq[1]: read /etc/hosts - 12 names
Mon Jun 16 07:43:11 2025 daemon.info dnsmasq[1]: read /tmp/hosts/dhcp.cfg01411c - 29 names
Mon Jun 16 07:43:11 2025 daemon.info dnsmasq[1]: read /tmp/hosts/odhcpd - 6 names
Mon Jun 16 07:52:54 2025 daemon.info dnsmasq[1]: read /etc/hosts - 12 names
Mon Jun 16 07:52:54 2025 daemon.info dnsmasq[1]: read /tmp/hosts/dhcp.cfg01411c - 29 names
Mon Jun 16 07:52:54 2025 daemon.info dnsmasq[1]: read /tmp/hosts/odhcpd - 12 names
Mon Jun 16 07:53:33 2025 daemon.info dnsmasq[1]: read /etc/hosts - 12 names
Mon Jun 16 07:53:33 2025 daemon.info dnsmasq[1]: read /tmp/hosts/dhcp.cfg01411c - 29 names
Mon Jun 16 07:53:33 2025 daemon.info dnsmasq[1]: read /tmp/hosts/odhcpd - 18 names
Mon Jun 16 08:01:50 2025 daemon.info dnsmasq[1]: read /etc/hosts - 12 names
Mon Jun 16 08:01:50 2025 daemon.info dnsmasq[1]: read /tmp/hosts/dhcp.cfg01411c - 29 names
Mon Jun 16 08:01:50 2025 daemon.info dnsmasq[1]: read /tmp/hosts/odhcpd - 24 names
Mon Jun 16 08:26:03 2025 kern.info kernel: [ 2698.080780] br-lan: left allmulticast mode
Mon Jun 16 08:26:03 2025 kern.info kernel: [ 2698.179484] br-lan: entered allmulticast mode
Mon Jun 16 08:41:45 2025 daemon.notice netifd: wan (3061): udhcpc: sending renew to server 69.55.40.1
Mon Jun 16 08:41:45 2025 daemon.notice netifd: wan (3061): udhcpc: lease of 69.55.40.118 obtained from 69.55.40.1, lease time 7200
Mon Jun 16 09:41:45 2025 daemon.notice netifd: wan (3061): udhcpc: sending renew to server 69.55.40.1
Mon Jun 16 09:41:45 2025 daemon.notice netifd: wan (3061): udhcpc: lease of 69.55.40.118 obtained from 69.55.40.1, lease time 7200
Mon Jun 16 10:06:47 2025 kern.warn kernel: [ 8742.229046] ath10k_pci 0001:01:00.0: wmi: fixing invalid VHT TX rate code 0xff
Mon Jun 16 10:34:00 2025 daemon.err uhttpd[2153]: [info] luci: accepted login on / for root from 172.17.2.110
This was a case of me not remembering exactly how this was initially set up, and it seemed to work, but I have now removed br-rlyeh and associated the Rlyeh interface with br-lan.
This behaviour persists and I'm no closer to identifying a cause, though I have eliminated the one new interface (wan6 from my ISP) and the operation of the upstream device (GPON ONT) as contributing factors.
Please connect to your OpenWrt device using ssh and copy the output of the following commands and post it here using the "Preformatted text </> " button:
Remember to redact passwords, MAC addresses and any public IP addresses you may have:
You have two network assigned to the same bridge. That will not work.
What is your intention in terms of those two networks? What are you trying to achieve, and what do you want each physical port to do with respect to the network memberships?
As you see above, I previously had a second bridge, br-rlyeh, associated with with the same devices as br-lan, but removed that for being wrong and associated the network rlyeh with bridge br-lan.
I want clients connecting to the wireless network R'lyeh to be assigned addresses from a DHCP pool in 172.17.3/24 while wired clients and clients on wireless network HALPlant to be assigned addresses from a DHCP pool in 172.17.2/24.
The clients on wireless network R'lyehshould not be able to connect to each other or to clients on 172.17.2/24, but should have access to the WAN(s).
Due to the equipment on the physical network, I do (and believe can) not use VLANs.
This appeared to work with the configuration before the upgrade and appears to work since the upgrade and reconfiguration. I consider "works" to be the minimum threshold and want it to be "right", so appreciate correction and direction.
I want
the LAN side of the physical network to just move packets, except for the isolation of wireless clients from each other,
the single wan Ethernet port which connects to my ISP's device to provide Internet access,
router to
a) allow all clients Internet access,
b) keep clients on 172.17.3/24 from accessing 172.17.2/24, and
c) allow wired and wireless clients on 172.17.2/24 to access wired clients on 172.17.2/24.
Despite my fondness for the command line interface, I also want to make all changes with LuCi in order to maintain a recorded and reproducible process.
Yes, I saw that. When you said you removed the second bridge, it wasn't clear that you had assigned both networks to the same bridge. That will not work.
Does this imply that the R'lyeh network is wireless only? If so, that's fairly easy to do.
If that network is indeed wifi only (and only on a single AP), this is easy.
If you have multiple APs broadcasting this second network, you will need to be able to use VLANs. There is no other way around it.
If it works, it's really just dumb luck because the configuration does not allow deterministic control over devices n the network.
All of these are fine, as long as you're only taking about the C2600 as the wifi AP and the R'lyeh network is wireless.
Writing br-lan instead of br-rlyeh - since corrected - didn't help. I don't intend to quibble about what it means to "work", since I want the configuration to be right, for which working is a necessary consequence.
It does. R'lyeh is a wireless network and only its clients should be on 172.17.3/24.
I'm tempted to explain how I did it wrong because I previously did it wrong and it worked, but again I'm interested in doing it right.
It is not a single AP. I have devices which are dumb APs and switches - ap1 and ap2 - in addition to router. These devices serve wireless networks HALPlant and R'lyeh, have all ports bridged, and are wired to router over Ethernet over powerline adapters which carry traffic for both networks.
Thank you for confirming my understanding. The future version of the network will have long Ethernet runs and VLANs.
Long away and far ago I had even less understanding, but ended up with this.
If I disable the R'lyeh wireless network on ap1 and ap2, thus serving it only on router, is the path to a right configuration straightforward?
I have no reservation making this change to see if it resolves the original problem, and am open to this as a potential long-term configuration.
You must use VLANs since you want to distribute multiple networks to multiple AP devices. As such, you need to replace your unmanaged switches.... but there are some scenarios that can make this a bit easier -- simply moving around some connections with your existing hardware (this may depend on the physical proximity of said devices, etc.).
Can you draw a system topology diagram, complete the brand+model of each of the devices and the port numbers for the connections? Additionally, it would be helpful if you could draw things "geographically" such that we can understand the physical proximity of the devices (just generally... like "this switch and AP2 are sitting together on a shelf" or "these are different rooms".
Yes, if you have just a single network (aside maybe from the main router having an extra wifi SSID), everything is pretty straight forward.
That said, another thing you should be aware of...
When you use wifi client isolation (which would be the general plan for R'lyeh), this only works on a per-AP basis. That is to say that if you have a client on that network connected to AP1, it would not be able to see any other clients on the same network on AP1, but it would be able to see clients on AP2 (on the same network). The isolation only applies to wifi-to-wifi connections on the same AP... ethernet connections are not isolated (and it's really hard to achieve this)... from a practical perspective, the clients on the AP2 appear to be ethernet connected from the perspective of the clients on AP1 and vice versa.
Thank you for your continuing help with this, @psherman. I appreciate both the effort to help resolve the WAN loss problem and increasing my understanding.
This I understand and will do in the future version of the network.
The TP-LINK Archer C2600v1 (router) and Archer A7v5 APs ap1 and ap2 (linked above) support VLANs and could be wired to properly provide the segregated networks, however the TP-LINK TL-PA8010P AV1200 Ethernet over Powerline (EoP) Adapters physically preclude this as both APs effectively connect to a single port on router.
For completeness: the CUDY GS1024 (which is none of these) unmanaged distribution switch which does not support 802.1Q (VLAN) is not in the phsyical network path.
If it will help, I will do this properly, but in ASCII with -- being Ethernet and ~~ being powerline:
The ONT connects to the WAN port and the EoP adapter connects to a LAN port on router in the basement with me, with ap2 on the floor above and ap1 on the floor above that.
By "extra wifi SSID" I infer that you mean R'lyeh in addition to HALPlant, as I currently have configured on router.
Understood, including how this compromises my desired isolation which is only properly achieved with VLANs or physically separate networks. The current configuration with separate DHCP pools and firewall rules appears to work sufficiently well with acceptable risks.
I have disabled SSID: R'lyeh on each radio on ap1 and ap2.
Do I need to make any further changes before waiting to see if this change resolves the (WAN loss) problem?
Disable the SSID for the R'lyeh network on the other APs.
Then create an empty bridge (the issue before was that you were using the ethernet ports in both bridges):
config device
option name 'br-rleyh'
option type 'bridge'
option bridge_empty '1'
Then modify the network to use the new bridge:
config interface 'Rlyeh'
option proto 'static'
option device 'br-rlyeh'
list ipaddr '172.17.3.1/24'
list dns '149.112.112.11'
list dns '9.9.9.11'
option delegate '0'
root@router:~# cat /etc/config/network
...
config interface 'Rlyeh'
option proto 'static'
option device 'br-rlyeh'
list ipaddr '172.17.3.1/24'
list dns '149.112.112.11'
list dns '9.9.9.11'
option delegate '0'
...
config device
option type 'bridge'
option name 'br-rlyeh'
option ipv6 '0'
option bridge_empty '1'
Rebooted router.
Attempting to connect a previously connected wireless client to R'lyeh, it prompts for the password, which I provided, then moments later reports that it "Could not connects to Wi-Fi network R'lyeh". Forgetting, then connecting did not help.
The only entries in the System log from this time referencing the client's MAC were
hostapd: phy0-ap0: AP-STA-DISCONNECTED 12:34:56:78:90:ab
hostapd: phy0-ap0: STA 12:34:56:78:90:ab IEEE 802.11: disassociated
hostapd: phy0-ap0: STA 12:34:56:78:90:ab IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)
Connections from this client to HALPlant work as normal.
Please connect to your OpenWrt device using ssh and copy the output of the following commands and post it here using the "Preformatted text </> " button:
Remember to redact passwords, MAC addresses and any public IP addresses you may have:
root@router:~# ubus call system board ; cat /etc/config/network /etc/config/wireless /etc/config/dhcp /etc/config/firewall
{
"kernel": "6.6.86",
"hostname": "router",
"system": "ARMv7 Processor rev 0 (v7l)",
"model": "TP-Link Archer C2600",
"board_name": "tplink,c2600",
"rootfs_type": "squashfs",
"release": {
"distribution": "OpenWrt",
"version": "24.10.1",
"revision": "r28597-0425664679",
"target": "ipq806x/generic",
"description": "OpenWrt 24.10.1 r28597-0425664679",
"builddate": "1744562312"
}
}
config interface 'loopback'
option device 'lo'
option proto 'static'
option ipaddr '127.0.0.1'
option netmask '255.0.0.0'
config globals 'globals'
option ula_prefix 'fd72:fd72:fd72::/48'
option packet_steering '1'
config device
option name 'br-lan'
option type 'bridge'
list ports 'lan1'
list ports 'lan2'
list ports 'lan3'
list ports 'lan4'
config interface 'lan'
option device 'br-lan'
option proto 'static'
option ipaddr '172.17.2.1'
option netmask '255.255.255.0'
option ip6assign '64'
list dns '149.112.112.11'
list dns '9.9.9.11'
option delegate '0'
config interface 'wan'
option device 'wan'
option proto 'dhcp'
option peerdns '0'
list dns '149.112.112.11'
list dns '9.9.9.11'
config interface 'wan6'
option device 'wan'
option proto 'dhcpv6'
option reqaddress 'try'
option reqprefix 'auto'
option norelease '1'
option peerdns '0'
list dns '2620:fe::fe:11'
list dns '2620:fe::11'
config interface 'Rlyeh'
option proto 'static'
option device 'br-rlyeh'
list ipaddr '172.17.3.1/24'
list dns '149.112.112.11'
list dns '9.9.9.11'
option delegate '0'
config interface 'he6'
option proto '6in4'
option peeraddr '202.32.147.2'
option ip6addr '2210:120:5:89a::2/64'
option tunnelid '123456'
option username 'root'
option password 'password1'
option mtu '1480'
list ip6prefix '2210:120:b55a::/48'
config device
option type 'bridge'
option name 'br-rlyeh'
option ipv6 '0'
option bridge_empty '1'
config wifi-device 'radio0'
option type 'mac80211'
option path 'soc/1b700000.pci/pci0001:00/0001:00:00.0/0001:01:00.0'
option band '2g'
option channel 'auto'
option htmode 'HT40'
option country 'US'
option cell_density '0'
config wifi-iface 'default_radio0'
option device 'radio0'
option network 'lan'
option mode 'ap'
option ssid 'HALPlant'
option encryption 'sae'
option isolate '1'
option key 'password!'
option ieee80211r '1'
option mobility_domain '4A57'
option ft_over_ds '0'
option ocv '0'
config wifi-device 'radio1'
option type 'mac80211'
option path 'soc/1b500000.pci/pci0000:00/0000:00:00.0/0000:01:00.0'
option band '5g'
option channel 'auto'
option htmode 'VHT80'
option country 'US'
option cell_density '0'
config wifi-iface 'default_radio1'
option device 'radio1'
option network 'lan'
option mode 'ap'
option ssid 'HALPlant'
option encryption 'sae'
option isolate '1'
option key 'password!'
option ieee80211r '1'
option mobility_domain '4A57'
option ft_over_ds '0'
option ocv '0'
config wifi-iface 'wifinet2'
option device 'radio0'
option mode 'ap'
option ssid 'R'\''lyeh'
option encryption 'sae-mixed'
option key 'p@ssw0rd'
option ieee80211r '1'
option mobility_domain '7594'
option ft_over_ds '0'
option ocv '0'
option network 'Rlyeh'
option isolate '1'
config wifi-iface 'wifinet3'
option device 'radio1'
option mode 'ap'
option ssid 'R'\''lyeh'
option encryption 'sae-mixed'
option isolate '1'
option key 'p@ssw0rd'
option ieee80211r '1'
option mobility_domain '7594'
option ft_over_ds '0'
option ocv '0'
option network 'Rlyeh'
config dnsmasq
option domainneeded '1'
option localise_queries '1'
option rebind_protection '1'
option rebind_localhost '1'
option domain 'halplant.net'
option expandhosts '1'
option cachesize '1000'
option authoritative '1'
option readethers '1'
option leasefile '/tmp/dhcp.leases'
option resolvfile '/tmp/resolv.conf.d/resolv.conf.auto'
option localservice '1'
option ednspacket_max '1232'
list interface 'lan'
option dhcpleasemax '253'
config dhcp 'lan'
option interface 'lan'
option start '2'
option limit '252'
option leasetime '12h'
option dhcpv4 'server'
option dhcpv6 'server'
option ra 'server'
list dhcp_option '6,172.17.2.53'
list ntp '0.us.pool.ntp.org'
list ntp '1.us.pool.ntp.org'
list ntp '2.us.pool.ntp.org'
list ntp '3.us.pool.ntp.org'
option ndp 'relay'
list dns 'fd72:fd72:fd72:0:5ae5:d558:8934:4ea6'
config dhcp 'wan'
option interface 'wan'
option ignore '1'
config odhcpd 'odhcpd'
option maindhcp '0'
option leasefile '/tmp/hosts/odhcpd'
option leasetrigger '/usr/sbin/odhcpd-update'
option loglevel '4'
config host
option name 'notarealone'
option ip '172.17.2.100'
list mac 'AA:BB:CC:DD:EE:FF'
option hostid '0100'
option dns '1'
config dhcp 'Rlyeh'
option interface 'Rlyeh'
option start '100'
option limit '150'
option leasetime '12h'
config defaults
option input 'REJECT'
option output 'ACCEPT'
option forward 'REJECT'
option synflood_protect '1'
config zone
option name 'lan'
list network 'lan'
option input 'ACCEPT'
option output 'ACCEPT'
option forward 'ACCEPT'
config zone
option name 'wan'
option input 'REJECT'
option output 'ACCEPT'
option forward 'REJECT'
option masq '1'
option mtu_fix '1'
list network 'wan'
list network 'wan6'
list network 'he6'
config forwarding
option src 'lan'
option dest 'wan'
config rule
option name 'Allow-DHCP-Renew'
option src 'wan'
option proto 'udp'
option dest_port '68'
option target 'ACCEPT'
option family 'ipv4'
config rule
option name 'Allow-Ping'
option src 'wan'
option proto 'icmp'
option icmp_type 'echo-request'
option family 'ipv4'
option target 'ACCEPT'
config rule
option name 'Allow-IGMP'
option src 'wan'
option proto 'igmp'
option family 'ipv4'
option target 'ACCEPT'
config rule
option name 'Allow-DHCPv6'
option src 'wan'
option proto 'udp'
option dest_port '546'
option family 'ipv6'
option target 'ACCEPT'
config rule
option name 'Allow-MLD'
option src 'wan'
option proto 'icmp'
option src_ip 'fe80::/10'
list icmp_type '130/0'
list icmp_type '131/0'
list icmp_type '132/0'
list icmp_type '143/0'
option family 'ipv6'
option target 'ACCEPT'
config rule
option name 'Allow-ICMPv6-Input'
option src 'wan'
option proto 'icmp'
list icmp_type 'echo-request'
list icmp_type 'echo-reply'
list icmp_type 'destination-unreachable'
list icmp_type 'packet-too-big'
list icmp_type 'time-exceeded'
list icmp_type 'bad-header'
list icmp_type 'unknown-header-type'
list icmp_type 'router-solicitation'
list icmp_type 'neighbour-solicitation'
list icmp_type 'router-advertisement'
list icmp_type 'neighbour-advertisement'
option limit '1000/sec'
option family 'ipv6'
option target 'ACCEPT'
config rule
option name 'Allow-ICMPv6-Forward'
option src 'wan'
option dest '*'
option proto 'icmp'
list icmp_type 'echo-request'
list icmp_type 'echo-reply'
list icmp_type 'destination-unreachable'
list icmp_type 'packet-too-big'
list icmp_type 'time-exceeded'
list icmp_type 'bad-header'
list icmp_type 'unknown-header-type'
option limit '1000/sec'
option family 'ipv6'
option target 'ACCEPT'
config rule
option name 'Allow-IPSec-ESP'
option src 'wan'
option dest 'lan'
option proto 'esp'
option target 'ACCEPT'
config rule
option name 'Allow-ISAKMP'
option src 'wan'
option dest 'lan'
option dest_port '500'
option proto 'udp'
option target 'ACCEPT'
config zone
option name 'rlyeh'
option input 'REJECT'
option output 'ACCEPT'
option forward 'ACCEPT'
list network 'Rlyeh'
config forwarding
option src 'rlyeh'
option dest 'wan'
Again I removed the many static lease entries.
I found an error in the key for R'lyeh on router which evaded notice all these years. Fixing it, the client now appears to fail DHCP, reporting "Obtaining IP address..." a few times before failing with "IP configuration failure".
I don't see a DHCP server for your R'lyeh network.
Other things:
You don't allow input to the router, but you don't have rules to allow DHCP and DNS:
Do not use sae-mixed -- use either WPA2 (psk2) or WPA3 (sae).
Also, for this network, you should remove all 802.11r lines since there is only one AP involved here. (I actually recommend removing it in all cases since it tends to cause more problems than it solves, but that's secondary.)
I updated my previous response coincident with your reply, so to maintain the timeline I'll repeat it:
I found an error in the key for R'lyeh on router which evaded notice all these years. Fixing it, the client now appears to fail DHCP, reporting "Obtaining IP address..." a few times before failing with "IP configuration failure".
This fits with your observation that
however on the Network > Interfaces page in LuCi, [Edit]ing interface Rlyeh and examining the DHCP Server tab, it shows the same settings as always, which previously worked.
Given that this worked before but clients were connecting to ap1 or ap2, not router, pending a better config, I changed Input for rlyeh ⇒ wan from Reject to Accept in Network > Firewall, matching the setting for lan ⇒ wan.
This resulted in no change to the client's apparent inability to obtain a DHCP lease.
This setting, which has also been working for all APs for years, was originally to accommodate devices which could not use WPA3. Now I may be able to change this to WPA3, but will defer this change for later.
Removed.
Noted. I added it to some time back to address certain wireless clients losing connections while moving and it seemed to resolve the problem at the time without creating any new problems.
As much as I prefer to be seen to follow instructions, I see in the Devices & Ports tab of the Network > DHCP & DNS page,
Listen interfaces: lan
I changed this to
Listen interfaces: lan Rlyeh
and in the Limits tab changed
Max. DHCP leases: 253
to
Max. DHCP leases:
and [Save & Apply]ed.
The wireless client is now connected and has an address on 172.17.3/24.
Thank you for all your time, attention, instruction and advice.
Tomorrow I'll review this all with less tired eyes to learn if I actually understood everything, then use this and the current working config to improve it until things break, then fix them.
