Bug 1227384 - NetworkManager: conflict detected for IP address
Summary: NetworkManager: conflict detected for IP address
Status: RESOLVED WORKSFORME
Alias: None
Product: openSUSE Tumbleweed
Classification: openSUSE
Component: Network (show other bugs)
Version: Current
Hardware: x86-64 openSUSE Tumbleweed
: P5 - None : Normal (vote)
Target Milestone: ---
Assignee: E-mail List
QA Contact: E-mail List
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2024-07-04 09:04 UTC by Michael Hirmke
Modified: 2024-07-14 17:57 UTC (History)
0 users

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Michael Hirmke 2024-07-04 09:04:32 UTC 
With the latest NetworkManager version 1.48.2-1.1 I always get

NetworkManager[2610]: <info>  [1720082775.7457] device (enp62s0): conflict detected for IP address 192.168.1.42 with host 38:14:28:F7:B5:B7

when resuming the system from sleep or hibernate or after a reboot.

38:14:28:F7:B5:B7 is the second network adapter in the system, but it is disabled (see below).
After a while this network adapter gets deactivated and the first adapter is activated. This has to some every strange effects regarding dispatcher scripts - especially for mounting nfs or smb shares.

Do I have to configure something else to get it working as before the update?

-----
[connection]
id=eth0_(LAN)
uuid=25b6d1be-8a6b-4762-88da-cd27eb0a0c89
type=ethernet
autoconnect-priority=1
zone=home

[ethernet]
auto-negotiate=true
mac-address=64:4B:F0:10:7B:CE

[ipv4]
may-fail=false
method=auto

[ipv6]
addr-gen-mode=stable-privacy
method=auto

[proxy]
-----
[connection]
id=eth1_(LAN)
uuid=96f4821b-5eb3-4094-8ad9-70aa94478abc
type=ethernet
autoconnect=false
zone=home

[ethernet]
mac-address=38:14:28:F7:B5:B7

[ipv4]
method=disabled

[ipv6]
addr-gen-mode=stable-privacy
method=disabled

[proxy]
Comment 1 Michael Hirmke 2024-07-14 17:57:23 UTC 
Solved.
I guess, the "problem" has been triggered by ipv4.dad-timeout setting.

I created /etc/NetworkManager/conf.d/99-unmanaged-devices.conf:

[keyfile]
unmanaged-devices=mac:38:14:28:f7:b5:b7

That already solved the problem.
To be absolutely sure, I also created /etc/sysctl.d/99-sysctl-mh.conf:

net.ipv4.conf.enp63s0u2u3.arp_ignore = 1

for the second network adapter.