Another lost connection

I’m now working on my second unconnectable desktop. Both connected by cable only, no wi-fi. Both connect from Ubuntu. On this one I have the good fortune to have a working Leap 15.2 to compare with.
15.2 connects using NetworkManager.

:~> ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=114 time=14.1 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=114 time=12.8 ms
^C
— 8.8.8.8 ping statistics —
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 12.892/13.501/14.110/0.609 ms

and the connections information is…

Hardware Address D8:97:5A:72:A0:98
Driver r8169

IPV4

IP Address 192.168.44.101
Broadcast Address 192.168.44.255
Subnet Mask 255.255.255.0
Default Route 192.168.44.1
Primary DNS 208.67.222.222
Secondary DNS 208.67.220.220
Tertiary DNS 8.8.8.8

IPV6

IP Address fe80:73b:7e78:f116:2836/64

So now I exit 15.2 and boot 15.3 with NetworkManager also running. It does not connect.

:~> ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
From 192.168.2.1 icmp_seq=1 Destination Host Unreachable
From 192.168.2.1 icmp_seq=2 Destination Host Unreachable
^C
— 8.8.8.8 ping statistics —
2 packets transmitted, 0 received, +2 errors, 100% packet loss, time 1001ms

…and this time the connections information is…

Hardware Address D8:97:5A:72:A0:98
Driver r8169

IPV4

IP Address 192.168.2.61
Broadcast Address 192.168.2.255
Subnet Mask 255.255.255.0
Default Route 192.168.2.1
Primary DNS 192.168.2.1

IPV6

IP Address fe80::ba97:5aff:fe72:a098/64

Same box, same motherboard, same cable, same software. What am I doing wrong?

15.2 connects using NetworkManager.

IPV4

IP Address 192.168.44.101
Broadcast Address 192.168.44.255
Subnet Mask 255.255.255.0
Default Route 192.168.44.1
Primary DNS 208.67.222.222
Secondary DNS 208.67.220.220
Tertiary DNS 8.8.8.8

So now I exit 15.2 and boot 15.3 with NetworkManager also running. It does not connect.

IP Address 192.168.2.61
Broadcast Address 192.168.2.255
Subnet Mask 255.255.255.0
Default Route 192.168.2.1
Primary DNS 192.168.2.1

Same box, same motherboard, same cable, same software. What am I doing wrong?

Your NetworkManager config is clearly different between the two distro versions. Did you manually configure the Leap 15.3 for the 192.168.2.0/24 network somehow?

The NetworkManager connection configurations live in /etc/NetworkManager/system-connections/ directory. Compare the connection definitions between your two distros.

No, I haven’t touched anything.

Well, you should at least investigate the config files and compare as already explained. Where does the different IP addressing arise from (especially if you’re using DHCP in your network)?

Not much to compare. Even the filenames are different.

 :~$ sudo cat /mnt/hd/etc/NetworkManager/system-connections/"Wired connection 1.nmconnection"[connection]
id=Wired connection 1
uuid=f50f9543-0ca6-3009-99ce-8ed04e9d6d1d
type=ethernet
autoconnect-priority=-999
interface-name=eth0
permissions=
timestamp=1612459722


[ethernet]
mac-address-blacklist=


[ipv4]
dns-search=
method=auto


[ipv6]
addr-gen-mode=stable-privacy
dns-search=
ip6-privacy=0
method=auto


[proxy]
ion@ion-A960D:~$ 




:~$ sudo cat /mnt/hd/etc/NetworkManager/system-connections/eth0.nmconnection
[connection]
id=eth0
permissions=
interface-name=eth0
type=ethernet
[ipv4]
method=auto
[ipv6]
method=auto
ion@ion-A960D:~$ 

And now if I can refer you to my other post which is a different box, different motherboard Network Manager failed connection

/etc/NetworkManager/system-connections/ shows no files present. I thought the posts should be different on account of different motherboards. There is still a third desktop to be updated to 15.3. Plus a notebook. I hesitate to move on those.

The file name is irrelevant. Both are equivalent from a DHCP POV at least…


[ipv4]
dns-search=
method=auto

With the Leap 15.3 OS, disconnect via NetworkManager, then open a terminal and run

sudo journalctl -fu NetworkManager

Attempt to reconnect again, and examine/capture the output during the DHCP connection process. Report back here.

When no config is present, NetworkManager provides a default DHCP connection for the user.

I note the other box also gets assigned an address within the 192.168.2.0/24 address space. Not clear to me why the Leap 15.2 installation gets assigned an address in the 192.168.44.0/24 address space, but that may well be down to your router (or device providing the DHCP service).

If it is similar to what I have seen, then with Leap 15.2, that directory is empty. With Leap 15.3, that directory has a connection definition file put there by the installer. It possibly has a connection name based on the device (perhaps “eth0”).

My practice is to remove that file and reboot. Maybe that’s worth trying. That causes NetworkManager to use its defaults, and those usually work.

Yes, nothing to lose I guess. (Not clear to me why an unexpected DHCP address and gateway is assigned though.)

On some systems, I use NetworkManager for device independence. And that config file set by the installer removes the device independence. If I install to an external drive, I don’t want the network to depend on which computer I connect that drive to.

Perhaps he installed in one location, then moved the computer to a different location. And that would be an example of the device independence issue.

We do not even know actual interface name(s) so those connections may be red herring.

Output (on both systems) of

ip a
ip r
ip -6 r
nmcli device

would give some starting points.

For sure. The OP needs to share all relevant information.

I’ve made a decision. I have spent three days trying to connect two computers with no success. I have answered all your questions as best I could. I have decided to continue using 15.2 until it is no longer supported. At that point I will re-install 15.3. If it works, fine. If not, I will switch to another distro that works for me.

In any case I thank you for the time you have wasted trying to solve my problem.

Hi
I don’t see any mention of rebooting the local routers dishing out the IP addresses, could be stale arp cache…