Thank you for this project, it already helped a lot for drilling down on my internet outages at home!
Unfortunately, in my case, it's often caused by some NAT table filling up upstream (at least that's my running theory), which leads to currently running pings continuing to work, while new connections can't be established anymore.
For my use case, having some option like alwaysUseNewIcmpIdentifier would be sufficient.
Another, maybe even better, solution would be what @foogod requested to merge - this way, I could just set ping.id-change.interval: 5s.
Edit: when pinging "manually", I can see the difference in behaviour with ping 8.8.8.8 vs while true; do ping 8.8.8.8 -c 1; done.
Is there a way to use go-ping in a similar fashion, always restarting the ping to get a new identifier, without losing on history / metrics? Then it should be possible to do this already without having digineo/go-ping/pull/19 merged.
Thank you for this project, it already helped a lot for drilling down on my internet outages at home!
Unfortunately, in my case, it's often caused by some NAT table filling up upstream (at least that's my running theory), which leads to currently running pings continuing to work, while new connections can't be established anymore.
For my use case, having some option like
alwaysUseNewIcmpIdentifierwould be sufficient.Another, maybe even better, solution would be what @foogod requested to merge - this way, I could just set
ping.id-change.interval: 5s.But I guess the necessary PR for that in go-ping, which isn't merge yet, would be required for any of those two solutions?
Edit: when pinging "manually", I can see the difference in behaviour with
ping 8.8.8.8vswhile true; do ping 8.8.8.8 -c 1; done. Is there a way to usego-pingin a similar fashion, always restarting the ping to get a new identifier, without losing on history / metrics? Then it should be possible to do this already without having digineo/go-ping/pull/19 merged.