GNOME Bugzilla – Bug 765578
No internet connection through WLAN although connected to wireless network
Last modified: 2016-09-05 19:01:28 UTC
Created attachment 326729 [details] Output of some commands In a fresh install of Kubuntu 16.04 on a ThinkPad t460s, I can connect wireless to the local WLAN, but I don't have an internet connection sometimes - but sometimes I do. The connection is established without problems through LAN though. Without being able to reproduce it, it seems that after being connected through LAN for some time, the internet connection through WLAN becomes active, too. At first it looked as if the error disappeared when I set the IPv6 settings to "ignore", but the problem returned. I also filed two bug reports in other places, but I figured that it's not the right place: https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1566987 https://bugs.kde.org/show_bug.cgi?id=361655 Reproducible: Most of the times, but sometimes it works Always Steps to Reproduce: 1. Connect to WLAN/wireless 2. Try to visit a website or send a ping Actual Results: Connected to wireless network, but no internet connection Expected Results: Be connected to the internet I attach some output that was asked for in forum discussions I found. If any more information is needed, let me know.
Hi yan, when you have no connectivity, please show the output of: ip route ip addr ip link nmcli connection nmcli device cat /etc/resolv.conf Thank you.
Thanks for the quick reply. Here is the output: jan@t460s:~$ ip route default via 192.168.178.1 dev wlp4s0 proto static metric 600 169.254.0.0/16 dev wlp4s0 scope link metric 1000 192.168.178.0/24 dev wlp4s0 proto kernel scope link src 192.168.178.7 metric 600 jan@t460s:~$ ip addr 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: enp0s31f6: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000 link/ether 50:7b:9d:ab:13:3a brd ff:ff:ff:ff:ff:ff 3: wlp4s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000 link/ether a4:34:d9:be:bd:f1 brd ff:ff:ff:ff:ff:ff inet 192.168.178.7/24 brd 192.168.178.255 scope global dynamic wlp4s0 valid_lft 597535sec preferred_lft 597535sec inet6 fe80::a634:d9ff:febe:bdf1/64 scope link valid_lft forever preferred_lft forever jan@t460s:~$ ip link 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 2: enp0s31f6: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN mode DEFAULT group default qlen 1000 link/ether 50:7b:9d:ab:13:3a brd ff:ff:ff:ff:ff:ff 3: wlp4s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DORMANT group default qlen 1000 link/ether a4:34:d9:be:bd:f1 brd ff:ff:ff:ff:ff:ff jan@t460s:~$ nmcli connection NAME UUID TYP GERÄT paula b8bb18c0-da8d-4654-a1b7-abe4f3dd2fda 802-11-wireless wlp4s0 Kabelnetzwerkverbindung 1 70f14c04-94a8-4fff-928f-bebb43f419dc 802-3-ethernet -- Telekom_ICE fdbcf65a-f5d9-4c3b-ac9c-896c95855489 802-11-wireless -- micmag 1c6d01c2-c9b1-4df5-952f-7b765b9728fe 802-11-wireless -- jan@t460s:~$ nmcli device GERÄT TYP STATUS VERBINDUNG wlp4s0 wifi verbunden paula enp0s31f6 ethernet nicht verfügbar -- lo loopback nicht verwaltet -- jan@t460s:~$ 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 search localdomain
Any ideas what could be the problem? It's really annoying not to be able to use wireless.
Created attachment 327194 [details] wireless-info script output Output of the wireless-info script from https://github.com/UbuntuForums/wireless-info
Could it be that Network Manager "thinks" that there is a wired connection although there isn't? In the wireless-info script I found the following information: GENERAL.DEVICE: enp0s31f6 GENERAL.TYPE: ethernet (...) GENERAL.STATE: 100 (connected) But the script ran when there was only a wireless connection. So I'm wondering if Network Manager is trying to use an ethernet connection that doesn't exist.
Can somebody please help me? Do you need more information?
In the IRC I was pointed to trying nmcli dev show wlp4s0 when the connection works and when it doesn't. The output shows that there is a wrong IP address being used when the connection fails: # INTERNET CONNECTION WORKING # $ nmcli dev show wlp4s0 GENERAL.DEVICE: wlp4s0 GENERAL.TYPE: wifi GENERAL.HWADDR: A4:34:D9:BE:BD:F1 GENERAL.MTU: 0 GENERAL.STATE: 100 (verbunden) GENERAL.CONNECTION: paula GENERAL.CON-PATH: /org/freedesktop/NetworkManager/ActiveConnection/5 IP4.ADRESS[1]: 192.168.1.11/24 IP4.GATEWAY: 192.168.1.1 IP4.ROUTE[1]: dst = 169.254.0.0/16, nh = 0.0.0.0, mt = 1000 IP4.DNS[1]: 192.168.1.1 IP4.DOMAIN[1]: localdomain IP6.ADRESS[1]: fe80::a634:d9ff:febe:bdf1/64 IP6.GATEWAY: # INTERNET CONNECTION NOT WORKING # $ nmcli dev show wlp4s0 GENERAL.DEVICE: wlp4s0 GENERAL.TYPE: wifi GENERAL.HWADDR: <MAC 'wlp4s0' [IF]> GENERAL.MTU: 0 GENERAL.STATE: 100 (connected) GENERAL.CONNECTION: paula GENERAL.CON-PATH: /org/freedesktop/NetworkManager/ActiveConnection/0 IP4.ADDRESS[1]: 192.168.178.7/24 IP4.GATEWAY: 192.168.178.1 IP4.ROUTE[1]: dst = 169.254.0.0/16, nh = 0.0.0.0, mt = 1000 IP4.DNS[1]: 192.168.178.1 IP4.DOMAIN[1]: localdomain IP6.ADDRESS[1]: fe80::<IP6 'wlp4s0' [IF]>/64
I was misguided before, the output of nmcli is identical in both cases: # INTERNET CONNECTION WORKING # GENERAL.GERÄT: wlp4s0 GENERAL.TYP: wifi GENERAL.HWADDR: A4:34:D9:BE:BD:F1 GENERAL.MTU: 0 GENERAL.STATUS: 100 (verbunden) GENERAL.VERBINDUNG: paula GENERAL.CON-PFAD: /org/freedesktop/NetworkManager/ActiveConnection/0 IP4.ADRESSE[1]: 192.168.1.11/24 IP4.GATEWAY: 192.168.1.1 IP4.ROUTE[1]: dst = 169.254.0.0/16, nh = 0.0.0.0, mt = 1000 IP4.DNS[1]: 192.168.1.1 IP4.DOMÄNE[1]: localdomain IP6.ADRESSE[1]: fe80::a634:d9ff:febe:bdf1/64 IP6.GATEWAY: # INTERNET CONNECTION NOT WORKING # GENERAL.GERÄT: wlp4s0 GENERAL.TYP: wifi GENERAL.HWADDR: A4:34:D9:BE:BD:F1 GENERAL.MTU: 0 GENERAL.STATUS: 100 (verbunden) GENERAL.VERBINDUNG: paula GENERAL.CON-PFAD: /org/freedesktop/NetworkManager/ActiveConnection/0 IP4.ADRESSE[1]: 192.168.1.11/24 IP4.GATEWAY: 192.168.1.1 IP4.ROUTE[1]: dst = 169.254.0.0/16, nh = 0.0.0.0, mt = 1000 IP4.DNS[1]: 192.168.1.1 IP4.DOMÄNE[1]: localdomain IP6.ADRESSE[1]: fe80::a634:d9ff:febe:bdf1/64 IP6.GATEWAY:
I just tried Kernel 4.6 as described here: http://ubuntuhandbook.org/index.php/2016/05/install-linux-kernel-4-6-ubuntu-16-04/ The problem persists.
When I don't have a connection and then plug in the cable, wait some minutes and then unplug the cable, the internet connection stays working through WLAN. I was wondering if the following error from syslog (I'll attach it) could be a hint: kernel: [ 3460.949655] wlp4s0: AP 88:03:55:10:78:f5 changed bandwidth, new config is 2412 MHz, width 1 (2412/0 MHz) Is actually anybody reading this?
Created attachment 329161 [details] syslog output when plugging and unplugging cable
Any ideas, please?
I looks like your routes are wrong. When you have no connectivity, check the output of `ip route`. Try to reach something on the internet, e.g. traceroute -n 8.8.8.8 can you resolve DNS names? ping www.google.com dig www.google.com Check that you can ping/reach the gateways of your routes. E.g. you have 192.168.178.1 as gateway. Does it work, when you only connect wifi, but not ethernet? - comment 1 makes it sound like "no". Does it work, when connecting only ethernet, not wifi? - sounds like "yes". Does it work, when connecting ethernet and wifi together? - comment 4 shows that case, so I assume no too. Which isn't plausible, because the logfile from comment 4 shows that ethernet is preferred (metric 100 vs. metric 600). Check which devices are connected via `nmcli device`.
Thanks for your reply Thomas Haller! Here are my answers: > When you have no connectivity, check the output of `ip route`. Connected to wifi, no internet connection: $ ip route default via 192.168.1.1 dev wlp4s0 proto static metric 600 192.168.1.0/24 dev wlp4s0 proto kernel scope link src 192.168.1.13 metric 600 Connected to wifi & ethernet, internet connection established: $ ip route default via 192.168.1.1 dev enp0s31f6 proto static metric 100 default via 192.168.1.1 dev wlp4s0 proto static metric 600 169.254.0.0/16 dev enp0s31f6 scope link metric 1000 192.168.1.0/24 dev enp0s31f6 proto kernel scope link src 192.168.1.5 metric 100 192.168.1.0/24 dev wlp4s0 proto kernel scope link src 192.168.1.13 metric 600 > Try to reach something on the internet, e.g. > traceroute -n 8.8.8.8 Connected to wifi, no internet connection: jan@t460s:~$ traceroute -n 8.8.8.8 traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets 1 * * * 2 * * * 3 * * * 4 * * * 5 * * * 6 * * * 7 * * * 8 * * * 9 * * * 10 * * * 11 * * * 12 * * * 13 * * * 14 * * * 15 * * * 16 * * * 17 * * * 18 * * * 19 * * * 20 * * * 21 * * * 22 * * * 23 * * * 24 * * * 25 * * * 26 * * * 27 * * * 28 * * * 29 * * * 30 * * * Connected to wifi & ethernet, internet connection established: $ traceroute -n 8.8.8.8 traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets 1 192.168.1.1 0.664 ms 0.653 ms 0.648 ms 2 62.52.201.187 19.812 ms 21.316 ms 21.626 ms 3 62.53.22.200 23.734 ms 24.036 ms 62.53.22.198 25.185 ms 4 62.53.4.153 25.487 ms 62.53.4.155 27.326 ms 28.543 ms 5 62.53.5.43 30.515 ms 30.538 ms 33.066 ms 6 72.14.239.115 31.080 ms 72.14.239.113 32.433 ms 72.14.239.109 32.654 ms 7 8.8.8.8 32.663 ms 18.442 ms 18.191 ms > can you resolve DNS names? > ping www.google.com $ ping www.google.com ping: unknown host www.google.com > dig www.google.com $ dig www.google.com ; <<>> DiG 9.10.3-P4-Ubuntu <<>> www.google.com ;; global options: +cmd ;; connection timed out; no servers could be reached > Check that you can ping/reach the gateways of your routes. E.g. you have > 192.168.178.1 as gateway. I think it's 192.168.1.1 now, but at some point it was 192.168.178.1. $ ping 192.168.1.1 PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data. ^C --- 192.168.1.1 ping statistics --- 82 packets transmitted, 0 received, 100% packet loss, time 81647ms > Does it work, when you only connect wifi, but not ethernet? > - comment 1 makes it sound like "no". No. But usually, when ethernet is connected for a while and I unplug the cable, the connection does work through wifi. > Does it work, when connecting only ethernet, not wifi? > - sounds like "yes". Yes, ethernet always works. > Does it work, when connecting ethernet and wifi together? > - comment 4 shows that case, so I assume no too. Which isn't plausible, > because the logfile from comment 4 shows that ethernet is preferred > (metric 100 vs. metric 600). Whenever ethernet is connected, the connection works.
(In reply to yan from comment #14) > Thanks for your reply Thomas Haller! Here are my answers: > > > When you have no connectivity, check the output of `ip route`. > > Connected to wifi, no internet connection: > > $ ip route > default via 192.168.1.1 dev wlp4s0 proto static metric 600 > 192.168.1.0/24 dev wlp4s0 proto kernel scope link src 192.168.1.13 > metric 600 > > Connected to wifi & ethernet, internet connection established: > > $ ip route > default via 192.168.1.1 dev enp0s31f6 proto static metric 100 > default via 192.168.1.1 dev wlp4s0 proto static metric 600 > 169.254.0.0/16 dev enp0s31f6 scope link metric 1000 > 192.168.1.0/24 dev enp0s31f6 proto kernel scope link src 192.168.1.5 > metric 100 > 192.168.1.0/24 dev wlp4s0 proto kernel scope link src 192.168.1.13 > metric 600 In this case, you see that both ethernet and wifi has a default route. As ethernet has the lower metric (100 vs. 600), it works because you reach the internet via ethernet. While debugging Wifi it doesn't seem that your ethernet matters and only makes it more confusing. But I don't know what is wrong here. Can you confirm that your Wifi is actually working (maybe connect your smartphone)? 192.168.1.1 seems to be your gateway. You should be able to ping that one (unless the gateway doesn't answers to pings, try `arping 192.168.1.1` which should also work in that case)... If applicable, check your firewall settings (firewalld, iptable).
Thanks again for taking your time. > But I don't know what is wrong here. Can you confirm that your Wifi is > actually working (maybe connect your smartphone)? It definitely works. I am using multiple other devices with this WLAN and they work just fine. Also, as I said before, it works on the computer with the problems after having an ethernet connection for some minutes and then unplugging the cable.
yan, seems to me an issue with the WiFi driver. Anyway, we can do a check at level 2 too... the command Thomas suggests would be of help: `arping -I enp0s31f6 192.168.1.1` and `arping -I wlp4s0 192.168.1.1` while both WiFi and ethernet connected. Then, post the output also of: `ip neigh` for each of the 3 connectivity statuses: 1) when both eth and wifi are connected 2) when you unplug ethernet and wifi works 3) when only wifi is connected and it does not work
Thanks Francesco. (In reply to Francesco Giudici from comment #17) > yan, seems to me an issue with the WiFi driver. > Anyway, we can do a check at level 2 too... > the command Thomas suggests would be of help: > `arping -I enp0s31f6 192.168.1.1` $ arping -I enp0s31f6 192.168.1.1 ARPING 192.168.1.1 from 192.168.1.5 enp0s31f6 Unicast reply from 192.168.1.1 [88:03:55:10:78:F4] 0.960ms Unicast reply from 192.168.1.1 [88:03:55:10:78:F4] 1.084ms Unicast reply from 192.168.1.1 [88:03:55:10:78:F4] 1.353ms Unicast reply from 192.168.1.1 [88:03:55:10:78:F4] 0.992ms ^CSent 4 probes (1 broadcast(s)) Received 4 response(s) > and > `arping -I wlp4s0 192.168.1.1` > while both WiFi and ethernet connected. $ arping -I wlp4s0 192.168.1.1 ARPING 192.168.1.1 from 192.168.1.13 wlp4s0 Unicast reply from 192.168.1.1 [88:03:55:10:78:F4] 4.798ms Unicast reply from 192.168.1.1 [88:03:55:10:78:F4] 5.003ms Unicast reply from 192.168.1.1 [88:03:55:10:78:F4] 5.060ms Unicast reply from 192.168.1.1 [88:03:55:10:78:F4] 5.891ms ^CSent 4 probes (1 broadcast(s)) Received 4 response(s) > Then, post the output also of: > `ip neigh` > for each of the 3 connectivity statuses: > 1) when both eth and wifi are connected 192.168.1.1 dev enp0s31f6 lladdr 88:03:55:10:78:f4 REACHABLE 192.168.1.1 dev wlp4s0 lladdr 88:03:55:10:78:f4 REACHABLE fe80::1 dev wlp4s0 lladdr 88:03:55:10:78:f4 router STALE fe80::1 dev enp0s31f6 lladdr 88:03:55:10:78:f4 router STALE > 2) when you unplug ethernet and wifi works 192.168.1.1 dev wlp4s0 lladdr 88:03:55:10:78:f4 REACHABLE fe80::1 dev enp0s31f6 lladdr 88:03:55:10:78:f4 router STALE fe80::1 dev wlp4s0 lladdr 88:03:55:10:78:f4 router STALE > 3) when only wifi is connected and it does not work 192.168.1.1 dev wlp4s0 lladdr 88:03:55:10:78:f4 REACHABLE fe80::1 dev wlp4s0 lladdr 88:03:55:10:78:f4 router STALE
Yan, thanks for posting the results. L2 link seems fine and L3 (ip routing table and addresses) seems fine to. Weird behavior... I hardly can believe this could be due to NM, I think you have an issue with the wireless driver. I don't have any great idea here. If it sometimes works and sometimes stops... maybe I would try to disable power save on the wireless device. Check if it is enabled first: iw dev wlp4s0 get power_save if it says that is on, try: sudo iw dev wlp4s0 set power_save off and check if it is turned off now: iw dev wlp4s0 get power_save
Thanks Francesco. Unfortunately power save didn't change anything. It's really frustrating. Any ideas where I could get help?
Hi Yan, would you mind to do another try to better highlight the issue? Collecting packets would be of great help. You can do in this way: * Start from boot, don't connect ethernet at all. * Start collecting packet sent/received with tcpdump for all the test duration in a dedicated terminal (if you prefer wireshark could be fine too): sudo tcpdump -nei wlp4s0 * Connect to your WiFi network. 1) Address and gw acquired? check with: ip route 2) Try a ping to the gateway ping 192.168.1.1 3) Try a ping to an internet address ping 8.8.8.8 * now you can stop tcpdump (CTRL-C) copy output of tcpdump and of 1,2,3 checks here please.
Thanks for taking your time Franceso. > sudo tcpdump -nei wlp4s0 > > * Connect to your WiFi network. > > 1) Address and gw acquired? check with: > ip route > > 2) Try a ping to the gateway > ping 192.168.1.1 > > 3) Try a ping to an internet address > ping 8.8.8.8 > > * now you can stop tcpdump (CTRL-C) > > copy output of tcpdump and of 1,2,3 checks here please. I attach the outputs of tcpdump (and also of tcpdump -v). The 1, 2, 3 are these: $ ip route default via 192.168.1.1 dev wlp4s0 proto static metric 600 169.254.0.0/16 dev wlp4s0 scope link metric 1000 192.168.1.0/24 dev wlp4s0 proto kernel scope link src 192.168.1.16 metric 600 $ ping 192.168.1.1 PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data. ^C --- 192.168.1.1 ping statistics --- 45 packets transmitted, 0 received, 100% packet loss, time 44000ms $ ping 8.8.8.8 PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data. ^C --- 8.8.8.8 ping statistics --- 19 packets transmitted, 0 received, 100% packet loss, time 17999ms The third file contains the output of tcpdump when plugging in ethernet and then after a moment unplugging it again.
Created attachment 330447 [details] Output of tcpdump
Created attachment 330448 [details] Output of tcpdump -v
Created attachment 330449 [details] Output of tcpdump when plugging in ethernet
Hi yan, well, what we can see in the dumps is that l2 connection works (router answers to the ARP queries from the laptop) but no answer are received for L3 packets... nor for the ping, nor for the DNS queries. The packets seem formatted well, with the right destination MAC address. Moreover, no issue in receiving the address from the DHCP server. I would think about some issues in the radio link between the router and the laptop... but that plug/unplug of the ethernet cable that can fix cannot be explained by this. I really cannot understand what is going on. Is there any way to do a check on the router side too? Can you have access to a cli, or at least doing a ping toward the wireless client and check the ARP table? Maybe this could give any clue... unfortunately I have none at present :-(
Thanks Francesco. I don't have a clue neither.. It's so weird. It's my router, a o2 box I have at home. If you tell me what to try, I'll do it. This problem only occurs with my new t460s, no other device has a similar problem.
The problem hasn't re-appeared since a week or so. Possibly some Ubuntu update has fixed it. I'll get back to you in case it happens again.
Nice, thanks for the update yan.
And the problem is back again.. I didn't change anything and all of a sudden wireless connection isn't working, just as described above. So annoying.
Sorry, my bad: This time it was the networks' fault, not my computers'.