mailing list of musl libc
 help / color / mirror / Atom feed
* [musl] getaddrinfo(3) with AI_V4MAPPED and AI_ALL flags
@ 2020-02-27 10:17 Alexander Scherbatiy
  2020-02-27 14:45 ` Rich Felker
  0 siblings, 1 reply; 8+ messages in thread
From: Alexander Scherbatiy @ 2020-02-27 10:17 UTC (permalink / raw)
  To: musl

Hello,

When I call getaddrinfo() with different families, SOCK_STREAM socktype, 
IPPROTO_TCP protocol, and AI_PASSIVE flag the result is the same on the 
Alpine Linux 3.11.3 and Ubuntu 19.10 (the code sample is below):

----------------

family: AF_UNSPEC, flags: AI_PASSIVE
AF_INET  IPv4 addr '0.0.0.0'
AF_INET6 IPv6 addr '::'

family: AF_INET,   flags: AI_PASSIVE
AF_INET  IPv4 addr '0.0.0.0'

family: AF_INET6,  flags: AI_PASSIVE
AF_INET6 IPv6 addr '::'

----------------

When I use getaddrinfo() with AF_INET6 family and additional AI_V4MAPPED 
| AI_ALL (return both IPv6 and IPv4-mapped IPv6 addresses) flags the 
result on Ubuntu contains only IPv6 '::' address:

----------------

family: AF_INET6,  flags: AI_PASSIVE | AI_V4MAPPED | AI_ALL
AF_INET6 IPv6 addr '::'

----------------

whereas the result on Alpine Linux contains both IPv4-mapped IPv6 
addresses '::ffff:0.0.0.0' and  IPv6 '::'

----------------

family: AF_INET6,  flags: AI_PASSIVE | AI_V4MAPPED | AI_ALL
AF_INET6 IPv6 addr '::ffff:0.0.0.0'
AF_INET6 IPv6 addr '::'

----------------

Is it expected behavior?

I use Alpine Linux 3.11.3 from docker with musl libc (x86_64).

Thanks,

Alexander.


Code sample:

-------------  addr_info.c -----------

#include <stdio.h>
#include <stdlib.h>
#include <string.h>

#include <netdb.h>
#include <arpa/inet.h>


void sockaddr_show(struct sockaddr *sa) {

     int family = sa->sa_family;

     if (family == AF_INET) {
         char buff[INET_ADDRSTRLEN];
         struct sockaddr_in server_addr = *((struct sockaddr_in*) sa);
         inet_ntop(AF_INET, &server_addr.sin_addr, buff, INET_ADDRSTRLEN);
         printf("AF_INET  IPv4 addr '%s'\n", buff);
     } else if (family == AF_INET6) {
         char buff[INET_ADDRSTRLEN];
         struct sockaddr_in6 server_addr = *((struct sockaddr_in6*) sa);
         inet_ntop(AF_INET6, &server_addr.sin6_addr, buff, 
INET6_ADDRSTRLEN);
         printf("AF_INET6 IPv6 addr '%s'\n", buff);
     } else {
         printf("family: %d\n", family);
     }
}

void show_addr_info(int family, int flags) {

     char* hostname = NULL;
     char* service = "33833";

     struct addrinfo hints;
     struct addrinfo *result, *rp;

     memset (&hints, 0, sizeof(hints));

     hints.ai_family = family;
     hints.ai_socktype = SOCK_STREAM;
     hints.ai_protocol = IPPROTO_TCP;
     hints.ai_flags = flags;

     int res = getaddrinfo(hostname, service, &hints, &result);
     for (rp = result; rp != NULL; rp = rp->ai_next) {
         sockaddr_show(rp->ai_addr);
     }
     printf("\n");
}

int main(void) {

     printf("family: AF_UNSPEC, flags: AI_PASSIVE\n");
     show_addr_info(AF_UNSPEC, AI_PASSIVE);

     printf("family: AF_INET,   flags: AI_PASSIVE\n");
     show_addr_info(AF_INET,   AI_PASSIVE);

     printf("family: AF_INET6,  flags: AI_PASSIVE\n");
     show_addr_info(AF_INET6,  AI_PASSIVE);

     printf("family: AF_INET6,  flags: AI_PASSIVE | AI_V4MAPPED | 
AI_ALL\n");
     show_addr_info(AF_INET6,  AI_PASSIVE | AI_V4MAPPED | AI_ALL);

     return EXIT_SUCCESS;
}

--------------------------------






^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [musl] getaddrinfo(3) with AI_V4MAPPED and AI_ALL flags
  2020-02-27 10:17 [musl] getaddrinfo(3) with AI_V4MAPPED and AI_ALL flags Alexander Scherbatiy
@ 2020-02-27 14:45 ` Rich Felker
  2020-07-30 15:20   ` Alexander Scherbatiy
  0 siblings, 1 reply; 8+ messages in thread
From: Rich Felker @ 2020-02-27 14:45 UTC (permalink / raw)
  To: musl

On Thu, Feb 27, 2020 at 01:17:20PM +0300, Alexander Scherbatiy wrote:
> Hello,
> 
> When I call getaddrinfo() with different families, SOCK_STREAM
> socktype, IPPROTO_TCP protocol, and AI_PASSIVE flag the result is
> the same on the Alpine Linux 3.11.3 and Ubuntu 19.10 (the code
> sample is below):
> 
> ----------------
> 
> family: AF_UNSPEC, flags: AI_PASSIVE
> AF_INET  IPv4 addr '0.0.0.0'
> AF_INET6 IPv6 addr '::'
> 
> family: AF_INET,   flags: AI_PASSIVE
> AF_INET  IPv4 addr '0.0.0.0'
> 
> family: AF_INET6,  flags: AI_PASSIVE
> AF_INET6 IPv6 addr '::'
> 
> ----------------
> 
> When I use getaddrinfo() with AF_INET6 family and additional
> AI_V4MAPPED | AI_ALL (return both IPv6 and IPv4-mapped IPv6
> addresses) flags the result on Ubuntu contains only IPv6 '::'
> address:
> 
> ----------------
> 
> family: AF_INET6,  flags: AI_PASSIVE | AI_V4MAPPED | AI_ALL
> AF_INET6 IPv6 addr '::'
> 
> ----------------
> 
> whereas the result on Alpine Linux contains both IPv4-mapped IPv6
> addresses '::ffff:0.0.0.0' and  IPv6 '::'
> 
> ----------------
> 
> family: AF_INET6,  flags: AI_PASSIVE | AI_V4MAPPED | AI_ALL
> AF_INET6 IPv6 addr '::ffff:0.0.0.0'
> AF_INET6 IPv6 addr '::'
> 
> ----------------
> 
> Is it expected behavior?
> 
> I use Alpine Linux 3.11.3 from docker with musl libc (x86_64).

The musl behavior is as intended and I think it's more correct. If
net.ipv6.bindv6only sysctl is enabled, binding using the glibc results
would fail to accept ipv4 connections.

Rich

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [musl] getaddrinfo(3) with AI_V4MAPPED and AI_ALL flags
  2020-02-27 14:45 ` Rich Felker
