your ipv4 "embedding" doesn't need to be part of the ping tool. it's
not commonly used anyway.
allowing the ping tool to do dns lookups on the other hand are a
common convenience.
unfortunately, the simlification removes the code that solves an important
use case. it's important to be able to specify the protocol or network stack,
such as in
ip/ping /net.alt/icmp!someaddress
the diff is here and i'll be working on a patch.
the basic idea is to translate only the
> i spent some time thinking about this problem.
>
> the purpose of -6 is to force icmpv6. (one can use a v4 address
> with icmpv6, that works due to ipv4 embedding.) this is not the same as
> controlling name lookup. since there are better more flexible tools
> for doing that by hand. the
On Sun Jan 3 13:42:21 PST 2016, 23h...@gmail.com wrote:
> your ipv4 "embedding" doesn't need to be part of the ping tool. it's
> not commonly used anyway.
i think the attribution here is false. i read the man page for that
information.
in any event, ping as patched is wrong. addresses like
On Sat, Jan 02, 2016 at 04:26:39PM -0800, erik quanstrom wrote:
> i'm not sure what the root cause of your problem is,
I'm now suspecting that the underlying problem is that a 9fat is a dos,
but that is a special dos: part of a plan9 slice, so whether kfs or
fossil supplementary partitions are
-4 and -6 should error when used with an ip of the wrong type. when
used with domains correct behavior should be trivial and if there's no
dns response for A or it should error once again.
