http.get fails on Android and FreeBSD

[javihernandez]

Hi,

when making a simple http request I'm getting the following error:

Error: getaddrinfo EAI_BADFLAGS
    at Object.exports._errnoException (util.js:742:11)
    at errnoException (dns.js:46:15)
    at Object.onlookup [as oncomplete] (dns.js:91:26)

Did a few tests and tried to follow the error through the code, but at this point all I can say is that I'm lost. Any ideas? As usually, I'll be happy to help on fixing this.

Resulting object from calling http.get can be found here

[brendanashworth]

What code are you running that gives you this error?

[javihernandez]

@brendanashworth,

I'm running:

• Node v0.13.0-pre
• Built against android-ndk-r9d

I'm just making a simple http request, something like:

http.get("www.google.com", function(a,b,c) {});


Hope this answers to your question.

Also, I checked if cares.getaddrinfo was failing but it's not. It seems to be a problem elsewhere but I'm not experienced enough to diagnose the offending code. :/

[brendanashworth]

Some suggestions of mine:

• There isn't a node v0.13.0-pre, do you mean another version?
• Supply the protocol in the request, i.e.:

https.get('https://google.com', function() {});

Note the use of https, not http as Google redirects to https anyways.

[javihernandez]

@brendanashworth,

$ ./node --version v0.13.0-pre

I previously tried with https, same problem.

[misterdjules]

@javihernandez Could you please try with a build from the v0.12 branch? Some fixes that are in this branch have not yet been ported to master.

Also, your issue seems like Node.js doesn't pass the right flags to getaddrinfo, or that the flags it passes are not supported on your platform. Could you please tell us what flags are supported by Android for getaddrinfo?

[hertzg]

Maybe this is an emulator issue?

https://groups.google.com/forum/#!topic/android-developers/sEU32CfE-eE

[javihernandez]

thanks for commenting :)

@hertzg, nope, real device