@ 2020-07-30 15:20   ` Alexander Scherbatiy
  2020-07-30 16:00     ` Rich Felker
  0 siblings, 1 reply; 8+ messages in thread
From: Alexander Scherbatiy @ 2020-07-30 15:20 UTC (permalink / raw)
  To: musl, Rich Felker


  glibc getaddrinfo(3) function uses /etc/gai.conf file to sort addrinfo 
results.
  does musl getaddrinfo(3) implementations allows to configure the 
results order?

Thanks,
Alexander.

On 27.02.2020 17:45, Rich Felker wrote:
> On Thu, Feb 27, 2020 at 01:17:20PM +0300, Alexander Scherbatiy wrote:
>> Hello,
>>
>> When I call getaddrinfo() with different families, SOCK_STREAM
>> socktype, IPPROTO_TCP protocol, and AI_PASSIVE flag the result is
>> the same on the Alpine Linux 3.11.3 and Ubuntu 19.10 (the code
>> sample is below):
>>
>> ----------------
>>
>> family: AF_UNSPEC, flags: AI_PASSIVE
>> AF_INET  IPv4 addr '0.0.0.0'
>> AF_INET6 IPv6 addr '::'
>>
>> family: AF_INET,   flags: AI_PASSIVE
>> AF_INET  IPv4 addr '0.0.0.0'
>>
>> family: AF_INET6,  flags: AI_PASSIVE
>> AF_INET6 IPv6 addr '::'
>>
>> ----------------
>>
>> When I use getaddrinfo() with AF_INET6 family and additional
>> AI_V4MAPPED | AI_ALL (return both IPv6 and IPv4-mapped IPv6
>> addresses) flags the result on Ubuntu contains only IPv6 '::'
>> address:
>>
>> ----------------
>>
>> family: AF_INET6,  flags: AI_PASSIVE | AI_V4MAPPED | AI_ALL
>> AF_INET6 IPv6 addr '::'
>>
>> ----------------
>>
>> whereas the result on Alpine Linux contains both IPv4-mapped IPv6
>> addresses '::ffff:0.0.0.0' and  IPv6 '::'
>>
>> ----------------
>>
>> family: AF_INET6,  flags: AI_PASSIVE | AI_V4MAPPED | AI_ALL
>> AF_INET6 IPv6 addr '::ffff:0.0.0.0'
>> AF_INET6 IPv6 addr '::'
>>
>> ----------------
>>
>> Is it expected behavior?
>>
>> I use Alpine Linux 3.11.3 from docker with musl libc (x86_64).
> The musl behavior is as intended and I think it's more correct. If
> net.ipv6.bindv6only sysctl is enabled, binding using the glibc results
> would fail to accept ipv4 connections.
>
> Rich

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [musl] getaddrinfo(3) with AI_V4MAPPED and AI_ALL flags
  2020-07-30 15:20   ` Alexander Scherbatiy
@ 2020-07-30 16:00     ` Rich Felker
  2020-07-31 16:21       ` Dmitry Samersoff
  0 siblings, 1 reply; 8+ messages in thread
From: Rich Felker @ 2020-07-30 16:00 UTC (permalink / raw)
  To: Alexander Scherbatiy; +Cc: musl

On Thu, Jul 30, 2020 at 06:20:36PM +0300, Alexander Scherbatiy wrote:
> 
>  glibc getaddrinfo(3) function uses /etc/gai.conf file to sort
> addrinfo results.
>  does musl getaddrinfo(3) implementations allows to configure the
> results order?

Presently no, and there doesn't seem to have been a lot of demand for
it, though there was at least one other request. IIRC I asked about
the motivation since normally the default sorting should do the right
thing, and I believe it was for the sake of overriding for some sites
with broken IPv6 connectivity. If you have other use cases in mind it
would be good to mention them to help document that this is a feature
that makes sense to consider adding.

Rich

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [musl] getaddrinfo(3) with AI_V4MAPPED and AI_ALL flags
  2020-07-30 16:00     ` Rich Felker
