Bug #10551
closedgateway group not restoring the higher tier gateway
0%
Description
Not knowing the technical details, it's unclear to me if this is related to this bug,
https://redmine.pfsense.org/issues/10546
or perhaps this:
https://redmine.pfsense.org/issues/10397
while receiving notifcations that the gateway is being added back to the gateway group after momentarily being set down (for latency, packet loss) it fails to update. Here's is the output in normal gateway state from /tmp/rules.debug
GWCABLE_DHCP = " route-to ( hn0 184.xxx.xxx.97 ) "
GWDSL_PPPOE = " route-to ( pppoe0 206.xxx.xxx.132 ) "
GWCable_failover = " route-to { ( hn0 184.xxx.xxx.97 ) } "
GWDSL_Failover = " route-to { ( pppoe0 206.xxx.xxx.132 ) } "
GWLoad_Balance = " route-to { ( hn0 184.xxx.xxx.97 ) ( pppoe0 206.xxx.xxx.132 ) } round-robin "
and here is the output after it successfully fails over to tier 2 (dsl), yet fails to add the tier 1 (cable) gateway back despite receiving the notification that it is doing so (it also happens the other way if the dsl is set to down)
- Gateways
GWCABLE_DHCP = " route-to ( hn0 184.xxx.xx.97 ) "
GWDSL_PPPOE = " route-to ( pppoe0 206.xxx.xxx.132 ) "
GWCable_failover = " route-to { ( pppoe0 206.xxx.xxx.132 ) } "
GWDSL_Failover = " route-to { ( pppoe0 206.xxx.xxx.132 ) } "
GWLoad_Balance = " route-to { ( pppoe0 206.xxx.xxx.132 ) } "
the 2.5 bug doesn't seem directly related (?) because after resetting the filters (restoring the tier 1) the double default gateway exists and it will still function as intended if the gateway group was specified inside the advanced section of the default lan rule or other rule