Bug #6875
closed
dpinger not switching icmp id automatically
0%
Description
I'm having a problem with dpinger that's not switching ICMP id when there's packet loss, for example in a CGNAT scenario where my ISP restars one of its routers , the NAT states for the icmp id are lost, and dpinger keeps on using that id which will never result in a reply, the icmp id in the meanwhile may have been taken by someone else so it would be unuseable and the state will not be automatically recreated
A correct behavior would be after N consecutive ICMP echo requests lost , to switch to a new icmp id
Updated by Luiz Souza over 7 years ago
This is the same behaviour of ping (the icmp_id comes from the PID).
So, when you have an issue with your ISP ping stops working too ?
Updated by Tiziano Bacocco over 7 years ago
Luiz Otavio O Souza wrote:
This is the same behaviour of ping (the icmp_id comes from the PID).
So, when you have an issue with your ISP ping stops working too ?
Yeah , when the ISP restarts some equipment , the icmp id becomes unuseable, i've checked with packet capture that the packets are actually leaving the interface , but there's no reply, only when i change the ICMP id by restarting dpinger every starts working again
Instead if there's only a fault that does not involve Carrier Grade NAT equipment rebooting , it won't give problem because the icmp id stays useable
Updated by Jim Thompson over 7 years ago
- Category set to dpinger
- Assignee set to Jim Thompson
Updated by Denny Page about 7 years ago
I think the report is erroneous. There should be no state association beyond a single ICMP Echo Request and it's Echo Reply. The NAT cannot count on the first packet seen being sequence 0 or 1, or even that ping will start with sequence 0 or 1. Any state dependency beyond a single request/replay interaction would be a serious defect in the NAT implementation.
Regardless, changing the ICMP Identification on the fly would not be correct behavior. It should always be tied to the process unique identifier (pid).