I own a Framework 16 laptop running Fedora 42, KDE 6.4.3, Kernel 6.15.7-200.fc42.x86_64, BIOS 3.05.
There is one specific network which drops the internet connection a few seconds after connecting. This applies to both, a wired and a wireless connection. I am out of ideas to try.
Facts I collected so far:
this network works perfectly fine on the same machine running Windows 11 (both wired and wireless)
other devices have no issues connecting to this network whatsoever
this device has no issues connecting to other networks
pinging e.g. google.com fails ~10 seconds after connecting
pinging e.g. 8.8.8.8 fails ~10 seconds after connecting
pinging local addresses does not fail at any point
sudo ip neigh flush all does not help
sudo systemctl restart NetworkManager makes it work for another ~10 seconds
sudo ip route flush table main does not help
journalctl -f shows NetworkManager-dispatcher.service: Deactivated successfully. and SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=NetworkManager-dispatcher comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' when internet stops working
sudo dmesg -wH does not show anything at the time the internet connection drops
setting a static IP does not help
deactivating wifi completely and just using a wired connection does not help
deactivating the firewall with sudo systemctl stop firewalld does not help
setting sudo nmcli general logging level TRACE domains ALL reveals the following journalctl messages around the connectivity drop
I donât have any answers for you, only a few observations.
Since this ONLY happens on a single network, thereâs clearly something different about that network, either its hardware or its configuration. Determining exactly what that is would probably point directly to a solution.
Since both named systems and IP addresses are failing after ten seconds, itâs definitely not a DNS problem. And since you can still ping local addresses, it seems to be a routing issue.
I have (a very small amount of) experience with routing problems under Linux. Can you provide the output of ip route show, preferably both before and after the ten-second mark?
Thank you for your suggestion & sorry for the late response, but I was not in reach of this network since I wrote my post.
Now I am back in reach & currently connected to it without any problems.
Next time Iâm encountering issues I will record the routes before and after the connection loss - I am pretty sure it will happen again soon! I donât want to jinx it, but I had happy times of no connection loss before already
There is no difference in ip route show before and after the connection loss.
default via 172.20.0.1 dev eth0 proto dhcp src 172.20.0.234 metric 100
default via 172.20.0.1 dev wlp4s0 proto dhcp src 172.20.0.103 metric 600
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown
172.18.0.0/16 dev br-9c919db98ec8 proto kernel scope link src 172.18.0.1
172.19.0.0/16 dev br-7414dc282dce proto kernel scope link src 172.19.0.1 linkdown
172.20.0.0/24 dev eth0 proto kernel scope link src 172.20.0.234 metric 100
172.20.0.0/24 dev wlp4s0 proto kernel scope link src 172.20.0.103 metric 600
172.20.0.0/16 dev br-ec21472f9828 proto kernel scope link src 172.20.0.1 linkdown
172.21.0.0/16 dev br-56d907d4a2c2 proto kernel scope link src 172.21.0.1 linkdown
172.22.0.0/16 dev br-d98757f6ec13 proto kernel scope link src 172.22.0.1 linkdown
172.23.0.0/16 dev br-31a7baed5ea8 proto kernel scope link src 172.23.0.1 linkdown
172.24.0.0/16 dev br-5eb8065eddaf proto kernel scope link src 172.24.0.1
172.25.0.0/16 dev br-843380b00d30 proto kernel scope link src 172.25.0.1 linkdown
Huh. And all of those linkdown indicators appear both in the first ten seconds and after it? Thatâs the only oddity that I can identify in that report.
As far as I can tell, the problem isnât in your setup, itâs upstream of you. Maybe at 172.20.0.1, maybe upstream of that address. I assume you donât own the router at that address; maybe the owner/operator of it would be willing to troubleshoot the problem with you?
I can finally easily reproduce the error. This only happens on the particular network mentioned above, and only when using Linux.
The internet connection drops reliably after opening the Pycharm IDE. It will not recover from this - restarting NetworkManager makes the connection work for ~10 seconds, but the issue is fully resolved only after rebooting the machine.
As soon as I open Pycharm the internet connection reliably breaks every single time.
This does not seem to be an upstream issue after all, but a weird problem between Fedora, this connection and Pycharm.
I will further go in this direction and contact Pycharm/Jetbrains support on this matter, but given the obscurity of this I donât expect much from them.
Either way I will update this thread for reference for poor people experiencing the same issue (unlikely, but possible )
Found the solution without contacting Pycharm support after all.
The issue was also not Pycharm-specific per se.
Problem
Pycharm triggers the Docker daemon after init if the Docker plugin is set up.
The Docker daemon creates network bridges automatically, starting with 172.0.x.x, until it hits an âavailableâ range. Unfortunately, Docker doesnât check if these ranges are used by any physical networks. In my case Docker always hit 172.20.x.x, which is the actual IP range of the network in use. This made all internet traffic route to the Docker bridge instead of the internet - hence the connectivity issues. Why it works for 10 seconds - no clue, probably some kind of race condition.
Solution
Remove the (docker bridge) network shown with
ip route show | grep 172.20
In my case this showed
172.20.0.0/16 dev br-cc5389a2bb89 proto kernel scope link src 172.20.0.1 linkdown
hence I ran the following to remove the bridge from Docker:
docker network rm cc5389a2bb89
Then I configured Docker to not use 172.20.x.x anymore:
Nice detective work!