Gateway monitor down
-
@kevindd992002 why are you running the pcscd service ?
It may not be helping ... -
That's a good point, you could certainly add the patch disables that.
But usually that causes excess memory use not CPU. -
@hda said in Gateway monitor down:
@kevindd992002 why are you running the pcscd service ?
It may not be helping ...I'm not running it intentionally. It is enabled by default since 2.5.0.
@stephenw10 said in Gateway monitor down:
That's a good point, you could certainly add the patch disables that.
But usually that causes excess memory use not CPU.Thanks. I just added that system patch.
-
@stephenw10 said in Gateway monitor down:
Mmm, there are only two things I'm aware of that can produce behaviour like that in pfSense.
-
Active traffic shaping.
-
A bug in 21.05 that affected the SG-3100.
Is there a system patch to this bug as well?
-
-
It was fixed in 21.05.1. https://docs.netgate.com/pfsense/en/latest/releases/21-05-1.html
It only affected multicore arm32 anyway. It would have been the same on your old ISP.
Steve
-
I see. Since my firewalls are really just for home use (not mission critical), can I just upgrade to the 2.6.x CE dev release to get all the latest updates? I know Christian McDonald is suggesting to do this.
-
Yes, I would do that. I have been running 2.6/22.01 on my primary router her for months now.
Obviously be sure to backup first and have a copy of the 2.5.2 installer on hand anyway.
Steve.
-
@stephenw10 said in Gateway monitor down:
Yes, I would do that. I have been running 2.6/22.01 on my primary router her for months now.
Obviously be sure to backup first and have a copy of the 2.5.2 installer on hand anyway.
Steve.
And when 2.6 stable comes out, can I simply upgrade from dev to latest stable without any issues?
As for the pcscd patch that I just applied, I'm assuming I should just delete the entry after upgrading to dev (without reverting) as jim mentioned here, correct?
-
Yes and yes.
-
@stephenw10 said in Gateway monitor down:
Yes and yes.
After updating, I got this crash report error right after logging into the GUI:
Crash report begins. Anonymous machine information: amd64 12.3-STABLE FreeBSD 12.3-STABLE devel-12-n226728-3672bd5377a pfSense Crash report details: PHP Errors: [27-Dec-2021 18:27:56 UTC] PHP Warning: PHP Startup: Unable to load dynamic library 'zmq.so' (tried: /usr/local/lib/php/20190902/zmq.so (Cannot open "/usr/local/lib/php/20190902/zmq.so"), /usr/local/lib/php/20190902/zmq.so.so (Cannot open "/usr/local/lib/php/20190902/zmq.so.so")) in Unknown on line 0 No FreeBSD crash data found.Is that pretty much expected with snapshots?
-
If it was during the update it could well have been since the library version may have been updated resulting in the wrong lib being present at some point.
As long as it doesn't return if you remove it a reboot you're fine.Steve
-
@stephenw10 said in Gateway monitor down:
If it was during the update it could well have been since the library version may have been updated resulting in the wrong lib being present at some point.
As long as it doesn't return if you remove it a reboot you're fine.Steve
Yeah, it didn't show anymore after a reboot so I'm good. Although the upgrade to dev didn't really fix the latency issue, it seems to be better now and I'm still convinced that it's an ISP issue. I'm having a 24ms RTT to 8.8.8.8 now which is ideal but RTTsd is still erratic. What does a high RTTsd mean?
-
It means there's a large variation in ping round-trip times. Standard Deviation.
Steve
-
@stephenw10 Right, that I get. But does this usually to translate to an unstable Internet experience?
-
Probably not, it depends how high you are seeing. But, for exmaple, if all your pings are exactly 10.0ms and then you see one at 10.9 that's going to be a high deviation. You would not notice a 0.9ms change though.
Steve
-
@stephenw10 said in Gateway monitor down:
Probably not, it depends how high you are seeing. But, for exmaple, if all your pings are exactly 10.0ms and then you see one at 10.9 that's going to be a high deviation. You would not notice a 0.9ms change though.
Steve
Ok, then this is super insane, wouldn't you say?
-
It's certainly much larger than I would expect. Rttsd values are usually and order or mangnitune less than the actuall RTT time. Like:
Name Monitor Source Delay StdDev Loss Status Substatus BT_DHCP6 fe80::2621:24ff:fed9:623f%pppoe1 fe80::fad1:11ff:fec1:5b57%pppoe1 2.566ms 0.282ms 0.0% online none PROTONVPN_VPNV4 10.24.0.1 10.24.0.9 227.778ms 60.327ms 0.0% online delay WAN2 8.8.4.4 xx.xxx.xxx.xxx 3.243ms 0.337ms 0.0% online none WAN_PPPOE 8.8.8.8 yy.yyy.yyy.yy 6.194ms 0.132ms 0.0% online noneAre you actually seeing ping spikes to 8.8.4.4?
Steve
-
Right now, I do. But that's probably because there was a recent submarine cable cut in SEA that our ISP is using. The latency problem, however, started happening way before that submarine cable cut issue. I tried using the mtr package and I see the same spikes after 100 pings to each hop.
-
Might just be how your link behaves then.
