Join Log in
Score:0
avatar Ubuntu

DNS and/or routing broken on one machine after subnet change in LAN

cn flag
Tim Richardson

I reconfigured my home router to use 192.168.39.0 as the subnet. Previously it was 192.168.0.0

I have one Ubuntu 22.04 machine which now has broken DNS and/or routing. I have eliminated hardware problems (no problem booting it from an ubuntu 22.04 on external drive). Everything else on the network is fine, including this ubuntu 22.10 laptop.

This problem machine has two wired interfaces and wifi. All connect to the LAN, but DNS is broken for all of them. Pinging works, e.g. ping 8.8.8.8 works, but there is a long delay (>2s) for the first ping.

There are severe routing problems. For instance, trying to reach another host:

# ping archimedes.local
PING archimedes.local (192.168.39.37) ....
From 192.168.39.1 icmp_seq=1 Destination Host Unreachable

and yet

ping 192.168.39.37

works

I can not ssh to any machine: I get a password prompt, but the password is not delivered correctly.

ping 8.8.8.8 works, ping google.com fails (Name or service not known).

resolvectl status

gives identical results comparing the broken Ubuntu with my working laptop.

/etc/resolv.conf is also identical.

I can not ssh into the problem host from my laptop either.

I have set DHCP on, not a fixed IP lease. It gets an IP address just fine.

on a working machine, tracepath looks like this:

root@yellow:/home/tim# tracepath 8.8.8.8
 1?: [LOCALHOST]                      pmtu 1500
 1:  ipfire.rumahtumi                                      8.979ms 
 1:  ipfire.rumahtumi                                      3.329ms 
 2:  loop119171560.bng.mel.aussiebb.net                   12.075ms 
 3:  ???                                                  13.824ms asymm  5 
 4:  10.241.4.142                                         20.187ms 
 5:  10.241.4.147                                         15.787ms asymm  3 
 6:  142.250.165.14                                       14.676ms asymm  5

ipfire.rumahtumi is the router

On the broken machine, line 1 is the same, but the following lines are

no reply

there is no reference to ipfire.rumahtumi

#route -n

shows the correct Gateway.

EDIT. more output from the problem machine:

route -n and resolvectl status

root@indigo:/home/tim# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.39.1    0.0.0.0         UG    20100  0        0 eth1
169.254.0.0     0.0.0.0         255.255.0.0     U     1000   0        0 virbr1
172.17.0.0      0.0.0.0         255.255.0.0     U     0      0        0 docker0
192.168.39.0    0.0.0.0         255.255.255.0   U     0      0        0 virbr1
192.168.39.0    0.0.0.0         255.255.255.0   U     100    0        0 eth1
192.168.122.0   0.0.0.0         255.255.255.0   U     0      0        0 virbr0



root@indigo:/home/tim# resolvectl status
Global
       Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
resolv.conf mode: stub

Link 2 (eth2)
Current Scopes: none
     Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported

Link 3 (eth1)
    Current Scopes: DNS
         Protocols: +DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
Current DNS Server: 192.168.39.1
       DNS Servers: 192.168.39.1
        DNS Domain: rumahtumi

Link 4 (wlp6s0)
Current Scopes: none
     Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported

Link 5 (virbr1)
Current Scopes: none
     Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported

Link 6 (virbr0)
Current Scopes: none
     Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported

Link 8 (docker0)
Current Scopes: none
     Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
root@indigo:/home/tim#

Solution and explanation

I doing that, I noticed in the routing table that virbr1 looks a bit odd.

I deleted that device and connectivity is restored. However, it keeps restoring each boot.

... and I found the reason. I had minikube installed. It created a bridge which is automatically started at boot. It choose 192.168.39.0 as its subnet. Just dumb bad luck.

that was in /etc/libvirt/qemu/networks/autostart The subnet can be edited with virsh net-edit mk-minikube

54
0 + 6
dns
ru flag
Thomas Ward
Can you *include* the `resolvectl status` output? It sounds like something got set somewhere or the DHCP options on your router are mis-set.
0
Reply
cn flag
Tim Richardson
yes, will do. Copy and paste is a bit a of pain since the machine in question is isolated ...
0
Reply
cn flag
Tim Richardson
ok, some more output added.
0
Reply
ru flag
Thomas Ward
Just to check, but does `dig` exist on your system? Like `dig +short @192.168.39.91 google.com` or does your system say it doesn't exist? Asking because if it does exist and it gives output then we need to start looking into potentially changing your DNS setup for making DNS work.
0
Reply
ru flag
Thomas Ward
Additionally, if you have a bridge set up (virbr1 is still present!) it could be affecting things as well
1
Reply
cn flag
Tim Richardson
I found the problem: virtual bridge device virbr1 was causing routing failure. [Our comments overlapped... you saw that immediately, it took me much longer]
0
Reply
ธงชาติไทย
Elon Musk
I sit in a Tesla and translated this thread with Ai:

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.