Hide Forgot
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 Or this? [root@server1 /]# ping 192.010.010.002 PING 192.010.010.002 (192.8.8.2) 56(84) bytes of data. ^^^ ^^^ ^ ^ Or this? [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): iputils-20020927-11
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.