Serious network problem with Xubuntu 24.04.4

[cjsmall]

Quick Summary:

About 6-8 weeks ago, I started experiencing random, intermittent, network connection problems on my primary machine running Xubuntu 24.04.4 LTS (fully patched). Prior to that there were no network issues. I'm unsure whether an automatic software update is responsible, but when I ping a site, for example the Google DNS server (8.8.8.8), I can do this for a while with no problem and then I will start having problems reported as either:

ERROR: unknown host: 8.8.8.8
ERROR: host unreachable: 8.8.8.8

The first message seems to indicate a DNS problem while the second indicates a network failure after DNS lookup.

Many programs experience the underlying problem. A periodic fetchmail frequently reports "Network is unreachable." and the Firefox browser runs into the problem frequently with all sorts of sites, reporting "Unable to connect. Firefox can't establish a connection to the server at ...". A retry to connect may or may not work immediately, but eventually the connection is made, so the interruption is always temporary.

The Details:

I have two machines running Ubuntu 24.04.4 that are wired up to my LAN identically, going through two 2.5 Gb switches to my cable modem with 2+ Gb network connection (Comcast/Xfinity). I mention this because the Asus laptop with a minimal desktop Xubuntu installation does not exhibit any of these network problems no matter how much I stress it, while my recently built primary desktop machine had Ubuntu 24.04.3 server edition installed and then had all the xfce4 packages added and patches to bring it up to Xubuntu 24.04.4. There were no problems until recently. I switched the network cable from the box to the first link and tried different link ports, with no improvement. I also ran a cable directly from the desktop LAN port to the cable modem and the problem continued. The point being that I've ruled out the cable and link infrastructure as a source of the problem.

One difference between the two machines is that the laptop is using NetworkManager while the desktop is using netplan, although no network changes have been made since the initial OS installation months ago.

On the laptop:

# cat /etc/netplan/01-network-manager-all.yaml
# Let NetworkManager manage all devices on this system
network:
version: 2
renderer: NetworkManager

On the desktop:

# cat /etc/netplan/50-cloud-init.yaml
network:
version: 2
ethernets:
eno2np1:
addresses:
- "10.10.10.5/24"
nameservers:
addresses:
- 8.8.8.8
- 8.8.4.4
- 68.87.85.98
search: []
routes:
- to: "default"
via: "10.10.10.1"
eno3np0:
addresses:
- "10.10.10.101/24"
bridges:
br0:
dhcp4: no
interfaces:
- eno3np0
addresses:
- "10.10.10.101/24"

I started running traceroute to monitor the problem. Here are some typical runs:

# traceroute -I 8.8.8.8
traceroute to dns1 (8.8.8.8), 30 hops max, 60 byte packets
1 * * *
2 10.60.128.74 (10.60.128.74) 15.541 ms 16.265 ms 16.503 ms
3 po-59-rur301.bellevue.wa.seattle.comcast.net (68.86.97.221) 15.257 ms 15.748 ms 16.001 ms
4 po-2-rur302.bellevue.wa.seattle.comcast.net (69.139.161.118) 15.293 ms 23.264 ms 23.527 ms
5 po-300-xar02.bellevue.wa.seattle.comcast.net (68.86.96.157) 23.337 ms 23.382 ms 23.452 ms
6 be-300-arsc1.seattle.wa.seattle.comcast.net (24.124.128.89) 25.065 ms 9.915 ms 10.001 ms
7 * * be-36131-cs03.seattle.wa.ibone.comcast.net (68.86.93.9) 18.210 ms
8 be-2311-pe11.seattle.wa.ibone.comcast.net (96.110.32.234) 19.345 ms 19.412 ms 12.947 ms
9 * * *
10 142.251.229.135 (142.251.229.135) 20.564 ms 19.183 ms 19.208 ms
11 142.251.50.243 (142.251.50.243) 17.435 ms 8.547 ms 7.155 ms
12 dns1 (8.8.8.8) 12.729 ms 12.475 ms 14.468 ms

OK. I get many successful runs with the route varying, but ultimately reaching the Google DNS server.