@misterdjules, good point.
Switched to 0.12 branch, fixed a v8-related build error (perhaps it's worth to be reported) and finally got it building well, BUT, still getting the same error.
So yes, seems to be a problem with getaddrinfo's flags. I'll try to find out which flags are supported.

[misterdjules]

@javihernandez Did you have some time to investigate what getaddrinfo flags are supported on Android?

[javihernandez]

Hey @misterdjules,

not really (been quite busy at work), but a quick search gave me the following:

/*
 * Flag values for getaddrinfo()
 */
#define AI_PASSIVE      0x00000001 /* get address to use bind() */
#define AI_CANONNAME    0x00000002 /* fill ai_canonname */
#define AI_NUMERICHOST  0x00000004 /* prevent host name resolution */
#define AI_NUMERICSERV  0x00000008 /* prevent service name resolution */

and just below we can see ...

/* valid flags for addrinfo (not a standard def, apps should not use it) */
#define AI_MASK \
    (AI_PASSIVE | AI_CANONNAME | AI_NUMERICHOST | AI_NUMERICSERV | \
    AI_ADDRCONFIG)
#define AI_ALL          0x00000100 /* IPv6 and IPv4-mapped (with AI_V4MAPPED) */
#define AI_V4MAPPED_CFG 0x00000200 /* accept IPv4-mapped if kernel supports */
#define AI_ADDRCONFIG   0x00000400 /* only if any address is assigned */
#define AI_V4MAPPED     0x00000800 /* accept IPv4-mapped IPv6 address */

Any hint about how/where this should be addressed?

[javihernandez]

up

[josser]

Very similar issue on freebsd 10:

events.js:85
      throw er; // Unhandled 'error' event
            ^
Error: getaddrinfo EAI_BADFLAGS
    at Object.exports._errnoException (util.js:746:11)
    at errnoException (dns.js:49:15)
    at GetAddrInfoReqWrap.onlookup [as oncomplete] (dns.js:94:26)

Code:

http = require('http');
http.get("www.google.com", function(a,b,c) {}); 

man 3 getaddrinfo https://gist.github.com/josser/ccad69a7c767aa0d3159

node --version
v0.12.0

[josser]

Also, I don't have such error on OS X, but it have a bit more extended list of AI_FLAGS:
Additional flags which I found in os x but didn't find in freebsd:

AI_ALL If the AI_ALL bit is set with the AI_V4MAPPED bit, then getaddrinfo() shall return all matching IPv6 and IPv4 addresses. The AI_ALL bit without the AI_V4MAPPED bit is ignored.

AI_V4MAPPED If the AI_V4MAPPED flag is specified along with an ai_family of AF_INET6, then getaddrinfo() shall return IPv4-mapped IPv6 addresses on finding no matching IPv6 addresses ( ai_addrlen shall be 16). The AI_V4MAPPED flag shall be ignored unless ai_family equals AF_INET6.

[leonkunert]

I have a similar error after updating from node-0.10.35 to 0.12.0 on Freebsd 10.1.

{ [Error: getaddrinfo EAI_BADFLAGS]
  code: 'EAI_BADFLAGS',
  errno: 'EAI_BADFLAGS',
  syscall: 'getaddrinfo',
  hostname: 'xxx' }

[pct]

Please see the patch, Thanks.

nodejs/node@04bea9f

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=197539

[misterdjules]

More background for the issue on FreeBSD here, with the related source change here.

nodejs/node@04bea9f seems it would definitely fix this issue, however I'm wondering whether we should fix this in dns.lookup or in net.connect.

In my opinion the question boils down to: do we want explicit calls to dns.lookup with V4MAPPED set to success silently on FreeBSD? Users of FreeBSD might be confused by the fact that dns.lookup would not return IPv4-mapped addresses when they explicitly asked for it.

Instead, we could remove the V4MAPPED flag in net.connect which is the only place in node.js' core where it's set. That would fix this issue, and explicit uses of dns.lookup with V4MAPPED would fail on FreeBSD, making it clear that FreeBSD users should not expect IPv4-mapped to work.

@joyent/node-coreteam Thoughts?

[piscisaureus]

Instead, we could remove the V4MAPPED flag in net.connect which is the only place in node.js' core where it's set. That would fix this issue, and explicit uses of dns.lookup with V4MAPPED would fail on FreeBSD, making it clear that FreeBSD users should not expect IPv4-mapped to work.

That's a possibility, but also an API change. I guess for node that means the patch goes into v0.14.0

[misterdjules]

@piscisaureus I don't understand why it would be an API change, could you please elaborate?

The other candidate for a fix I had in mind is available here: https://gist.github.com/misterdjules/8b451749630de0b17218. In my opinion, this is a behavior change that only affects a single platform where the previous behavior is not available and fails all the time, so I would qualify it as a bug fix, but I may be missing something.

Also, again to make sure we're on the same page, if https://gist.github.com/misterdjules/8b451749630de0b17218 qualifies as a breaking API change, then my understanding is that nodejs/node@04bea9f would also be considered as a breaking change.

Thanks!

[piscisaureus]

@misterdjules
I see what you mean. I would say your fix is better. @bnoordhuis @indutny wdyt?

[bnoordhuis]

I'm working from memory here but Fedor's patch disables AI_V4MAPPED iff it's not an AAAA query and the platform is FreeBSD. Julien's patch looks wrong to me because it disables it unconditionally on FreeBSD, regardless of the query type.

Side note: OpenBSD doesn't support AI_V4MAPPED at all, see nodejs/node@ca039b4.

[misterdjules]

@bnoordhuis Ok, based on this post: http://lists.freebsd.org/pipermail/freebsd-bugs/2008-February/028260.html, I thought FreeBSD also did not support AI_V4MAPPED at all (regardless of the query type) in recent versions.

It seems that the code example in this message does an AAAA query with AI_V4MAPPED and getaddrinfo returns EAI_BADFLAGS. However, I don't have a FreeBSD setup I can test this on, so I'm only guessing.

[bnoordhuis]

That mailing list post is about FreeBSD 7, which is ancient. io.js's minimum requirement is FreeBSD 10 and that seems to support AI_V4MAPPED fine for AAAA queries.

[indutny]

I think we better remove this flag at the query time since V4MAPPED is
exposed to users and might cause platform imcompatibility in user code

On Monday, March 2, 2015, Ben Noordhuis notifications@github.com wrote:

That mailing list post is about FreeBSD 7, which is ancient. io.js's
minimum requirement is FreeBSD 10 and that seems to support AI_V4MAPPED
fine for AAAA queries.

—
Reply to this email directly or view it on GitHub
#8540 (comment).

[misterdjules]

I had some more time to continue my investigations. So it seems that FreeBSD 10.1 does not support AI_V4MAPPED at all, even for AAAA queries. Here's a slightly modified version of the small C program I mentioned in the previous comments:

$ cat test.c
#include <sys/socket.h>
#include <sys/types.h>

#include <netdb.h>
#include <netinet/in.h>
#include <stdio.h>
#include <string.h>
#include <arpa/inet.h>

int main(int argc, char** argv)
{
    struct addrinfo hints;
    struct addrinfo* res = NULL, *cur_res = NULL;
    int r;
    char str_addr[INET6_ADDRSTRLEN];

    memset(&hints,0,sizeof(hints));
    hints.ai_flags = AI_V4MAPPED; 
    hints.ai_family = AF_INET6;
    hints.ai_socktype = SOCK_STREAM;

    printf("Looking up www.google.com...\n");

    if ((r = getaddrinfo("www.google.com","http", &hints, &res))) {
        printf("Error: %s.\n",gai_strerror(r));
        return 1;
    } else {
      printf("Got address(es)\n");
      for (cur_res = res; cur_res; cur_res = res->ai_next) {
        struct sockaddr_in6 *addr;
        addr = (struct sockaddr_in6*)cur_res->ai_addr; 
        inet_ntop(AF_INET6, &addr->sin6_addr, str_addr,
                  sizeof(str_addr));
        printf("IPv6 address: %s\n", str_addr);
      }
    }

    freeaddrinfo(res);
    return 0;
}
$ cc test.c -o test
$ ./test 
Looking up www.google.com...
Error: Invalid value for ai_flags.
$ diff -uN test.c test-no-v4mapped.c 
--- test.c  2015-04-17 19:21:57.000000000 +0000
+++ test-no-v4mapped.c  2015-04-17 20:34:53.000000000 +0000
@@ -15,7 +15,7 @@
     char str_addr[INET6_ADDRSTRLEN];

     memset(&hints,0,sizeof(hints));
-    hints.ai_flags = AI_V4MAPPED; 
+    //hints.ai_flags = AI_V4MAPPED; 
     hints.ai_family = AF_INET6;
     hints.ai_socktype = SOCK_STREAM;

$ cc test-no-v4mapped.c -o test-no-v4mapped
$ ./test-no-v4-mapped
Looking up www.google.com...
Got address(es)
IPv6 address: 2607:f8b0:4002:c01::69
$

which is also reflected in the behavior of latest io.js when using dns.lookup with family: 6 and hints: dns.V4MAPPED:

root@381f0506-b6c5-c14a-db53-b02109976e52:/tmp/io.js # cat dns-ipv6-mapped.js 
var dns = require('dns');
dns.lookup('www.google.com', { family: 6, hints: dns.V4MAPPED }, function onLookup(err) {
  console.log('err:', err);
});
$ ./iojs --version
v1.7.2
$ ./iojs dns-ipv6-mapped.js 
err: { [Error: getaddrinfo EAI_BADFLAGS]
  code: 'EAI_BADFLAGS',
  errno: 'EAI_BADFLAGS',
  syscall: 'getaddrinfo',
  hostname: 'www.google.com' }
$

So as I understand it, nodejs/node@04bea9f does not fix dns.lookup entirely regarding the usage of dns.V4MAPPED on FreeBSD. In its current status, it seems to only fix the net.connect use case, but by changing code that is not necessarily directly related. If I understand the original intention correctly, this change would need to be modified to also clear dns.V4MAPPED when family === 6.

So it seems to me we have several different ways to fix this problem:

1. Not using dns.V4MAPPED in net.connect only on FreeBSD and not changing dns.lookup. Pros: This fixes the net.connect use case. Users using dns.V4MAPPED in dns.lookup will get an error on FreeBSD clearly indicating that it's not supported instead of having to find out why it doesn't return mapped addresses. Cons: code that uses dns.lookup and the dns.V4MAPPED flag running on several different platforms including FreeBSD might need to be modified to special-case FreeBSD.
2. Using nodejs/node@04bea9f as is, with the problems highlighted above.
3. Using nodejs/node@04bea9f and clearing the dns.V4MAPPED flag regardless of the family on FreeBSD. Pros: that fixes all errors that FreeBSD users will get when using dns.V4MAPPED. Cons: That can leave FreeBSD users wondering why mapped addresses are not returned when they explicitly asked for it.
4. Using a fix similar to [the one for OpenBSD](Using nodejs/node@04bea9f), as it seems that AI_V4MAPPED is not supported at all.

@joyent/node-coreteam We need to make a decision and I want your input on this. My preference goes to 1 because it fixes the most common use case and it doesn't fail silently for the other explicit dns.lookup use cases, giving the right information to the users so that they know what's happening.

[trevnorris]

1 sounds good

[misterdjules]

@trevnorris Thank you for the feedback, created #18204.

[misterdjules]

Downgrading to P-2 since it seems to be fixed in FreeBSD ports.

[misterdjules]

Fixed by 0e392f3, thank you everyone!