Suddenly network reachable but no internet until reconnect manually

My WiFi on a fairly fresh install of Fedora 33 Workstation will “cut-off”, meaning that, although the network is still reachable, pages will appear to take forever to load, and domain names cannot be resolved. Services that I’m already communicating with, such as a playing video or zoom meeting, may continue to work, but I cannot view new web pages, regardless of browser or command line tool. ping 1.1.1.1 simply produces no output. When I disconnect, either by moving to airplane mode or by disconnecting and reconnecting to the same network. When this problem occurs, my OS doesn’t seem to know what is wrong, and neither does my browser. After a while, a question-mark WiFi icon may replace the regular WiFi-strength icon, indicating that I’m not connected to the internet although I am connected to the WiFi. This problem only happens when connecting to either of my home networks, whether the 5G or the 2.4G. It does not occur for other devices on the same network, nor does it occur for this device on other networks. This shows that the problem is specific to my device and the modem combined. Furthermore, this occurred on a previous install, Fedora 32. So it occurs without regard to any configuration I made other than setting up internet, and is not new in Fedora 33. There’s even a Debian machine that works without issue on my network. So it seems to be an interaction specifically between Fedora and this specific modem. A DNS issue maybe? That would explain why connections that are already open are still working. Yet it appears I can’t ping 1.1.1.1 which isn’t a text domain name, right? What commands might I run to diagnose this issue when it happens, or what logs might I check for anomalies?

1 Like

Post the output:

