Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

This one caused a friend some headache when setting up a switched internet connection which had zero padded IP addresses in the configuration paper like so:

192.168.019.254

No matter how he tried to configure the Mac network stack, it just didn't work. But the GUI also didn't complain about errors.

I later found out that pinging these zero padded addresses in a terminal showed "unable to resolve" while pinging the same address without padded zeros (192.168.19.254 vs. 192.168.019.254) showed "unable to reach" which brought much light into this mysterium. Removing the useless zeros made everything work.

Is this a bug or a feature? I never experienced such strange behaviour before - no matter if I use the GUI or CLI to configure or test IP stuff.

share|improve this question
add comment

1 Answer

up vote 10 down vote accepted

Translation from a string to an address is usually performed by the POSIX function getaddrinfo(). This function first checks for a numeric IP address using inet_addr(), and if that fails it will then attempt to resolve the string as a domain name. inet_addr() interprets numbers with a leading 0 as octal, so for example 010 would become 8, and 019 would be an error (and would therefore be resolved as a domain name). The same behavior occurs on Linux and Solaris as well.

From getaddrinfo():

If the specified address family is AF_INET or AF_UNSPEC, address strings using Internet standard dot notation as specified in inet_addr() are valid.

From inet_addr():

All numbers supplied as parts in IPv4 dotted decimal notation may be decimal, octal, or hexadecimal, as specified in the ISO C standard (that is, a leading 0x or 0X implies hexadecimal; otherwise, a leading '0' implies octal; otherwise, the number is interpreted as decimal).

Note the address 192.168.8.254 in parentheses:

$ ping 192.168.010.254
PING 192.168.010.254 (192.168.8.254): 56 data bytes
Request timeout for icmp_seq 0
share|improve this answer
    
Okay this pretty counterintuitive but could be useful. Still it does not explain why 192.168.010.254 was unable to resolve while 192.168.10.254 was unable to reach. Should've not both been unable to reach? –  hurikhan77 Feb 15 '10 at 7:17
3  
It just hit me like a flash: Speaking of octal numbers I remember that the original IP in question was something like xxx.xxx.019.xxx - which is of course no valid number and thus an invalid host name. Amending my question... –  hurikhan77 Feb 15 '10 at 7:25
    
I have updated my answer to answer the updated question. –  mark4o Feb 15 '10 at 8:07
    
+1 and acc for the great explanation. Question remains why the system settings GUI of Mac OS does not interpret the numbers decimal as it should. However, the configuration paper of the ISP is simply plain wrong anyway. I tested against a Windows machine (because it's non-posix) which exhibits the same interpretation on CLI - it does however not do this on the GUI. –  hurikhan77 Feb 15 '10 at 10:14
    
@hurikhan77 You got it. It's not a valid IP address, since 9 is not a legal octal digit, so the rule is to treat it as a host name. –  David Schwartz Sep 16 '13 at 16:37
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.