Re: libc: #define to remove support for %n from printf(3)?
What's their hangup with %n? We normally don't like polluting the world with #ifdef OPENSSL_NO_PERCENT_N... We normally nuke stuff like that On 2 May 2014 16:19, "enh" wrote: > i maintain Android's C library which, as you may know, contains a lot > of OpenBSD code. i've been working to clean up our mess and get us > back in sync with upstream, and currently have 173 files that are > exactly the same as current upstream OpenBSD. (more than we have from > the other two BSDs put together.) > > the one thing i've had pushback on is that by switching to the current > upstream source i've effectively added support for printf(3)'s %n to > Android, which our security guys are not happy about. Android has > never supported %n before. > > ideally i'd like to have no differences between Android and OpenBSD in > the shared source files, because i've seen what a mess things were > when we diverged (and how many bugs went unfixed in Android despite > having been fixed for years upstream). so rather than start back on > the slippery slope of adding Android-specific hacks, i wondered if > you'd consider adding #ifndef REMOVE_PERCENT_N_SUPPORT (or whatever) > around the implementation of %n in lib/libc/stdio/vfprintf.c and > lib/libc/stdio/vfwprintf.c. > > you already have stuff like FLOATING_POINT and PRINTF_WIDE_CHAR so > there's some precedent here. > > thoughts? (assuming this is the right list. if not, please point me in > the right direction.) > > --elliott > >
Re: [RFC] Ai_ADDRCONFIG^WAIAIAIAIAIAIAEEEEEEEEE tweaks?
* Kenneth Westerback [2014-05-02 22:14]: > On 2 May 2014 16:08, Paul de Weerd wrote: > > Well, I think -inet6 would be a good default, but I think there's more > > to it. Enabling net.inet6.ip6.accept_rtadv should still get me a > > link-local address (and, if router advertisements are present on the > > local network, an autoconfigured (autoconfprivacy) address too). But > > if I have multiple interfaces and configure my system for SLAAC, what > > should happen? To me, it seems that accept_rtadv should be a > > per-interface thing. > > > > Anyway, I believe at least -inet6 is a better default than the current > > situation. > -inet6 as the default seems more OpenBSD'ish to me. Everything off > that can be off, but not more. there is way more to it than "the default". there is no easy way to get rid of ipvshit completely, short of recompiling w/o option INET6. every interface you take up has that linklocal shit, unless you give -inet6 for each and every one every time, which is very easy to miss. thus I do think we want a net.inet6.ip.enable sysctl or the like, which, if not set to 1, enforces -inet6 on all ifs. what the default of such a sysctl would be is another discussion - any value is fine with me as long as it is 0. -- Henning Brauer, h...@bsws.de, henn...@openbsd.org BS Web Services GmbH, http://bsws.de, Full-Service ISP Secure Hosting, Mail and DNS Services. Dedicated Servers, Root to Fully Managed Henning Brauer Consulting, http://henningbrauer.com/
Re: [RFC] Ai_ADDRCONFIG^WAIAIAIAIAIAIAEEEEEEEEE tweaks?
Henning Brauer writes: > * Paul de Weerd [2014-05-02 21:20]: >> On Fri, May 02, 2014 at 06:53:08PM +0200, Jérémie Courrèges-Anglas wrote: > [connectivity via link-local] >> | Not really, I'm puzzled by your question. It works and has always >> | worked but I shouldn't expect them to work... >> I'm puzzled by the fact it has always been this way in OpenBSD. It >> goes against the OpenBSD philosophy. > > see where the v6 zealots got us? So there can't be a middle ground between the opinions of the v6 zealots and those of the v6 haters, great. -- jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
Re: [RFC] Ai_ADDRCONFIG^WAIAIAIAIAIAIAEEEEEEEEE tweaks?
Paul de Weerd writes: > On Fri, May 02, 2014 at 06:53:08PM +0200, Jérémie Courrèges-Anglas wrote: > | > | What's a regular OpenBSD host with no IPv6? I'd assume that it is > | > | a host that can perform IPv6 connections to ::1 / localhost and reach > | > | its neighbors through link-local addresses. > | > > | > Why would you expect to be able to reach your neighbors through > | > link-local addresses if you have "no IPv6" (which I take to mean 'no > | > *configured* IPv6', please correct me if I'm wrong here)? > | > | I don't make a big difference between automatically or "manually" > | configured addresses. They're here and supposed to be usable for > | whatever purpose, limited only by their intrinsic limitations. > > I'm not referring to SLAAC. I'm referring to addresses that are > configured on interfaces without the user even requesting them. > link-local addresses, specifically. I was actually answering your question about link-local addresses. > Bring up an interface and you > have IPv6. Accessible (and attackable) by everyone on the local > network (i.e., not firewalled by default). If you have no use for this interface, why do you bring it up? Why do you have services listening on it, be it an IPv4 address or an IPv6 link-local one? > Why do you expect this to > work without specific configuration (either setting up a static > address, configuring SLAAC, by using DHCPv6, or whatever means)? You know why. This is how v6 works, and I heard OpenBSD made a pretty good job at making it work in a pretty safe way. > | > I believe your expectation here is wrong (although it is the current > | > state of IPv6 on OpenBSD). Can you explain why you disagree? > | > | Not really, I'm puzzled by your question. It works and has always > | worked but I shouldn't expect them to work... > > I'm puzzled by the fact it has always been this way in OpenBSD. It > goes against the OpenBSD philosophy. Maybe it is, or maybe not. I am not the one that says that (almost?) all the IPv6 implementations out there, running ND by default, are wrong. What's the actual impact? What are the risks? How do you evaluate them? How much may someone be surprised by this fact? > I'll try to rephrase the > question: > > Why do you expect that you are accessible on IPv6 > when you configure an interface with IPv4? You > don't expect to get IPv4 connectivity when you > configure IPv6, do you? Same answer. The current practice is to run ND and configure link-local addresses by default, yet I have to explain why this assumption should be valid. This is tiresome. > I hope this question is less puzzling, apologies if that's still not > the case. It's not puzzling anymore, it's merely annoying. -- jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
Re: [RFC] Ai_ADDRCONFIG^WAIAIAIAIAIAIAEEEEEEEEE tweaks?
On 2 May 2014 16:25, Philip Guenther wrote: > On Fri, May 2, 2014 at 1:14 PM, Kenneth Westerback > wrote: >> >> -inet6 as the default seems more OpenBSD'ish to me. Everything off >> that can be off, but not more. > > > "That is not off which can eternal lie, > And with strange aeons even inet4 may die." > > "Their hand is at your throats, yet ye see Them not; and Their habitation is even one with your guarded interface." Ken
Re: [RFC] Ai_ADDRCONFIG^WAIAIAIAIAIAIAEEEEEEEEE tweaks?
On Fri, May 2, 2014 at 1:14 PM, Kenneth Westerback wrote: > > -inet6 as the default seems more OpenBSD'ish to me. Everything off > that can be off, but not more. > "That is not off which can eternal lie, And with strange aeons even inet4 may die."
Re: [RFC] Ai_ADDRCONFIG^WAIAIAIAIAIAIAEEEEEEEEE tweaks?
On 2 May 2014 16:08, Paul de Weerd wrote: > On Fri, May 02, 2014 at 09:59:09PM +0200, Henning Brauer wrote: > | * Paul de Weerd [2014-05-02 21:20]: > | > On Fri, May 02, 2014 at 06:53:08PM +0200, Jérémie Courrèges-Anglas wrote: > | [connectivity via link-local] > | > | Not really, I'm puzzled by your question. It works and has always > | > | worked but I shouldn't expect them to work... > | > I'm puzzled by the fact it has always been this way in OpenBSD. It > | > goes against the OpenBSD philosophy. > | > | see where the v6 zealots got us? > > Well, I do consider myself an IPv6 enthusiast. Probably not a zealot; > I'm not one for zealotry myself... :) > > | > I'll try to rephrase the question: > | > > | > Why do you expect that you are accessible on IPv6 > | > when you configure an interface with IPv4? You > | > don't expect to get IPv4 connectivity when you > | > configure IPv6, do you? > | > | a very good question to ask. > | > | i wish -inet6 was default. > | > | i'll probably add a sysctl to globally nuke v6 from all interfaces > | soon. somebody pls remind me at the next hackathon. > > Well, I think -inet6 would be a good default, but I think there's more > to it. Enabling net.inet6.ip6.accept_rtadv should still get me a > link-local address (and, if router advertisements are present on the > local network, an autoconfigured (autoconfprivacy) address too). But > if I have multiple interfaces and configure my system for SLAAC, what > should happen? To me, it seems that accept_rtadv should be a > per-interface thing. > > Anyway, I believe at least -inet6 is a better default than the current > situation. > > Paul 'WEiRD' de Weerd > > -- >>[<++>-]<+++.>+++[<-->-]<.>+++[<+ > +++>-]<.>++[<>-]<+.--.[-] > http://www.weirdnet.nl/ > -inet6 as the default seems more OpenBSD'ish to me. Everything off that can be off, but not more. Ken
Re: [RFC] Ai_ADDRCONFIG^WAIAIAIAIAIAIAEEEEEEEEE tweaks?
On Fri, May 02, 2014 at 09:59:09PM +0200, Henning Brauer wrote: | * Paul de Weerd [2014-05-02 21:20]: | > On Fri, May 02, 2014 at 06:53:08PM +0200, Jérémie Courrèges-Anglas wrote: | [connectivity via link-local] | > | Not really, I'm puzzled by your question. It works and has always | > | worked but I shouldn't expect them to work... | > I'm puzzled by the fact it has always been this way in OpenBSD. It | > goes against the OpenBSD philosophy. | | see where the v6 zealots got us? Well, I do consider myself an IPv6 enthusiast. Probably not a zealot; I'm not one for zealotry myself... :) | > I'll try to rephrase the question: | > | > Why do you expect that you are accessible on IPv6 | > when you configure an interface with IPv4? You | > don't expect to get IPv4 connectivity when you | > configure IPv6, do you? | | a very good question to ask. | | i wish -inet6 was default. | | i'll probably add a sysctl to globally nuke v6 from all interfaces | soon. somebody pls remind me at the next hackathon. Well, I think -inet6 would be a good default, but I think there's more to it. Enabling net.inet6.ip6.accept_rtadv should still get me a link-local address (and, if router advertisements are present on the local network, an autoconfigured (autoconfprivacy) address too). But if I have multiple interfaces and configure my system for SLAAC, what should happen? To me, it seems that accept_rtadv should be a per-interface thing. Anyway, I believe at least -inet6 is a better default than the current situation. Paul 'WEiRD' de Weerd -- >[<++>-]<+++.>+++[<-->-]<.>+++[<+ +++>-]<.>++[<>-]<+.--.[-] http://www.weirdnet.nl/
Re: [RFC] Ai_ADDRCONFIG^WAIAIAIAIAIAIAEEEEEEEEE tweaks?
* Paul de Weerd [2014-05-02 21:20]: > On Fri, May 02, 2014 at 06:53:08PM +0200, Jérémie Courrèges-Anglas wrote: [connectivity via link-local] > | Not really, I'm puzzled by your question. It works and has always > | worked but I shouldn't expect them to work... > I'm puzzled by the fact it has always been this way in OpenBSD. It > goes against the OpenBSD philosophy. see where the v6 zealots got us? > I'll try to rephrase the question: > > Why do you expect that you are accessible on IPv6 > when you configure an interface with IPv4? You > don't expect to get IPv4 connectivity when you > configure IPv6, do you? a very good question to ask. i wish -inet6 was default. i'll probably add a sysctl to globally nuke v6 from all interfaces soon. somebody pls remind me at the next hackathon. -- Henning Brauer, h...@bsws.de, henn...@openbsd.org BS Web Services GmbH, http://bsws.de, Full-Service ISP Secure Hosting, Mail and DNS Services. Dedicated Servers, Root to Fully Managed Henning Brauer Consulting, http://henningbrauer.com/
Re: [RFC] Ai_ADDRCONFIG^WAIAIAIAIAIAIAEEEEEEEEE tweaks?
On Fri, May 02, 2014 at 06:53:08PM +0200, Jérémie Courrèges-Anglas wrote: | > | What's a regular OpenBSD host with no IPv6? I'd assume that it is | > | a host that can perform IPv6 connections to ::1 / localhost and reach | > | its neighbors through link-local addresses. | > | > Why would you expect to be able to reach your neighbors through | > link-local addresses if you have "no IPv6" (which I take to mean 'no | > *configured* IPv6', please correct me if I'm wrong here)? | | I don't make a big difference between automatically or "manually" | configured addresses. They're here and supposed to be usable for | whatever purpose, limited only by their intrinsic limitations. I'm not referring to SLAAC. I'm referring to addresses that are configured on interfaces without the user even requesting them. link-local addresses, specifically. Bring up an interface and you have IPv6. Accessible (and attackable) by everyone on the local network (i.e., not firewalled by default). Why do you expect this to work without specific configuration (either setting up a static address, configuring SLAAC, by using DHCPv6, or whatever means)? | > I believe your expectation here is wrong (although it is the current | > state of IPv6 on OpenBSD). Can you explain why you disagree? | | Not really, I'm puzzled by your question. It works and has always | worked but I shouldn't expect them to work... I'm puzzled by the fact it has always been this way in OpenBSD. It goes against the OpenBSD philosophy. I'll try to rephrase the question: Why do you expect that you are accessible on IPv6 when you configure an interface with IPv4? You don't expect to get IPv4 connectivity when you configure IPv6, do you? I hope this question is less puzzling, apologies if that's still not the case. Cheers, Paul 'WEiRD' de Weerd -- >[<++>-]<+++.>+++[<-->-]<.>+++[<+ +++>-]<.>++[<>-]<+.--.[-] http://www.weirdnet.nl/
nc -F for clients
A recently added -F option to the nc (netcat) command to pass a
connected file descriptor to stdout only works for the listen mode
when it passes the accepted descriptor.
The patch below makes -F universal. When given it makes nc to always
pass the socket to stdout rather than performing the copy loop. This
works both in the client and the server modes including -l -k when nc
continuesly passes to stdout all sockets it accepted when listening to
the connection.
The patch aslo updates nc.1 to show how to use nc -F together with
ProxyUseFdPass.
Index: nc.1
===
RCS file: /cvs/src/usr.bin/nc/nc.1,v
retrieving revision 1.67
diff -U3 -p -r1.67 nc.1
--- nc.126 Feb 2014 20:56:11 -1.67
+++ nc.12 May 2014 18:18:10 -
@@ -103,9 +103,9 @@ Enable debugging on the socket.
.It Fl d
Do not attempt to read from stdin.
.It Fl F
-Pass the first connected socket using
+Pass the connected socket using
.Xr sendmsg 2
-to stdout and exit.
+to stdout and close own copy.
This is useful in conjunction with
.Fl X
to have
@@ -116,7 +116,14 @@ connection to another program (e.g.\&
using the
.Xr ssh_config 5
.Cm ProxyUseFdPass
-option).
+directive). When this option is specified together with
+.Fl l,
+.Nm
+sends a socket representing the connection it accepted from a client. If the
+.Fl k
+is also given,
+.Nm
+will continue to send all incomming connections indefinitely.
.It Fl h
Prints out
.Nm
@@ -445,16 +452,18 @@ stream socket:
.Dl $ nc -lU /var/tmp/dsocket
.Pp
Connect to port 42 of host.example.com via an HTTP proxy at 10.2.3.4,
-port 8080.
+port 8080, pass the connected socket to stdout and exit.
This example could also be used by
.Xr ssh 1 ;
see the
.Cm ProxyCommand
-directive in
+and
+.Cm ProxyUseFdPass
+directives in
.Xr ssh_config 5
for more information.
.Pp
-.Dl $ nc -x10.2.3.4:8080 -Xconnect host.example.com 42
+.Dl $ nc -F -x10.2.3.4:8080 -Xconnect host.example.com 42
.Pp
The same example again, this time enabling proxy authentication with username
.Dq ruser
Index: netcat.c
===
RCS file: /cvs/src/usr.bin/nc/netcat.c,v
retrieving revision 1.118
diff -U3 -p -r1.118 netcat.c
--- netcat.c12 Mar 2014 10:19:40 -1.118
+++ netcat.c2 May 2014 18:18:10 -
@@ -99,7 +99,7 @@ voidbuild_ports(char *);
voidhelp(void);
intlocal_listen(char *, char *, struct addrinfo);
voidreadwrite(int);
-voidfdpass(int nfd) __attribute__((noreturn));
+voidfdpass(int nfd);
intremote_connect(const char *, const char *, struct addrinfo);
inttimeout_connect(int, const struct sockaddr *, socklen_t);
intsocks_connect(const char *, const char *, struct addrinfo,
@@ -286,6 +286,15 @@ main(int argc, char *argv[])
if (!lflag && kflag)
errx(1, "must use -l with -k");
+if (Fflag && zflag) {
+warnx(1, "ignoring -z flag as -F is given");
+zflag = 0;
+}
+if (FFlag && uflag && kflag) {
+warnx(1, "ignoring -k flag as -F is given together with -u");
+kflag = 0;
+}
+
/* Get name of temporary socket for unix datagram client */
if ((family == AF_UNIX) && uflag && !lflag) {
if (sflag) {
@@ -469,9 +478,7 @@ main(int argc, char *argv[])
uflag ? "udp" : "tcp",
sv ? sv->s_name : "*");
}
-if (Fflag)
-fdpass(s);
-else if (!zflag)
+if (!zflag)
readwrite(s);
}
}
@@ -727,17 +734,25 @@ local_listen(char *host, char *port, str
/*
* readwrite()
- * Loop that polls on the network file descriptor and stdin.
+ * Loop that polls on the network file descriptor and stdin, or, when the
+ * FFlag is given, pass the descriptor to stdout.
*/
void
readwrite(int nfd)
{
struct pollfd pfd[2];
unsigned char buf[16384];
-int n, wfd = fileno(stdin);
-int lfd = fileno(stdout);
+int n, wfd;
+int lfd;
int plen;
+if (Fflag) {
+fdpass(nfd);
+return;
+}
+
+lfd = fileno(stdout);
+wfd = fileno(stdin);
plen = 2048;
/* Setup Network FD */
@@ -793,7 +808,7 @@ readwrite(int nfd)
/*
* fdpass()
- * Pass the connected file descriptor to stdout and exit.
+ * Pass the connected file descriptor to stdout.
*/
void
fdpass(int nfd)
@@ -848,7 +863,6 @@ fdpass(int nfd)
else
break;
}
-exit(0);
}
/* Deal with RFC 854 WILL/WONT DO/DONT negotiation. */
Re: [RFC] AI_ADDRCONFIG tweaks?
Le 2014-05-02 13:19, Jérémie Courrèges-Anglas a écrit : > Some bugs: > - https://sourceware.org/bugzilla/show_bug.cgi?id=12398 > - http://article.gmane.org/gmane.comp.freedesktop.xcb/6973 > - https://svn.boost.org/trac/boost/ticket/8503 > > Links with more information: > - http://fedoraproject.org/wiki/Networking/NameResolution/ADDRCONFIG > - https://fedoraproject.org/wiki/Features/FixNetworkNameResolution > - http://tools.ietf.org/html/rfc2553 obsolete and also informational, > specified AI_ADDRCONFIG for DNS () purposes only (dunno why this > has been changed) Thanks! I'll look at these in detail and get back to you. Simon
Re: [RFC] Ai_ADDRCONFIG^WAIAIAIAIAIAIAEEEEEEEEE tweaks?
As somone who has paid out of his own pocket for ARIN access to allocate v6 space for things, I can assure you I am not anti-v6. What I am is anti-I-am-a-v6-zealot-and-submit-diffs-with-no-thought-to-how-everyone-but-my-own-setup-works-and-because-I-am-a-zealot-I-am-right-until-proven-wrong. No. You can't just break how everyone else works to make your life better, or get the mystic portal here sooner. People who really want to promote v6 should be testing their diffs on a v4 only setup first. and verify they do no harm or make things better - not saying "this makes v6 better can everyone else who doesn't use it think of a downside" - that's not anti v6 - that's anti-bad-attitude. Sorry too many people: 1) have v4 only setups because they have no choice 2) have v4 only because their v6 connectivity is crap. 3) have v4 only setups because they have a choice and don't want that much extra code surface exposed in a security sensitive environment. All those reasons will be valid for a long time. long enough that I bet philip's time_t fixes will be tested for real before they are not. It doesn't mean we don't want good v6 - it means we do not want v6 at the expense of such things, and the burden is on the v6 diff submitter to prove it, not tell everyone else it's the way and they should prove otherwise. On Fri, May 2, 2014 at 11:39 AM, Kenneth Westerback wrote: > On 2 May 2014 13:24, Bob Beck wrote: >> Honestly folks, I'm sick of the attitude of "The future is nigh, the >> mystic portal awaits! V6 is coming!" as an excuse for >> we *MUST* change things related to this. >> >> We've been hearing the mystic portal awaits for 15 years - and yet >> MANY of us in MANY parts of the world still can not >> get reasonable v6 connectivity - or it's is substantially worse than >> v4 for what we normally do. It's not our fault, >> our providers are useless. >> >> I have no problem with having changes to make V6 more usable. but >> here's what I have a problem with. >> >> 1) Here is wonderful V6 diff - many standards idiots of the same type >> that designed V6 say this is good. Can you >> show me a down side? >> >> My answer to this is simple. No.. We've been bit before. You want me >> to pay attention to this discussion and encourage >> that a diff goes in do this instead: >> >> 2) Here is a diff that makes V6 better - I'm not talking to you about >> the standards bodies related to V6 because they are all >> ivory tower idiots, but it *does* make things better because I've >> tested it under *these* v6 scenarios and hit helps *AND* I tested it >> under the default and these normal scenarios WITH ONLY V4, and NOTHING >> SLOWED DOWN OR GOT FUCKED UP. >> >> Having now experienced more than enough "show me a down side" V6 diffs >> in the tree over the years, I do not want to >> "show a down side" - PROVE TO ME THERE ISN'T ONE, or go away. >> > > Careful Bob, or you will be lumped in with Theo and I as roadblocks to > IPv6 adoption! > > Ken > >> >> >> >> >> >> >> On Fri, May 2, 2014 at 10:53 AM, Jérémie Courrèges-Anglas >> wrote: >>> Paul de Weerd writes: >>> On Fri, May 02, 2014 at 05:35:13PM +0200, Jérémie Courrèges-Anglas wrote: | > If you're running on a host without IPv6, why would you want | > getaddrinfo() to return any IPv6 results? What good would it do to you? | | What's a regular OpenBSD host with no IPv6? I'd assume that it is | a host that can perform IPv6 connections to ::1 / localhost and reach | its neighbors through link-local addresses. Why would you expect to be able to reach your neighbors through link-local addresses if you have "no IPv6" (which I take to mean 'no *configured* IPv6', please correct me if I'm wrong here)? >>> >>> I don't make a big difference between automatically or "manually" >>> configured addresses. They're here and supposed to be usable for >>> whatever purpose, limited only by their intrinsic limitations. >>> I believe your expectation here is wrong (although it is the current state of IPv6 on OpenBSD). Can you explain why you disagree? >>> >>> Not really, I'm puzzled by your question. It works and has always >>> worked but I shouldn't expect them to work... >>> (sorry to hijack the thread, your remark piqued my interest) Paul 'WEiRD' de Weerd >>> >>> -- >>> jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE >>> >>
Re: [RFC] Ai_ADDRCONFIG^WAIAIAIAIAIAIAEEEEEEEEE tweaks?
On 2 May 2014 13:24, Bob Beck wrote: > Honestly folks, I'm sick of the attitude of "The future is nigh, the > mystic portal awaits! V6 is coming!" as an excuse for > we *MUST* change things related to this. > > We've been hearing the mystic portal awaits for 15 years - and yet > MANY of us in MANY parts of the world still can not > get reasonable v6 connectivity - or it's is substantially worse than > v4 for what we normally do. It's not our fault, > our providers are useless. > > I have no problem with having changes to make V6 more usable. but > here's what I have a problem with. > > 1) Here is wonderful V6 diff - many standards idiots of the same type > that designed V6 say this is good. Can you > show me a down side? > > My answer to this is simple. No.. We've been bit before. You want me > to pay attention to this discussion and encourage > that a diff goes in do this instead: > > 2) Here is a diff that makes V6 better - I'm not talking to you about > the standards bodies related to V6 because they are all > ivory tower idiots, but it *does* make things better because I've > tested it under *these* v6 scenarios and hit helps *AND* I tested it > under the default and these normal scenarios WITH ONLY V4, and NOTHING > SLOWED DOWN OR GOT FUCKED UP. > > Having now experienced more than enough "show me a down side" V6 diffs > in the tree over the years, I do not want to > "show a down side" - PROVE TO ME THERE ISN'T ONE, or go away. > Careful Bob, or you will be lumped in with Theo and I as roadblocks to IPv6 adoption! Ken > > > > > > > On Fri, May 2, 2014 at 10:53 AM, Jérémie Courrèges-Anglas > wrote: >> Paul de Weerd writes: >> >>> On Fri, May 02, 2014 at 05:35:13PM +0200, Jérémie Courrèges-Anglas wrote: >>> | > If you're running on a host without IPv6, why would you want >>> | > getaddrinfo() to return any IPv6 results? What good would it do to you? >>> | >>> | What's a regular OpenBSD host with no IPv6? I'd assume that it is >>> | a host that can perform IPv6 connections to ::1 / localhost and reach >>> | its neighbors through link-local addresses. >>> >>> Why would you expect to be able to reach your neighbors through >>> link-local addresses if you have "no IPv6" (which I take to mean 'no >>> *configured* IPv6', please correct me if I'm wrong here)? >> >> I don't make a big difference between automatically or "manually" >> configured addresses. They're here and supposed to be usable for >> whatever purpose, limited only by their intrinsic limitations. >> >>> I believe your expectation here is wrong (although it is the current >>> state of IPv6 on OpenBSD). Can you explain why you disagree? >> >> Not really, I'm puzzled by your question. It works and has always >> worked but I shouldn't expect them to work... >> >>> (sorry to hijack the thread, your remark piqued my interest) >>> >>> Paul 'WEiRD' de Weerd >> >> -- >> jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE >> >
Re: [RFC] Ai_ADDRCONFIG^WAIAIAIAIAIAIAEEEEEEEEE tweaks?
Honestly folks, I'm sick of the attitude of "The future is nigh, the mystic portal awaits! V6 is coming!" as an excuse for we *MUST* change things related to this. We've been hearing the mystic portal awaits for 15 years - and yet MANY of us in MANY parts of the world still can not get reasonable v6 connectivity - or it's is substantially worse than v4 for what we normally do. It's not our fault, our providers are useless. I have no problem with having changes to make V6 more usable. but here's what I have a problem with. 1) Here is wonderful V6 diff - many standards idiots of the same type that designed V6 say this is good. Can you show me a down side? My answer to this is simple. No.. We've been bit before. You want me to pay attention to this discussion and encourage that a diff goes in do this instead: 2) Here is a diff that makes V6 better - I'm not talking to you about the standards bodies related to V6 because they are all ivory tower idiots, but it *does* make things better because I've tested it under *these* v6 scenarios and hit helps *AND* I tested it under the default and these normal scenarios WITH ONLY V4, and NOTHING SLOWED DOWN OR GOT FUCKED UP. Having now experienced more than enough "show me a down side" V6 diffs in the tree over the years, I do not want to "show a down side" - PROVE TO ME THERE ISN'T ONE, or go away. On Fri, May 2, 2014 at 10:53 AM, Jérémie Courrèges-Anglas wrote: > Paul de Weerd writes: > >> On Fri, May 02, 2014 at 05:35:13PM +0200, Jérémie Courrèges-Anglas wrote: >> | > If you're running on a host without IPv6, why would you want >> | > getaddrinfo() to return any IPv6 results? What good would it do to you? >> | >> | What's a regular OpenBSD host with no IPv6? I'd assume that it is >> | a host that can perform IPv6 connections to ::1 / localhost and reach >> | its neighbors through link-local addresses. >> >> Why would you expect to be able to reach your neighbors through >> link-local addresses if you have "no IPv6" (which I take to mean 'no >> *configured* IPv6', please correct me if I'm wrong here)? > > I don't make a big difference between automatically or "manually" > configured addresses. They're here and supposed to be usable for > whatever purpose, limited only by their intrinsic limitations. > >> I believe your expectation here is wrong (although it is the current >> state of IPv6 on OpenBSD). Can you explain why you disagree? > > Not really, I'm puzzled by your question. It works and has always > worked but I shouldn't expect them to work... > >> (sorry to hijack the thread, your remark piqued my interest) >> >> Paul 'WEiRD' de Weerd > > -- > jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE >
Re: [RFC] AI_ADDRCONFIG tweaks?
j...@wxcvbn.org (Jérémie Courrèges-Anglas) writes: > Simon Perreault writes: [...] >> Has this caused any real-world problems? > > All the examples I've listed above are cases where programs that used no > hints will now fail. I think they're valid, real-world cases. Some bugs: - https://sourceware.org/bugzilla/show_bug.cgi?id=12398 - http://article.gmane.org/gmane.comp.freedesktop.xcb/6973 - https://svn.boost.org/trac/boost/ticket/8503 Links with more information: - http://fedoraproject.org/wiki/Networking/NameResolution/ADDRCONFIG - https://fedoraproject.org/wiki/Features/FixNetworkNameResolution - http://tools.ietf.org/html/rfc2553 obsolete and also informational, specified AI_ADDRCONFIG for DNS () purposes only (dunno why this has been changed) -- jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
Re: [RFC] Ai_ADDRCONFIG^WAIAIAIAIAIAIAEEEEEEEEE tweaks?
Paul de Weerd writes: > On Fri, May 02, 2014 at 05:35:13PM +0200, Jérémie Courrèges-Anglas wrote: > | > If you're running on a host without IPv6, why would you want > | > getaddrinfo() to return any IPv6 results? What good would it do to you? > | > | What's a regular OpenBSD host with no IPv6? I'd assume that it is > | a host that can perform IPv6 connections to ::1 / localhost and reach > | its neighbors through link-local addresses. > > Why would you expect to be able to reach your neighbors through > link-local addresses if you have "no IPv6" (which I take to mean 'no > *configured* IPv6', please correct me if I'm wrong here)? I don't make a big difference between automatically or "manually" configured addresses. They're here and supposed to be usable for whatever purpose, limited only by their intrinsic limitations. > I believe your expectation here is wrong (although it is the current > state of IPv6 on OpenBSD). Can you explain why you disagree? Not really, I'm puzzled by your question. It works and has always worked but I shouldn't expect them to work... > (sorry to hijack the thread, your remark piqued my interest) > > Paul 'WEiRD' de Weerd -- jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
Re: [RFC] AI_ADDRCONFIG tweaks?
On Fri, May 02, 2014 at 05:35:13PM +0200, Jérémie Courrèges-Anglas wrote: | > If you're running on a host without IPv6, why would you want | > getaddrinfo() to return any IPv6 results? What good would it do to you? | | What's a regular OpenBSD host with no IPv6? I'd assume that it is | a host that can perform IPv6 connections to ::1 / localhost and reach | its neighbors through link-local addresses. Why would you expect to be able to reach your neighbors through link-local addresses if you have "no IPv6" (which I take to mean 'no *configured* IPv6', please correct me if I'm wrong here)? I believe your expectation here is wrong (although it is the current state of IPv6 on OpenBSD). Can you explain why you disagree? (sorry to hijack the thread, your remark piqued my interest) Paul 'WEiRD' de Weerd -- >[<++>-]<+++.>+++[<-->-]<.>+++[<+ +++>-]<.>++[<>-]<+.--.[-] http://www.weirdnet.nl/
Re: [RFC] AI_ADDRCONFIG tweaks?
I think I have already addressed all your points below, no need to
rehash endlessly. I'll let others chime in.
I'm still very interested in any real-world problems this might have caused.
Simon
Le 2014-05-02 11:35, Jérémie Courrèges-Anglas a écrit :
> Simon Perreault writes:
>
>> Le 2014-05-02 10:48, Jérémie Courrèges-Anglas a écrit :
>>> Let's say you have a machine with no IPv6 address configured (or rather,
>>> only link-local addresses configured and ::1 on lo0). With the
>>> AI_ADDRCONFIG flag (either set explicitely or assumed if the caller
>>> passes no hints structure):
>>>
>>> - getaddrinfo("fe80::...%em0") fails with "no address associated with name"
>>> - getaddrinfo("::1") fails similarly
>>> - more generally, getaddrinfo("numeric IPv6 address") fails with "no
>>> address associated with that name"
>>> - getaddrinfo("localhost") now requires IPv4/v6 connectivity on non-lo
>>> interfaces. oops.
>>>
>>> All those are IMHO poor behavior (lies), especially since getaddrinfo is
>>> supposed to handle pretty much anything you're throwing at it.
>>
>> I think you need to change your expectations.
>
> I don't think that any of the failing examples given above can qualify
> as "reasonable expectation".
>
>> If you're running on a host without IPv6, why would you want
>> getaddrinfo() to return any IPv6 results? What good would it do to you?
>
> What's a regular OpenBSD host with no IPv6? I'd assume that it is
> a host that can perform IPv6 connections to ::1 / localhost and reach
> its neighbors through link-local addresses. It is certainly not a host
> that has been butchered by removing option INET6 or removing all
> automatically configured IPv6 address (link-local / lo0).
>
> If you pass a raw IPv6 address to getaddrinfo, is "no address associated
> with name" a reasonable result?
>
>> AI_ADDRCONFIG is all about what it *returns*. The fact that it allows
>> skipping DNS requests is a nice side-effect.
>
> Yet people use it for this side-effect, else why would you propose to
> make the base programs use it (explicitely) as a way to mitigate the
> impact of switching to "family inet6 inet4" by default?
>
>> If your program needs to resolve addresses for the sake of resolving
>> addresses, and you want accuracy,
>
> I think that I've clearly explained that it is more than mere accuracy.
>
>> you need to explicitly unset
>> AI_ADDRCONFIG. You're writing something special. In the general case,
>> where you will just connect() or bind() on the returned addresses,
>> AI_ADDRCONFIG makes sense as is.
>>
>> Has this caused any real-world problems?
>
> All the examples I've listed above are cases where programs that used no
> hints will now fail. I think they're valid, real-world cases.
>
Re: [RFC] AI_ADDRCONFIG tweaks?
Simon Perreault writes:
> Le 2014-05-02 10:48, Jérémie Courrèges-Anglas a écrit :
>> Let's say you have a machine with no IPv6 address configured (or rather,
>> only link-local addresses configured and ::1 on lo0). With the
>> AI_ADDRCONFIG flag (either set explicitely or assumed if the caller
>> passes no hints structure):
>>
>> - getaddrinfo("fe80::...%em0") fails with "no address associated with name"
>> - getaddrinfo("::1") fails similarly
>> - more generally, getaddrinfo("numeric IPv6 address") fails with "no
>> address associated with that name"
>> - getaddrinfo("localhost") now requires IPv4/v6 connectivity on non-lo
>> interfaces. oops.
>>
>> All those are IMHO poor behavior (lies), especially since getaddrinfo is
>> supposed to handle pretty much anything you're throwing at it.
>
> I think you need to change your expectations.
I don't think that any of the failing examples given above can qualify
as "reasonable expectation".
> If you're running on a host without IPv6, why would you want
> getaddrinfo() to return any IPv6 results? What good would it do to you?
What's a regular OpenBSD host with no IPv6? I'd assume that it is
a host that can perform IPv6 connections to ::1 / localhost and reach
its neighbors through link-local addresses. It is certainly not a host
that has been butchered by removing option INET6 or removing all
automatically configured IPv6 address (link-local / lo0).
If you pass a raw IPv6 address to getaddrinfo, is "no address associated
with name" a reasonable result?
> AI_ADDRCONFIG is all about what it *returns*. The fact that it allows
> skipping DNS requests is a nice side-effect.
Yet people use it for this side-effect, else why would you propose to
make the base programs use it (explicitely) as a way to mitigate the
impact of switching to "family inet6 inet4" by default?
> If your program needs to resolve addresses for the sake of resolving
> addresses, and you want accuracy,
I think that I've clearly explained that it is more than mere accuracy.
> you need to explicitly unset
> AI_ADDRCONFIG. You're writing something special. In the general case,
> where you will just connect() or bind() on the returned addresses,
> AI_ADDRCONFIG makes sense as is.
>
> Has this caused any real-world problems?
All the examples I've listed above are cases where programs that used no
hints will now fail. I think they're valid, real-world cases.
--
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
Re: [RFC] AI_ADDRCONFIG tweaks?
Le 2014-05-02 10:48, Jérémie Courrèges-Anglas a écrit :
> Let's say you have a machine with no IPv6 address configured (or rather,
> only link-local addresses configured and ::1 on lo0). With the
> AI_ADDRCONFIG flag (either set explicitely or assumed if the caller
> passes no hints structure):
>
> - getaddrinfo("fe80::...%em0") fails with "no address associated with name"
> - getaddrinfo("::1") fails similarly
> - more generally, getaddrinfo("numeric IPv6 address") fails with "no
> address associated with that name"
> - getaddrinfo("localhost") now requires IPv4/v6 connectivity on non-lo
> interfaces. oops.
>
> All those are IMHO poor behavior (lies), especially since getaddrinfo is
> supposed to handle pretty much anything you're throwing at it.
I think you need to change your expectations.
If you're running on a host without IPv6, why would you want
getaddrinfo() to return any IPv6 results? What good would it do to you?
AI_ADDRCONFIG is all about what it *returns*. The fact that it allows
skipping DNS requests is a nice side-effect.
If your program needs to resolve addresses for the sake of resolving
addresses, and you want accuracy, you need to explicitly unset
AI_ADDRCONFIG. You're writing something special. In the general case,
where you will just connect() or bind() on the returned addresses,
AI_ADDRCONFIG makes sense as is.
Has this caused any real-world problems?
Simon
Re: [RFC] AI_ADDRCONFIG tweaks?
Simon Perreault writes:
> Le 2014-05-02 04:13, Jérémie Courrèges-Anglas a écrit :
>> I don't like AI_ADDRCONFIG. It's useless as specified, and making it
>> useful requires interpretations and deviations.
>
> Can you justify this? Sounds to me like a blanket statement as it is.
Didn't you need to make it ignore link-local addresses to make it
useful?
>> My understanding is that its goal is to solve a real world problem,
>> as in avoiding useless and potentially harmful DNS requests. So why not
>> make it do that, and just that? Because I don't think the end goal is
>> preventing IPv6 link-local communication, or communication with ::1 or
>> "localhost", etc.
>
> I don't understand the above paragraph at all. Facts only please, and no
> hyperbole. What's the problem exactly?
Let's say you have a machine with no IPv6 address configured (or rather,
only link-local addresses configured and ::1 on lo0). With the
AI_ADDRCONFIG flag (either set explicitely or assumed if the caller
passes no hints structure):
- getaddrinfo("fe80::...%em0") fails with "no address associated with name"
- getaddrinfo("::1") fails similarly
- more generally, getaddrinfo("numeric IPv6 address") fails with "no
address associated with that name"
- getaddrinfo("localhost") now requires IPv4/v6 connectivity on non-lo
interfaces. oops.
All those are IMHO poor behavior (lies), especially since getaddrinfo is
supposed to handle pretty much anything you're throwing at it. Yet it
is now the default behavior when you pass no hints, and adding explicit
AI_ADDRCONFIG flags to base programs has been recently proposed.
>> -bit is set, IPv4 addresses will be returned only if an IPv4 address is
>> -configured on an interface, and IPv6 addresses will be returned only if an
>> IPv6
>> -address is configured on an interface.
>> +bit is set, DNS requests for IPv4 addresses will be performed only if an
>> +IPv4 address is configured on an interface, and DNS requetsts for IPv6
>> +addresses will be performed only if an IPv6 address is configured on an
>> +interface.
>
> Targeting only DNS is wrong. That's not at all what AI_ADDRCONFIG does.
I'm proposing to change its semantics so that it targets only DNS.
Saying that it doesn't target DNS doesn't help much. :)
Why do we ignore link-local IPv6 addresses when iterating over the
result of getifaddrs? Because without this AI_ADDRCONFIG would be
almost useless; yet the spec doesn't say we should ignore link-local
addresses...
> It is of no use to return an IPv6 address that you found in a non-DNS
> database if the host has no IPv6 address configured on its interfaces.
... I see it the other way. I think that if AI_ADDRCONFIG has been
proposed to avoid *useless and potentially harmful* DNS requests. I'd
feel better if it had not been adopted in the first place, because it's
basically useless if interpreted literally. But also it helps to cope
with the stupid behavior some CPEs exhibit, instead of forcing people
(hi, Orange) to fix their errors. That is not a good thing IMHO.
> But take the above with a grain of salt because I absolutely don't
> understand the problem you're trying to fix.
I hope its clearer this way. :)
--
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
Re: [RFC] AI_ADDRCONFIG tweaks?
Le 2014-05-02 04:13, Jérémie Courrèges-Anglas a écrit : > I don't like AI_ADDRCONFIG. It's useless as specified, and making it > useful requires interpretations and deviations. Can you justify this? Sounds to me like a blanket statement as it is. > My understanding is that its goal is to solve a real world problem, > as in avoiding useless and potentially harmful DNS requests. So why not > make it do that, and just that? Because I don't think the end goal is > preventing IPv6 link-local communication, or communication with ::1 or > "localhost", etc. I don't understand the above paragraph at all. Facts only please, and no hyperbole. What's the problem exactly? > -bit is set, IPv4 addresses will be returned only if an IPv4 address is > -configured on an interface, and IPv6 addresses will be returned only if an > IPv6 > -address is configured on an interface. > +bit is set, DNS requests for IPv4 addresses will be performed only if an > +IPv4 address is configured on an interface, and DNS requetsts for IPv6 > +addresses will be performed only if an IPv6 address is configured on an > +interface. Targeting only DNS is wrong. That's not at all what AI_ADDRCONFIG does. It is of no use to return an IPv6 address that you found in a non-DNS database if the host has no IPv6 address configured on its interfaces. But take the above with a grain of salt because I absolutely don't understand the problem you're trying to fix. Simon
Re: Annoying emacs variable in if_spppsubr.c
Henning Brauer writes: > I don't think that kind of stuff has any place in our tree whatsoever. > everybody inserting such "hints" for his/her favorite editor...? All other occurrences of 'Local Variables' in the base tree were in source imported from elsewhere or in autoconf-produced files. Nothing worth a massive deletion IMHO. I don't care much about this. This one was useless and getting in my way, so I killed it. But I won't prevent people to use annotations for other editors in files they're often modifying. -- jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
Re: Annoying emacs variable in if_spppsubr.c
I don't think that kind of stuff has any place in our tree whatsoever.
everybody inserting such "hints" for his/her favorite editor...?
* Jérémie Courrèges-Anglas [2014-05-02 12:11]:
>
> This one is bugging me each time I start my Emacs session (because Emacs
> now asks confirmation for most variables). This one would be useful
> only with hilit19.el (obsolete) from editors/emacs21... if the size of
> the file was actually under 12 bytes (it's not anymore).
>
> ok to kill it?
>
> Index: if_spppsubr.c
> ===
> RCS file: /cvs/src/sys/net/if_spppsubr.c,v
> retrieving revision 1.121
> diff -u -p -p -u -r1.121 if_spppsubr.c
> --- if_spppsubr.c 19 Apr 2014 12:12:02 - 1.121
> +++ if_spppsubr.c 30 Apr 2014 00:53:56 -
> @@ -5236,13 +5236,6 @@ sppp_null(struct sppp *unused)
> {
> /* do just nothing */
> }
> -/*
> - * This file is large. Tell emacs to highlight it nevertheless.
> - *
> - * Local Variables:
> - * hilit-auto-highlight-maxout: 12
> - * End:
> - */
>
> void
> sppp_set_phase(struct sppp *sp)
>
>
> --
> jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
>
--
Henning Brauer, h...@bsws.de, henn...@openbsd.org
BS Web Services GmbH, http://bsws.de, Full-Service ISP
Secure Hosting, Mail and DNS Services. Dedicated Servers, Root to Fully Managed
Henning Brauer Consulting, http://henningbrauer.com/
Re: Annoying emacs variable in if_spppsubr.c
On 2 May 2014 12:09, Jérémie Courrèges-Anglas wrote: > > This one is bugging me each time I start my Emacs session (because Emacs > now asks confirmation for most variables). This one would be useful > only with hilit19.el (obsolete) from editors/emacs21... if the size of > the file was actually under 12 bytes (it's not anymore). > > ok to kill it? > yes, please.
Annoying emacs variable in if_spppsubr.c
This one is bugging me each time I start my Emacs session (because Emacs
now asks confirmation for most variables). This one would be useful
only with hilit19.el (obsolete) from editors/emacs21... if the size of
the file was actually under 12 bytes (it's not anymore).
ok to kill it?
Index: if_spppsubr.c
===
RCS file: /cvs/src/sys/net/if_spppsubr.c,v
retrieving revision 1.121
diff -u -p -p -u -r1.121 if_spppsubr.c
--- if_spppsubr.c 19 Apr 2014 12:12:02 - 1.121
+++ if_spppsubr.c 30 Apr 2014 00:53:56 -
@@ -5236,13 +5236,6 @@ sppp_null(struct sppp *unused)
{
/* do just nothing */
}
-/*
- * This file is large. Tell emacs to highlight it nevertheless.
- *
- * Local Variables:
- * hilit-auto-highlight-maxout: 12
- * End:
- */
void
sppp_set_phase(struct sppp *sp)
--
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
Re: What's the pid of the pagedaemon - intro(2)
> From: j...@wxcvbn.org (=?utf-8?Q?J=C3=A9r=C3=A9mie_Courr=C3=A8ges-Anglas?=) > Date: Fri, 02 May 2014 10:17:45 +0200 > > I don't know when this changed, but the information below seems no > longer relevant. > > ok? Kill it! > Index: intro.2 > === > RCS file: /cvs/src/lib/libc/sys/intro.2,v > retrieving revision 1.48 > diff -u -p -p -u -r1.48 intro.2 > --- intro.2 21 Jan 2014 03:15:45 - 1.48 > +++ intro.2 30 Apr 2014 09:40:22 - > @@ -556,7 +556,6 @@ Process 1 is the initialization process > .Xr init 8 , > and is the ancestor of every other process in the system. > It is used to control the process structure. > -Process 2 is the paging daemon. > .It Descriptor > An integer assigned by the system when a file is referenced > by > > > -- > jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE > >
What's the pid of the pagedaemon - intro(2)
I don't know when this changed, but the information below seems no longer relevant. ok? Index: intro.2 === RCS file: /cvs/src/lib/libc/sys/intro.2,v retrieving revision 1.48 diff -u -p -p -u -r1.48 intro.2 --- intro.2 21 Jan 2014 03:15:45 - 1.48 +++ intro.2 30 Apr 2014 09:40:22 - @@ -556,7 +556,6 @@ Process 1 is the initialization process .Xr init 8 , and is the ancestor of every other process in the system. It is used to control the process structure. -Process 2 is the paging daemon. .It Descriptor An integer assigned by the system when a file is referenced by -- jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
[RFC] AI_ADDRCONFIG tweaks?
Hi,
I don't like AI_ADDRCONFIG. It's useless as specified, and making it
useful requires interpretations and deviations.
My understanding is that its goal is to solve a real world problem,
as in avoiding useless and potentially harmful DNS requests. So why not
make it do that, and just that? Because I don't think the end goal is
preventing IPv6 link-local communication, or communication with ::1 or
"localhost", etc.
What do you folks think?
The diff below seems to work well, as a bonus it avoids changing the
hints passed by the caller, and extends the use of local variable "ai"
("ai" could probably be renamed to "hints", btw).
Index: asr/getaddrinfo_async.c
===
RCS file: /cvs/src/lib/libc/asr/getaddrinfo_async.c,v
retrieving revision 1.27
diff -u -p -r1.27 getaddrinfo_async.c
--- asr/getaddrinfo_async.c 28 Apr 2014 21:38:59 - 1.27
+++ asr/getaddrinfo_async.c 2 May 2014 06:25:03 -
@@ -129,7 +129,7 @@ getaddrinfo_async_run(struct asr_query *
#endif
char fqdn[MAXDNAME];
const char *str;
- struct addrinfo *ai;
+ struct addrinfo *ai, *saved_ai, addrconfig_hints;
int i, family, r, v4, v6;
FILE*f;
struct ifaddrs *ifa, *ifa0;
@@ -157,7 +157,7 @@ getaddrinfo_async_run(struct asr_query *
break;
}
- ai = &as->as.ai.hints;
+ ai = saved_ai = &as->as.ai.hints;
if (ai->ai_addrlen ||
ai->ai_canonname ||
@@ -219,17 +219,12 @@ getaddrinfo_async_run(struct asr_query *
v6 = 1;
}
freeifaddrs(ifa0);
- if (ai->ai_family == PF_UNSPEC && !v4 && !v6 ||
- ai->ai_family == PF_INET && !v4 ||
- ai->ai_family == PF_INET6 && !v6) {
- ar->ar_gai_errno = EAI_NONAME;
- async_set_state(as, ASR_STATE_HALT);
- break;
- }
+
+ memcpy(&addrconfig_hints, ai, sizeof(addrconfig_hints));
if (ai->ai_family == PF_UNSPEC && v4 && !v6)
- ai->ai_family = PF_INET;
+ addrconfig_hints.ai_family = PF_INET;
if (ai->ai_family == PF_UNSPEC && !v4 && v6)
- ai->ai_family = PF_INET6;
+ addrconfig_hints.ai_family = PF_INET6;
}
/* Make sure there is at least a valid combination */
@@ -246,10 +241,10 @@ getaddrinfo_async_run(struct asr_query *
if (ai->ai_protocol == 0 || ai->ai_protocol == IPPROTO_UDP)
as->as.ai.port_udp = get_port(as->as.ai.servname, "udp",
- as->as.ai.hints.ai_flags & AI_NUMERICSERV);
+ ai->ai_flags & AI_NUMERICSERV);
if (ai->ai_protocol == 0 || ai->ai_protocol == IPPROTO_TCP)
as->as.ai.port_tcp = get_port(as->as.ai.servname, "tcp",
- as->as.ai.hints.ai_flags & AI_NUMERICSERV);
+ ai->ai_flags & AI_NUMERICSERV);
if (as->as.ai.port_tcp == -2 || as->as.ai.port_udp == -2 ||
(as->as.ai.port_tcp == -1 && as->as.ai.port_udp == -1) ||
(ai->ai_protocol && (as->as.ai.port_udp == -1 ||
@@ -322,13 +317,24 @@ getaddrinfo_async_run(struct asr_query *
async_set_state(as, ASR_STATE_NOT_FOUND);
break;
}
+ ai = saved_ai;
+ /* AF filtering is only for dns */
+ if (ai->ai_flags & AI_ADDRCONFIG && AS_DB(as) == ASR_DB_DNS) {
+ if (ai->ai_family == PF_UNSPEC && !v4 && !v6 ||
+ ai->ai_family == PF_INET && !v4 ||
+ ai->ai_family == PF_INET6 && !v6) {
+ async_set_state(as, ASR_STATE_NEXT_DB);
+ break;
+ }
+ ai = &addrconfig_hints;
+ }
as->as_family_idx = 0;
async_set_state(as, ASR_STATE_SAME_DB);
break;
case ASR_STATE_NEXT_FAMILY:
as->as_family_idx += 1;
- if (as->as.ai.hints.ai_family != AF_UNSPEC ||
+ if (ai->ai_family != AF_UNSPEC ||
AS_FAMILY(as) == -1) {
/* The family was specified, or we have tried all
* families with this DB.
@@ -384,8 +390,8 @@ getaddrinfo_async_run(struct asr_query *
break;
}
- family = (as->a
