Help needed to understand if this is a bug/feature/weirdness:
I've made some progress diagnosing this problem with losing DHCP connectivity. I've got it reproducible by a simple command: 'nmcli con down br0; nmcli con up br0' fails to get a DHCP lease in the "up" case.
It seems to be the way that NM handles a bridge connection. When Fedora boots, it comes up with the bridge (br0) using the same MAC address as the slave (eno1), which is the hardware MAC address of the wired card. However, if you do 'nmcli con down br0; nmcli con up br0', the br0 device now has a randomly generated MAC address.
This is a little weird. I suspect I can work around my specific problem by giving the br0 device a fixed ether.mac-address. However, I don't know if that is the right thing for others to do in my situation.
In fact, there is little info about bridge management behavior in NM docs I can find, so it's not obvious what is the "correct" behavior of an NM-managed bridge connection.
Should NM be giving the bridge its MAC address from the slave device the first time? Makes sense, though it's a little unclear what the "default" should be.
And should the second and later times use "random addresses"?
Seems like there may be two different pieces of NM code that do the same function of bringing up the interface, but which are not consistent with each other.
Anyway, I'd like to know what is right.
-----Original Message-----
From: "dpreed deepplum com" <dpreed deepplum com>
Sent: Thursday, January 4, 2018 3:59pm
To: networkmanager-list gnome org
Subject: Problem I've been having with dhclient dhcp in Fedora27
I've been having problems with NetworkManager dhcp on my Fedora27 Workstation (desktop, wired).. Note, because I'm using VMs on that workstation, the interface is a bridge (br0 with slave eno1).
What seems to happen is this:
Workstation wakes up from sleeping, reactivates connection.
dhclient issues 4 DHCPDISCOVER tries, none of which get a response.
the interface state changes "unknown-->timeout->done", and the DHCPv4 transaction is cancelled.
A restart is scheduled for 120 seconds later.
The restart 120 seconds later succeeds with DHCPDISCOVER, DHCPREQUEST, DHCPOFFER, DHCPACK.
All the other machines served by my DHCP server have no problems at all, however, they are MacBooks, various storage servers, and RaspberryPis.
It seems to be that NetworkManager somehow interferes with the DHCPDISCOVER after the workstation wakes up.
The attached log file shows this sequence of events.
(I'm wondering if there is a timing issue because the first dhclient call is issued when eno1 is in the "unavailable" state, and before it is captured as a slave to br0)