Project

General

Profile

Bug #2910

monitoring-disabled gateway causes wrong tiered gateway in route-to

Added by Chris Buechler about 7 years ago. Updated over 6 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
-
Category:
Gateways
Target version:
Start date:
03/25/2013
Due date:
% Done:

100%

Estimated time:
Affected Version:
All
Affected Architecture:

Description

When there is a tier 1 gateway that's being monitored, and a tier 2 gateway with monitoring disabled, the system skips the tier 1 gateway when its status is online as if it were down. Take the attached config for instance, 192.168.15.1 is never the gateway used in the route-to in the ruleset, even when Status>Gateways shows it as up.

Associated revisions

Revision f4a8e38c (diff)
Added by Ermal Luçi over 6 years ago

Resolves #2910. Make apinger write its status file just after starting so that thing work as expected

Revision 63356262 (diff)
Added by Ermal Luçi over 6 years ago

Resolves #2910. Make apinger write its status file just after starting so that thing work as expected

Revision 265be6f5 (diff)
Added by Ermal Luçi over 6 years ago

Resolves #2910. Make apinger write its status file just after starting so that thing work as expected

History

#1 Updated by Renato Botelho about 7 years ago

  • Status changed from New to Feedback

Could not reproduce it here using latest snapshot, tier1 was used as expected on rules when it's up.

#2 Updated by Louis-David Perron almost 7 years ago

Hi Chris and Renato.

I have the exact same issue. My tier2 gateway monitoring is disabled. It's a PPP interface through a 3G stick.

I have 2.0.3, and I don't remember seeing this bug in 2.0.

Everytime the PPP reconnects, the route-to goes to ppp0, instead of em1 (my Tier1 interface).
I can reproduce the bug every time I execute rc.newwanip.

If I do a filter reload later, the route-to goes back to em1, like expected. So I believe that this is because filter_configure() is executed too rapidly after setup_gateways_monitor() in rc.newwanip.

To prove my point, I added a sleep, and can't reproduce the bug anymore:

/* reconfigure our gateway monitor /
setup_gateways_monitor();
sleep(5); // sleep(2); wasn't enough.
/
signal filter reload */

I'm running pfSense on Atom machines (with SSD), so it may be because of your CPU speed you can't reproduce this bug, or either this bug already been fixed in the snapshot.

Note, if both gateways has monitoring enabled, without my sleep, I get this in the logs. With the sleep, this message is gone:
May 16 14:12:17 chafw001 php: : Gateways status could not be determined, considering all as up/active.

Thanks

#3 Updated by Renato Botelho almost 7 years ago

  • Status changed from Feedback to New

#4 Updated by Ermal Luçi over 6 years ago

  • Status changed from New to Feedback
  • % Done changed from 0 to 100

#5 Updated by Ermal Luçi over 6 years ago

#6 Updated by Ermal Luçi over 6 years ago

  • % Done changed from 100 to 0

I pushed some fixes for this.
On newer snapshots it should behave as expected.

#7 Updated by Ermal Luçi over 6 years ago

  • % Done changed from 0 to 100

#8 Updated by Ermal Luçi over 6 years ago

#9 Updated by Chris Buechler over 6 years ago

  • Status changed from Feedback to Resolved

fixed

Also available in: Atom PDF