@ 2020-07-31 16:21       ` Dmitry Samersoff
  2020-07-31 19:19         ` Rich Felker
  0 siblings, 1 reply; 8+ messages in thread
From: Dmitry Samersoff @ 2020-07-31 16:21 UTC (permalink / raw)
  To: musl, Rich Felker, Alexander Scherbatiy

Hello Rich,

I'm not sure that mapping of INADDR_ANY (0.0.0.0) and return of 
::ffff:0.0.0.0' has any sense.

Should it be filtered out on musl level?

-Dmitry

On 30.07.2020 19:00, Rich Felker wrote:
> On Thu, Jul 30, 2020 at 06:20:36PM +0300, Alexander Scherbatiy wrote:
>>
>>   glibc getaddrinfo(3) function uses /etc/gai.conf file to sort
>> addrinfo results.
>>   does musl getaddrinfo(3) implementations allows to configure the
>> results order?
> 
> Presently no, and there doesn't seem to have been a lot of demand for
> it, though there was at least one other request. IIRC I asked about
> the motivation since normally the default sorting should do the right
> thing, and I believe it was for the sake of overriding for some sites
> with broken IPv6 connectivity. If you have other use cases in mind it
> would be good to mention them to help document that this is a feature
> that makes sense to consider adding.
> 
> Rich
> 


^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [musl] getaddrinfo(3) with AI_V4MAPPED and AI_ALL flags
  2020-07-31 16:21       ` Dmitry Samersoff
@ 2020-07-31 19:19         ` Rich Felker
  2020-08-03  8:15           ` Dmitry Samersoff
  0 siblings, 1 reply; 8+ messages in thread
From: Rich Felker @ 2020-07-31 19:19 UTC (permalink / raw)
  To: musl

On Fri, Jul 31, 2020 at 07:21:47PM +0300, Dmitry Samersoff wrote:
> Hello Rich,
> 
> I'm not sure that mapping of INADDR_ANY (0.0.0.0) and return of
> ::ffff:0.0.0.0' has any sense.
> 
> Should it be filtered out on musl level?

This is an interesting question. What happens if you bind
::ffff:0.0.0.0 on an IPv6 socket? Is it the same as binding :: or does
it produce a v6 socket that only accepts v4 connections? If it has its
own distinct functionality then returning it when V4MAPPED is
requested seems to make some sense.

Rich

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [musl] getaddrinfo(3) with AI_V4MAPPED and AI_ALL flags
  2020-07-31 19:19         ` Rich Felker
@ 2020-08-03  8:15           ` Dmitry Samersoff
  2020-08-03 13:37             ` Rich Felker
  0 siblings, 1 reply; 8+ messages in thread
