I am experiencing a problem with Linux Mint 17.2. Some experiments demonstrated there's some issue with resolving URL-s.

update 2015-12-02:

Perhaps some one who understands this problem can comment if there could be a connection. In the network manager:

  • /var/log/upstart/network-manager.log

Has the following error:

  (NetworkManager:1015): GLib-WARNING **: GError set over the top of a previous GError or uninitialized memory.
  This indicates a bug in someone's code. You must ensure an error is NULL before it's set.
  The overwriting error message was: Key file does not have group 'connectivity'

The reason I'm wondering if it is connected is that this Ubuntu bug on LaunchPad:

Makes reference to this error and it seems to be associated with various networking problems.

My current woes appear to lie with the same cause for this StackOverflow question, which I though was fixed. It isn't:

So the problem may be in Network-Manager?? update 2015-12-01:

At first the problem was only associated with the TLS SSL / HTTPS lookups on on pretty much EVERYTHING from time-to-time -- not all the time.

Usually 'mainstream' sites like google.com, linkedin.com, yahoo.com, facebook, github, and others from time to time (e.g. my mobile service providers customer service site). It has been really annoying.

There are some comments that it can't be the HTTPS. Until now experimental evidence only shows the problem on encrypted links. However as of yesterday

apt-get update

Is failing. Most things work fine and then ...

  W: Failed to fetch http://dl.google.com/linux/chrome/deb/dists/stable/Release.gpg  Cannot initiate the connection to dl.google.com:80 (2404:6800:4006:800::200e). - connect (101: Network is unreachable)

  W: Failed to fetch http://dl.google.com/linux/chrome/deb/dists/stable/main/i18n/Translation-en_AU  Cannot initiate the connection to dl.google.com:80 (2404:6800:4006:800::200e). - connect (101: Network is unreachable)

  W: Failed to fetch http://dl.google.com/linux/chrome/deb/dists/stable/main/i18n/Translation-en  Cannot initiate the connection to dl.google.com:80 (2404:6800:4006:800::200e). - connect (101: Network is unreachable)

   W: Failed to fetch http://dl.google.com/linux/chrome/deb/dists/stable/main/binary-amd64/Packages  Cannot initiate the connection to dl.google.com:80 (2404:6800:4006:800::200e). - connect (101: Network is unreachable)

  W: Failed to fetch http://dl.google.com/linux/chrome/deb/dists/stable/main/binary-i386/Packages  Cannot initiate the connection to dl.google.com:80 (2404:6800:4006:800::200e). - connect (101: Network is unreachable)

  E: Some index files failed to download. They have been ignored, or old ones used instead.

At them moment that is the ONLY non-HTTPS/SSL link to fail. But it would seem that the issue is actually related to some local intermediate server/cluster thing. The sites failing are all big enough to have several local nodes.

The experimental results are still accurate. And, the issue is about a bad DNS look-up or an out-of-date DNS address.

Restarting DNSmasq has no effect.

  • Is there some log some place I can scan of places to look???

[end Update]

An actual example from tonight is worth 1,000 words. Take GitHub as an example in Chrome or Firefox.

  • https://github.com -- FAIL-s

Resending as:

  • https://www.github.com -- will WORK

You can see more with dig. A simple demonstration use-case follows.


  • github.com (fails)

    ~ $ dig github.com
    ; <<>> DiG 9.9.5-3ubuntu0.5-Ubuntu <<>> github.com
    ;; global options: +cmd
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40526
    ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 0
    ;github.com. IN A
    . 42044 IN NS e.root-servers.net.
    . 42044 IN NS d.root-servers.net.
    . 42044 IN NS h.root-servers.net.
    . 42044 IN NS m.root-servers.net.
    . 42044 IN NS l.root-servers.net.
    . 42044 IN NS c.root-servers.net.
    . 42044 IN NS b.root-servers.net.
    . 42044 IN NS a.root-servers.net.
    . 42044 IN NS j.root-servers.net.
    . 42044 IN NS i.root-servers.net.
    . 42044 IN NS g.root-servers.net.
    . 42044 IN NS f.root-servers.net.
    . 42044 IN NS k.root-servers.net.
    ;; Query time: 91 msec
    ;; SERVER:
    ;; WHEN: Tue Nov 17 21:41:20 AEDT 2015
    ;; MSG SIZE rcvd: 239
  • www.github.com (works)

    ~ $ dig www.github.com

    ; <<>> DiG 9.9.5-3ubuntu0.5-Ubuntu <<>> www.github.com
    ;; global options: +cmd
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 25458
    ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
    ; EDNS: version: 0, flags: do; udp: 512
    ;www.github.com. IN A
    www.github.com. 3599 IN CNAME github.com.
    github.com. 29 IN A
    ;; Query time: 827 msec
    ;; SERVER:
    ;; WHEN: Tue Nov 17 21:41:26 AEDT 2015
    ;; MSG SIZE rcvd: 73

