SG-2220 duplicate echo on WAN from process dpinger
-
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