14

I've got a new laptop running Ubuntu 16.04 that worked like a charm for a couple of weeks but has now lost its appetite for connecting to the internet via Wi-fi. I know it's not a problem with my router or ISP, because I'm writing this post using my old Windows laptop on the exact same home network by Ubuntu laptop won't connect to.

I'm connecting to my router successfully, and running nmcli dev shows that I'm connected to my wifi device (wlp2s0) and to the wireless network.

Last night I was able to open some pages (Google, Facebook, YouTube), but not others (ubuntu.com, riken.jp). At the time I suspected it was something where IPv6 was working but IPv4 wasn't. Now, however, nothing works. Chromium, ping, wget, dig -- nothing. /etc/resolv.conf/ contains nothing at all (beyond the comment lines telling me not to edit it), and the table returned by route is empty.

UPDATE 1: I used ipconfig /all on my Windows machine to figure out which DNS servers it was using (75.75.75.75, 75.75.76.76., 2001:558:feed::1, 2001:558:feed::2), then used Network Connections to add these as DNS Servers for my home network. cat /etc/resolv.conf now gives me nameserver 127.0.1.1; I'm not entirely sure what this means, but I think it's some kind of alias, right? nmcli dev show | grep DNS shows me as using the two IPv6 DNS servers (2001:558:feed::1 and 2001:558:feed::2).

I can get wget to work with URLs that resolve to an IPv6 address, like so:

craig@craig-XPS-13-9370:~$ wget www.google.com
--2018-04-14 13:06:17--  http://www.google.com/
Resolving www.google.com (www.google.com)... 2607:f8b0:4004:808::2004, 
172.217.13.68
Connecting to www.google.com 
(www.google.com)|2607:f8b0:4004:808::2004|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [text/html]
Saving to: ‘index.html.5’

index.html.5            [ <=>                ]  10.41K  --.-KB/s    in 0.003s  

2018-04-14 13:06:17 (3.36 MB/s) - ‘index.html.5’ saved [10659]

I can't get a wget request to work with URLs that resolve to an IPv4 address:

craig@craig-XPS-13-9370:~$ wget www.ubuntu.com
--2018-04-14 13:06:28--  http://www.ubuntu.com/
Resolving www.ubuntu.com (www.ubuntu.com)... 91.189.89.118
Connecting to www.ubuntu.com (www.ubuntu.com)|91.189.89.118|:80... failed: 
Network is unreachable.

Adding the -4 flag to wget to force IPv4 usage gets a similar result:

craig@craig-XPS-13-9370:~$ wget -4 www.google.com
--2018-04-14 13:06:41--  http://www.google.com/
Resolving www.google.com (www.google.com)... 172.217.13.68
Connecting to www.google.com (www.google.com)|172.217.13.68|:80... failed: 
Network is unreachable.

Similarly, ping www.google.com doesn't work, but ping6 www.google.com does. So it's pretty clear that something is wrong with IPv4, but I'm not sure what...

UPDATE 2: I thought my problem looked pretty similar to this question, but the solution suggested there (disabling IPv4 via Network Connections) doesn't seem to have affected anything. It did give me some ideas for what it's useful to share with others, though:

Output from cat /etc/network/interfaces:

craig@craig-XPS-13-9370:~$ cat /etc/network/interfaces
# interfaces(5) file used by ifup(8) and ifdown(8)
auto lo
iface lo inet loopback

Output from ifconfig:

craig@craig-XPS-13-9370:~$ ifconfig
lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:13526 errors:0 dropped:0 overruns:0 frame:0
          TX packets:13526 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1 
          RX bytes:1031920 (1.0 MB)  TX bytes:1031920 (1.0 MB)

wlp2s0    Link encap:Ethernet  HWaddr 9c:b6:d0:8b:4b:c5  
          inet6 addr: fe80::1f3b:5545:508:919a/64 Scope:Link
          inet6 addr: 2601:140:8600:e0:d64b:9272:665f:3734/64 Scope:Global
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:19665 errors:0 dropped:0 overruns:0 frame:0
          TX packets:10262 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:14731745 (14.7 MB)  TX bytes:1722860 (1.7 MB)

Output from iwconfig:

craig@craig-XPS-13-9370:~$ iwconfig
lo        no wireless extensions.

wlp2s0    IEEE 802.11abgn  ESSID:"MOTOROLA-ABD39"  
          Mode:Managed  Frequency:2.447 GHz  Access Point: 34:1F:E4:E4:35:D0   
          Bit Rate=1 Mb/s   Tx-Power=20 dBm   
          Retry short limit:7   RTS thr:off   Fragment thr:off
          Power Management:on
          Link Quality=55/70  Signal level=-55 dBm  
          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
          Tx excessive retries:0  Invalid misc:39   Missed beacon:0