Unfortunately the www. solution won't work with URL-s like:

And www.google.com goes to search. So I can't use any google or youtube, etc.

It is an intermittent problem. Seems to persist for around 2 to 4 days with loosely coupled wired connections. E.g. USB modem or USB to wi-fi access point; where a reconnect or a system restart / resume generally needs to get new addresses. At least that's what seem to make sense.

But that doesn't explain my gmail session just dropping-out one or two hours after restarting my PC, so I have to StackExchange.

I haven't found anything similar mention. But then again I don't know what to call this issue really.

System information:

  Linux 3.16.0-38-generic #52~14.04.1-Ubuntu 
    SMP Fri May 8 09:43:57 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
  DISTRIB_DESCRIPTION="Linux Mint 17.2 Rafaela"

Update (2015-11-18)

After my experiments forcing the github.com example; the normal browser today appears to find github.com satisfactorily. Until the next drop out presumably.

My main concerns is that the mail.google.com look-up fails; I thought the github example is a good easy to appreciate URL.

dig and drill give more or less the same answer for mail.google.com - I'm not sure how to understand the report returned though:

    ~ $ drill @  dns-admin.google.com
    ;; ->>HEADER<<- opcode: QUERY, rcode: NXDOMAIN, id: 32352
    ;; flags: qr rd ra ; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 
    ;; dns-admin.google.com.    IN  A


    google.com. 59  IN  SOA ns2.google.com. dns-admin.google.com. 108125159 900 900 1800 60


    ;; Query time: 537 msec
    ;; EDNS: version 0; flags: do ; udp: 512
    ;; SERVER:
    ;; WHEN: Wed Nov 18 22:13:27 2015
    ;; MSG SIZE  rcvd: 89

Whereas the search https://google.com

nslookup is a little more commutative even though it lacks information:

    ~ $ nslookup host  mail.google.com

    ;; connection timed out; no servers could be reached
    ~ $  ping
    PING ( 56(84) bytes of data.
    64 bytes from icmp_seq=1 ttl=54 time=105 ms
    64 bytes from icmp_seq=2 ttl=54 time=97.8 ms
    64 bytes from icmp_seq=3 ttl=54 time=95.8 ms
    --- ping statistics ---
    3 packets transmitted, 3 received, 0% packet loss, time 2002ms
    rtt min/avg/max/mdev = 95.899/99.745/105.446/4.120 ms

So it reaches the DNS server fine enough. What's going on.

Files ... (EDIT to add config contents.) Note only active (uncommented) options are pasted below. Any other options should be per the Linux Mint defaults and DNSmasq install defaults.

  • /etc/dnsmasq.conf

     # Configuration file for dnsmasq.
     # Format is one option per line, legal options are the same
     # as the long options legal on the command line. See
     # "/usr/sbin/dnsmasq --help" or "man 8 dnsmasq" for details.
     #       :
     #   only showing active options from this file
     #       :
     # Change this line if you want dns to get its upstream servers from
     # somewhere other that /etc/resolv.conf
     ## use resolv
     # By  default,  dnsmasq  will  send queries to any of the upstream
     # servers it knows about and tries to favour servers to are  known
     # to  be  up.  Uncommenting this forces dnsmasq to try each query
     # with  each  server  strictly  in  the  order  they   appear   in
     # /etc/resolv.conf
  • /etc/resolv.dnsmasq.con (resolv-file)

     ##  file:   /etc/resolv.dnsmasq.conf
     #-- Google's nameservers:
     ##  [end]  ##
  • /etc/resolv.conf

     # Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
  • Would you please show us your /etc/resolv.conf? – Rui F Ribeiro Nov 17 '15 at 12:54
  • If dig fails, then it's purely a DNS issue and not a HTTPS issue. If you agree, maybe change the title of the question? A correct title may attract the right person to answer :-) – garethTheRed Nov 17 '15 at 13:04
  • Thanks; however it is definitely HTTPS URL-s that fail. If you look at the example they will work when it is feasible to add "www." to a domain (e.g. www.github.com for: github.com) That's definitely a DNS issue. Who uses "www." these days! – will Nov 17 '15 at 13:22
  • I actually thinks he has bandwidth constraints, fails to reach in an useful time google servers, and the negative answer remains cached. I agree with gareth that it is not a problem specific to https urls. And lot of people still use www. – Rui F Ribeiro Nov 17 '15 at 14:00
  • would you please run the test on speedtest.net and tell us what does it show for you up and down bandwidth? – Rui F Ribeiro Nov 17 '15 at 14:00

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.