Opened 9 years ago

Closed 9 years ago

#6200 closed bug (duplicate)

getaddrinfo() not correctly accepting some flag combinations

Reported by: anevilyak Owned by: axeld
Priority: normal Milestone: R1
Component: Kits/Network Kit Version: R1/Development
Keywords: Cc:
Blocked By: #3945 Blocking:
Has a Patch: no Platform: All

Description

Haiku's getaddrinfo() returns an error indicating invalid flags with the following sample code:

struct addrinfo *ai;
struct addrinfo hints;
memset (&hints, '\0', sizeof (hints));
hints.ai_flags = AI_PASSIVE | AI_ADDRCONFIG;
hints.ai_socktype = SOCK_STREAM;
int e = getaddrinfo (NULL, "113", &hints, &ai);

All the documentation I've read indicates that this set of flags is correct though. Removing AI_ADDRCONFIG from the flags results in normal behavior though. I suspect this is due to some hack to temporarily disable IPv6 functionality, but haven't looked more closely. The error returned was 3, which gai_strerror() indicates as being "invalid flags".

Change History (6)

comment:1 Changed 9 years ago by axeld

Component: System/libroot.soKits/Network Kit

Doesn't really look like it. In any case, you could easily try to revert hrev35942 which introduced ignoring IPv6 for AF_UNSPEC, and check it out.

comment:2 Changed 9 years ago by anevilyak

Will see what I can find hopefully sometime this week, thanks for the tip!

comment:3 Changed 9 years ago by anevilyak

Had a look, and it looks like a number of our AI_* defines are either bogus or out of date. Unfortunately I'm uncertain where our getaddrinfo() actually came from, though its code looks near identical to that used in FreeBSD. Our netdb.h looks quite different though as far as the AI_* defines go. Ours has AI_MASK (used to validate the flags in getaddrinfo()) hardwired to 0x00000007 for some reason, whereas FreeBSD's looks like:

#define AI_MASK \
    (AI_PASSIVE | AI_CANONNAME | AI_NUMERICHOST | AI_NUMERICSERV | \
    AI_ADDRCONFIG)

Also, some of the other AI_* values differ between us and FreeBSD's, though I'm uncertain if that's due to theirs simply being a newer revision or what. In any case, what would be the best course of action to update this, since I'm uncertain if our current libbind source is vendor branched somewhere?

comment:4 Changed 9 years ago by anevilyak

On second thought, maybe it's simply a case of our netdb.h being out of date? The getaddrinfo()/getnameinfo() code that we have looks like it would work correctly with the updated flag defs (assuming libbind was recompiled).

comment:5 in reply to:  3 Changed 9 years ago by kaliber

Replying to anevilyak:

Had a look, and it looks like a number of our AI_* defines are either bogus or out of date.

I reported that 13 months ago, see ticket #3945 ...

comment:6 Changed 9 years ago by anevilyak

Blocked By: 3945 added
Resolution: duplicate
Status: newclosed

Didn't see that one, thanks.

Note: See TracTickets for help on using tickets.