1

I am not sure ... but as I updated Ubuntu 22.04 & its kernel & restarted, I am being blocked from accessing the internet; though I am connected & can access & login the router's admin pages.

My smartphone which is in the same wifi has no problems.

Anything happened when updating that blocked the laptop ?

Update

I am not using Ethernet as I do not have the Ethernet cable right now, so I cannot comment on it at the moment.

My wifi chip based upon the command :

$ lspci -knn | grep Net -A2
02:00.0 Network controller [0280]: Intel Corporation Wireless 7260 [8086:02b1] (rev 73)
    Subsystem: Intel Corporation Wireless-N 7260 [8086:4462]
    Kernel driver in use: iwlwifi

Update 2

With$ ping 8.8.4.4 I get Destination Host Unreachable :

$ping 8.8.4.4
PING 8.8.4.4 (8.8.4.4) 56(84) bytes of data.
From 192.168.1.162 icmp_seq=1 Destination Host Unreachable
From 192.168.1.162 icmp_seq=2 Destination Host Unreachable
From 192.168.1.162 icmp_seq=3 Destination Host Unreachable

I see packets transmitted when tethering.

Also, when with tethering :

$ ip route show
default via 192.168.1.1 dev br0 proto static metric 100 linkdown 
default via 192.168.42.129 dev usb0 proto dhcp metric 100 
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.42.0/24 dev usb0 proto kernel scope link src 192.168.42.167 metric 100 
192.168.122.0/24 dev virbr0 proto kernel scope link src 192.168.122.1 linkdown

$ dig google.com
; <<>> DiG 9.18.1-1ubuntu1.2-Ubuntu <<>> google.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 13107
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1


;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;google.com.            IN  A


;; ANSWER SECTION:
google.com.     285 IN  A   142.250.196.46


;; Query time: 4 msec
;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP)
;; WHEN: Wed Nov 23 17:04:43 +0545 2022
;; MSG SIZE  rcvd: 55

And with Wifi only :

$ 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

$ dig google.com
; <<>> DiG 9.18.1-1ubuntu1.2-Ubuntu <<>> google.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 45316
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1


;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;google.com.            IN  A


;; ANSWER SECTION:
google.com.     102 IN  A   142.250.196.46


;; Query time: 0 msec
;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP)
;; WHEN: Wed Nov 23 17:12:16 +0545 2022
;; MSG SIZE  rcvd: 55

I see there is a slight difference in ip route show.

It seems the packets are not able to get past the gateway when using wifi (?) .

Update 3

Wifi works fine when using a live cd.

When booting normally, I cannot access the net using mobile hotspot wireless alone.

Something wrong with the wireless settings of current Ubuntu ?

Update 4

I think VirtualBox had installed the bridge, and I use VirtualBox regularly.

maan81
  • 657
  • 1
  • 8
  • 26

1 Answers1

5

maan81 did a pretty good job isolating this issue to the route table:

  1. Testing with the installation disk eliminated all hardware as a cause - smart start.
  2. 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.

Frobozz
  • 719