WiFi stopped working after update, how to rollback?

Thanks for pointing it out! I have no idea how they got in there in the first place :smiley:

This sounds to me like a DNS issue, since you have an IP address assigned but pinging and browser activity fails. You can check by pinging say 8.8.8.8 directly. If that succeeds, then you were likely hit by a change that reset any configured DNS settings, and then we need to look into that by getting the output of cat /etc/resolv.conf, resolvectl status, systemctl status systemd-resolved. And you don’t mention it, but are you using a VPN?

1 Like

Yeh, +1 to what Dave notes. If you’re getting an IP address etc. the hardware seems to be working. So probably good to check dns bits first before tinkering with hardware/drivers.

Here’s the output of the commands you requested:
cat /etc/resolv.conf

# This is /run/systemd/resolve/stub-resolv.conf managed by man:systemd-resolved(8).
# Do not edit.
#
# This file might be symlinked as /etc/resolv.conf. If you're looking at
# /etc/resolv.conf and seeing this text, you have followed the symlink.
#
# This is a dynamic resolv.conf file for connecting local clients to the
# internal DNS stub resolver of systemd-resolved. This file lists all
# configured search domains.
#
# Run "resolvectl status" to see details about the uplink DNS servers
# currently in use.
#
# Third party programs should typically not access this file directly, but only
# through the symlink at /etc/resolv.conf. To manage man:resolv.conf(5) in a
# different way, replace this symlink by a static file or a different symlink.
#
# See man:systemd-resolved.service(8) for details about the supported modes of
# operation for /etc/resolv.conf.

nameserver 127.0.0.53
options edns0 trust-ad
search .

resolvectl status

Global
       Protocols: LLMNR=resolve -mDNS -DNSOverTLS DNSSEC=no/unsupported
resolv.conf mode: stub

Link 2 (wlo1)
    Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6
         Protocols: +DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
Current DNS Server: 8.8.8.8
       DNS Servers: 8.8.8.8

Link 5 (br-5db06a83296b)
Current Scopes: LLMNR/IPv4 LLMNR/IPv6
     Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported

Link 6 (docker0)
Current Scopes: none
     Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported

Link 7 (br-b4669879cc62)
Current Scopes: LLMNR/IPv4 LLMNR/IPv6
     Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported

Link 8 (br-3373313d118c)
Current Scopes: LLMNR/IPv4 LLMNR/IPv6
     Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported

Link 10 (vethbe512dd)
Current Scopes: LLMNR/IPv6
     Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported

Link 12 (veth3058053)
Current Scopes: LLMNR/IPv6
     Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported

Link 14 (veth83032cf)
Current Scopes: LLMNR/IPv6
     Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported

Link 16 (vethb74f491)
Current Scopes: LLMNR/IPv6
     Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported

Link 18 (veth97a7352)
Current Scopes: LLMNR/IPv6
     Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported

Link 20 (veth8a331ba)
Current Scopes: LLMNR/IPv6
     Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported

Link 22 (veth2ea5480)
Current Scopes: LLMNR/IPv6
     Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported

Link 24 (veth5f191ec)
Current Scopes: LLMNR/IPv6
     Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported

Link 26 (vethe418ee1)
Current Scopes: LLMNR/IPv6
     Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported

Link 28 (veth5da7420)
Current Scopes: LLMNR/IPv6
     Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported

Link 30 (veth76b3984)
Current Scopes: LLMNR/IPv6
     Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported

Link 32 (vethd3a26d3)
Current Scopes: LLMNR/IPv6
     Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported

Link 34 (vethb9fc38f)
Current Scopes: LLMNR/IPv6
     Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported

Link 36 (vethbaa0c15)
Current Scopes: LLMNR/IPv6
     Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported

Link 38 (veth4a849e2)
Current Scopes: LLMNR/IPv6
     Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported

Link 40 (veth8414fc0)
Current Scopes: LLMNR/IPv6
     Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported

Link 42 (veth5a03657)
Current Scopes: LLMNR/IPv6
     Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported

Link 44 (vethcf0669d)
Current Scopes: LLMNR/IPv6
     Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported

Link 46 (vethd5bec62)
Current Scopes: LLMNR/IPv6
     Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported

Link 48 (vethe51eeeb)
Current Scopes: LLMNR/IPv6
     Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported

Link 50 (vethfdb5eea)
Current Scopes: LLMNR/IPv6
     Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported

