This is a bug where the regex used to lookup the default gateway and ping it can fail to lookup then right next-hop default address when the route table includes other routes of different masks for the default or 0.0.0.0/0 route.
This was discovered when a default route to 0.0.0.0/0 is added to route all ER traffic over a VPN tunnel. The route then discovered by eap_proxy will give an address of 0.0.0.0 to attempt to ping and a result will fail the ping test and restart the tunnel.
Proposed solutions:
Allow for a configurable address to ping
Discover the next-hop gateway address by adding the WAN interface name to the regex (only get the default gateway from the eap_proxy configured VLAN interface)
In the for loop ignore address that are not truly the default gateway (effectively ensure the netmask but also be 0.0.0.0 for it to match the regex)
This is a bug where the regex used to lookup the default gateway and ping it can fail to lookup then right next-hop default address when the route table includes other routes of different masks for the default or 0.0.0.0/0 route.
This was discovered when a default route to 0.0.0.0/0 is added to route all ER traffic over a VPN tunnel. The route then discovered by eap_proxy will give an address of 0.0.0.0 to attempt to ping and a result will fail the ping test and restart the tunnel.
Proposed solutions:
Allow for a configurable address to ping
Discover the next-hop gateway address by adding the WAN interface name to the regex (only get the default gateway from the eap_proxy configured VLAN interface)
In the for loop ignore address that are not truly the default gateway (effectively ensure the netmask but also be 0.0.0.0 for it to match the regex)