8000 ping: support IPv4-Mapped-in-IPv6 target addresses by iam-TJ · Pull Request #558 · iputils/iputils · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

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

Closed
wants to merge 1 commit into from

Conversation

iam-TJ
Copy link
@iam-TJ iam-TJ commented Oct 17, 2024

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.

iputils$ build/ping/ping -n -v ::ffff:127.0.0.1
IPv4-Mapped-in-IPv6 address; using IPv4 127.0.0.1
build/ping/ping: sock4.fd: 3 (socktype: SOCK_RAW), 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 127.0.0.1: icmp_seq=1 ident=45999 ttl=64 time=0.032 ms
64 bytes from 127.0.0.1: icmp_seq=2 ident=45999 ttl=64 time=0.053 ms
64 bytes from 127.0.0.1: icmp_seq=3 ident=45999 ttl=64 time=0.054 ms
^C
--- 127.0.0.1 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2039ms
rtt min/avg/max/mdev = 0.032/0.046/0.054/0.010 ms

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>
@iam-TJ iam-TJ force-pushed the feature_ipv4-mapped-in-ipv6 branch from 78dd8c6 to 9c58ec0 Compare October 17, 2024 19:53
@pevik pevik self-assigned this Oct 18, 2024
@pevik pevik added this to the Next release (bug fixes) milestone Oct 18, 2024
@pevik
Copy link
Contributor
pevik commented Oct 18, 2024
Reviewed-by: Petr Vorel <pvorel@suse.cz>

Thanks a lot for your PR, very nice improvement. It is also nice that whole thing works when forcing a protocol (both -4 and -6).

Could you please reveal your real name? Tj is against kernel rules for signing the work we follow?

https://www.kernel.org/doc/html/latest/process/submitting-patches.html#sign-your-work-the-developer-s-certificate-of-origin

@iam-TJ
Copy link
Author
iam-TJ commented Oct 18, 2024

Could you please reveal your real name? Tj is against kernel rules for signing the work we follow?

It is my real name.

@pevik
Copy link
Contributor
pevik commented Oct 18, 2024

Could you please reveal your real name? Tj is against kernel rules for signing the work we follow?

It is my real name.

If it's your full name, than I'm sorry for asking.

@iam-TJ
Copy link
Author
iam-TJ commented Oct 18, 2024

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.

pevik pushed a commit to pevik/iputils that referenced this pull request Oct 18, 2024
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>
@pevik pevik closed this in 8ed7ffc Oct 18, 2024
@pevik
Copy link
Contributor
pevik commented Oct 18, 2024

Thanks a lot for your fix, merged. I dared to unify verbose reporting (print to stderr, translate, use comma).

@aral-matrix
Copy link
aral-matrix commented Oct 19, 2024

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.

@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.

@aral-matrix
Copy link
aral-matrix commented Oct 19, 2024

I just realized, there's a potential bug in this implementation.

			target = strrchr(target, ':') + 1;

Is the code that subsequently uses target equipped to deal with an address of the form 7f00:1?
In other words: I can see that this fix addresses ping ::ffff:127.0.0.1 - but would it work on ping ::ffff:7f00:1 as well?

@pevik
Copy link
Contributor
pevik commented Oct 20, 2024

@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

I can understand why anyone would think this translation is normal, because
the socket API normally unmaps IPv4-mapped IPv6 addresses for compatibility:

https://www.rfc-editor.org/rfc/rfc3493.html#section-3.7

Applications may use AF_INET6 sockets to open TCP connections to IPv4
nodes, or send UDP packets to IPv4 nodes, by simply encoding the
destination's IPv4 address as an IPv4-mapped IPv6 address, and
passing that address, within a sockaddr_in6 structure, in the
connect() or sendto() call.

But this is not the case with ping because ping uses IPv6 raw sockets,
and that seems to stop sendto() from performing the convenience unmapping.

Sadly, this patch breaks the case where an advanced user wants ping
to send a packet with an IPv4-mapped IPv6 addresses. For example, you
might be testing or diagosing firewall rules in that subnet.

Additionally, I can't see any combination of -4 or -6 option flags that
could be used as a guard to make the unmapping behaviour expected.

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?

@aral-matrix
Copy link
aral-matrix commented Oct 20, 2024

Could you please subscribe to the busybox mailing list (https://lists.busybox.net/mailman/listinfo/busybox) and post your opinion there?

[x] done :)

@auerswal
Copy link

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.

@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?

@aral-matrix
Copy link

@yvs2014
Copy link
yvs2014 commented Oct 20, 2024 8000

target = strrchr(target, ':') + 1;

there could be many invalid patterns, like
0:0:0:0:0:ffff:: or ::ffff:feed:cafe

@aral-matrix
Copy link

@yvs2014 : #558 (comment) :) already spotted

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants
0