# traceroute -I 8.8.8.8
traceroute 8.8.8.8
traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
1 router (10.10.10.1) 7.004 ms 7.019 ms 7.010 ms
2 10.60.128.74 (10.60.128.74) 17.428 ms 10.60.128.75 (10.60.128.75) 17.367 ms 17.307 ms
3 po-59-rur301.bellevue.wa.seattle.comcast.net (68.86.97.221) 17.334 ms po-59-rur302.bellevue.wa.seattle.comcast.net (68.86.113.49) 17.342 ms po-59-rur301.bellevue.wa.seattle.comcast.net (68.86.97.221) 17.441 ms
4 po-300-xar02.bellevue.wa.seattle.comcast.net (68.86.96.157) 26.412 ms 26.539 ms po-2-rur302.bellevue.wa.seattle.comcast.net (69.139.161.118) 17.229 ms
5 po-300-xar02.bellevue.wa.seattle.comcast.net (68.86.96.157) 26.679 ms 26.919 ms 26.790 ms
6 be-300-arsc1.seattle.wa.seattle.comcast.net (24.124.128.89) 28.248 ms * 20.988 ms
7 be-2311-pe11.seattle.wa.ibone.comcast.net (96.110.32.234) 20.659 ms * be-36121-cs02.seattle.wa.ibone.comcast.net (68.86.93.5) 10.571 ms
8 * be-2412-pe12.seattle.wa.ibone.comcast.net (96.110.34.142) 18.732 ms *
9 * * 192.178.105.141 (192.178.105.141) 12.144 ms
10 dns1 (8.8.8.8) 20.175 ms 192.178.105.141 (192.178.105.141) 21.594 ms 108.170.255.179 (108.170.255.179) 21.473 ms

Another successful one using the -I switch.

# traceroute -I 8.8.8.8
traceroute -I 8.8.8.8

connect: Permission denied

And a failed one.

% traceroute 8.8.8.8
traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
connect: Permission denied

And another.

traceroute 8.8.8.8
traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
1 router (10.10.10.1) 1.788 ms * *
2 10.60.128.74 (10.60.128.74) 13.039 ms 19.790 ms 20.026 ms
3 po-59-rur302.bellevue.wa.seattle.comcast.net (68.86.113.49) 19.860 ms po-59-rur301.bellevue.wa.seattle.comcast.net (68.86.97.221) 20.052 ms 19.910 ms
4 po-300-xar02.bellevue.wa.seattle.comcast.net (68.86.96.157) 19.965 ms po-2-rur302.bellevue.wa.seattle.comcast.net (69.139.161.118) 19.827 ms 19.861 ms
5 be-300-arsc1.seattle.wa.seattle.comcast.net (24.124.128.89) 21.550 ms 21.394 ms po-300-xar02.bellevue.wa.seattle.comcast.net (68.86.96.157) 19.899 ms
6 be-36111-cs01.seattle.wa.ibone.comcast.net (68.86.93.1) 21.384 ms be-36131-cs03.seattle.wa.ibone.comcast.net (68.86.93.9) 19.659 ms be-300-arsc1.seattle.wa.seattle.comcast.net (24.124.128.89) 12.720 ms
7 be-36121-cs02.seattle.wa.ibone.comcast.net (68.86.93.5) 12.614 ms
connect: Permission denied

Got a bit further here.

