getaddrinfo, ip address sort order?

getaddrinfo, ip address sort order?

[John Mudd]

[-- Attachment #1.1: Type: text/plain, Size: 322 bytes --]

I read that getaddrinfo() returns addresses sorted based on RFC 3484. I'm
using the attached program to test it and I'm not sure if they are sorted.

I looked at the musl getaddrinfo.c here:
https://github.com/idunham/musl/blob/master/src/network/getaddrinfo.c

I don't see an obvious sort in the code. Is it there?

John

[-- Attachment #1.2: Type: text/html, Size: 544 bytes --]

[-- Attachment #2: showip.c --]
[-- Type: text/x-csrc, Size: 1506 bytes --]

//
//
//
// Copied from http://www.logix.cz/michal/devel/various/getaddrinfo.c.xp
// Some changes.
//
//


/* 
 * getaddrinfo.c - Simple example of using getaddrinfo(3) function.
 * 
 * Michal Ludvig <michal@logix.cz> (c) 2002, 2003
 * http://www.logix.cz/michal/devel/
 *
 * License: public domain.
 */

#include <stdio.h>
#include <string.h>
#include <stdlib.h>
#include <netdb.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <arpa/inet.h>

int
lookup_host (const char *host)
{
  struct addrinfo hints, *res;
  int errcode;
  char addrstr[100];
  void *ptr;

  memset (&hints, 0, sizeof (hints));
  hints.ai_family = PF_UNSPEC;
  hints.ai_socktype = SOCK_STREAM;
  hints.ai_flags |= AI_CANONNAME;

  errcode = getaddrinfo (host, NULL, &hints, &res);
  if (errcode != 0)
    {
      perror ("getaddrinfo");
      return -1;
    }

  //printf ("Host: %s\n", host);
  while (res)
    {
      inet_ntop (res->ai_family, res->ai_addr->sa_data, addrstr, 100);

      switch (res->ai_family)
        {
        case AF_INET:
          ptr = &((struct sockaddr_in *) res->ai_addr)->sin_addr;
          break;
        case AF_INET6:
          ptr = &((struct sockaddr_in6 *) res->ai_addr)->sin6_addr;
          break;
        }
      inet_ntop (res->ai_family, ptr, addrstr, 100);
      printf ("IPv%d %s\n", res->ai_family == PF_INET6 ? 6 : 4, addrstr);
      res = res->ai_next;
    }

  return 0;
}

int
main (int argc, char *argv[])
{
  if (argc < 2)
    exit (1);
  return lookup_host (argv[1]);
}

Re: getaddrinfo, ip address sort order?

[John Mudd]

[-- Attachment #1: Type: text/plain, Size: 1065 bytes --]

Sorry, I see it listed now in release notes.
https://www.musl-libc.org/oldversions.html

Jun 25, 2014
This release adds many features including result sorting in the DNS/hosts
resolver modeled on RFC 3484, default timezone from /etc/localtime, gnu2
TLS dialect (TLSDESC) on i386 and x86_64, sendmmsg/recvmmsg functions
(Linux extensions), fmtmsg function (XSI), and optional arguments in getopt
(GNU extension). Handling of poorly-behaved nameservers (rcode=2 ServFail
result) is also improved, and setting of the %gs thread register is now
supported on pre-2.6 i386 kernels. Several bugs are fixed including a
potentially-important issue in memmem.

On Fri, Jun 3, 2016 at 11:21 AM, John Mudd <johnbmudd@gmail.com> wrote:

> I read that getaddrinfo() returns addresses sorted based on RFC 3484. I'm
> using the attached program to test it and I'm not sure if they are sorted.
>
> I looked at the musl getaddrinfo.c here:
> https://github.com/idunham/musl/blob/master/src/network/getaddrinfo.c
>
> I don't see an obvious sort in the code. Is it there?
>
> John
>
>

[-- Attachment #2: Type: text/html, Size: 1738 bytes --]

Re: getaddrinfo, ip address sort order?

[Rich Felker]

On Fri, Jun 03, 2016 at 11:21:42AM -0400, John Mudd wrote:
> I read that getaddrinfo() returns addresses sorted based on RFC 3484. I'm
> using the attached program to test it and I'm not sure if they are sorted.
> 
> I looked at the musl getaddrinfo.c here:
> https://github.com/idunham/musl/blob/master/src/network/getaddrinfo.c
> 
> I don't see an obvious sort in the code. Is it there?

The relevant code is in src/network/lookup_name.c. The reason it's
there is so that it also applies to the legacy host lookup functions.

It does not cover 100% of RFC 3484 but should do everything that
actually matters/makes sense. Let us know if you run into problems.
One known semi-bug is that it uses v4-mapped addresses with AF_INET6
to do the reachability probes for v4 addresses, which may fail on
systems with IPv6 completely removed, in which case the code will fail
to distinguish that v4 addresses are routable but v6 ones aren't (both
may appear non-routable). I plan to go back and fix the code to use
AF_INET sockets for probing v4 reachability.

Rich