-
Notifications
You must be signed in to change notification settings - Fork 271
ping: support IPv4-Mapped-in-IPv6 target addresses #558
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Addresses of the form ::ffff:127.0.0.1 would be treated as IPv6. Check the target early and switch to IPv4 path if found. Signed-off-by: Tj <linux@iam.tj>
78dd8c6
to
9c58ec0
Compare
Thanks a lot for your PR, very nice improvement. It is also nice that whole thing works when forcing a protocol (both Could you please reveal your real name? |
It is my real name. |
If it's your full name, than I'm sorry for asking. |
You're not the first to make the assumption - part of the reason I have the domain I AM . Tj ! :) Aside: I wrote this because a C++ programmer complained that Debian's ping "doesn't work" in our Matrix support room; instead of complaining the time and energy is best spent on fixing. |
Addresses of the form ::ffff:127.0.0.1 would be treated as IPv6. Check the target early and switch to IPv4 path if found. $ ./builddir/ping/ping -c1 -v ::ffff:127.0.0.1 ./builddir/ping/ping: IPv4-Mapped-in-IPv6 address; using IPv4 127.0.0.1 ./builddir/ping/ping: sock4.fd: 3 (socktype: SOCK_DGRAM), sock6.fd: -1 (socktype: 0), hints.ai_family: AF_INET ai->ai_family: AF_INET, ai->ai_canonname: '127.0.0.1' PING 127.0.0.1 (127.0.0.1) 56(84) bytes of data. 64 bytes from localhost (127.0.0.1): icmp_seq=1 ttl=64 time=0.058 ms Closes: iputils#558 Reviewed-by: Petr Vorel <pvorel@suse.cz> Signed-off-by: Tj <linux@iam.tj> [ pvorel: use _() to translate, error() to redirect to stderr ] Signed-off-by: Petr Vorel <pvorel@suse.cz>
Thanks a lot for your fix, merged. I dared to unify verbose reporting (print to stderr, translate, use comma). |
@ALL: you are welcome ;) and thanks @iam-TJ for implementing it - I thought about it myself yesterday following the discussion, but I wouldn't have been nearly as fast. |
I just realized, there's a potential bug in this implementation.
Is the code that subsequently uses |
@iam-TJ @aral-matrix FYI given a discussion in busybox mailing list I'm seriously thinking about reverting this feature instead of using one of your fixes. https://lists.busybox.net/pipermail/busybox/2024-October/090975.html
You got Cc in the discussion. Ideally, the discussion would be hold in the busybox mailing list (keep on single place). Could you please subscribe to the busybox mailing list (https://lists.busybox.net/mailman/listinfo/busybox) and post your opinion there? |
[x] done :) |
@iam-TJ: Would it be possible for you to expand on this "doesn't work" complaint? What was attempted to be achieved, but did not work as intended? What happened instead? |
@auerswal : don't get sidetracked :) |
there could be many invalid patterns, like |
@yvs2014 : #558 (comment) :) already spotted |
Additional feature:
Addresses of the form
::ffff:127.0.0.1
would be treated as IPv6 but should be converted to IPv4 and handled as such.