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
