Opened 10 years ago

Closed 2 years ago

#3884 closed bug (fixed)

short-form IP adress format broken

Reported by: marcusoverhagen Owned by: nobody
Priority: normal Milestone: R1
Component: Network & Internet Version: R1/pre-alpha1
Keywords: gsoc2017 Cc:
Blocked By: Blocking:
Has a Patch: yes Platform: All

Description (last modified by 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

Attachments (2)

0001-resolved-shorthand-ipv4-addresses-for-getaddrinfo-vi.patch (2.9 KB ) - added by a-star 3 years ago.
Modi
0001-getaddrinfo-now-accepts-shorthand-ipv4-notation.patch (1.0 KB ) - added by a-star 2 years ago.
For AF_INET inet_aton is used, inet_pton otherwise

Download all attachments as: .zip

Change History (17)

comment:1 by marcusoverhagen, 10 years ago

Description: modified (diff)

comment:2 by marcusoverhagen, 10 years ago

Summary: IP adress formatshort-form IP adress format broken

"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

comment:3 by diver, 8 years ago

Component: - GeneralNetwork & Internet

comment:4 by pulkomandy, 5 years ago

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.

comment:5 by a-star, 3 years ago

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?

comment:6 by pulkomandy, 3 years ago

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.

comment:7 by a-star, 3 years ago

Has a Patch: set

comment:8 by pulkomandy, 2 years ago

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.

comment:9 by pulkomandy, 2 years ago

Has a Patch: unset

comment:10 by a-star, 2 years ago

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.

comment:11 by pulkomandy, 2 years ago

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).

comment:12 by a-star, 2 years ago

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.

comment:13 by axeld, 2 years ago

Owner: changed from axeld to nobody
Status: newassigned

by a-star, 2 years ago

For AF_INET inet_aton is used, inet_pton otherwise

comment:14 by a-star, 2 years ago

Has a Patch: set

comment:15 by pulkomandy, 2 years ago

Keywords: gsoc2017 added
Resolution: fixed
Status: assignedclosed

Applied in hrev51113. Thanks!

Note: See TracTickets for help on using tickets.