Name or service not known

[Tim Rühsen]

Hi,

renamed the subject since now it is about name resolution.

Please read https://serverfault.com/questions/76421/wget-cant-resolve-host

That possibly answers your question. (your config.log looks goodto me).

Regards, Tim

On 20.05.20 01:20, Stephen Kirby wrote:
> Tim,
> 
> Thanks for your post -- please see below with my responses prefaced with
> "**".  Note - I have attached the config.log and src/config.h files from
> my wget build.
> 
>> Certificates loaded: 138
> 
> This looks good now.  
> **Excellent.
> 
>> Resolving (URL) ... failed: Name or service not known
>> wget: unable to resolve host address '(URL)'
> 
> This means your name resolution doesn't work. It has nothing to do with
> TLS. Wget uses getaddrinfo() to resolve host names. Maybe you can attach
> config.log and src/config.h ?
> **OK - I am attaching these files from my wget build tree.  Hopefully,
> they are useful.
> 
> To prove that, test without https, e.g.
> wget http://example.com
> 
> 
> (Does this work for you ?)
> **wget http://example.com did not work yielding:
>    Resolving example.com <http://example.com> ... failed: Name or
> service not known
> 
>> OK - so this begs these questions:
>> (1) How can I find out if the (hash #).0 files in the --ca-directory I
>> point to are PEM format and thus readable?
> 
> GnuTLS found 138 distinct certificates and loaded them. You solved this
> issue already now.
> **Good.
> 
>> (2) Assuming they are readable, and are PEM format, how can I update one
>> of them, or create a new PEM format file, that will allow access to the
>> URL I need?
> 
> That is also not your problem right now.
> **OK.
> 
> Best,
> Steve
> 
> On Tue, May 19, 2020 at 3:16 PM Tim Rühsen <address@hidden
> <mailto:address@hidden>> wrote:
> 
>     On 19.05.20 20:55, Stephen Kirby wrote:
>     > Tim,
>     >
>     > Thanks for that.  I like the idea of rebuilding GnuTLS so I don't have
>     > to add the --ca-directory flag, but will hold on that until I can
>     > resolve the connecting problem.
>     >
>     > I added the --ca-directory=/system/etc/security/cacerts flag to
>     the wget
>     > call and now see this (still not connecting and pulling the file, but
>     > slightly different message):
>     >
>     > Certificates loaded: 138
> 
>     This looks good now.
> 
>     > Resolving (URL) ... failed: Name or service not known
>     > wget: unable to resolve host address '(URL)'
> 
>     This means your name resolution doesn't work. It has nothing to do with
>     TLS. Wget uses getaddrinfo() to resolve host names. Maybe you can attach
>     config.log and src/config.h ?
> 
>     To prove that, test without https, e.g.
>     wget http://example.com
> 
>     (Does this work for you ?)
> 
>     > OK - so this begs these questions:
>     > (1) How can I find out if the (hash #).0 files in the --ca-directory I
>     > point to are PEM format and thus readable?
> 
>     GnuTLS found 138 distinct certificates and loaded them. You solved this
>     issue already now.
> 
>     > (2) Assuming they are readable, and are PEM format, how can I
>     update one
>     > of them, or create a new PEM format file, that will allow access
>     to the
>     > URL I need?
> 
>     That is also not your problem right now.
> 
> 
> 
>     >
>     > thanks,
>     > Steve
>     >
>     > On Tue, May 19, 2020 at 1:43 AM Tim Rühsen <address@hidden
>     <mailto:address@hidden>
>     > <mailto:address@hidden <mailto:address@hidden>>> wrote:
>     >
>     >     Stephen,
>     >
>     >     you should use the --ca-directory=directory options for this.
>     >
>     >     That one loads all PEM files in that directory into the
>     internal GnuTLS
>     >     cert store. The file naming doesn't matter, only the content
>     must be
>     >     PEM.
>     >
>     >     You wouldn't have that hassle if GnuTLS would have been built
>     with the
>     >     correct system cert store set. As far as I know, that would be
>     >     "./configure
>     >     --with-default-trust-store-dir=/system/etc/security/cacerts".
>     >
>     >     Regards, Tim
>     >
>     >     On 19.05.20 00:10, Stephen Kirby wrote:
>     >     > Tim,
>     >     >
>     >     > Thanks for that clarification.   You are correct --
>     >     >
>     >     > I checked the x86-based Google Pixel emulator and there is no
>     >     > /etc/ssl/certs directory.  Rather it appears this OS puts
>     certificates
>     >     > in: /system/etc/security/cacerts.  There the files are named
>     (hash
>     >     #'s).0. 
>     >     >
>     >     > Do I need to tell wget to look in this directory instead?  The
>     >     relevant
>     >     > flag available with wget looks to be "--ca-certificate=FILE". 
>     >     However,
>     >     > I do not know, out of the 30 or so files in the aforementioned
>     >     directory
>     >     > I should point to.  Furthermore does wget require these
>     certificate
>     >     > files strictly be either PEM or DER format?  Not sure what the
>     >     format of
>     >     > the files in /system/etc/security/cacerts on this emulator
>     are?  Sorry
>     >     > for this short list of questions.  Just trying to get a feel for
>     >     what to
>     >     > do next...
>     >     >
>     >     > Best,
>     >     > Steve
>     >     >
>     >     > On Sun, May 17, 2020 at 12:24 PM Tim Rühsen
>     <address@hidden <mailto:address@hidden>
>     >     <mailto:address@hidden <mailto:address@hidden>>
>     >     > <mailto:address@hidden <mailto:address@hidden>
>     <mailto:address@hidden <mailto:address@hidden>>>> wrote:
>     >     >
>     >     >     -1250 is a GnuTLS failure "GNUTLS_E_UNIMPLEMENTED_FEATURE"
>     >     returned by
>     >     >     gnutls_certificate_set_x509_system_trust().
>     >     >
>     >     >     Due to a bug, this is output instead of the real number of
>     >     certs loaded.
>     >     >
>     >     >     The fallback code tries to open /etc/ssl/certs to search for
>     >     >     certificates. But it seems, this doesn't exist on your
>     system.
>     >     >
>     >     >     Regards, Tim
>     >     >
>     >     >     On 16.05.20 19:15, Stephen Kirby wrote:
>     >     >     > Hi all,
>     >     >     >
>     >     >     > Tim let me know I only responded to him instead of the
>     list.  My
>     >     >     bad and
>     >     >     > thanks for noticing!  So here is what I sent Tim the other
>     >     day --
>     >     >     >
>     >     >     > Thanks all for you inputs!
>     >     >     >
>     >     >     > I just tried adding the --debug flag and get one more
>     piece
>     >     of info:
>     >     >     > certificates loaded: -1250
>     >     >     >
>     >     >     > I am not seeing this error code on a quick search.  Maybe
>     >     someone
>     >     >     on the
>     >     >     > list knows what it means?.
>     >     >     >
>     >     >     > Thanks for the strace suggestion.  I do see it on the
>     phone
>     >     >     emulator and am
>     >     >     > thinking next I would run an strace on my Debian Linux
>     system
>     >     >     where my wget
>     >     >     > is working and compare it to the strace on the mobile
>     emulator
>     >     >     where wget
>     >     >     > is failing.
>     >     >     >
>     >     >     > thanks,
>     >     >     > Steve
>     >     >     >
>     >     >     > On Sat, May 16, 2020 at 5:24 AM Tim Rühsen
>     >     <address@hidden <mailto:address@hidden>
>     <mailto:address@hidden <mailto:address@hidden>>
>     >     >     <mailto:address@hidden <mailto:address@hidden>
>     <mailto:address@hidden <mailto:address@hidden>>>> wrote:
>     >     >     >
>     >     >     >> Hi Stephen,
>     >     >     >>
>     >     >     >> please answer to the mailing list, so everybody can
>     >     participate :)
>     >     >     >>
>     >     >     >> Regards, Tim
>     >     >     >>
>     >     >     >> On 15.05.20 20:22, Stephen Kirby wrote:
>     >     >     >>> Thanks all for you inputs!
>     >     >     >>>
>     >     >     >>> I just tried adding the --debug flag and get one more
>     >     piece of info:
>     >     >     >>> certificates loaded: -1250
>     >     >     >>>
>     >     >     >>> Any idea what this code means?
>     >     >     >>>
>     >     >     >>> It does look like the emulator has strace.  I will check
>     >     this as
>     >     >     well...
>     >     >     >>>
>     >     >     >>> thanks,
>     >     >     >>> Steve
>     >     >     >>>
>     >     >     >>> On Fri, May 15, 2020 at 12:07 PM Tim Rühsen
>     >     <address@hidden <mailto:address@hidden>
>     <mailto:address@hidden <mailto:address@hidden>>
>     >     >     <mailto:address@hidden <mailto:address@hidden>
>     <mailto:address@hidden <mailto:address@hidden>>>
>     >     >     >>> <mailto:address@hidden
>     <mailto:address@hidden> <mailto:address@hidden
>     <mailto:address@hidden>>
>     >     <mailto:address@hidden <mailto:address@hidden>
>     <mailto:address@hidden <mailto:address@hidden>>>>> wrote:
>     >     >     >>>
>     >     >     >>>     On 15.05.20 19:08, Stephen Kirby wrote:
>     >     >     >>>     > Petr/Everyone,
>     >     >     >>>     >
>     >     >     >>>     > Thanks so much for your detailed
>     recommendations on
>     >     how to
>     >     >     >>>     proceed.  You
>     >     >     >>>     > were spot on regarding
>     gnutls_priority_set_direct.  I
>     >     >     looked at
>     >     >     >>>     config.log
>     >     >     >>>     > and noticed configure was failing due to a missing
>     >     pthread
>     >     >     lib.  I
>     >     >     >>>     inserted
>     >     >     >>>     > that, then had to fix some other missing symbols. 
>     >     Anyway,
>     >     >     I have a
>     >     >     >>>     > statically linked wget that I have now pushed
>     onto the
>     >     >     Google Pixel
>     >     >     >>>     > Emulated phone I have running via Android Studio.
>     >     >     >>>     >
>     >     >     >>>     > I can definitely move this question to another
>     forum if
>     >     >     you all
>     >     >     >>>     believe it
>     >     >     >>>     > better since it involves an emulated Google Pixel
>     >     phone now
>     >     >     >>>     (x86_64 arch.),
>     >     >     >>>     > but it has to do with wget still, so if I may
>     please:
>     >     >     >>>     >
>     >     >     >>>     > on the emulated phone, I am trying:
>     >     >     >>>     >
>     >     >     >>>     > wget -O filename http://###.##.###.## (i.e.,
>     here I
>     >     use the IP
>     >     >     >> address
>     >     >     >>>     > found via nslookup on the named URL)
>     >     >     >>>     >
>     >     >     >>>     > Then, I get:
>     >     >     >>>     > HTTP request sent, awaiting response... 302
>     object moved
>     >     >     >>>     > Location: https://(here it lists the correctly
>     named
>     >     URL)
>     >     >     >>>     > Resolving (named URL)... Failed: Name or
>     Server not
>     >     known
>     >     >     >>>     > wget: unable to resolve host address "named URL"
>     >     >     >>>     >
>     >     >     >>>     > I'll note that this wget call works perfectly
>     on my
>     >     Debian
>     >     >     Linux
>     >     >     >>>     > system, downloading the file I need.
>     >     >     >>>     > Also interesting to me is the fact that I can ping
>     >     >     _successfully_
>     >     >     >>>     both the
>     >     >     >>>     > URL by name or its associated IP address, on the
>     >     emulated
>     >     >     phone
>     >     >     >>>     So, not
>     >     >     >>>     > sure why wget would throw this error.
>     >     >     >>>
>     >     >     >>>     wget uses getaddrinfo(), except you built it
>     with c-ares.
>     >     >     >>>
>     >     >     >>>     Perhaps you have 'strace' installed !?
>     >     >     >>>     Then you could start wget with strace and see what
>     >     fails (or why
>     >     >     >>>     getaddrinfo fails).
>     >     >     >>>
>     >     >     >>>     Regards, Tim
>     >     >     >>>
>     >     >     >>
>     >     >     >>
>     >     >
>     >
>

signature.asc
Description: OpenPGP digital signature