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" 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.
Hi, your previously sent logfile has no level=TRACE logging enabled, so it's not clear whats happening. See https://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/contrib/fedora/rpm/NetworkManager.conf 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 redundant. 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 attached. 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 slave. 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 useful. Long story short, please send a log file to see what's happening. Thanks, Thomas
-----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) _______________________________________________ networkmanager-list mailing list networkmanager-list gnome org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Attachment:
signature.asc
Description: This is a digitally signed message part