Bug 617934

Hi,
I see proposed enhancement quite logical. On the other hand current state is deep-seated.

I've asked upstream about opinion/planing a couple weeks ago (currently no response). I'll decide next step after receiving any response from upstream.

Jiri

Non-responsive upstream. I don't want to do huge changes without upstream co-operation/adoption. Among others pinging via IPv6 is possible.

Reopening this bug report as part of your dualstack networking effort.

See:

https://fedoraproject.org/wiki/Features/DualstackNetworking

Comments from the tracker bug:


Michael Heimann 2013-01-03 07:43:10 EST

ping is not IPv6 compatible - instead IPv6 functions are outsourced to ping6.

How to create a bug for that and "attach" this tracker bug?


Jan Synacek 2013-01-07 05:19:13 EST

> ping is not IPv6 compatible - instead IPv6 functions are outsourced to ping6.
> 
> How to create a bug for that and "attach" this tracker bug?

There is no need for a bug because it is not one. I would just delete the line that mentions ping from the feature page.


And my answer:

> > ping is > > ping is not IPv6 compatible - instead IPv6 functions are outsourced to ping6.
> > 
> > How to create a bug for that and "attach" this tracker bug?

I would say a RFE for ping would do. It is common to use bug reports for requests for new features in Fedora.

> There is no need for a bug because it is not one.

Personal opinions are important part of our work. But this one is without justificatoin. Unless there is a special reason for a tool to be IPv4-only or IPv6-only it should be dualprotocol. And for ICMP ECHO tool, there is no such reason as this functionality is availabe for both IPv4 and IPv6.

There's a workaround to use a IPv6-only replacement when we work with IPv6. But as that one is IPv6-only, it doesn't constitute a universal replacement.

Most operating systems already have this feature which makes Fedora and other Linux distributions look backwards. That is not such a big deal, as we have bigger problems than that.

But what would really make us look foolish would be if we use various sorts of excuses and at the same time talk about defining distribution (or defining company for those who work at Red Hat).

> I would just delete the line that mentions ping from the feature page.

We could make this one optional for the feature, or we could split it out to another feature if we suspect we are unable to make it work. But I don't think it is justifiable to say that basic tools like ping can legitimately be IPv4-only.

Thanks for your feedback.not IPv6 compatible - instead IPv6 functions are outsourced to ping6.
> > 
> > How to create a bug for that and "attach" this tracker bug?

I would say a RFE for ping would do. It is common to use bug reports for requests for new features in Fedora.

> There is no need for a bug because it is not one.

Personal opinions are important part of our work. But this one is without justificatoin. Unless there is a special reason for a tool to be IPv4-only or IPv6-only it should be dualprotocol. And for ICMP ECHO tool, there is no such reason as this functionality is availabe for both IPv4 and IPv6.

There's a workaround to use a IPv6-only replacement when we work with IPv6. But as that one is IPv6-only, it doesn't constitute a universal replacement.

Most operating systems already have this feature which makes Fedora and other Linux distributions look backwards. That is not such a big deal, as we have bigger problems than that.

But what would really make us look foolish would be if we use various sorts of excuses and at the same time talk about defining distribution (or defining company for those who work at Red Hat).

> I would just delete the line that mentions ping from the feature page.

We could make this one optional for the feature, or we could split it out to another feature if we suspect we are unable to make it work. But I don't think it is justifiable to say that basic tools like ping can legitimately be IPv4-only.

Thanks for your feedback.

Ok, I guess I wasn't clear enough.

My original reasoning was that the fact that ping doesn't work with IPv6 addresses is not a bug, because there is no such functionality there. That's what ping6 is for.

Anyway, merging ping and ping6 makes a lot of sense. The upstream is quite responsive nowadays, so I'll look into it and perhaps start an upstream discussion.

