maan81 did a pretty good job isolating this issue to the route table:
- Testing with the installation disk eliminated all hardware as a cause - smart start.
- Connecting to the wireless router validated the wlan0 connection configuration.
Two very savvy steps. So why can you connect to the wireless router but no traffic bound for Internet can?
The problem becomes apparent in maan81's route table:
$ ip route show
default via 192.168.1.1 dev br0 proto static metric 100 linkdown
default via 192.168.0.1 dev wlan0 proto dhcp metric 600
169.254.0.0/16 dev wlan0 scope link metric 1000
192.168.0.0/24 dev wlan0 proto kernel scope link src 192.168.0.109 metric 600
192.168.1.0/24 dev br0 proto kernel scope link src 192.168.1.162 linkdown
192.168.122.0/24 dev virbr0 proto kernel scope link src 192.168.122.1 linkdown
The route via br0 (which goes nowhere because it is in a linkdown state) has a lower metric (100) than the wlan0 route (600). This means it wins all the traffic except that bound for the 192.168.0.1 subnet. There is an interface directly on that subnet so default routing does not apply to that traffic.
Who's in charge here?
First step you should take is determine what network manager is in charge. In the vast majority of cases it will be NetworkManager.
Sadly, maan81 and I skipped this step assuming NetworkManager was running the show and were led a merry chase for two days as the bridge br0 kept popping back up with every reboot.
# Determine network renderer
netplan get renderer
If your renderer is NetworkManger you can skip down to Troubleshooting technigues.
If your renderer is networkd, then you are running netplan and all your issues are in /etc/netplan/*.yaml. Please refer to Canonical Netplan for complete documentation. If you intend to stick with netplan, some of what follows may be useful but netplan is too big a subject to be handled in the scope of this answer.
maan81 was indeed running netplan and opted to revert to NetworkManager.
Revert from netplan to NetworkManager
The following is performed as root. The cat...EOF command must be executed as a contiguous block. Mind you don't mess up the indentations on the .yaml file - netplan is picky about such things.
mkdir /etc/netplan/old
mv /etc/netplan/*.yaml /etc/netplan/old
cat << 'EOF' > /etc/netplan/01-network-manager-all.yaml
# Let NetworkManager manage all devices on this system
network:
version: 2
renderer: NetworkManager
EOF
netplan generate && netplan apply && shutdown -r now
This is what ultimately resolved maan81's network issues. What follows are some of the "tools" we used to arrive at this solution.
Troubleshooting
Backing up your route table:
# Backup the route table
sudo ip route save > route.bin
# Recover the route table
sudo ip route restore < route.bin
Bridge manipulation:
# take bridge br0 down
sudo ip link set br0 down
# bring up bridge br0
sudo ip link set br0 up
# delete bridge br0 (requires bridge-utils)
sudo ip link set br0 down && sudo brctl delbr br0
Change connection metric
# list connections
nmcli connection
# list devices
nmcli device
# set connection metric # requires link dn/up to take effect
nmcli connection modify <name> ipv4.route-metric <metric>
Brute force overwrite of default route
# Delete the default routes
sudo ip route del default
# Recreate new route to wireless router IP
sudo ip route add default via 192.168.0.1 metric 50
Summary:
In the professional world, running multiple default routes is considered very bad practice. After all, "multiple" and "default" are contradictory concepts.
For user desktops, NetworkManager handles this automatically for you but does not always get it right. If you have more than one active network interface, it will create multiple default routes. When that happens, the metric determines where your Internet traffic flows.