# traceroute -T 8.8.8.8
traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
1 router (10.10.10.1) 1.896 ms 2.233 ms 2.343 ms
2 10.60.128.74 (10.60.128.74) 16.115 ms 16.142 ms 16.144 ms
3 po-59-rur301.bellevue.wa.seattle.comcast.net (68.86.97.221) 16.025 ms po-59-rur302.bellevue.wa.seattle.comcast.net (68.86.113.49) 16.018 ms 16.055 ms
4 po-2-rur302.bellevue.wa.seattle.comcast.net (69.139.161.118) 16.034 ms * *
5 be-300-arsc1.seattle.wa.seattle.comcast.net (24.124.128.89) 26.857 ms 26.942 ms po-300-xar02.bellevue.wa.seattle.comcast.net (68.86.96.157) 25.476 ms
6 be-300-arsc1.seattle.wa.seattle.comcast.net (24.124.128.89) 26.937 ms * *
7 be-2412-pe12.seattle.wa.ibone.comcast.net (96.110.34.142) 29.945 ms be-36131-cs03.seattle.wa.ibone.comcast.net (68.86.93.9) 16.345 ms *
8 be-2212-pe12.seattle.wa.ibone.comcast.net (96.110.34.134) 16.184 ms * *
9 * * *
10 * * *
11 * * *
12 * * *
13 * * *
14 * * *
15 * * *
16 * * *
17 * * *
18 * * *
19 * * *
20 * * *
21 * * *
22 * * *
23 * * *
24 * * *
25 * * *
26 * * *
27 * * *
28 * * *
29 * * *
30 * * *

Timed out on this one.

So my question is whether this could still be a local problem or does it look like something going wrong on the Comcast WAN. I replaced the cable modem with no improvement, and a reliable Comcast technician has checked the service to my cable modem and says that it looks good. This, and the fact that the laptop never shows any network problem leads me back to the desktop software and/or configuration.

Sorry for all the information, but I wanted to share what I had done so far. Any insights into the possible problem or suggestions of additional test to run would be greatly appreciated.

Regards.

 

[osprey]

Quick Summary:



I have two machines running Ubuntu 24.04.4 that are wired up to my LAN identically, going through two 2.5 Gb switches to my cable modem with 2+ Gb network connection (Comcast/Xfinity). I mention this because the Asus laptop with a minimal desktop Xubuntu installation does not exhibit any of these network problems no matter how much I stress it, while my recently built primary desktop machine had Ubuntu 24.04.3 server edition installed and then had all the xfce4 packages added and patches to bring it up to Xubuntu 24.04.4. There were no problems until recently. I switched the network cable from the box to the first link and tried different link ports, with no improvement. I also ran a cable directly from the desktop LAN port to the cable modem and the problem continued. The point being that I've ruled out the cable and link infrastructure as a source of the problem.

One difference between the two machines is that the laptop is using NetworkManager while the desktop is using netplan, although no network changes have been made since the initial OS installation months ago.

If the laptop works using NetworkManager, but the other two machines not using that software are the troublesome ones, a straight forward way of testing the software may be to replace network management on the two troublesome machines with NetworkManager, and ensure that the configurations are appropriate from the example of the working laptop. Maybe worth a try I'd think. These things are reversible.

 

[kibasnowpaw]

That # cat /etc/netplan/50-cloud-init.yaml looks wrong to me, or at least far more complicated than it needs to be unless you have a specific reason for doing it that way.

For a normal desktop setup, if your router is handling DHCP, DNS, and the default gateway, a netplan config can be very simple, for example:

network:
  version: 2
  renderer: NetworkManager
  ethernets:
    enp10s0:
      dhcp4: true

That is usually all you need on a normal home network. The router will hand out the IP address, gateway, and DNS settings automatically.

If you do not want to use the router’s DNS, then yes, you can set something like 8.8.8.8 manually, but personally I would rather do that on the router if possible so the whole network stays consistent instead of managing it per PC.

Besides that, the bigger problem is that you have two interfaces in the same 10.10.10.0/24 network on the same machine, and one of them is also part of a bridge. That is exactly the kind of setup that can create weird intermittent behavior, ARP confusion, asymmetric routing, and “works for a while until it doesn’t” problems.

This part especially looks wrong to me:

• eno3np0 has 10.10.10.101/24
• br0 also has 10.10.10.101/24
• br0 is built on eno3np0

If eno3np0 is enslaved to br0, the IP normally belongs on the bridge only, not on both. On top of that, you already have eno2np1 sitting in the same subnet with 10.10.10.5/24 and the default route. Unless you are doing policy routing on purpose, that is a messy setup.

A few other things stand out too:

unknown host: 8.8.8.8 is odd, because a literal IP address should not need DNS resolution in the first place.

