3

After upgrading from 20.04 to 22.04.1, I have no network access either via ethernet or wifi.

I can bring both interfaces up via command line or gui and they show as connected and also pick up an ip address over dhcp.

However, I can't ping anything (by address) - not even the loopback address.

The firewall is disabled. The routing table matches one of my other machines which is working fine.

Any ideas to debug this one gratefully received!

Possibly related to Broken network configuration after upgrade to 22.04

Network Manager Status

● NetworkManager.service - Network Manager
     Loaded: loaded (/lib/systemd/system/NetworkManager.service; enabled; vendor preset: enabled)
     Active: active (running) since Wed 2022-08-17 18:30:16 BST; 1 day 19h ago
       Docs: man:NetworkManager(8)
   Main PID: 1582 (NetworkManager)
      Tasks: 3 (limit: 16572)
     Memory: 11.3M
        CPU: 5.092s
     CGroup: /system.slice/NetworkManager.service
             └─1582 /usr/sbin/NetworkManager --no-daemon

Aug 19 13:54:43 deepthought NetworkManager[1582]: <info> [1660913683.8481] dhcp4 (enp34s0): activation: beginning transaction (timeout in 45 seconds) Aug 19 13:54:43 deepthought NetworkManager[1582]: <info> [1660913683.8654] dhcp4 (enp34s0): state changed new lease, address=192.168.0.225 Aug 19 13:54:43 deepthought NetworkManager[1582]: <info> [1660913683.8679] device (enp34s0): state change: ip-config -> ip-check (reason 'none', sys-iface-state: 'managed') Aug 19 13:54:43 deepthought NetworkManager[1582]: <info> [1660913683.9135] device (enp34s0): state change: ip-check -> secondaries (reason 'none', sys-iface-state: 'managed') Aug 19 13:54:43 deepthought NetworkManager[1582]: <info> [1660913683.9140] device (enp34s0): state change: secondaries -> activated (reason 'none', sys-iface-state: 'managed') Aug 19 13:54:43 deepthought NetworkManager[1582]: <info> [1660913683.9146] manager: NetworkManager state is now CONNECTED_LOCAL Aug 19 13:54:43 deepthought NetworkManager[1582]: <info> [1660913683.9150] manager: NetworkManager state is now CONNECTED_SITE Aug 19 13:54:43 deepthought NetworkManager[1582]: <info> [1660913683.9151] policy: set 'netplan-enp34s0' (enp34s0) as default for IPv4 routing and DNS Aug 19 13:54:43 deepthought NetworkManager[1582]: <info> [1660913683.9158] device (enp34s0): Activation: successful, device activated. Aug 19 13:54:53 deepthought NetworkManager[1582]: <info> [1660913693.3834] agent-manager: agent[438527325db3dfb9,:1.82/org.gnome.Shell.NetworkAgent/1000]: agent registered

resolved

systemd-resolved also looks unhappy although I'm way off being able to use names right now.

● systemd-resolved.service - Network Name Resolution
     Loaded: loaded (/lib/systemd/system/systemd-resolved.service; enabled; vendor preset: enabled)
     Active: active (running) since Wed 2022-08-17 18:30:15 BST; 1 day 19h 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: 1278 (systemd-resolve)
     Status: "Processing requests..."
      Tasks: 1 (limit: 16572)
     Memory: 9.4M
        CPU: 517ms
     CGroup: /system.slice/systemd-resolved.service
             └─1278 /lib/systemd/systemd-resolved

Aug 19 14:19:16 deepthought systemd-resolved[1278]: Using degraded feature set UDP instead of TCP for DNS server 192.168.0.2. Aug 19 14:19:26 deepthought systemd-resolved[1278]: Using degraded feature set TCP instead of UDP for DNS server 192.168.0.2. Aug 19 14:19:57 deepthought systemd-resolved[1278]: Using degraded feature set UDP instead of TCP for DNS server 192.168.0.2. Aug 19 14:20:08 deepthought systemd-resolved[1278]: Using degraded feature set TCP instead of UDP for DNS server 192.168.0.2. Aug 19 14:23:35 deepthought systemd-resolved[1278]: Using degraded feature set UDP instead of TCP for DNS server 192.168.0.2. Aug 19 14:23:45 deepthought systemd-resolved[1278]: Using degraded feature set TCP instead of UDP for DNS server 192.168.0.2. Aug 19 14:24:16 deepthought systemd-resolved[1278]: Using degraded feature set UDP instead of TCP for DNS server 192.168.0.2. Aug 19 14:24:26 deepthought systemd-resolved[1278]: Using degraded feature set TCP instead of UDP for DNS server 192.168.0.2. Aug 19 14:24:57 deepthought systemd-resolved[1278]: Using degraded feature set UDP instead of TCP for DNS server 192.168.0.2. Aug 19 14:25:08 deepthought systemd-resolved[1278]: Using degraded feature set TCP instead of UDP for DNS server 192.168.0.2.

meatballs
  • 131

2 Answers2

3

I spent one day one this, tried many methods. Finally, I found it was due to the firewall. I disabled the firewall, it connected to the internet right after.
But, I haven't figure out which parts in the firewall setting caused this.

sudo ufw disable

----------------

The problem I had: After upgrade from 20.04 to 22.04, the ethernet connection doesn't have internet!

  1. ping 127.0.0.1 not work, 100% loss
  2. ping 192.168.68.1 router, not work, 100% loss
  3. but the local network work, other devices can access the net-shared harddrives
  4. I can ssh to the pc from other device, and even from outside the home network openvpn works from outside the home network
  • Worked for me too! I am on a VirtualBox guest (macOS as host), just upgraded from 20.x to 22.04.1. Disabling ufw did the trick, maybe the problem is relics from previous iptables config (ufw is a wrapper of iptables). – zakmck Sep 06 '22 at 15:31
  • Worked for me as well, thank you. I will try to find what the problem with the firewall was – zpontikas Oct 21 '22 at 21:27
  • OK so after disabling firewall, i went and continued with the updated from Software Updater. After they were all finished I turned ufw back on and it was working OK. So I guess some updates were missing. – zpontikas Oct 21 '22 at 21:37
  • Worked for me as well! Thank you so much :) – Bartosz Petryński Nov 04 '22 at 15:34
0

Following Jie Geng option with ufw, found the real issue

There is a conflict between netfilter-persistent package and ufw.

You must remove netfilter-persistent

sudo apt purge netfilter-persistent

And then reboot the system.

You won't need to stop the ufw service if you do this.

In fact, when you run the ufw check requirements testing script, you will find that it will be saying that netfilter-persistent could be conflicting. Idea found in Launchpad bug tracker.

sudo /usr/share/ufw/check-requirements

SirLouen
  • 31
  • 4