Re: Problem I've been having with dhclient dhcp in Fedora27

On Sat, 2018-01-06 at 17:23 -0500, dpreed deepplum com wrote:
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"
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
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.


your previously sent logfile has no level=TRACE logging enabled, so
it's not clear whats happening.

You might set a fixed MAC address, via "bridge.mac-address" and
"ethernet.cloned-mac-address". The first property is used when creating
the bridge interface, the second later when activating.
On 1.10, "bridge.mac-address" got deprecated, because it's obviously

Anyway, in general, if you activate a master device alone with `nmcli
connection up` (be it bridge, bond, or team), then you only activate
the master alone. There is also a "connection.autoconnect-slaves"
property, that aims to brings up available slaves. So whether any
slaves are attaches is unclear. But quite possibly, no slaves are

Note that the sequence:
  nmcli connection up "$SLAVE"
  nmcli connection up "$MASTER"
is wrong, because activating the slave already brings up the master as
well, so activating the master again results in a disconnect of the
Either do
  nmcli connection up "$MASTER"
  nmcli connection up "$SLAVE"
or just
nmcli connection up "$SLAVE"

As you don't set "bridge.mac-address" nor "ethernet.cloned-mac-
address", the MAC address of a master device without slaves is randomly
assigned by kernel.
If the bridge's MAC address is unset (from kernel's point of view),
kernel will assign the MAC address of the first slave that attaches.
So, the MAC address changes. Usually, that shouldn't matter, because as
long as there are no slaves, the master's MAC address isn't very

Long story short, please send a log file to see what's happening.


-----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,
All the other machines served by my DHCP server have no problems at
all, however, they are MacBooks, various storage servers, and
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)
networkmanager-list mailing list
networkmanager-list gnome org

Attachment: signature.asc
Description: This is a digitally signed message part

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]