connect: Permission denied from traceroute points more toward something local as well firewall, routing or policy issue, permissions/capabilities, or interface state not a normal WAN outage.

And the fact that the laptop on the same LAN stays stable under stress is another big sign that the desktop is the problem box, not Comcast.

If it were me, I would strip the desktop down to one active NIC, one address, one default route, and no bridge unless there is a real need for it, then test again from there.

Small side note to people so they know: the simple DHCP example above is fine for a normal desktop, but not every system should use it. If they actually need static addressing or bridging for a specific reason, then those parts are valid in principle. The main red flag is the duplicate addressing and same-subnet multi-interface setup, not just that the file is longer.

 

[cjsmall]

Sorry for the long delay in responding to this thread. I took all of the comments to heart and spent many days reading networking documents and trying a great number of different netplan and NetworkManager configurations with no success.

Eventually I returned to my netplan configuration and tweaked it a bit. This was the best overall performance I could get for the LAN, VM and WAN, but still producing many networking errors as I described above. I tried removing the nameservers section from the netplan config file, but that actually caused new problem. Ultimately, I added the same DNS servers to the netplan configuration that the Comcast router was using and this is what finally improved things. I started with the google before the Comcast DNS servers (8.8.8.8, 8.8.4.4, 75.75.75.75, 75.75.76.76) and things improved considerably but I was still seeing network errors. I reversed this and put Comcast first (75.75.75.75, 75.75.76.76, 8.8.8.8, 8.8.4.4) and this finally solved the problem.

Ever since netplan was introduced, I have no idea what is going on under the hood. The old DNS configuration files are now ignored and netplan is doing some hidden DNS magic. In any event, there must have been some conflict between the system and the router that was causing the problems. I still do not understand why the original configuration worked for many months and then started to act up. Possibly due to a software update to either the system or the router that changed behavior.

Thanks for all of the help. It got me moving in the right direction. For other who may end up reading this thread, I will include the current working netplan configuration file.

Regards.

network:
version: 2
renderer: networkd
ethernets:
eno2np1:
addresses:
- "10.10.10.5/24"
nameservers:
addresses:
- 75.75.75.75
- 75.75.76.76
- 8.8.8.8
- 8.8.4.4
routes:
- to: "default"
via: "10.10.10.1"
eno3np0:
addresses:
- "10.10.10.105/24"
bridges:
br0:
dhcp4: no
interfaces:
- eno3np0
addresses:
- "10.10.10.6/24"

 

[theLegionWithin]

So my question is whether this could still be a local problem or does it look like something going wrong on the Comcast WAN. I replaced the cable modem with no improvement, and a reliable Comcast technician has checked the service to my cable modem and says that it looks good. This, and the fact that the laptop never shows any network problem leads me back to the desktop software and/or configuration.

it's got to be a Comcast issue - I'm in the area and experienced similar issues where the traceroute times out after 8 hops:

traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
 1  _gateway (192.168.50.1)  0.492 ms  0.480 ms  0.524 ms
 2  100.93.165.195 (100.93.165.195)  12.066 ms 100.93.165.194 (100.93.165.194)  12.033 ms 100.93.165.195 (100.93.165.195)  12.320 ms
 3  po-318-333-rur301.burien.wa.seattle.comcast.net (68.87.205.121)  11.778 ms po-318-334-rur302.burien.wa.seattle.comcast.net (68.87.206.157)  11.969 ms po-318-333-rur301.burien.wa.seattle.comcast.net (68.87.205.121)  11.790 ms
 4  po-2-rur301.burien.wa.seattle.comcast.net (24.124.128.9)  17.970 ms po-300-xar01.burien.wa.seattle.comcast.net (69.139.164.5)  18.002 ms  18.098 ms
 5  be-302-arsc1.burien.wa.seattle.comcast.net (24.124.128.110)  18.637 ms po-300-xar01.burien.wa.seattle.comcast.net (69.139.164.5)  18.120 ms  18.548 ms
 6  be-302-arsc1.burien.wa.seattle.comcast.net (24.124.128.110)  18.886 ms  17.227 ms  17.217 ms
 7  be-36131-cs03.portland.or.ibone.comcast.net (68.86.94.137)  18.883 ms be-36111-cs01.portland.or.ibone.comcast.net (68.86.94.129)  14.864 ms be-36141-cs04.portland.or.ibone.comcast.net (68.86.94.141)  19.673 ms
 8  be-2411-pe11.seattle.wa.ibone.comcast.net (96.110.32.238)  21.931 ms * *
 9  * * *