uname -a; lspci -n -n -k; lsusb -v -v -t
1 Like
talibpierson@xps-13-9370 ~> head -n -0 *.txt
==> ifconfig.txt <==
lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 4502  bytes 410490 (400.8 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 4502  bytes 410490 (400.8 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

virbr0: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
        inet 192.168.122.1  netmask 255.255.255.0  broadcast 192.168.122.255
        ether 52:54:00:d1:46:63  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

wlp2s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.0.8  netmask 255.255.255.0  broadcast 192.168.0.255
        inet6 2602:4b:a439:3c00:6648:53a7:5e18:29c3  prefixlen 64  scopeid 0x0<global>
        inet6 fd00::cfd4:5f96:2861:f242  prefixlen 64  scopeid 0x0<global>
        inet6 fe80::3e3a:3264:e9d:8b69  prefixlen 64  scopeid 0x20<link>
        ether 9c:b6:d0:8a:6e:a5  txqueuelen 1000  (Ethernet)
        RX packets 727625  bytes 749086945 (714.3 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 234208  bytes 67119101 (64.0 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0


==> ip_addr.txt <==
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    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: wlp2s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 9c:b6:d0:8a:6e:a5 brd ff:ff:ff:ff:ff:ff
    inet 192.168.0.8/24 brd 192.168.0.255 scope global dynamic noprefixroute wlp2s0
       valid_lft 84845sec preferred_lft 84845sec
    inet6 2602:4b:a439:3c00:6648:53a7:5e18:29c3/64 scope global noprefixroute 
       valid_lft forever preferred_lft forever
    inet6 fd00::cfd4:5f96:2861:f242/64 scope global noprefixroute 
       valid_lft forever preferred_lft forever
    inet6 fe80::3e3a:3264:e9d:8b69/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever
3: virbr0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default qlen 1000
    link/ether 52:54:00:d1:46:63 brd ff:ff:ff:ff:ff:ff
    inet 192.168.122.1/24 brd 192.168.122.255 scope global virbr0
       valid_lft forever preferred_lft forever
4: virbr0-nic: <BROADCAST,MULTICAST> mtu 1500 qdisc fq_codel master virbr0 state DOWN group default qlen 1000
    link/ether 52:54:00:d1:46:63 brd ff:ff:ff:ff:ff:ff

==> lspci_-n_-n_-k.txt <==
00:00.0 Host bridge [0600]: Intel Corporation Xeon E3-1200 v6/7th Gen Core Processor Host Bridge/DRAM Registers [8086:5914] (rev 08)
	Subsystem: Dell Device [1028:07e6]
	Kernel driver in use: skl_uncore
00:02.0 VGA compatible controller [0300]: Intel Corporation UHD Graphics 620 [8086:5917] (rev 07)
	DeviceName:  Onboard IGD
	Subsystem: Dell Device [1028:07e6]
	Kernel driver in use: i915
	Kernel modules: i915
00:04.0 Signal processing controller [1180]: Intel Corporation Xeon E3-1200 v5/E3-1500 v5/6th Gen Core Processor Thermal Subsystem [8086:1903] (rev 08)
	Subsystem: Dell Device [1028:07e6]
	Kernel driver in use: proc_thermal
	Kernel modules: processor_thermal_device
00:14.0 USB controller [0c03]: Intel Corporation Sunrise Point-LP USB 3.0 xHCI Controller [8086:9d2f] (rev 21)
	Subsystem: Dell Device [1028:07e6]
	Kernel driver in use: xhci_hcd
00:14.2 Signal processing controller [1180]: Intel Corporation Sunrise Point-LP Thermal subsystem [8086:9d31] (rev 21)
	Subsystem: Dell Device [1028:07e6]
	Kernel driver in use: intel_pch_thermal
	Kernel modules: intel_pch_thermal
00:15.0 Signal processing controller [1180]: Intel Corporation Sunrise Point-LP Serial IO I2C Controller #0 [8086:9d60] (rev 21)
	Subsystem: Dell Device [1028:07e6]
	Kernel driver in use: intel-lpss
00:15.1 Signal processing controller [1180]: Intel Corporation Sunrise Point-LP Serial IO I2C Controller #1 [8086:9d61] (rev 21)
	Subsystem: Dell Device [1028:07e6]
	Kernel driver in use: intel-lpss
00:16.0 Communication controller [0780]: Intel Corporation Sunrise Point-LP CSME HECI #1 [8086:9d3a] (rev 21)
	Subsystem: Dell Device [1028:07e6]
	Kernel driver in use: mei_me
	Kernel modules: mei_me
00:1c.0 PCI bridge [0604]: Intel Corporation Sunrise Point-LP PCI Express Root Port #1 [8086:9d10] (rev f1)
	Kernel driver in use: pcieport
00:1c.2 PCI bridge [0604]: Intel Corporation Sunrise Point-LP PCI Express Root Port #3 [8086:9d12] (rev f1)
	Kernel driver in use: pcieport
00:1c.4 PCI bridge [0604]: Intel Corporation Sunrise Point-LP PCI Express Root Port #5 [8086:9d14] (rev f1)
	Kernel driver in use: pcieport
00:1d.0 PCI bridge [0604]: Intel Corporation Sunrise Point-LP PCI Express Root Port #9 [8086:9d18] (rev f1)
	Kernel driver in use: pcieport
00:1f.0 ISA bridge [0601]: Intel Corporation Sunrise Point LPC Controller/eSPI Controller [8086:9d4e] (rev 21)
	Subsystem: Dell Device [1028:07e6]
00:1f.2 Memory controller [0580]: Intel Corporation Sunrise Point-LP PMC [8086:9d21] (rev 21)
	Subsystem: Dell Device [1028:07e6]
00:1f.3 Audio device [0403]: Intel Corporation Sunrise Point-LP HD Audio [8086:9d71] (rev 21)
	Subsystem: Dell Device [1028:07e6]
	Kernel driver in use: snd_hda_intel
	Kernel modules: snd_hda_intel, snd_soc_skl
00:1f.4 SMBus [0c05]: Intel Corporation Sunrise Point-LP SMBus [8086:9d23] (rev 21)
	Subsystem: Dell Device [1028:07e6]
	Kernel driver in use: i801_smbus
	Kernel modules: i2c_i801
01:00.0 Unassigned class [ff00]: Realtek Semiconductor Co., Ltd. RTS525A PCI Express Card Reader [10ec:525a] (rev 01)
	Subsystem: Dell Device [1028:07e6]
	Kernel driver in use: rtsx_pci
	Kernel modules: rtsx_pci
02:00.0 Network controller [0280]: Qualcomm Atheros QCA6174 802.11ac Wireless Network Adapter [168c:003e] (rev 32)
	Subsystem: Rivet Networks Killer 1435 Wireless-AC [1a56:143a]
	Kernel driver in use: ath10k_pci
	Kernel modules: ath10k_pci
03:00.0 PCI bridge [0604]: Intel Corporation JHL6540 Thunderbolt 3 Bridge (C step) [Alpine Ridge 4C 2016] [8086:15d3] (rev 02)
	Kernel driver in use: pcieport
04:00.0 PCI bridge [0604]: Intel Corporation JHL6540 Thunderbolt 3 Bridge (C step) [Alpine Ridge 4C 2016] [8086:15d3] (rev 02)
	Kernel driver in use: pcieport
04:01.0 PCI bridge [0604]: Intel Corporation JHL6540 Thunderbolt 3 Bridge (C step) [Alpine Ridge 4C 2016] [8086:15d3] (rev 02)
	Kernel driver in use: pcieport
04:02.0 PCI bridge [0604]: Intel Corporation JHL6540 Thunderbolt 3 Bridge (C step) [Alpine Ridge 4C 2016] [8086:15d3] (rev 02)
	Kernel driver in use: pcieport
04:04.0 PCI bridge [0604]: Intel Corporation JHL6540 Thunderbolt 3 Bridge (C step) [Alpine Ridge 4C 2016] [8086:15d3] (rev 02)
	Kernel driver in use: pcieport
39:00.0 USB controller [0c03]: Intel Corporation JHL6540 Thunderbolt 3 USB Controller (C step) [Alpine Ridge 4C 2016] [8086:15d4] (rev 02)
	Subsystem: Intel Corporation Device [8086:0000]
	Kernel driver in use: xhci_hcd
6e:00.0 Non-Volatile memory controller [0108]: Toshiba Corporation Device [1179:0116]
	Subsystem: Toshiba Corporation Device [1179:0001]
	Kernel driver in use: nvme
	Kernel modules: nvme

==> lsusb_-v_-v_-t.txt <==
/:  Bus 04.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/2p, 10000M
    ID 1d6b:0003 Linux Foundation 3.0 root hub
    /sys/bus/usb/devices/  /dev/bus/usb/004/001
/:  Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/2p, 480M
    ID 1d6b:0002 Linux Foundation 2.0 root hub
    /sys/bus/usb/devices/usb3  /dev/bus/usb/003/001
    |__ Port 2: Dev 2, If 0, Class=Human Interface Device, Driver=usbhid, 1.5M
        ID 046d:c077 Logitech, Inc. M105 Optical Mouse
        /sys/bus/usb/devices/3-2  /dev/bus/usb/003/002
/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/6p, 5000M
    ID 1d6b:0003 Linux Foundation 3.0 root hub
    /sys/bus/usb/devices/usb2  /dev/bus/usb/002/001
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/12p, 480M
    ID 1d6b:0002 Linux Foundation 2.0 root hub
    /sys/bus/usb/devices/usb1  /dev/bus/usb/001/001
    |__ Port 5: Dev 2, If 3, Class=Video, Driver=uvcvideo, 480M
        ID 0bda:58f4 Realtek Semiconductor Corp. 
        /sys/bus/usb/devices/1-5  /dev/bus/usb/001/002
    |__ Port 5: Dev 2, If 1, Class=Video, Driver=uvcvideo, 480M
        ID 0bda:58f4 Realtek Semiconductor Corp. 
        /sys/bus/usb/devices/1-5  /dev/bus/usb/001/002
    |__ Port 5: Dev 2, If 2, Class=Video, Driver=uvcvideo, 480M
        ID 0bda:58f4 Realtek Semiconductor Corp. 
        /sys/bus/usb/devices/1-5  /dev/bus/usb/001/002
    |__ Port 5: Dev 2, If 0, Class=Video, Driver=uvcvideo, 480M
        ID 0bda:58f4 Realtek Semiconductor Corp. 
        /sys/bus/usb/devices/1-5  /dev/bus/usb/001/002
    |__ Port 7: Dev 3, If 0, Class=Wireless, Driver=btusb, 12M
        ID 0489:e0a2 Foxconn / Hon Hai 
        /sys/bus/usb/devices/1-7  /dev/bus/usb/001/003
    |__ Port 7: Dev 3, If 1, Class=Wireless, Driver=btusb, 12M
        ID 0489:e0a2 Foxconn / Hon Hai 
        /sys/bus/usb/devices/1-7  /dev/bus/usb/001/003

==> uname_-a.txt <==
Linux xps-13-9370 5.9.11-200.fc33.x86_64 #1 SMP Tue Nov 24 18:18:01 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
1 Like

It just happened to me-- a page wouldn’t load. Messages wouldn’t send, question mark eventually appears. This time it went away on it’s own. While I was in the process of trying to traceroute -d and ping to look for anomalies.

This is not a browser issue-- even ping will fail while the problem is in effect.

talibpierson@xps-13-9370 ~> tail -n 3 /etc/resolv.conf
nameserver 127.0.0.53
options edns0 trust-ad
search Home

Most likely you issue is not limited to just DNS.
Try to ping or mtr your router and ISP gateway by IP.
I guess this is a problem with driver/firmware:

PING 192.168.0.1 (192.168.0.1) 56(84) bytes of data.

--- 192.168.0.1 ping statistics ---
4 packets transmitted, 0 received, 100% packet loss, time 3057ms
1 Like

To be clear, I try to run tests when the problem is in effect. I save the text output of commands in files and post them when I reconnect, which I can do manually, or if I just wait the issue sometimes resolves itself. It occurs multiple times a day, every day, all year.

1 Like

The following info was extracted from journalctl:

Dec 03 00:41:37 xps-13-9370 systemd-resolved[646]: Using degraded feature set UDP instead of UDP+EDNS0 for DNS server 2606:4700:4700::1111.
Dec 03 00:41:47 xps-13-9370 systemd-resolved[646]: Using degraded feature set UDP instead of UDP+EDNS0 for DNS server 1.1.1.1.
Dec 03 00:41:53 xps-13-9370 systemd-resolved[646]: Using degraded feature set UDP instead of UDP+EDNS0 for DNS server 2606:4700:4700::1001.
Dec 03 00:42:04 xps-13-9370 systemd-resolved[646]: Using degraded feature set TCP instead of UDP for DNS server 2606:4700:4700::1111.
Dec 03 00:42:09 xps-13-9370 systemd-resolved[646]: Using degraded feature set TCP instead of UDP for DNS server 1.1.1.1.
Dec 03 00:42:14 xps-13-9370 systemd-resolved[646]: Using degraded feature set TCP instead of UDP for DNS server 2606:4700:4700::1001.
Dec 03 00:42:44 xps-13-9370 systemd-resolved[646]: Using degraded feature set UDP instead of TCP for DNS server 2606:4700:4700::1001.
Dec 03 00:42:49 xps-13-9370 systemd-resolved[646]: Using degraded feature set UDP instead of TCP for DNS server 1.1.1.1.
[root@xps-13-9370 ~]# head -n -1 ping*
==> ping_-c_4_-b_192.168.0.1.txt <==
PING 192.168.0.1 (192.168.0.1) 56(84) bytes of data.

--- 192.168.0.1 ping statistics ---
4 packets transmitted, 0 received, 100% packet loss, time 3055ms

==> ping_-c_4_-b_192.168.0.8.txt <==
PING 192.168.0.8 (192.168.0.8) 56(84) bytes of data.
64 bytes from 192.168.0.8: icmp_seq=1 ttl=64 time=0.060 ms
64 bytes from 192.168.0.8: icmp_seq=2 ttl=64 time=0.067 ms
64 bytes from 192.168.0.8: icmp_seq=3 ttl=64 time=0.063 ms
64 bytes from 192.168.0.8: icmp_seq=4 ttl=64 time=0.059 ms

--- 192.168.0.8 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3052ms

==> ping_-c_4_-b_192.168.122.1.txt <==
PING 192.168.122.1 (192.168.122.1) 56(84) bytes of data.
64 bytes from 192.168.122.1: icmp_seq=1 ttl=64 time=0.054 ms
64 bytes from 192.168.122.1: icmp_seq=2 ttl=64 time=0.057 ms
64 bytes from 192.168.122.1: icmp_seq=3 ttl=64 time=0.060 ms
64 bytes from 192.168.122.1: icmp_seq=4 ttl=64 time=0.068 ms

--- 192.168.122.1 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3068ms

Why do you think so? And what else might I try? I showed you the result of pinging my router; it didn’t work.

I still think it’s probably a DNS problem.

A dns problem would only be seen when using hostnames to ping, in a browser, etc. but could be caused by local problems as well as the internet. In order to rule out DNS and identify that it is something else you try things using IP addresses so DNS is not in the picture. If that works it is DNS, If that fails it is not DNS. Process of elimination!

For example, if you can ping to 8.8.8.8 but not to www.google.com then it might be dns. If the ping to 8.8.8.8 fails then DNS has been eliminated from the issue. Now it is certainly a LAN, PC, router, ISP issue

A successful ping to the router using its IP would tell you the network in your LAN was working, including the driver and card in the PC.
A failure to ping the router by IP would tell you there was a problem in your PC or LAN. Follow that with a ping to the IP address of your PC, both from the PC itself and if possible from another PC as well. Also if possible ping the router from the other PC as well. This helps to identify if the problem is only on one PC or if it affects the entire LAN.

The goal is to identify what works and what does not so you can narrow down the problem to a specific device.

I have known cat 6 cables to fail and work intermittently, so trying a different cable is a quick and easy test.

In fact, reading your post with the ping stats, I see that the ping by IP to 192.168.0.1 failed and IIRC that is your router. I also see that the ping to 192.168.0.8 succeeded and IIRC that is your PC.

What is between those 2 devices???
Look there first.

1 Like

If it was a DNS related issue, pinging router/gateway IPs should work.
Try to configure a less occupied wireless channel on the router.

Okay you are correct this is definitely not a DNS problem. I’m not sure what the problem is. I am 192.168.0.8, correct. My router is 192.168.0.1. My connection is over WiFi. I’m just on a laptop.

It is very likely that your router is flaky. Recently had an issue with ISP provided cheap router. I changed it to a more powerful router with OpenWRT and it started to work like a charm.

Unfortunately then one windows laptop started to misbehave which caused me a lot of hassle until I fixed but lets not digress.

I had a similar problem although not quite the same. My wifi would go away. When I either reset the radio or went in and out of airplane mode it would work fine.

Then I realized if I ping’ed 8.8.8.8 after about 10-20 seconds I would start getting replies and the wifi would work again.

What I discovered was power management for the radio was turned on and it was going to sleep. Sometimes it was easier to wake up than others.

If you run iwconfig it will tell you if power management is off/on. If you run iwconfig power off it will turn it off. On reboot it will reset to on. You have to change your config settings to make it permanent.

I haven’t had a radio/wifi issue since.

2 Likes

OMG ty so much; that makes a lot of sense. Here is part of the output of iwconfig for me:

wlp2s0    IEEE 802.11  ESSID:"525NRussetSt_5G"  
          Mode:Managed  Frequency:5.18 GHz  Access Point:     54:83:3A:95:25:72   
              Bit Rate=6 Mb/s   Tx-Power=30 dBm   
              Retry short limit:7   RTS thr:off   Fragment thr:off
              Power Management:on
              Link Quality=54/70  Signal level=-56 dBm  
              Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
              Tx excessive retries:0  Invalid misc:85   Missed beacon:0

I created a file /etc/NetworkManager/conf.d/default-wifi-powersave-on.conf

I set its contents to:

[connection]
wifi.powersave = 2

I’ll mark your answer as the solution if it works!

Unfortunately, this solution has not worked for me. The problem appears to still be occurring. The problem indeed occurs only with this router, but it doesn’t seem that the connection is not powerful enough. Many other devices in the house don’t loose connection at all. I’m unsure really how the router plays a role, but I suppose it must play some role.