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;
next prev parent 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).