The ping utility accepts some wacky "numbers" as IP addresses.
Arguably, the following example might make a weird sort of sense:
[root@server1 /]# ping 0xc0a800fe
PING 0xc0a800fe (192.168.0.254) 56(84) bytes of data.
64 bytes from 192.168.0.254: icmp_seq=0 ttl=0 time=0.087 ms
as 0xC0A800FE is hex for 192.168.0.254. But should you really be able
to say this?
[root@server1 /]# ping 192.168.0.0xfe
PING 192.168.0.0xfe (192.168.0.254) 56(84) bytes of data.
64 bytes from 192.168.0.254: icmp_seq=0 ttl=0 time=0.078 ms
[root@server1 /]# ping 192.010.010.002
PING 192.010.010.002 (22.214.171.124) 56(84) bytes of data.
^^^ ^^^ ^ ^
[root@server1 /]# ping 192.168.011
PING 192.168.011 (192.168.0.9) 56(84) bytes of data.
Version-Release number of selected component (if applicable):
This behavior lies in the inet_aton (glibc) function, not in the ping
utility. Any utility that passes such strings directly to inet_aton
will exhibit this behavior (such as arping, nc, tcpdump, ftp,
wget,...). I personally don't consider this a bug.
Yes, now that you mention it, POSIX does say inet_aton() should accept
decimal, hex, or octal as any part of a dotted quad IPv4 address. But
should ping do this? This was originally brought to my attention by a
end user that was confused by this behavior (the last example above is
the one he showed me, typo for 192.168.0.11).
This is feature of many network tools, not only iputils but also
traceroute and other tools resolving ip adresses. I don't think it has
to be removed but I agree it should be more documented.