10  * * *
11  * * *
12  * * *
13  * * *
14  * * *
15  * * *
16  * * *
17  * * *
18  * * *
19  * * *
20  * * *
21  * * *
22  * * *
23  * * *
24  * * *
25  * * *
26  * * *
27  * * *
28  * * *
29  * * *
30  * * *

 

[cjsmall]

Regarding traceroute:

Right now, for me, a standard traceroute is working reliably and very quickly (unlike what I originally reported), while a traceroute -T is still reporting as theLegionWithin reports.

# traceroute 8.8.8.8
traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
1 router (10.10.10.1) 8.988 ms 8.909 ms 8.938 ms
2 10.60.128.75 (10.60.128.75) 15.949 ms 10.60.128.74 (10.60.128.74) 15.662 ms 15.702 ms
3 po-59-rur301.bellevue.wa.seattle.comcast.net (68.86.97.221) 15.738 ms 15.860 ms po-59-rur302.bellevue.wa.seattle.comcast.net (68.86.113.49) 15.495 ms
4 po-300-xar02.bellevue.wa.seattle.comcast.net (68.86.96.157) 22.334 ms po-2-rur302.bellevue.wa.seattle.comcast.net (69.139.161.118) 15.576 ms 22.276 ms
5 po-300-xar02.bellevue.wa.seattle.comcast.net (68.86.96.157) 22.333 ms be-300-arsc1.seattle.wa.seattle.comcast.net (24.124.128.89) 23.913 ms po-300-xar02.bellevue.wa.seattle.comcast.net (68.86.96.157) 22.345 ms
6 be-300-arsc1.seattle.wa.seattle.comcast.net (24.124.128.89) 23.689 ms * 14.973 ms
7 * * be-36131-cs03.seattle.wa.ibone.comcast.net (68.86.93.9) 15.125 ms
8 be-2311-pe11.seattle.wa.ibone.comcast.net (96.110.32.234) 14.999 ms * *
9 * * *
10 dns1 (8.8.8.8) 15.248 ms * 192.178.105.141 (192.178.105.141) 15.605 ms

# sudo traceroute -T 8.8.8.8
traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
1 router (10.10.10.1) 2.359 ms 2.766 ms 3.173 ms
2 10.60.128.74 (10.60.128.74) 13.815 ms 10.60.128.75 (10.60.128.75) 13.392 ms 10.60.128.74 (10.60.128.74) 13.798 ms
3 po-59-rur301.bellevue.wa.seattle.comcast.net (68.86.97.221) 13.353 ms po-59-rur302.bellevue.wa.seattle.comcast.net (68.86.113.49) 13.356 ms *
4 po-300-xar02.bellevue.wa.seattle.comcast.net (68.86.96.157) 22.550 ms * *
5 po-300-xar02.bellevue.wa.seattle.comcast.net (68.86.96.157) 22.843 ms * *
6 * be-300-arsc1.seattle.wa.seattle.comcast.net (24.124.128.89) 13.545 ms 13.185 ms
7 * * be-36121-cs02.seattle.wa.ibone.comcast.net (68.86.93.5) 18.103 ms
8 * be-2112-pe12.seattle.wa.ibone.comcast.net (96.110.34.130) 13.409 ms be-2312-pe12.seattle.wa.ibone.comcast.net (96.110.34.138) 16.027 ms
9 * * *
10 * * *
11 * * *
12 * * *
13 * * *
14 * * *
15 * * *
16 * * *
17 * * *
18 * * *
19 * * *
20 * * *
21 * * *
22 * * *
23 * * *
24 * * *
25 * * *
26 * * *
27 * * *
28 * * *
29 * * *
30 * * *

