SG-2220 duplicate echo on WAN from process dpinger
-
Hi -
My gateway logs are filled with dpinger duplicate echos.
I am new to pfsense and would like to know what could be the cause of this.
I keep PFSENSE up to date with every new release hoping it will get resolved but no luck.
And it still receives duplicate echos even though nothing is connected to the PFSENSE except the incoming WAN from my cable modem.
My hardware is the SG-2220 and currently using the latest 2.3.1-RELEASE-p1 (amd64).
What are the possible causes of this?
–--
Jun 6 09:46:47 dpinger WAN_DHCP6 fe80::201:5cff:ff6b:a846%igb0: duplicate echo reply received
Jun 6 09:46:47 dpinger WAN_DHCP6 fe80::201:5cff:ff6b:a846%igb0: duplicate echo reply received
Jun 6 09:46:47 dpinger WAN_DHCP6 fe80::201:5cff:ff6b:a846%igb0: duplicate echo reply received
Jun 6 09:46:47 dpinger WAN_DHCP6 fe80::201:5cff:ff6b:a846%igb0: duplicate echo reply received
Jun 6 09:46:47 dpinger WAN_DHCP6 fe80::201:5cff:ff6b:a846%igb0: duplicate echo reply received
Jun 6 09:46:47 dpinger WAN_DHCP6 fe80::201:5cff:ff6b:a846%igb0: duplicate echo reply received
Jun 6 09:46:46 dpinger WAN_DHCP6 fe80::201:5cff:ff6b:a846%igb0: duplicate echo reply received
Jun 6 09:46:46 dpinger WAN_DHCP6 fe80::201:5cff:ff6b:a846%igb0: duplicate echo reply received
Jun 6 09:46:46 dpinger WAN_DHCP6 fe80::201:5cff:ff6b:a846%igb0: duplicate echo reply received
Jun 6 09:46:46 dpinger WAN_DHCP6 fe80::201:5cff:ff6b:a846%igb0: duplicate echo reply received
Jun 6 09:46:46 dpinger WAN_DHCP6 fe80::201:5cff:ff6b:a846%igb0: duplicate echo reply received
Jun 6 09:46:46 dpinger WAN_DHCP6 fe80::201:5cff:ff6b:a846%igb0: duplicate echo reply received
Jun 6 09:46:46 dpinger WAN_DHCP6 fe80::201:5cff:ff6b:a846%igb0: duplicate echo reply received
Jun 6 09:46:46 dpinger WAN_DHCP6 fe80::201:5cff:ff6b:a846%igb0: duplicate echo reply received
Jun 6 09:46:46 dpinger WAN_DHCP6 fe80::201:5cff:ff6b:a846%igb0: duplicate echo reply received
Jun 6 09:46:46 dpinger WAN_DHCP6 fe80::201:5cff:ff6b:a846%igb0: duplicate echo reply received
Jun 6 09:46:46 dpinger WAN_DHCP6 fe80::201:5cff:ff6b:a846%igb0: duplicate echo reply received
Jun 6 09:46:46 dpinger WAN_DHCP6 fe80::201:5cff:ff6b:a846%igb0: duplicate echo reply received
Jun 6 09:46:45 dpinger WAN_DHCP6 fe80::201:5cff:ff6b:a846%igb0: duplicate echo reply received -
Very unusual. If you don't mind, would you do a "ps -axuwww | grep dpinger" and post the result please? Thanks.
-
Here is the output (with obfuscation xxx):
root 58708 0.0 0.1 17000 2516 - S 9:59PM 0:00.00 sh -c ps -axuwww | grep dpinger 2>&1
root 58811 0.0 0.1 18740 2252 - S 9:59PM 0:00.00 grep dpinger
root 78602 0.0 0.1 19108 2376 - Is Tue07AM 0:22.23 /usr/local/bin/dpinger -S -r 0 -i WAN_DHCP -B 24.4.xxx.xxx -p /var/run/dpinger_WAN_DHCP_24.4.xxx.xxx_24.4.yyy.yyy.pid -u /var/run/dpinger_WAN_DHCP_24.4.xxx.xxx_24.4.yyy.yyy.sock -C /etc/rc.gateway_alarm -d 0 -s 500 -l 2000 -t 60000 -A 1000 -D 500 -L 20 24.4.yyy.yyy
root 78883 0.0 0.1 23204 2464 - Is Tue07AM 1:41.01 /usr/local/bin/dpinger -S -r 0 -i WAN_DHCP6 -B fe80::xxx:xxxx:fe09:c246%igb0 -p /var/run/dpinger_WAN_DHCP6_fe80::xxx:xxxx:fe09:c246%igb0_fe80::xxx:xxxx:fe6b:a846%igb0.pid -u /var/run/dpinger_WAN_DHCP6_fe80::xxx:xxxx:fe09:c246%igb0_fe80::xxx:xxxx:fe6b:a846%igb0.sock -C /etc/rc.gateway_alarm -d 0 -s 500 -l 2000 -t 60000 -A 1000 -D 500 -L 20 fe80::201:xxxx:fe6b:a846%igb0 -
That all looks normal.
It would appear that the first hop router has a defect in handling IPv6 ICMP echo requests. There is a small chance that the problem is particular to a payload size of zero. You can test this by going to the gateway edit page (System -> Routing -> Gateways) and setting the Data Payload size to 1 in the advanced section to see if this stops the duplicate replies.
Alternatively, you can change your monitor target to a different address. Either an address a little farther inside your ISP or a public address beyond your ISP. Some people prefer using a public address for monitoring because this gives you information on your connection to the Internet rather than just to your ISP.
You can use traceroute to discover potential candidates for monitoring. Using Google DNS as an example:
traceroute6 dns.google.com
Choose the one you like and enter it as the Monitor IP in the gateway page mentioned above.
-
Thank you.
I changed the Data Payload size to 1 but that didn't solve it (as you suspected). And btw after the test I couldn't change the Payload size back to zero. The GUI says Payload needs to be greater than 0. So I just wanted to point that out – in case it helps you in your next dpinger revision, etc.
Regarding the first hop router defect in handling IPv6 ICMP echo requests, I assume that first hop would have to be my cable modem coupled to the PFsense WAN port. Is that safe to assume?
Finally, regarding the solution to change the monitor target to a different address, I tried to traceroute from the GUI in PFsense but traceroute seems to hang the web interface on my PFsense system, forcing me to drop into the console to reboot it. Is there something that I might be missing in terms of performing a traceroute without hanging gui?
-
While you cannot return the value to zero by ticking the down arrow, you should be able to click in the text field and delete the entry or enter a zero value.
I changed the Data Payload size to 1 but that didn't solve it (as you suspected). And btw after the test I couldn't change the Payload size back to zero. The GUI says Payload needs to be greater than 0. So I just wanted to point that out – in case it helps you in your next dpinger revision, etc.
-
There appears to be a defect in traceroute6. If one of the hops is not responding, receipt of an IPv6 ICMP echo reply resets the timeout for that hop. So if echo replies are coming in at a rate faster than the timeout, traceroute6 will essentially wait forever. You can see this via the console by running traceroute6 in verbose mode like so:
/usr/sbin/traceroute6 -v -n -w 2 -I -m 18 dns.google.com
You can work around this by stopping the dpinger service (Status -> Services) prior to running traceroute.
Finally, regarding the solution to change the monitor target to a different address, I tried to traceroute from the GUI in PFsense but traceroute seems to hang the web interface on my PFsense system, forcing me to drop into the console to reboot it. Is there something that I might be missing in terms of performing a traceroute without hanging gui?
-
A bug report for traceroute6 has been filed with FreeBSD.
-
Thanks for submitting the report and for all of your efforts here to help sort this out. Also, thank you for all of your contributions to PFsense in general.
-
I'm going to assume your ISP is Comcast. This is just something that they do in areas with Arris equipment. Try pinging your IPv6 default gateway from your pfsense box. You should see the same thing. My gateway logs get clogged with this junk too.
Try this on your router's command prompt (assuming the below is your default gateway):
ping6 -c 4 fe80::201:5cff:ff6b:a846%igb0 -
I've seen this also with Comcast and my SB6183 on a Core i5 system. Confirmed the messages are still there after upgrading to 2.3.2. No material impact but I would like to clean up my log files as there messages basically expire anything that may be of importance.
-
Just wanted to say I'm seeing the same thing and I haven't found a fix anywhere. Also you cannot manually set "Data Payload" back to zero, it still gives an error message…
-
Also you cannot manually set "Data Payload" back to zero, it still gives an error message…
While you cannot return the value to zero by ticking the down arrow, you should be able to click in the text field and delete the entry or enter a zero value.
-
Just wanted to say I'm seeing the same thing and I haven't found a fix anywhere.
The solution can be found earlier in this thread:
… you can change your monitor target to a different address. Either an address a little farther inside your ISP or a public address beyond your ISP. Some people prefer using a public address for monitoring because this gives you information on your connection to the Internet rather than just to your ISP.
You can use traceroute to discover potential candidates for monitoring. Using Google DNS as an example:
traceroute6 dns.google.com
Choose the one you like and enter it as the Monitor IP in the gateway page mentioned above.
-
Thank you, sorry I didn't catch that before. Manually entering a "0" doesn't work but just deleting anything in that field does.
How will I know that the "Monitor IP" that I chose from traceroute6 is working correcting? The "duplicate echo reply received" messages stopped but there are a couple others now:
dpinger send_interval 500ms loss_interval 2000ms time_period 60000ms report_interval 0ms data_len 0 alert_interval 1000ms latency_alarm 500ms loss_alarm 20% dest_addr [...] bind_addr [...] identifier "WAN_DHCP6 " dpinger send_interval 500ms loss_interval 2000ms time_period 60000ms report_interval 0ms data_len 0 alert_interval 1000ms latency_alarm 500ms loss_alarm 20% dest_addr [...] bind_addr [...] identifier "WAN_DHCP " dpinger WAN_DHCP6 [...] Alarm latency 0us stddev 0us loss 100% -
The first two are normal startup messages from dpinger. The third is an alarm message from dpinger indicating 100% packet loss for the WAN_DHCP6 gateway.
-
Thanks I'm guessing that the address I picked was one that doesn't reply. I will try other ones until I don't get that message. Please let me know if you have any more advice on that.
-
Thanks I'm guessing that the address I picked was one that doesn't reply. I will try other ones until I don't get that message.
To match the behavior of dpinger, you would use traceroute6 with the -I option (ICMP) and length 0. Example:
traceroute6 -I dns.google.com 0
You should be able to see from the traceroute6 output which are not responding to ICMP.
-
It would appear that the first hop router has a defect in handling IPv6 ICMP echo requests. There is a small chance that the problem is particular to a payload size of zero. You can test this by going to the gateway edit page (System -> Routing -> Gateways) and setting the Data Payload size to 1 in the advanced section to see if this stops the duplicate replies.
Alternatively, you can change your monitor target to a different address. Either an address a little farther inside your ISP or a public address beyond your ISP. Some people prefer using a public address for monitoring because this gives you information on your connection to the Internet rather than just to your ISP.
You can use traceroute to discover potential candidates for monitoring. Using Google DNS as an example:
traceroute6 dns.google.com
Choose the one you like and enter it as the Monitor IP in the gateway page mentioned above.
Thanks. I have Comcast as ISP and had to use your technique to change the monitoring IP to get rid of the flood of dpinger log messages.
-
I have the same problem
