What is the meaning of this dpinger log entry?

DominikHoffmann

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: 64

This 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.

Gertjan

@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 ....

DominikHoffmann

@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.

stephenw10

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

Gertjan

@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'

DominikHoffmann

@Gertjan: Okay. Not going to use 8.8.8.8. I had an instinctive aversion to this somehow, anyway.

stephenw10

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.

dennypage

@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.1

Look for an address that is a hop or two inside your ISPs infrastructure and has fairly consistent response times. YMMV.