I am using a GL-X3000 which has two WAN pathways. One of these is eth0 which connects to a PtP radio bridge. Multi-WAN mode is enabled in "failover" mode.
There are two IP addresses assigned to eth0: one is received from the DHCP server on the other end of the bridge, in the 192.168.1.0/24 subnet. The other is manually assigned in the 192.168.10.0/24 subnet so that I can access the PtP bridge devices' management UI. This is configured like so:
network.wan=interface
network.wan.device='eth0'
network.wan.proto='dhcp'
network.mgmt=interface
network.mgmt.proto='static'
network.mgmt.device='eth0'
network.mgmt.ipaddr='192.168.10.2'
network.mgmt.netmask='255.255.255.0'
kmwan.wan=member
kmwan.wan.interface='wan'
kmwan.wan.track_mode='force'
kmwan.wan.tracks='ping,1.1.1.1' 'ping,8.8.8.8' 'ping,208.67.222.222' 'ping,208.67.220.220'
When eth0 has been marked "dead" by kmwan, the liveness pings are originating from the management IP address 192.168.10.2. This subnet is not configured on the upstream router, so replies cannot route back:
# tcpdump -i eth0 -n "icmp or arp"
15:07:21.948649 IP 192.168.10.2 > 1.1.1.1: ICMP echo request, id 13415, seq 18561
This happens even though kmwan's own configuration message contains the correct address, according to the logs:
user.notice kmwan: config json str={ "op": 2, "data": { "cells": [ { "interface": "wan", "netdev": "eth0", "track_mode": "force", "addr_type": 4, "force_ip": "192.168.1.133", "tracks": [ ... ] } ] } }
So the tracker is not using the force_ip it was given.
While the tracker pings were failing as above, I inserted a NAT rule that forces the correct source address for a single test destination, and the path worked immediately:
# iptables -t nat -I POSTROUTING 1 -o eth0 -d 1.0.0.1 -j SNAT --to-source 192.168.1.133
# ping -c4 1.0.0.1
15:09:30.251164 IP 192.168.1.133 > 1.0.0.1: ICMP echo request, id 23527, seq 0
15:09:30.277888 IP 1.0.0.1 > 192.168.1.133: ICMP echo reply, id 23527, seq 0
Regular traffic can be corrected with a NAT rule as above, but the kmwan tracker's probes appear to be unaffected by NAT rules, so the interface never gets marked as recovered.
The liveness tracker should send its probes from the tracked interface's own address — which it already receives as force_ip in its configuration — regardless of what other addresses exist on the device or the dead/alive state of the route. With that, a recovered upstream would be detected and the interface would come back automatically.
Workaround
The only recovery I found is a full interface restart in which the WAN address is brought up before the management address — the tracker then correctly sources 192.168.1.x, receives replies, and the interface recovers. If management comes up first, it stays wedged. So the source appears to be chosen from whichever address is present on the device when the member comes up, rather than from force_ip.
Environment
- Firmware 4.8.3
kmod-gl-sdk4-kmwan 5.4.211+git-2025.304.07170-bb470c0-1- Kernel 5.4.211