GNOME Bugzilla – Bug 682618
tracker: autoconnection, reconnection and dependency problems
Last modified: 2014-06-19 13:12:49 UTC
Currently there are many connections that just won't activate when they should. It may be at NetworkManager start, at system wake up, when connection is lost or even when you try to bring it up with nmcli. These are usually virtual interfaces created at runtime. This currently seems to affect VPN, mobile broadband, VLAN, bonding and (if you build the 'bridge' branch) bridging. Bonding and bridging: These are master interfaces created at runtime that accept slave devices. They should usually work as follows. 1) Master connection's interface is set up. 2) Slave connection configuration notice that and enslave themselves. 3) There may be some time when bridging/bonding doesn't work yet. 4) Master connection starts automatic IPv4 and IPv6 configuration. VLAN: Master devices don't need to have an associated NM connection (isn't this a bug?) and they reportedly don't need the master interface to be up. This will probably break VLAN interfaces based on bridges. VPN: These connections rely on another connection to provide the route to the other VPN endpoint.
(In reply to comment #0) > These are master interfaces created at runtime that accept slave devices. They > should usually work as follows. > > 1) Master connection's interface is set up. > 2) Slave connection configuration notice that and enslave themselves. This is how I think it should work too, but this isn't how it worked in the Fedora initscripts, and it's not how NM works now. Instead, you bring up the slaves, and that causes the master to be brought up. (But bringing down the slaves does not cause the master to be brought down...) There are issues with, in some cases you might want some slaves but not others to be automatically connected, but we could just use the autoconnect flag on the slaves to determine that. > VLAN: > > Master devices don't need to have an associated NM connection (isn't this > a bug?) I think we already had this discussion offline since this bug was filed, but, no, it's not a bug; you can bring up eth0.1 without bringing up eth0. > This will probably break VLAN interfaces based on bridges. Stable kernels don't support that yet, but anyway, in theory, we do support that, correctly, though I don't remember what the current state of the code is. Anyway, some of the tracked bugs here may still be 0.9.8, but the tracker as a whole can't be.
Agreed.
I don't think there's much benefit to this tracker at this point, and neither of the remaining bugs is going to be fixed for 0.9.10. I'll mark them individually 1.0.