Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.
For bugs related to Red Hat Enterprise Linux 3 product line. The current stable release is 3.9. For Red Hat Enterprise Linux 6 and above, please visit Red Hat JIRA https://issues.redhat.com/secure/CreateIssue!default.jspa?pid=12332745 to report new issues.

Bug 122038

Summary: ping accepts wacky octal/hex in IP addresses
Product: Red Hat Enterprise Linux 3 Reporter: Steve Bonneville <sbonnevi>
Component: iputilsAssignee: Radek Vokál <rvokal>
Status: CLOSED NOTABUG QA Contact: Mike McLean <mikem>
Severity: medium Docs Contact:
Priority: medium    
Version: 3.0   
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2004-10-11 10:39:30 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Steve Bonneville 2004-04-29 21:03:03 UTC
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

Comment 1 Mike McLean 2004-04-29 22:00:45 UTC
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.

Comment 2 Steve Bonneville 2004-04-30 05:03:50 UTC
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).

Comment 3 Radek Vokál 2004-10-11 10:39:30 UTC
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.