mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Rich Felker <dalias@libc.org>
To: musl@lists.openwall.com
Subject: Re: getaddrinfo(3) / AI_ADDRCONFIG
Date: Fri, 13 Jul 2018 22:31:34 -0400	[thread overview]
Message-ID: <20180714023134.GH1392@brightrain.aerifal.cx> (raw)
In-Reply-To: <CAF4BF-RPKSYir55e7Z7V8NdPd16Sq+VD3g3O0ybcb++ccM4MUQ@mail.gmail.com>

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

On Thu, Jul 12, 2018 at 10:53:12PM -0400, Christopher Friedt wrote:
> On Thu, Jul 12, 2018 at 9:49 PM Rich Felker <dalias@libc.org> wrote:
> > Something's not going right with our communication about this. I've
> > attached an untested patch that's closer to what I've been looking
> > for. It corrects an oversight I'd made, that we need to block
> > cancellation during the probe, and localizes the change as originally
> > requested. Please let me know if it works. Arguably it might be nicer
> > to replace the repeated code with a table and 2-iteration for loop.
> 
> I originally wrote my patch with the intention of being as unobtrusive
> as possible but rather than disagree realized it was better to just do
> what you wanted me to.
> 
> The struct was a better solution for when the addrconfig logic lived
> in a separate function. It probably could have even been a separate
> static function inside of getaddrinfo.c, but I anticipated that you
> would not have liked that.
> 
> Definitely correct to disable pthread cancellation.
> 
> I used struct sockaddr_storage to avoid declaring more than one
> sockaddr because I thought you would have preferred that. Personally,
> I would have preferred to use two separate sockaddr too. Solves that
> problem.
> 
> Originally, I wanted to use a loop over the length of a table, but
> figured you would dislike that in favour of readability. Assuming
> there will only be ever be AF_INET and AF_INET6 support for
> getaddrinfo(3), handling it this or that way is fine.
> 
> The patch works for me as is or with the loop.

Here's a version with the loop. I've tested it now with ::1 removed
from device lo, but the connect to ::1 still succeeds; I suspect
presence of a default route for IPv6 makes it work since ::1 is
"routable" then. Can you confirm that it actually suppresses IPv6 in
your purely-no-IPv6 environment, as intended?

Rich

[-- Attachment #2: ai_addrconfig2.diff --]
[-- Type: text/plain, Size: 1558 bytes --]

diff --git a/src/network/getaddrinfo.c b/src/network/getaddrinfo.c
index b9439f7..91b4d30 100644
--- a/src/network/getaddrinfo.c
+++ b/src/network/getaddrinfo.c
@@ -3,6 +3,9 @@
 #include <netinet/in.h>
 #include <netdb.h>
 #include <string.h>
+#include <pthread.h>
+#include <unistd.h>
+#include <endian.h>
 #include "lookup.h"
 
 int getaddrinfo(const char *restrict host, const char *restrict serv, const struct addrinfo *restrict hint, struct addrinfo **restrict res)
@@ -43,6 +46,35 @@ int getaddrinfo(const char *restrict host, const char *restrict serv, const stru
 		}
 	}
 
+	if (flags & AI_ADDRCONFIG) {
+		static const struct sockaddr_in lo4 = {
+			.sin_family = AF_INET, .sin_port = 65535,
+			.sin_addr.s_addr = __BYTE_ORDER == __BIG_ENDIAN
+				? 0x7f000001 : 0x0100007f
+		};
+		static const struct sockaddr_in6 lo6 = {
+			.sin6_family = AF_INET6, .sin6_port = 65535,
+			.sin6_addr = IN6ADDR_LOOPBACK_INIT
+		};
+		int tf[2] = { AF_INET, AF_INET6 };
+		const void *ta[2] = { &lo4, &lo6 };
+		socklen_t tl[2] = { sizeof lo4, sizeof lo6 };
+		int cs;
+		pthread_setcancelstate(PTHREAD_CANCEL_DISABLE, &cs);
+		for (i=0; i<2; i++) {
+			if (family==tf[1-i]) continue;
+			int s = socket(tf[i], SOCK_CLOEXEC|SOCK_DGRAM,
+				IPPROTO_UDP);
+			if (s<0) continue;
+			int r = connect(s, ta[i], tl[i]);
+			close(s);
+			if (!r) continue;
+			if (family == tf[i]) return EAI_NONAME;
+			family = tf[1-i];
+		}
+		pthread_setcancelstate(cs, 0);
+	}
+
 	nservs = __lookup_serv(ports, serv, proto, socktype, flags);
 	if (nservs < 0) return nservs;
 

  reply	other threads:[~2018-07-14  2:31 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-07-09 15:16 Christopher Friedt
2018-07-09 22:38 ` Rich Felker
2018-07-10  0:11   ` Christopher Friedt
2018-07-10  0:59     ` Rich Felker
2018-07-10 12:05       ` Christopher Friedt
2018-07-10 15:08         ` Rich Felker
2018-07-10 23:21           ` Christopher Friedt
2018-07-10 23:30             ` Christopher Friedt
2018-07-10 23:42               ` Christopher Friedt
2018-07-11  0:38               ` Rich Felker
2018-07-11  1:01                 ` Christopher Friedt
2018-07-11  1:26                   ` Rich Felker
2018-07-11 10:12                     ` Christopher Friedt
2018-07-11 16:44                       ` Rich Felker
2018-07-11 16:50                         ` Christopher Friedt
2018-07-11 17:00                           ` Rich Felker
2018-07-12  1:20                             ` Christopher Friedt
2018-07-13  1:49                               ` Rich Felker
2018-07-13  2:53                                 ` Christopher Friedt
2018-07-14  2:31                                   ` Rich Felker [this message]
2018-07-14 23:53                                     ` Christopher Friedt
2018-07-15  0:07                                       ` Rich Felker
2018-07-15  0:19                                         ` Rich Felker
2018-07-15  0:52                                           ` Rich Felker
2018-07-15  1:17                                             ` Christopher Friedt
2018-07-19  0:14                                               ` Christopher Friedt
2018-07-19  0:49                                                 ` Rich Felker
2018-07-19  0:57                                                   ` Christopher Friedt

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180714023134.GH1392@brightrain.aerifal.cx \
    --to=dalias@libc.org \
    --cc=musl@lists.openwall.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).