RE: [PATCH] posix/tst-getaddrinfo4: Consider EAI_NODATA as an expected result
Hi Florian, > -Original Message- > From: linux-snps-arc On Behalf > Of Florian Weimer > Sent: Wednesday, April 24, 2019 3:50 PM > To: Alexey Brodkin > Cc: linux-snps-arc@lists.infradead.org; libc-al...@sourceware.org > Subject: Re: [PATCH] posix/tst-getaddrinfo4: Consider EAI_NODATA as an > expected result > > * Alexey Brodkin: > > > Hi Florian, > > > >> -Original Message- > >> From: Florian Weimer > >> Sent: Thursday, April 18, 2019 3:08 PM > >> To: Alexey Brodkin > >> Cc: libc-al...@sourceware.org; linux-snps-arc@lists.infradead.org > >> Subject: Re: [PATCH] posix/tst-getaddrinfo4: Consider EAI_NODATA as an > >> expected result > >> > >> * Alexey Brodkin: > >> > >> > Some proxy DNS servers might not resolve IPv6 names to addresses. > >> > Instead they reply with NOERROR while passing no real data. > >> > That combination of NOERROR and EAI_NODATA happen because the DNS > >> > server has a recored for requested name (example.net in our case) > >> > but that record is not of type which was requested. > >> > >> I think this invalidates the test to a large degree. I don't think this > >> is a valid test environment. You need to fix it. > > > > I think more interesting would be to figure out if behavior that I see > > is valid or not and then decide which test is representative. > > The test was added for this bug: > > getaddrinfo returns EAI_SYSTEM instead of EAI_NONAME when the network is > down > > <https://urldefense.proofpoint.com/v2/url?u=https-3A__sourceware.org_bugzilla_show-5Fbug.cgi-3Fid- > 3D15339=DwICAg=DPL6_X_6JkXFx7AXWqB0tg=lqdeeSSEes0GFDDl656eViXO7breS55ytWkhpk5R81I=sC1flmdXCo0K > _9eK__8gRyau_7kSpT32orktcQ2LNeQ=TlbAE45sBJja6y8F5OAcODgAOWc1Lx9MYQLP0_iOQSQ=> > > So I think the return code from getaddrinfo matters here. > > We could switch to a namespace with disabled networking; this way, the > test would perhaps be more reliable. > > I also think the test is wrong. EAI_NONAME indicates (negative) > success, something that should not happen if networking is disabled. That makes perfect sense, thanks for explanation. So I guess there's no point in spending any more time on that test now. -Alexey ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH] posix/tst-getaddrinfo4: Consider EAI_NODATA as an expected result
* Alexey Brodkin: > Hi Florian, > >> -Original Message- >> From: Florian Weimer >> Sent: Thursday, April 18, 2019 3:08 PM >> To: Alexey Brodkin >> Cc: libc-al...@sourceware.org; linux-snps-arc@lists.infradead.org >> Subject: Re: [PATCH] posix/tst-getaddrinfo4: Consider EAI_NODATA as an >> expected result >> >> * Alexey Brodkin: >> >> > Some proxy DNS servers might not resolve IPv6 names to addresses. >> > Instead they reply with NOERROR while passing no real data. >> > That combination of NOERROR and EAI_NODATA happen because the DNS >> > server has a recored for requested name (example.net in our case) >> > but that record is not of type which was requested. >> >> I think this invalidates the test to a large degree. I don't think this >> is a valid test environment. You need to fix it. > > I think more interesting would be to figure out if behavior that I see > is valid or not and then decide which test is representative. The test was added for this bug: getaddrinfo returns EAI_SYSTEM instead of EAI_NONAME when the network is down <https://sourceware.org/bugzilla/show_bug.cgi?id=15339> So I think the return code from getaddrinfo matters here. We could switch to a namespace with disabled networking; this way, the test would perhaps be more reliable. I also think the test is wrong. EAI_NONAME indicates (negative) success, something that should not happen if networking is disabled. Thanks, Florian ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
RE: [PATCH] posix/tst-getaddrinfo4: Consider EAI_NODATA as an expected result
Hi Florian, > -Original Message- > From: Florian Weimer > Sent: Thursday, April 18, 2019 3:08 PM > To: Alexey Brodkin > Cc: libc-al...@sourceware.org; linux-snps-arc@lists.infradead.org > Subject: Re: [PATCH] posix/tst-getaddrinfo4: Consider EAI_NODATA as an > expected result > > * Alexey Brodkin: > > > Some proxy DNS servers might not resolve IPv6 names to addresses. > > Instead they reply with NOERROR while passing no real data. > > That combination of NOERROR and EAI_NODATA happen because the DNS > > server has a recored for requested name (example.net in our case) > > but that record is not of type which was requested. > > I think this invalidates the test to a large degree. I don't think this > is a valid test environment. You need to fix it. I think more interesting would be to figure out if behavior that I see is valid or not and then decide which test is representative. >From my Googling I didn't find any data confirming that observed behavior is incorrect, otherwise I would have asked our IT team to fix it. Do you have a solid understanding that NOERROR && EIA_NODATA is not valid combination? -Alexey ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH] posix/tst-getaddrinfo4: Consider EAI_NODATA as an expected result
* Alexey Brodkin: > Some proxy DNS servers might not resolve IPv6 names to addresses. > Instead they reply with NOERROR while passing no real data. > That combination of NOERROR and EAI_NODATA happen because the DNS > server has a recored for requested name (example.net in our case) > but that record is not of type which was requested. I think this invalidates the test to a large degree. I don't think this is a valid test environment. You need to fix it. Thanks, Florian ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
RE: [PATCH] posix/tst-getaddrinfo4: Consider EAI_NODATA as an expected result
Hello, Any chance for this one to get reviewed? It allows 1 more test to complete successfully in case of certain (though seems to be valid) DNS server setups. -Alexey > -Original Message- > From: Vineet Gupta > Sent: Monday, December 17, 2018 9:54 PM > To: Alexey Brodkin ; libc-al...@sourceware.org > Cc: linux-snps-arc@lists.infradead.org > Subject: Re: [PATCH] posix/tst-getaddrinfo4: Consider EAI_NODATA as an > expected result > > On 7/30/18 3:40 AM, Alexey Brodkin wrote: > > Some proxy DNS servers might not resolve IPv6 names to addresses. > > Instead they reply with NOERROR while passing no real data. > > That combination of NOERROR and EAI_NODATA happen because the DNS > > server has a recored for requested name (example.net in our case) > > but that record is not of type which was requested. > > > > That's what Wireshark sees in that case: > > -->8- > > Domain Name System (response) > >Transaction ID: 0x6e2e > >Flags: 0x8180 Standard query response, No error > >1... = Response: Message is a response > >.000 0... = Opcode: Standard query (0) > > .0.. = Authoritative: Server is not an authority for > > domain > > ..0. = Truncated: Message is not truncated > > ...1 = Recursion desired: Do query recursively > > 1... = Recursion available: Server can do recursive > > queries > > .0.. = Z: reserved (0) > > ..0. = Answer authenticated: Answer/authority portion > > was not authenticated by > the server > > ...0 = Non-authenticated data: Unacceptable > > = Reply code: No error (0) > >Questions: 1 > >Answer RRs: 0 > >Authority RRs: 0 > >Additional RRs: 0 > >Queries > >example.net: type , class IN > >Name: example.net > >[Name Length: 11] > >[Label Count: 2] > >Type: (IPv6 Address) (28) > >Class: IN (0x0001) > > -->8- > > > > And that's what we see if Google DNS server (8.8.8.8) is used instead: > > -->8- > > Domain Name System (response) > >Transaction ID: 0x3cd4 > >Flags: 0x8180 Standard query response, No error > >1... = Response: Message is a response > >.000 0... = Opcode: Standard query (0) > > .0.. = Authoritative: Server is not an authority for > > domain > > ..0. = Truncated: Message is not truncated > > ...1 = Recursion desired: Do query recursively > > 1... = Recursion available: Server can do recursive > > queries > > .0.. = Z: reserved (0) > > ..0. = Answer authenticated: Answer/authority portion > > was not authenticated by > the server > > ...0 = Non-authenticated data: Unacceptable > > = Reply code: No error (0) > >Questions: 1 > >Answer RRs: 1 > >Authority RRs: 0 > >Additional RRs: 0 > >Queries > >example.net: type , class IN > >Name: example.net > >[Name Length: 11] > >[Label Count: 2] > >Type: (IPv6 Address) (28) > >Class: IN (0x0001) > > Answers > >example.net: type , class IN, addr 2606:2800:220:1:248:1893:25c8:1946 > > -->8- > > --- > > posix/tst-getaddrinfo4.c | 1 + > > 1 file changed, 1 insertion(+) > > > > diff --git a/posix/tst-getaddrinfo4.c b/posix/tst-getaddrinfo4.c > > index dc9e423448af..0139dee777a1 100644 > > --- a/posix/tst-getaddrinfo4.c > > +++ b/posix/tst-getaddrinfo4.c > > @@ -39,6 +39,7 @@ try (const char *service, int family, int flags) > > case 0: > > case EAI_AGAIN: > > case EAI_NONAME: > > +case EAI_NODATA: > >printf ("SUCCESS getaddrinfo(service=%s, family=%d, flags=%d): %s: > > %m\n", > >service ?: "NULL", family, flags, gai_strerror (res)); > >return 0; > > > > Ping ! ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH] posix/tst-getaddrinfo4: Consider EAI_NODATA as an expected result
On 7/30/18 3:40 AM, Alexey Brodkin wrote: > Some proxy DNS servers might not resolve IPv6 names to addresses. > Instead they reply with NOERROR while passing no real data. > That combination of NOERROR and EAI_NODATA happen because the DNS > server has a recored for requested name (example.net in our case) > but that record is not of type which was requested. > > That's what Wireshark sees in that case: > -->8- > Domain Name System (response) >Transaction ID: 0x6e2e >Flags: 0x8180 Standard query response, No error >1... = Response: Message is a response >.000 0... = Opcode: Standard query (0) > .0.. = Authoritative: Server is not an authority for > domain > ..0. = Truncated: Message is not truncated > ...1 = Recursion desired: Do query recursively > 1... = Recursion available: Server can do recursive > queries > .0.. = Z: reserved (0) > ..0. = Answer authenticated: Answer/authority portion > was not authenticated by the server > ...0 = Non-authenticated data: Unacceptable > = Reply code: No error (0) >Questions: 1 >Answer RRs: 0 >Authority RRs: 0 >Additional RRs: 0 >Queries >example.net: type , class IN >Name: example.net >[Name Length: 11] >[Label Count: 2] >Type: (IPv6 Address) (28) >Class: IN (0x0001) > -->8- > > And that's what we see if Google DNS server (8.8.8.8) is used instead: > -->8- > Domain Name System (response) >Transaction ID: 0x3cd4 >Flags: 0x8180 Standard query response, No error >1... = Response: Message is a response >.000 0... = Opcode: Standard query (0) > .0.. = Authoritative: Server is not an authority for > domain > ..0. = Truncated: Message is not truncated > ...1 = Recursion desired: Do query recursively > 1... = Recursion available: Server can do recursive > queries > .0.. = Z: reserved (0) > ..0. = Answer authenticated: Answer/authority portion > was not authenticated by the server > ...0 = Non-authenticated data: Unacceptable > = Reply code: No error (0) >Questions: 1 >Answer RRs: 1 >Authority RRs: 0 >Additional RRs: 0 >Queries >example.net: type , class IN >Name: example.net >[Name Length: 11] >[Label Count: 2] >Type: (IPv6 Address) (28) >Class: IN (0x0001) > Answers >example.net: type , class IN, addr 2606:2800:220:1:248:1893:25c8:1946 > -->8- > --- > posix/tst-getaddrinfo4.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/posix/tst-getaddrinfo4.c b/posix/tst-getaddrinfo4.c > index dc9e423448af..0139dee777a1 100644 > --- a/posix/tst-getaddrinfo4.c > +++ b/posix/tst-getaddrinfo4.c > @@ -39,6 +39,7 @@ try (const char *service, int family, int flags) > case 0: > case EAI_AGAIN: > case EAI_NONAME: > +case EAI_NODATA: >printf ("SUCCESS getaddrinfo(service=%s, family=%d, flags=%d): %s: > %m\n", >service ?: "NULL", family, flags, gai_strerror (res)); >return 0; > Ping ! ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc