What is the meaning of this dpinger log entry?
-
What does this mean (Status → System Logs → System → Gateways):
Apr 8 09:00:48 dpinger 71051 WAN_DHCP 100.93.160.1: sendto error: 64 Apr 8 09:00:48 dpinger 71051 WAN_DHCP 100.93.160.1: sendto error: 64 Apr 8 09:00:49 dpinger 71051 WAN_DHCP 100.93.160.1: sendto error: 64 Apr 8 09:00:49 dpinger 71051 WAN_DHCP 100.93.160.1: sendto error: 64 Apr 8 09:00:50 dpinger 71051 WAN_DHCP 100.93.160.1: sendto error: 64 Apr 8 09:00:50 dpinger 71051 WAN_DHCP 100.93.160.1: sendto error: 64 Apr 8 09:00:51 dpinger 71051 WAN_DHCP 100.93.160.1: sendto error: 64 Apr 8 09:00:51 dpinger 71051 WAN_DHCP 100.93.160.1: sendto error: 64 Apr 8 09:00:52 dpinger 71051 WAN_DHCP 100.93.160.1: sendto error: 64 Apr 8 09:00:52 dpinger 71051 WAN_DHCP 100.93.160.1: sendto error: 64 Apr 8 09:00:53 dpinger 71051 WAN_DHCP 100.93.160.1: sendto error: 64 Apr 8 09:00:53 dpinger 71051 WAN_DHCP 100.93.160.1: sendto error: 64 Apr 8 09:00:54 dpinger 71051 WAN_DHCP 100.93.160.1: sendto error: 64This Netgate is in a double-NATted situation. The ISP does not hand out internet-exposed IP addresses, but ones that are themselves one NAT hop away from the internet.
-
@DominikHoffmann said in What is the meaning of this dpinger log entry?:
Apr 8 09:00:54 dpinger 71051 WAN_DHCP 100.93.160.1: sendto error: 64
https://docs.netgate.com/pfsense/en/latest/routing/gateway-monitoring-errors.html
What I make of it : the process 71051 "dpinger" is using interface 100.63.160.1, probably the WAN interface, with a DHCP client handling the IP assignment, and it's "100.63.160.1" to ping out to a upstream gateway, but this interface has been taken down and dpinger 71051 isn't (yet ?) aware of it.
When dpinger uses an interface, and that interface goes down, that dpinger process is stopped nearly instantly, as it it useless to ping out over a non existent interface ^^
It can happen, I've found this sequence in my own logs :
6 weeks ago or so, during a couple of seconds, dono what I was doing, or what the upstream router was doing ....
-
@Gertjan: So the solution would be to ping 8.8.8.8, instead.
I am wondering, whether this is the cause of my client’s 1100’s churn that causes it to become unresponsive.
-
Error 64 implies the gateway IP stopped responding to ARP. It must always respond to ARP because pfSense has to route traffic to it so changing the monitoring IP wouldn't help that. That's a more fundamental error like the modem lost upstream link. Though setting an external monitoring IP is generally a good idea anyway.
Steve
-
@DominikHoffmann said in What is the meaning of this dpinger log entry?:
So the solution would be to ping 8.8.8.8, instead.
If ARP stops working, the issue is very local or nearby.
Pinging 8.8.8.8 which is much farther away won't help you here.But if you decide to use 8.8.8.8 : do get that huge yellow red post it and write on it : "what will happen with my connection if, for some reason, Google decides not to answer to ping anymore" ?
( answer : all the ping 8.8.8.8 lovers will have their network WAN going down, and oh boy, it will be quiet on the internet for while ^^ )A better choice is probably a nearby ISP gateway. It's closer, and if it goes down then your connection is most probably also 'down'.
Btw : I still wonder how "8.8.8.8" can keep up having while half the planet is actively pinging them ?
But I get it, at least 'they' (Google) have accurate database with all the active IP addresses. Always nice to have around for trying something 'new'
-
@Gertjan: Okay. Not going to use 8.8.8.8. I had an instinctive aversion to this somehow, anyway.
-
Yup, Google doesn't have to reply to pings there. And there have been reports of it stopping though I've never seen that. Plus.....Google.
But if I'm paying them with my personal data already they can payback with pings at least.
-
@DominikHoffmann said in What is the meaning of this dpinger log entry?:
What does this mean
For future reference, see here.
As @stephenw10 noted, the issue is that your immediate gateway (default route) is not reachable. A much more basic problem than what IP you decide to ping.
As for choosing a target, I usually recommend performing a traceroute to 1.1.1.1 or 8.8.8.8, to help choose a target inside your ISP's infrastructure:
traceroute -I 1.1.1.1Look for an address that is a hop or two inside your ISPs infrastructure and has fairly consistent response times. YMMV.
