I currently have a very weird issue on my local network.
Sometimes, it seems to happen consistently after sleep and also randomly, my internet stop working.
It happens on my Framework laptop running Fedora Silverblue and on my raspberry pi running Fedora Server.
This issue happens on my home Wifi network, and on my Android hotspot.
This issue doesn’t seems to happen on other network, for example my mobile hotspot.
Here are the symptoms:
ping always works (I can ping never visited domains before without issues)
ssh works, both directions (I can ssh into my server having the issue, and ssh out of it to github for example)
curl never works (even when using IP adresses, I can’t get pages to load)
firefox don’t load web pages
nslookup don’t work (;; communications error to 127.0.0.53#53: timed out, and ;; communications error to 8.8.8.8#53: timed out when trying to use Google’s DNS)
dnf don’t work
It isn’t a general issue on my network since other devices (iPhones, Macs, my Pixel phone) connect to the internet just fine.
It isn’t related to Silverblue since it also is broken on my raspberry pi running Fedora Server (42, up to date at the time of writing).
It’s not related to Wifi since it happens both with WIFI on my laptop and wired on my server.
It can’t be just a DNS issue since I can’t access web pages even when specifying the IP adresse directly in curl.
I have the default iptable config on my laptop, and I still encounter issues.
Disabling wifi for a bit sometimes fix the issue, but it’s not a reliable fix.
I tried disabling power management for my wifi card, reverting my firewall changes… With no luck.
It took me a while to find a moment to reset the routeur without disturbing everyone.
I finally did it, but the issue remains.
It just occurred to me when booting my laptop after the night.
In GNOME, there were a question mark on the wifi icon, though it doesn’t appear each time.
I tried a few commands:
ascpial@ascpial-framework:~$ dig @8.8.8.8 ascpial.fr
; <<>> DiG 9.18.38 <<>> @8.8.8.8 ascpial.fr
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 60823
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;ascpial.fr. IN A
;; ANSWER SECTION:
ascpial.fr. 3600 IN A 88.139.48.9
;; Query time: 41 msec
;; SERVER: 8.8.8.8#53(8.8.8.8) (UDP)
;; WHEN: Tue Aug 26 09:43:24 CEST 2025
;; MSG SIZE rcvd: 55
ascpial@ascpial-framework:~$ sudo systemctl status resolved
[sudo] Mot de passe de ascpial :
Unit resolved.service could not be found.
ascpial@ascpial-framework:/usr/share/containers/systemd$ sudo systemctl status systemd-resolved
● systemd-resolved.service - Network Name Resolution
Loaded: loaded (/usr/lib/systemd/system/systemd-resolved.service; enabled; preset: enabled)
Drop-In: /usr/lib/systemd/system/service.d
└─10-timeout-abort.conf
Active: active (running) since Tue 2025-08-26 09:39:37 CEST; 4min 16s ago
Invocation: be0b051735f3491fb63ecc47e57f0112
Docs: man:systemd-resolved.service(8)
man:org.freedesktop.resolve1(5)
https://systemd.io/WRITING_NETWORK_CONFIGURATION_MANAGERS
https://systemd.io/WRITING_RESOLVER_CLIENTS
Main PID: 1171 (systemd-resolve)
Status: "Processing requests..."
Tasks: 1 (limit: 17970)
Memory: 5.1M (peak: 5.8M)
CPU: 81ms
CGroup: /system.slice/systemd-resolved.service
└─1171 /usr/lib/systemd/systemd-resolved
août 26 09:39:36 ascpial-framework systemd[1]: Starting systemd-resolved.service - Network Name Resolution...
août 26 09:39:37 ascpial-framework systemd-resolved[1171]: Positive Trust Anchors:
août 26 09:39:37 ascpial-framework systemd-resolved[1171]: . IN DS 20326 8 2 e06d44b80b8f1d39a95c0b0d7c65d08458e880409bbc683457104237c7f8ec8d
août 26 09:39:37 ascpial-framework systemd-resolved[1171]: . IN DS 38696 8 2 683d2d0acb8c9b712a1948b27f741219298d0a450d612c483af444a4c0fb2b16
août 26 09:39:37 ascpial-framework systemd-resolved[1171]: Negative trust anchors: home.arpa 10.in-addr.arpa 16.172.in-addr.arpa 17.172.in-addr.arpa 18.172.in-addr.arpa 19.172.in-addr.arpa 20.172.in-addr.arpa 21>
août 26 09:39:37 ascpial-framework systemd-resolved[1171]: Using system hostname 'ascpial-framework'.
août 26 09:39:37 ascpial-framework systemd[1]: Started systemd-resolved.service - Network Name Resolution.
août 26 09:39:41 ascpial-framework systemd-resolved[1171]: wlp192s0: Bus client set default route setting: yes
août 26 09:39:41 ascpial-framework systemd-resolved[1171]: wlp192s0: Bus client set DNS server list to: 192.168.1.1
ascpial@ascpial-framework:~$ dig ascpial.fr
; <<>> DiG 9.18.38 <<>> ascpial.fr
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 3649
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;ascpial.fr. IN A
;; ANSWER SECTION:
ascpial.fr. 2639 IN A 88.139.48.9
;; Query time: 0 msec
;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP)
;; WHEN: Tue Aug 26 09:56:29 CEST 2025
;; MSG SIZE rcvd: 55
ascpial@~$ dig github.com
; <<>> DiG 9.18.38 <<>> github.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 55834
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;github.com. IN A
;; Query time: 330 msec
;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP)
;; WHEN: Tue Aug 26 09:56:36 CEST 2025
;; MSG SIZE rcvd: 39
ascpial@ascpial-framework:~$ curl github.com
curl: (6) Could not resolve host: github.com
ascpial@ascpial-framework:~$ curl ascpial.fr
curl: (7) Failed to connect to ascpial.fr port 80 after 6132 ms: Could not connect to server
To resolve the issue, all I did was hope to another wifi network (in this case my android hotspot) and go back to the previous wifi network.
First of all, it seems like I only have problems when connected to a devolo wifi router (with wired wireless).
When running tcpdump, I can see that the domain is resolved correctly, and that curl tries to contact the server regularly, but it’s not getting any packets back.
I was setting up a Wireguard VPN on my server to access the machine remotly. I figured I could also set it up to tunnel all my internet traffic. When doing so, the issue gets magically resolved (when stopping the VPN, internet also stops working).
Your local DNS resolver resolves ascpial..fr to a public ip address used for residential networks. Are you trying to curl from your laptop to your server using the public ip address of your router?
Do you use PowerLine in your Wifi/Ethernet network?
I don’t think you are alone, I updated my Framework 13 running Fedora KDE last week. Firefox and Librewolf would keep failing to load websites. I updated today and it seems to be doing better, knock on wood!
Yes I configured it well, you can check by visiting the domain.
My Powerline adapters (not Devolo) lose sync once in a while and I have to unplug/replug one of them to recover quickly.
When the issue happens, leds on the adapter are displayed as usual. I also tried unplugging it and it still didn’t worked one replugged. I didn’t checked the status of the main one connected to the box.
Kernel 6.16.3 was shipped after your original post.
This is the kernel I’m currently running, and I still had my issue.
Sorry I took so long to get back to you, and yeah you are correct I’m still having occasional internet issues. I think this is the real problem I’m having.
I might try rolling back, or most likely wait for the Kernel regression to get ironed out.
To be fair, this bug is driving me crazy. It’s probably too late to rollback easily since I updated my system a few times since then, so I’ll wait for the fix…
@ascpial In the main discussion thread for this issue there are people saying that they are still having issues, even with 6.16.5. It’s still possible they weren’t able to fix this issue in this kernel. I rolled back to 6.15.10-200.fc42.x86_64 and I think I might have to hold on to it for a little bit longer as well.
The IPv4 broadcast bug in 6.16.3 is definitely fixed in 6.16.5.
No doubt there still are network issues with 6.16.5 given the huge range of networking hardware, but those will be different issues than the IPv4 broadcast bug.
