dpinger question (new behavior in 24.03-RELEASE?)

ludensen

First my simple setup:
Internet-box (5G) > Netgate SG-2220 (24.03-RELEASE) > LAN

After reading through some log-files - I can trace/follow back 3 events - that my internet-box apparently reboots every 3 weeks.
pfSense's WAN-interface is down for 2-3 min., dpinger quits and it triggers '/rc.newwanip' (which does not (re)start dpinger - I know).

After I upgraded to 24.03-RELEASE (from pfSense+ 24.03.r.20240416.0005), the have been 2 internet-box restarts.
Every time I had to restart dpinger myself.

Using pfSense+ 24.03.r.20240416.0005 and earlier (before upgrading to 24.03-RELEASE) there is only one event of the internet-box restarting and dpinger is restartet right away.
(I'm limited by the standard 'Maximum 500' log entries - and need to deploy greylog!)
There are no prior entries about restarting dpinger in pfSense-logs, my own IT-log/notes (or my mind ).

In this time-span there have been no other changes or upgrades to my setup - that I'm aware of.

Is this

a coincidence?
a known behavior?
below the bagatelle-limit (can't remember the English expression)?
a less than minor bug?

[Edit: see post below instead]
~~2) In the 'Gateways' log there are many 'spurious' "exiting on signal 15" and pronto restarts. Is that normal?~~

I haven't deemed it necessary to append log- and conf-files, but can of course do so...

BSD-regards
a long time private pfSense user

PS.
My knowledge-level is "know enough to be dangerous", but I'm trying to contribute...
PPS.
Yes, I know the SG-2220 is EOL'ed - I bought it to have a stand-alone firewall, because I could afford it and to experience Netgate hardware.
I was quite surprised, when it could still run pfSense PLUS - but I appreciate a ZFS-filesystem

ludensen

@ludensen said in dpinger question (new behavior in 24.03-RELEASE?):

~~2) In the 'Gateways' log there are many 'spurious' "exiting on signal 15" and pronto restarts. Is that normal?~~

Sorry for speaking nonsense - 'spurious' is something completely different!

Looking in my 'Gateways' log, there are more (random time) entries of:

dpinger 	80311 	exiting on signal 15
dpinger 	84310 	send_interval 2000ms loss_interval 6000ms time_period 60000ms report_interval 0ms data_len 1 alert_interval 4000ms latency_alarm 500ms loss_alarm 20% alarm_hold 40000ms dest_addr 2.22.31.178 bind_addr 192.168.32.21 identifier "WAN_DHCP "

than 'Alarm latency' and 'sendto error' entries.
Is that normal (with a 5G WAN connection)?

[Edit]
To quantify my claim (ADD!?):
Number of events in log during the last 2 months
"Signal 15" - 31 events
*Alarm latency" - 15 events
"sendto error" - 9 events
(repeated events counted as multiple)

stephenw10

Check the system log at that time. Something is restarting dpinger, that could be a number of things.

Do you actually see latency or packet loss alarms? Any wireless connection like that can be variable, you might see loss or latency so you may need to tune those values.

Which sendto error are you seeing?

ludensen

@stephenw10 said in dpinger question (new behavior in 24.03-RELEASE?):

Which sendto error are you seeing?

Thank-you for taking the time to answer!
It was mostly 'sendto error 65' and a few 'sendto error 50'.

Then I will answer my 2nd question:

Is that normal (with a 5G WAN connection)?

No, it's not normal

Right after starting this thread I searched in my notes to find out, why I chose that IP-address from my ISP as 'Monitor IP' - probably something with the least number of jumps...
To rule out that that IP provoked the errors, I changed the 'Monitor IP' to Quad9 - my DNS-provider.
... and since then there have been no 'sendto error xx' in the 'Gateways' log - only a few 'Alarm latency' and 2 'dpinger exiting on signal 15' where dpinger did restart. Both correlating with:

Jun 17 02:19:17 	check_reload_status 	610 	Reloading filter
Jun 17 02:19:17 	check_reload_status 	610 	Restarting OpenVPN tunnels/interfaces
Jun 17 02:19:17 	check_reload_status 	610 	Restarting IPsec tunnels
Jun 17 02:19:17 	check_reload_status 	610 	updating dyndns WAN_DHCP
Jun 17 02:19:17 	rc.gateway_alarm 	84325 	>>> Gateway alarm: WAN_DHCP (Addr:192.168.84.42 Alarm:down RTT:0ms RTTsd:0ms Loss:100%)

and those were the only 'gateway_alarm's in the 'General' log - so correlation.

Now to my first question:

Is this <snip> a coincidence? <snip> or minor bug?

The next restart of my 5G-box is (probably) 2024-07-01, but I guess it can be simulated by removing the network-cable between the 5G-box and SG-2220 for 2-3 min. - and doing that stopped and restarted dpinger

"Correlation does not imply causation" - so right now I can only call my observation a coincidence.

Does my train of thought look sane?

Have a nice day

stephenw10

Yes that does seem like the monitor target was simply not prioritising pings and dropping them under load.