Output from cat /etc/resolv.conf:

craig@craig-XPS-13-9370:~$ cat /etc/resolv.conf
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
#     DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
nameserver 127.0.1.1

Output from route -n:

craig@craig-XPS-13-9370:~$ route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface

Output from route -6 -n:

craig@craig-XPS-13-9370:~$ route -6 -n
Kernel IPv6 routing table
Destination                    Next Hop                   Flag Met Ref Use If
2601:140:8600:e0::/64          ::                         U    600 0     0 wlp2s0
2601:140:8600:e0::/60          fe80::361f:e4ff:fee4:35cf  UG   600 0     0 wlp2s0
fe80::/64                      ::                         U    256 0     0 wlp2s0
::/0                           fe80::361f:e4ff:fee4:35cf  UG   600 2     4 wlp2s0
::/0                           ::                         !n   -1  1  1495 lo
::1/128                        ::                         Un   0   7    46 lo
2601:140:8600:e0:d64b:9272:665f:3734/128 ::                         Un   0   2   150 lo
fe80::1f3b:5545:508:919a/128   ::                         Un   0   2     4 lo
ff00::/8                       ::                         U    256 7    99 wlp2s0
::/0                           ::                         !n   -1  1  1495 lo

Output from ip neigh:

craig@craig-XPS-13-9370:~$ ip neigh
fe80::361f:e4ff:fee4:35cf dev wlp2s0 lladdr 34:1f:e4:e4:35:cf router REACHABLE
1
  • nameserver 127.0.0.1 just means your computer runs its own DNS server or proxy, this usually means systemd these days. – Ketil Malde Sep 14 '20 at 7:06
20

Not sure if this is a permanent solution, but I managed to get things working again by releasing and renewing my IP address:

sudo dhclient -r wlp2s0
sudo dhclient wlp2s0

Now I see an inet addr line when I run ifconfig (which was never there before) and cat /etc/resolv.conf has added an IPv4 nameserver and a "search" line for my ISP (search hsd1.va.comcast.net). Problem solved!

3
  • 1
    As it is no permanent solution and I've got the same issue here - what is the permanent solution for it? – ferdy Nov 26 '20 at 5:47
  • @mmoisse You saved my evening – User Rebo Apr 23 at 16:22
  • This did helped but only until the next restart. Since it can't be in option to do this each restart, a permanent solution would be nice. – The End Jun 25 at 15:14
7
+100

Sometimes this can be caused by an incorrect system time. If your system time is too far off, you will not be leased an IPv4 by DHCP -- only an IPv6.

You can check the system time settings by running timedatectl in a terminal.

If you need to reconfigure your system time and/or time zone, run sudo dpkg-reconfigure tzdata in a terminal.

Assigning a static IP/Gateway/DNS could also work regardless, but certain websites will complain.

2
  • Good call on time! I don't use DHCP but as a programmer I have observed the issue of clock skew and other such things; it can cause so many problems! People think that it's not all that important to have accurate time but it most certainly is important and for technology it's critically important! – Pryftan Dec 12 '19 at 14:36
  • I initially upvoted this answer, but it led me down a wrong path that cost me hours. The system time did not matter! I got a lease even with system time at epoch zero. What did indeed matter was that no timezone was configured. A lot of programs default to UTC0 and work fine, but DHCP may not send out options 100/101, which in my case lead to the router just silently dropping all requests. dpkg-reconfigure tzdata does do the trick, but I just had to export TZ=UTC0 to get DHCP to work. – iFreilicht Oct 15 '20 at 21:25
0

I got my wired connection broken after running the firewall: sudo ufw enable

After that, disabling the firewall still didn't fix the problem.

Looking at the network configuration through the GUI (Wired connected --> Wired settings), I was able to see that IPv4 was not enabled automatically.

Click on the configuration icon (gear), select to "connect automatically" Then click on IPv4 tab, and select Automatic (DHCP)

Wait a bit and it worked.

0

After spending full day troubleshooting on laptop end, changing my mobile APN from ipv6 to ipv4/ipv6 did the trick finally.

1
  • 5
    Would you care to explain how you did this? – Nmath Sep 3 '20 at 4:40
0

In my case (on Ubuntu 20.04 FWIW) the NIC wasn't configured to use DHCP. I had to update /etc/netplan/00-installer-config.yaml with

network:
  ethernets:
    enp5s0:  # new interface
      dhcp4: true

and then run netplan apply

I can't recall if I had to also run dhclient -r enp5s0 to force it to get DHCP again.

Your Answer

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

Not the answer you're looking for? Browse other questions tagged or ask your own question.