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: "[email protected]" <[email protected]>
Sent: Thursday, January 4, 2018 3:59pm
To: [email protected]
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)
_______________________________________________
networkmanager-list mailing list
[email protected]
https://mail.gnome.org/mailman/listinfo/networkmanager-list