(In reply to comment #4)
> My original reasoning was that the fact that ping doesn't work with IPv6
> addresses is not a bug, because there is no such functionality there.

Yes. My answer wasn't either. I confirm that it is not a bug but from the dualstack networking point of view it's lack of an important feature.

> That's what ping6 is for.

That's why the feature is not so urgent and why I'm considering moving it to a separate feature page.

> Anyway, merging ping and ping6 makes a lot of sense. The upstream is quite
> responsive nowadays, so I'll look into it and perhaps start an upstream
> discussion.

Thanks. Ping is not so complicated, so I think it warrants (a) discussion with upstream or (b) a fork. Especially the second option calls for a separate feature page and more time to finish it.

Forgot to add (c) a wrapper ping that would call ping4 or ping6 depending on its arguments.

(In reply to comment #7)
> Forgot to add (c) a wrapper ping that would call ping4 or ping6 depending on
> its arguments.

In my opinion this would a good way to go if there was a need to quickly
implement this idea. My understanding is that there is no such need, so I
suggest going the (a) way as well.

I moved it to a separate feature page that I'm *not* submitting for F19 unless upstream reacts quickly.

https://fedoraproject.org/wiki/Features/DualstackNetworkTestingTools

See also:

https://fedoraproject.org/wiki/Networking#Fedora_feature_pages

Upstream is ok with a unified ping. Some details are yet to be agreed on though.

Jan,

At the time when I wrote the first new traceroute-2.0.x implementation in 2006 (certainly dual stack friendly :) always), I thought about rewriting of ping as well, since both utilities are from the same knowledge area.

But I've stopped myself, because ping and ping6 work fine at that time, and a chance to be included in a distro was too small (unlike in traceroute, which was very actual at that time).

Well, now the idea of uniting ping4/ping6 into one utility is considered good, by upstream as well. But when I last time looked into their code, the code was not so clean (not so good... etc.). Anyway it would be much better to rewrite the code, rather than combine the current ping and ping6 into one.

Could you please consider the situation -- whether the current ping upstream has a good motivation to provide a good (including "good code") common IPv4/IPv6 ping implementation, which will be suitable in Enterprise Linux as well? If so, it will be fine.

But if not, I feel some responsibility in this, since yes, I'm capable to re-write the ping from the scratch... With code and style similar to the current traceroute.

But certainly I should know whether it might be actually needed from me or not, to plan my time in the near future.

(In reply to comment #10)
> Upstream is ok with a unified ping. Some details are yet to be agreed on
> though.

That's a good news. For the beginning I don't care so much about what ping will do by default. I just want to be sure that 'ping -4' and 'ping -6' will do exactly what they should do.

(In reply to comment #11)
> Well, now the idea of uniting ping4/ping6 into one utility is considered
> good, by upstream as well. But when I last time looked into their code, the
> code was not so clean (not so good... etc.). Anyway it would be much better
> to rewrite the code, rather than combine the current ping and ping6 into one.

Then you might consider communicating with upstream and reporting the details here...

> But if not, I feel some responsibility in this, since yes, I'm capable to
> re-write the ping from the scratch... With code and style similar to the
> current traceroute.

Great.

To comment #12:
> Then you might consider communicating with upstream and reporting the details here

I prefer some Red Hat people to do it.

Ping is "a very basic", "fundamental", "good ancient" utility etc. It should not be implemented just by an occasional people enthusiasm.

This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle.
Changing version to '19'.

(As we did not run this process for some time, it could affect also pre-Fedora 19 development
cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.)

More information and reason for this action is here:
https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19

As far as I know, ping still doesn't support IPv6 in rawhide.

My priorities and duties have since shifted elsewhere, so I will not be rewriting ping.

(In reply to Jan Synacek from comment #16)
> My priorities and duties have since shifted elsewhere, so I will not be
> rewriting ping.

Thanks for information.

I opened bug for iputils with this topic [1].

I'll try someway import ping6 into ping and get it together. Anyway any help appreciated!

[1] https://github.com/iputils/iputils/issues/5

I've put a quick hack which allows ping to use ipv6 addresses as fallback at: https://github.com/iputils/iputils/pull/16

Patches are already upstream. Please consider merging them in F23.

I'll wait for a release, but thanks for letting me know! I'm keeping the needinfo on myself for now.

FYI

Upstream recently accepted my patches that build on top of the work by Nikos and I submitted another pull request removing ping6 entirely. For compatibility, the ping binary supports being called via a ping6 symlink to trigger IPv6 mode and for consistency a ping4 symlink can be created for the IPv4 mode.

The default mode is now full looping through all getaddrinfo() results in the given order which results in giving precedence to available protocols. If both protocols are available, getaddrinfo returns IPv6 first by default.

When there is a release, I recommend also checking that the ping6 symlink is included and creating it if it isn't. People are used to it and it is enough to trick them with ping defaulting to IPv6. Whether a ping4 symlink is useful or not remains a question.

Anyone is welcome to review the new pull request:

https://github.com/iputils/iputils/pull/25

Upstream now has a decent dual-stack ping command.

This bug appears to have been reported against 'rawhide' during the Fedora 23 development cycle.
Changing version to '23'.

(As we did not run this process for some time, it could affect also pre-Fedora 23 development
cycle bugs. We are very sorry. It will help us with cleanup during Fedora 23 End Of Life. Thank you.)

More information and reason for this action is here:
https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora23

There is a new release by upstream including the dual stack changes:
https://github.com/iputils/iputils/releases/tag/s20150815

I'm sorry, I have completely missed the information about the new upstream release. New version incoming...

Jan do you want to submit that feature as a self contained change for Fedora 24?

Is that really necessary? The package is already in rawhide.

The self contained changes are for public announcements. Otherwise one will figure that ping supports ipv6 addresses only by accident.

Ok, in that case, we should probably submit the change.

Jan do you want me to fill the change request? I could do that, but I believe it should be you as you are the maintainer. The deadline for change requests is close.

(In reply to Nikos Mavrogiannopoulos from comment #33)
> Jan do you want me to fill the change request?

Yes, please.