Internal error when pinging with dgram socket

[PlanetTeamSpeakk]

As the title suggests, I am getting an internal error when calling ping::dgramsock::ping. I am not getting this error when running the raw socket version, but as the crate already suggests, that requires me to run the program with sudo. I have been able to figure out where the error is coming from exactly, namely the last part of the ping function, that being the decoding of the response packet. The error in the decoding happens when checking whether the version is 4, this is because it is actually 0.

I do not know what this means, but that is what I managed to extrapolate. The data returned when using a dgram socket is the following:

00 00 A2 EF 00 07 00 01 2E DD 45 29 13 D0 DC 21
AA 78 A4 7D 84 B4 0D 0E 7D 66 2D C4 56 90 16 9C

I cannot provide the data returned when using a raw socket as getting CodeLLDB to run the program with sudo is a pain.

I am running the program on a Raspberry Pi 4B running Raspberry Pi OS Bookworm (Debian 12) 64 bit.

[aisk]

I just guess, maybe there is another udp packet send to your process, and ping try to decoded it and centainly failed.

20 just fixed it and shipped with v0.5.2, you can retry with this version.

[sploders101]

During my own debugging, I found that on our system, dgram sockets did not provided proper IP packet headers. I found logic in the code to only decode IPv4 headers, but decode IPv6 data directly. Upon reverting this so IPv4 and v6 both parse only the ICMP data directly from the socket, the pings worked, but the validation stage failed. Upon further research, it seems as though the Linux kernel may be assigning random ident values when performing unprivileged pings, I assume as a safety measure (similar to how one cannot bind to ports below 1024 without special capabilities), which invalidates the check within the ping library itself. I fixed it for us, but it's not the cleanest solution, and I'm not 100% sure if this is the correct solution, since the code functions fine as it is on Mac OS. Posting to hopefully provide insight and further discussion to find a better solution.

[sploders101]

It could also be relevant that I was building for x86_64-unknown-linux-musl. I would imagine that musllibc isn't doing anything different from glibc here, but it is a possibility.

[aisk]

Ok, I'll try to re-produce this error with x86_64-unknown-linux-mus when I have time. Can you also provice what Distro and kernel version for your system?

[sploders101]

We are using RedHat 8 on kernel 4.18.0-372.9.1.el8.x86_64

Thanks!

[samitbasu]

This also happens for me on Ubuntu 22.04, kernel 6.5. I will try and investigate when I have some time.