dpinger broken or Dashboard broken or my brain is broken....
-
try to ping the modem or the next hop to see where it stop working
-
@kiokoman
This is not the point, whatever causes the packet loss, it is not permanent, but dpinger never recovers -
if you restart the service does it start to work again?
is wan1 dhcp or static ? -
-
-
The Ranges of the "FritzBox" Modems are split so that 100-200 are in DHCP Pool, rest is static. So "DHCP=ON" is a bit misleading. Adresses 1-99 are in fact static.
-
yeah I see, anyway on pfsense it's set as static IP, I don't understand why dpinger does not recover in your case
-
@kiokoman : good to review, found a copy&paste mistake in the drawing, config is ok.
-
Ok, I guess it is a bug, not a misconfiguration, how to submit a bug?
-
you can do it here https://redmine.pfsense.org/
but maybe there is already a ticket for that, take a look at the list of open bugs before opening a new one -
Have you packet captured the ICMP pings on the WAN you think should be up when it is showing as down to see what is really going on?
If pfSense is sending the echo requests and there is no response, dpinger is doing everything it is supposed to be doing.
-
Like I wrote above:
The destination address is always responding, the interface is up and carrying massive traffic.
I was testing today again, during massive speedtest of my interface, the ping was delayed and for 1-2 seconds the dashboard widget was showing "offline", but recovered soon after.
My problem here seems to be that the status is getting unpredictable "stuck" showing 100% packet loss forever UNTIL I do any change to any gateway or the gatewaygroup.
So I have doubts that not sent or filtered ICMP responses are the real cause of this issue. -
Here another log example:
2020/09/25 09:38:37 I fiddled around with gateway settings to trigger the problematic gateway group to recover from OFFLINE that was set 2020/09/25 05:53:50
2020/09/26 13:46:28 gateway group OFFLINE again
2020/09/26 15:38:53 manual changing of gateway settings (usually setting default IPv4 gateway from automatic to the problematic gateway and back)
2020/09/26 20:37:51 gateway group OFFLINE again
2020/09/27 10:44:08 manual changing of gateway settings
2020/09/27 13:13:30 gateway group permanently OFFLINE again
-
A question:
netgate is utilizing the same core code for professional use, right?
They must experience the same issues, how can it come that related bug descriptions are not fixed for 1 year and longer?https://redmine.pfsense.org/issues/9450
-
@Pfosten said in dpinger broken or Dashboard broken or my brain is broken....:
Like I wrote above:
The destination address is always responding, the interface is up and carrying massive traffic.
I was testing today again, during massive speedtest of my interface, the ping was delayed and for 1-2 seconds the dashboard widget was showing "offline", but recovered soon after.
My problem here seems to be that the status is getting unpredictable "stuck" showing 100% packet loss forever UNTIL I do any change to any gateway or the gatewaygroup.
So I have doubts that not sent or filtered ICMP responses are the real cause of this issue.That is exactly why he asks you to do a packet capture, so the problem can be narrowed in to either something within pfsense or something external blocking your ICMP traffic.
-
On 2020/09/28 09:19:52 I was setting the default IPv4 gateway to WAN_PHY1_IGB0 which is resetting the status shown in the dashboard widget
Interface was able to carry traffic all the time!
Several times I pinged 8.8.4.4 as defined for gateway monitoring - always fine.
2020/09/28 21:59:22 the status shown in the dashboard widget changed to OFFLINE, even after that, interfaces is able to carry traffic by speedtest up to subscribed max + pingtest is fine.
-
Now tested with 2.5.0.a.20201101.1850
I still get for unknown reasons sometimes partial or full loss for alive-ping at one of the 2 WAN interfaces, but this is not the issue.
Nov 2 10:37:56 dpinger 16236 WAN_PHY1_IGB0GW 8.8.4.4: Alarm latency 0us stddev 0us loss 100%
Problem is that this status remains until any change to the gateway group is made - then it works immediately.
dpinger is not reattempting to reach the defined IP or the process maintaining the operational status is not taking over the changes.
-
Repeating the symptoms and posting screenshots still doesn't get anyone closer an explanation for what is going on in your setup. Make a packet capture on the WAN_PHY1_IGB0GW interface so you can actually determine if the problem is internal or external of pfsense to start with.
-
1st: I just wanted to state that with 2.5.0 I have the same issues
2nd: If the system is considering the IBG0 OFFLINE while I can ping successfully at the same time the configured 8.8.4.4 (and any other I treid before) by the help of the pfsense ping tool - I am pretty sure that the issue is inside the pfsense.
3rd: I will setup a external capturing if this helps -
You can make the capture within pfsense:
Diagnostics > Packet Capture
You can also limit it to capture icmp traffic to and from 8.8.4.4 so you don't get an unnecessarily large packet capture.