From: Dmitry Samersoff @ 2020-08-03  8:15 UTC (permalink / raw)
  To: musl, Rich Felker

Hello Rich,

If you bind to ::ffff:0.0.0.0 on an IPv6 socket you will be able to 
receive IPv4 connection only.

If you bind to :: on an IPv6 socket you will be able to receive both,
IPv6 and IPv4 connections.

So, on my opinion, if ::ffff:0.0.0.0 is the only IPv4 address on the 
interface it should not be returned.

-Dmitry

On 31.07.2020 22:19, Rich Felker wrote:
> On Fri, Jul 31, 2020 at 07:21:47PM +0300, Dmitry Samersoff wrote:
>> Hello Rich,
>>
>> I'm not sure that mapping of INADDR_ANY (0.0.0.0) and return of
>> ::ffff:0.0.0.0' has any sense.
>>
>> Should it be filtered out on musl level?
> 
> This is an interesting question. What happens if you bind
> ::ffff:0.0.0.0 on an IPv6 socket? Is it the same as binding :: or does
> it produce a v6 socket that only accepts v4 connections? If it has its
> own distinct functionality then returning it when V4MAPPED is
> requested seems to make some sense.
> 
> Rich
> 


^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [musl] getaddrinfo(3) with AI_V4MAPPED and AI_ALL flags
  2020-08-03  8:15           ` Dmitry Samersoff
@ 2020-08-03 13:37             ` Rich Felker
  0 siblings, 0 replies; 8+ messages in thread
From: Rich Felker @ 2020-08-03 13:37 UTC (permalink / raw)
  To: Dmitry Samersoff; +Cc: musl

On Mon, Aug 03, 2020 at 11:15:54AM +0300, Dmitry Samersoff wrote:
> Hello Rich,
> 
> If you bind to ::ffff:0.0.0.0 on an IPv6 socket you will be able to
> receive IPv4 connection only.
> 
> If you bind to :: on an IPv6 socket you will be able to receive both,
> IPv6 and IPv4 connections.
> 
> So, on my opinion, if ::ffff:0.0.0.0 is the only IPv4 address on the
> interface it should not be returned.

I don't see how your reasoning follows. On a system with
net.ipv6.bindv6only=1 configured, binding :: does not suffice to receive
ipv4 connections. If the application is using AI_V4MAPPED in order to
work entirely with v6 sockets, it needs to bind ::ffff:0.0.0.0 in
order to be able to receive v4 connections, so it needs to be returned
in the list of results.

On a system with net.ipv6.bindv6only=0 (the default and reasonable
setting), it does not hurt to attempt binding both; in one order I
believe the v4mapped one may fail, but that's fine.

Rich



> On 31.07.2020 22:19, Rich Felker wrote:
> >On Fri, Jul 31, 2020 at 07:21:47PM +0300, Dmitry Samersoff wrote:
> >>Hello Rich,
> >>
> >>I'm not sure that mapping of INADDR_ANY (0.0.0.0) and return of
> >>::ffff:0.0.0.0' has any sense.
> >>
> >>Should it be filtered out on musl level?
> >
> >This is an interesting question. What happens if you bind
> >::ffff:0.0.0.0 on an IPv6 socket? Is it the same as binding :: or does
> >it produce a v6 socket that only accepts v4 connections? If it has its
> >own distinct functionality then returning it when V4MAPPED is
> >requested seems to make some sense.
> >
> >Rich
> >

^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2020-08-03 13:37 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-02-27 10:17 [musl] getaddrinfo(3) with AI_V4MAPPED and AI_ALL flags Alexander Scherbatiy
2020-02-27 14:45 ` Rich Felker
2020-07-30 15:20   ` Alexander Scherbatiy
2020-07-30 16:00     ` Rich Felker
2020-07-31 16:21       ` Dmitry Samersoff
2020-07-31 19:19         ` Rich Felker
2020-08-03  8:15           ` Dmitry Samersoff
2020-08-03 13:37             ` Rich Felker

mailing list of musl libc

This inbox may be cloned and mirrored by anyone:

	git clone --mirror http://inbox.vuxu.org/musl

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V1 musl musl/ http://inbox.vuxu.org/musl \
		musl@inbox.vuxu.org
	public-inbox-index musl

Example config snippet for mirrors.
Newsgroup available over NNTP:
	nntp://inbox.vuxu.org/vuxu.archive.musl


code repositories for the project(s) associated with this inbox:

	https://git.vuxu.org/mirror/musl/

AGPL code for this site: git clone https://public-inbox.org/public-inbox.git