Link 52 (vethce66533)
Current Scopes: LLMNR/IPv6
     Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported

systemctl status systemd-resolved (this output shows an attempt I made to manually set the DNS to 8.8.8.8 in gnome settings, which did not solve the issue)

● systemd-resolved.service - Network Name Resolution
     Loaded: loaded (/usr/lib/systemd/system/systemd-resolved.service; enabled; vendor preset: enabled)
     Active: active (running) since Wed 2022-07-27 12:36:29 CEST; 24h ago
       Docs: man:systemd-resolved.service(8)
             man:org.freedesktop.resolve1(5)
             https://www.freedesktop.org/wiki/Software/systemd/writing-network-configuration-managers
             https://www.freedesktop.org/wiki/Software/systemd/writing-resolver-clients
   Main PID: 1082 (systemd-resolve)
     Status: "Processing requests..."
      Tasks: 1 (limit: 18252)
     Memory: 5.5M
        CPU: 2.966s
     CGroup: /system.slice/systemd-resolved.service
             └─ 1082 /usr/lib/systemd/systemd-resolved

Jul 28 12:44:23 uno systemd-resolved[1082]: wlo1: Bus client reset DNS server list.
Jul 28 12:44:28 uno systemd-resolved[1082]: wlo1: Bus client set search domain list to: lan
Jul 28 12:44:28 uno systemd-resolved[1082]: wlo1: Bus client set default route setting: yes
Jul 28 12:44:28 uno systemd-resolved[1082]: wlo1: Bus client set DNS server list to: 192.168.1.254
Jul 28 12:44:28 uno systemd-resolved[1082]: Using degraded feature set UDP instead of UDP+EDNS0 for DNS server 192.168.1.254.
Jul 28 12:45:11 uno systemd-resolved[1082]: wlo1: Bus client reset search domain list.
Jul 28 12:45:11 uno systemd-resolved[1082]: wlo1: Bus client set default route setting: no
Jul 28 12:45:11 uno systemd-resolved[1082]: wlo1: Bus client reset DNS server list.
Jul 28 12:45:14 uno systemd-resolved[1082]: wlo1: Bus client set default route setting: yes
Jul 28 12:45:14 uno systemd-resolved[1082]: wlo1: Bus client set DNS server list to: 8.8.8.8

EDIT: I also tried to ping 8.8.8.8 (or whatever DNS server reported as configured in gnome settings) but I DO NOT receive any response. As an alternative to USB tethering my phone to access the internet, I also tried Bluetooth tethering and that works too.

EDIT 2: About a VPN, I don’t use any and nothing of the sort has ever been configured. I do have a docker instance running for development purposes, but it was not an issue before updating. Also, the problem occurs even if I do not start it in the first place.

OK, looks like DNS is not the issue, as you can’t ping a common internet address, skipping name resolution. So, back to looking at your wireless configuration. And, of course, I’ll still ask dumb questions, not meant to be insulting – you mentioned that tethering to your phone gives you internet access, but to your wireless router, no connection. So, dumb question: other devices connected through your router are working fine, right? Can you connect to your router via your browser (administrative console)? Often your router can list other devices connected to your LAN segment; if so, can you ping them? This is intended to see if your problem is before, at, or beyond your router connection.

1 Like

One thing I have sometimes seen is the router may block connections outbound from a certain machine.

Have never figured out why or how, but usually removing power to the router, wait about a minute, then power it back on so it does a clean boot and makes new connections to everything seems to work.

I had a similar problem on an HP laptop with the only difference being that my Wi-Fi worked fine for 1 minute and didn’t work for about 3 minutes. (Fedora 36, GNOME). The problem was solved by installing a driver for my Wi-Fi module (RTL8821ce): GitHub - lwfinger/rtw88

Now everything is working properly.

I am facing the same problem on my fedora36.

As a workaround i am flushing the mac address filter from the router(from other device), which temporarily some how allows my fedora machine to connect with internet

during the problematic time, traceroute towards the gateway IP is routed to the local IP

2f93e966d325e5911b44c670f1debe16ac81a1dd.png

I tried your commands and I receive a very similar output. I can’t currently mess around with the router I am testing with though.

