short-form IP adress format broken

[marcusoverhagen]

Specifying the DNS address as 10.1 in Network preferences, and thus also in /etc/resolv.conf doesn't work. It has to be written as 10.0.0.1

"ftp 10.1" or "telnet 10.1" in Terminal doesn't work, using "ftp 10.0.0.1" or "telnet 10.0.0.1" works.

Using ​http://10.1 in Firefox however does work.

10.1 is a valid address. Something is wrong, please fix.

a -- 32 bits

a.b -- 8.24 bits

a.b.c -- 8.8.16 bits

a.b.c.d -- 8.8.8.8 bits

[marcusoverhagen]

"There are four forms of the standard numbers-and-dots notation for Internet addresses" ​http://www.gnu.org/software/hello/manual/libc/Abstract-Host-Addresses.html

[pulkomandy]

Support for this is available in libbind in inet_aton, but not in inet_pton which is the multi-protocol (ie. ipv6 aware) version. This makes sense, since the class notation is deprecated and was replaced by network masks which are more flexible.

However, getaddrinfo should handle both IPv6 (it does) and old IPv4 class notation. I'm not sure if it does currently.

[a-star]

I was able to rectify the problem by changing the inet_pton.c file (under src/kits/network/netresolv/inet) without breaking anything. Is it acceptable or do I need to change the getaddrinfo.c file for patching this issue?

[pulkomandy]

It is fine, if you are sure nothing is broken. For such changes, adding to the unit tests would be nice, in order to prevent future regressions.

[a-star]

Modi

[pulkomandy]

Actually, this is not the right solution. POSIX explicitly disallow doing this: ​http://pubs.opengroup.org/onlinepubs/9699919799/functions/inet_ntop.html

inet_pton must accept only addresses in the ddd.ddd.ddd.ddd format.

If the af argument of inet_pton() is AF_INET, the src string shall be in the standard IPv4 dotted-decimal form:

ddd.ddd.ddd.ddd

where "ddd" is a one to three digit decimal number between 0 and 255 (see inet_addr). The inet_pton() function does not accept other formats (such as the octal numbers, hexadecimal numbers, and fewer than four numbers that inet_addr() accepts).

So, it would seem everything is as expected: this address format is no longer supported in the default case.

[a-star]

In comment 5, when I mentioned that I changed the inet_pton.c file, this is what I was worried about. Thanks for the review. I was wondering if changing the code for getaddrinfo to send the expanded version of short form ip address to inet_pton would be a valid patch. If not so, can you point me in the correct direction.

[pulkomandy]

From POSIX documentation of getaddrinfo:

If the nodename argument is not null, it can be a descriptive name or can be an address string. If the specified address family is AF_INET, AF_INET6, or AF_UNSPEC, valid descriptive names include host names. 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.

If the specified address family is AF_INET6 or AF_UNSPEC, standard IPv6 text forms described in inet_ntop are valid.

(​http://pubs.opengroup.org/onlinepubs/9699919799/functions/freeaddrinfo.html)

And, inet_addr explicitly says that the forms mentionned here should be accepted (​http://pubs.opengroup.org/onlinepubs/9699919799/functions/inet_addr.html).

So, if our getaddrinfo does not do that, it should be adjusted to handle it properly.

I think the cleanest solution would be for getaddrinfo to call inet_pton4 directly for the AF_INET family (telling it to use the inet_addr format), and inet_pton for other cases? (didn't check getaddrinfo code, so maybe that doesn't make sense).

[a-star]

Will work on that and provide a patch in a few days. Currently busy working on the proposal. Shouldn't take more than 2 days.

[a-star]

For AF_INET inet_aton is used, inet_pton otherwise

[pulkomandy]

Applied in hrev51113. Thanks!