Maybe someone with more networking experience can comment on the implication of using the -T option. From the manual:

-T, --tcp Use TCP SYN for probes

 

[dos2unix]

That connect: Permission denied error is your biggest clue — and it's not a network error. That's a socket/capability permission failure. The fact that it's intermittent and appears mid-session rules out a simple misconfiguration. Something is changing at runtime.
First thing I'd check is AppArmor. Ubuntu 24.04 has been tightening profiles via automatic updates, and a new or more restrictive profile could be blocking raw socket access intermittently. Pull the logs and see:

sudo dmesg | grep -i apparmor
sudo journalctl -k | grep -i apparmor | tail -50

Second thing — look at that 50-cloud-init.yaml. The cloud-init filename is a tell; that config was auto-generated for a server role and it's got two interfaces, a bridge, and static routes all tangled together. With systemd-networkd as the backend, routing table state can get weird after a suspend/resume cycle or after certain daemon restarts. During one of the failure windows, run:

ip route show
ip rule show
networkctl status

Watch for duplicate default routes or orphaned routing rules.
But the most interesting thing in your whole writeup is the laptop vs. desktop asymmetry. The laptop runs NetworkManager. The desktop runs systemd-networkd — Netplan's default for server installs. NetworkManager handles link flaps, lease renewals, and routing changes much more gracefully in a desktop environment. Your desktop got its Netplan config from a server install and was never updated to reflect that it's actually being used as a workstation.
Switching the desktop renderer to NetworkManager — same as the laptop — is worth trying before you go any deeper down the diagnostics rabbit hole. It's a one-line change in the Netplan YAML and it may save you a lot of time.

 

[cjsmall]

dos2unix: I may play with this some more in the future, but I actually did a lot of testing with render:NetworkManager in the netplan file and then a lot of screwing around with the configuration in /etc/network/interfaces. The results were not good, however I do not think I tried it with the Comcast DNS servers listed before the Google ones so I may try that out. In general, the network configuration looked identical regardless of which approach was taken.

After making these sorts of NetworkManager changes, I reconfigure the network with netplan apply and check it with netplan status --all. It seems to work. Is there anything else missing from these steps?

As for why the server install, this was a new system build and although I had done this successfully in the past with my last desktop system, somewhere along the way the geniuses at Ubuntu decided to hide the ability to set up a mirror during a desktop install. I needed to mirror the root partition which is difficult after an install, so I reverted to the server installation in order to be able to mirror my partitions and then installed the xfce4 components on top of this. I'm constantly frustrated when people keep "simplifying" everything and taking away features rather than making them options. This is especially true as the same partition manager used in the server install is actually running behind the scene on the desktop install!

 

[GatorsFan]

Comcast/Xfinity is doing network upgrades and has been for about a year - expecially Multi-GBs lines which require a new DOCSIS 3.1 Mid/High-Split Cable Modem for cable plans to 2.5Gbps
I was having wierd things happening until I upgraded my modem when Mediacom did their upgrades this solved my issues
I bought a NETGEAR Nighthawk DOCSIS 3.1 Mid/high-Split Cable Modem CM3000 which was $299 on Amazon

 

[cjsmall]

Yes, I also upgraded my modem through Comcast to support 2+GB service and then tried a replacement modem as well. Unfortunately, the problems began prior to the modem upgrade/replacement and the new modems did not really address the problem I was seeing. I also thought this was likely a Comcast network issue, but finally ruled that out as other machines were not experiencing the same problem.

 

[Trml]

# sudo traceroute -T 8.8.8.8

I'd say this does time out simply because the DNS server has no business with a TCP SYN unless you specify the DNS port . Simply choose a regular host, e.g. traceroute -T linux.org or add the port, i.e. traceroute -T 8.8.8.8 -p 53.

 

[cjsmall]

Trml: Thanks for the explanation. Yes, that works fine. As I said, I'm no networking guy and a lot of this is something with which I really have no experience. Regards.