[maikewng@uno ~]$ netstat -nr
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
0.0.0.0         192.168.70.253  0.0.0.0         UG        0 0          0 wlo1
192.168.70.0    0.0.0.0         255.255.255.0   U         0 0          0 wlo1
[micheleriva@uno ~]$ ping 192.168.70.253
PING 192.168.70.253 (192.168.70.253) 56(84) bytes of data.
^C
--- 192.168.70.253 ping statistics ---
8 packets transmitted, 0 received, 100% packet loss, time 23231ms

[maikewng@uno ~]$ traceroute 192.168.70.253
traceroute to 192.168.70.253 (192.168.70.253), 30 hops max, 60 byte packets
 1  uno (192.168.70.158)  140.785 ms !H  140.720 ms !H  140.701 ms !H
[maikewng@uno ~]$ 

No worries about the dumb questions :slight_smile: They’re necessary to get a good understanding of the issue.
Other devices connected to the same network work fine, and I tried with several hotspots, namely:

  • My home router
  • My workplace router (both private and guest networks)
  • My phone as a Wifi hotspot

I get the same behavior with all of the above: I receive a good configuration (IP, DNS, gateway get all assigned) but then I don’t get any response from any network request I make. The only way I can access the internet with this laptop right now is through USB/Bluetooth tethering it to my phone.

Feels like no packets get through for some reason, thus I suspected some update to the firewall to be the culprit. But disabling fedora’s firewall (systemctl stop firewalld) made no difference, and iptables output is as clean as it gets:

[maikewng@uno ~]$ sudo iptables -S
-P INPUT ACCEPT
-P FORWARD ACCEPT
-P OUTPUT ACCEPT
[maikewng@uno ~]$ sudo iptables -t nat -S
-P PREROUTING ACCEPT
-P INPUT ACCEPT
-P OUTPUT ACCEPT
-P POSTROUTING ACCEPT
[maikewng@uno ~]$ 

I have an RTL8822CE, likely covered by the same driver package. Maybe a driver update went wrong? Do you have any suggestion on how to check it out? I tried to boot with an older kernel version (thinking it would use old drivers this way) but the problem persisted.

I MAY consider to use a driver from an external repository, but I feel it should not be necessary as it used to work before. Reverting the update (or whatever) which caused this issue should be all I need.

You mention this interface. (RTL8822CE)

There are several threads on here about that particular card and several show the fix as installing a new driver.
This post is one of those.
https://discussion.fedoraproject.org/t/no-internet-access-with-connected-wifi/72589

1 Like

For that particular issue, the user couldn’t ping the gateway, so the symptom is different, but the suggestion of loading the different driver is sound. The issues around the RTL8822CE are strange, looking at the collection of bizarre symptoms. @maikewng would you consider trying the drivers mentioned as the solution for the other posts? Otherwise I think you’d have to look at firewall issues not on your system but for the network, if you can ping the router but not beyond. Strange that the issue seems triggered by the update.

In post 12 @maikewng also shows he cannot ping the gateway.

The thread pointed by @computersavvy could be the issue. As in that thread, I also noticed that very rarely the wifi network resumes working after playing with connecting/disconnecting multiple interfaces, but I didn’t mention it as I thought it was due to some sort of browser caching. Maybe it wasn’t?

I will give a shot a replacing the drivers. Still, it is strange that the issue occurred now. I have used Fedora on this laptop for about 2 years (F33 first, then clean installed F36) and this never occurred before. Will keep you updated.

I have exactly the same problem. After an update, yesterday, wifi became erratic and, most of the time, even being able to logon to wireless network, I can’t access internet.

I have a HP 15s ryzen 7 Radeon with a RTL8822CE card.

As hinted by @computersavvy and @user097 , it turned out to be a WiFi driver issue. Installing a newer driver from the linked repository (GitHub - lwfinger/rtw88) solved the problem.

For future reference, I have an HP envy x360 13 (ryzen 4700u) with a RTL8822CE card.

Might be worth to open a bugzilla report as apparently I am not the only user affected by this.

Thanks to everyone who contributed :slight_smile:

2 Likes

It would be necessary for one of the affected users to file the bugzilla.redhat.com report since those of us with different interfaces would not have the details nor logs you have which are usually needed.

1 Like

Definitely my case: HP Laptop 15s-eq2xxx, Ryzen 3, AMD RENOIR, RTL8822CE, Fedora 36, GNOME 42.3. There was a sporadic internet access. Have installed driver from Github manually. WiFi get worked.

2 posts were split to a new topic: Using older iwl*firmware packages to ensure wifi works