Apinger (yes, ANOTHER thread about this, but with a twist)
-
yes, i know there are probably umpteen million threads on this, just chiming in reporting what has been said already.
start apinger, do a speedtest over on dslreports, apinger goes to high rtt, disconnects gateways, then goes to 0 rtt, gateways come back up and apinger reports 0-5ms ping (normal is ~18-25ms at idle) until restarted.
log snippet showing it rapidly omitting gateways, then after several times of this it just breaks:
May 26 04:43:17 syslogd: kernel boot file is /boot/kernel/kernel May 26 04:53:22 check_reload_status: Restarting ipsec tunnels May 26 04:53:22 check_reload_status: Restarting OpenVPN tunnels/interfaces May 26 04:53:22 check_reload_status: Reloading filter May 26 04:53:23 php-fpm[24021]: /rc.dyndns.update: MONITOR: WAN_PPPOE has high latency, omitting from routing group LB May 26 04:53:23 php-fpm[24021]: /rc.dyndns.update: MONITOR: WAN2_PPPOE has high latency, omitting from routing group LB May 26 04:53:23 php-fpm[24021]: /rc.dyndns.update: Gateways status could not be determined, considering all as up/active. (Group: LB) May 26 04:53:23 php-fpm[24021]: /rc.dyndns.update: phpDynDNS (all.dnsomatic.com): No change in my IP address and/or 25 days has not passed. Not updating dynamic DNS entry. May 26 04:53:24 php-fpm[50009]: /rc.filter_configure_sync: MONITOR: WAN_PPPOE has high latency, omitting from routing group LB May 26 04:53:24 php-fpm[50009]: /rc.filter_configure_sync: MONITOR: WAN2_PPPOE has high latency, omitting from routing group LB May 26 04:53:24 php-fpm[50009]: /rc.filter_configure_sync: Gateways status could not be determined, considering all as up/active. (Group: LB) May 26 04:53:24 check_reload_status: updating dyndns WAN2_PPPOE May 26 04:53:24 check_reload_status: Restarting ipsec tunnels May 26 04:53:24 check_reload_status: Restarting OpenVPN tunnels/interfaces May 26 04:53:24 check_reload_status: Reloading filter May 26 04:53:25 php-fpm[50009]: /rc.dyndns.update: MONITOR: WAN_PPPOE has high latency, omitting from routing group LB May 26 04:53:25 php-fpm[50009]: /rc.dyndns.update: MONITOR: WAN2_PPPOE has high latency, omitting from routing group LB May 26 04:53:25 php-fpm[50009]: /rc.dyndns.update: Gateways status could not be determined, considering all as up/active. (Group: LB) May 26 04:53:25 php-fpm[50009]: /rc.filter_configure_sync: MONITOR: WAN_PPPOE has high latency, omitting from routing group LB May 26 04:53:25 php-fpm[50009]: /rc.filter_configure_sync: MONITOR: WAN2_PPPOE has high latency, omitting from routing group LB May 26 04:53:25 php-fpm[50009]: /rc.filter_configure_sync: Gateways status could not be determined, considering all as up/active. (Group: LB) May 26 04:53:58 check_reload_status: updating dyndns WAN2_PPPOE May 26 04:53:58 check_reload_status: Restarting ipsec tunnels May 26 04:53:58 check_reload_status: Restarting OpenVPN tunnels/interfaces May 26 04:53:58 check_reload_status: Reloading filter May 26 04:53:59 check_reload_status: updating dyndns WAN_PPPOE May 26 04:53:59 check_reload_status: Restarting ipsec tunnels May 26 04:53:59 check_reload_status: Restarting OpenVPN tunnels/interfaces May 26 04:53:59 check_reload_status: Reloading filterthat's where the typical complaint stops however. i have two internet connections (try getting anything above 3Mbps dsl out here, it doesn't happen), and apinger is tightly tied into failover and whatnot, which is important for such a setup, and for me the problem consistently reproducible. i am not versed in delving into what makes apinger tick, but i know the devs are, so here is my proposal; i have a setup that can without fail, fail, and i'm sure that a bunch of people would like to see this issue squished seeing how important it is, so if someone from the dev team wants to contact me you can have access to a system that has this chronic issue to dink around with (as long as you try not to break it too much, since it is my in-use router).
-
When you max out your internet connection, then the traffic from Apinger gets in the cue.
Thats why it reports GW offline. You saturate your bandwith and thats why it fails.
-
When you max out your internet connection, then the traffic from Apinger gets in the cue.
Thats why it reports GW offline. You saturate your bandwith and thats why it fails.
apinger pings are set to a higher priority queue (icmp ping anything goes in qAck, which is set to 7), and regardless it shouldn't outright stop working, it should return to normal operation once everything is cleared up (which it doesn't do either). if this behavior is normal then apinger wouldn't exist in the first place as watching a video, downloading mp3s, updating a game, etc… would just break it anyway, rendering it useless for any environment. what should happen (and what it used to do on 2.1.5 on the occasion that it did work) is stop sending traffic to an overloaded interface and route it elsewhere, if all interfaces are overloaded then whatever (it's been so long since i've seen it work that i forget what it did, but i know it didn't just punch out and leave). i dislike having to just disable apinger because then if something does break there's no internet at all (or rather, it's 50/50).
as for what i remember apinger doing otherwise is that if a connection would experience high ping or packetloss it would route any new connections over to the other line and continue monitoring the faulty line and when the fault was fixed it would once again allow connections on both lines (as expected), and at all times it would provide accurate ping and packetloss numbers. now, it's useless because the only legit faults it detects are when i do something liek reboot a modem or turn off a modem, and in the meantime it does nothing but reset connections all day long (which doesn't help when the congested backbone i'm on already causes enough of this) whenever i try to do something productive. also of note is that when apinger reports a high ping at idle (say 100ms), i can do a ping from pfsense to the same ip over the same interface and get a much more reasonable number (~25-35ms), so that doesn't help anything.
-
When you max out your internet connection, then the traffic from Apinger gets in the cue.
Thats why it reports GW offline. You saturate your bandwith and thats why it fails.
He's not concerned about how apinger thinks the interface is offline, he's concerned how apinger thinks the interface comes back online and reports the wrong information. apinger has a known bug that gives false readings.