Hmm, it could be Ubuntu specific.
Auto-connecting works for me with both latest Fedora 17 version (0.9.4.0-9.git20120521.fc17) and NM git master (using your configuration file).

Would you try a newer NM version? If the problem persists, please attach /var/log/syslog.

Well, I did a bit of testing and here autoconnecting is pretty flaky.

When the system boots or awakes from standby or hibernate, autoconnect works!

When I am connected and just pull the plug, wait 10 sec and reconnect the plug, autoconnect does NOT work. (Putting the system then to sleep and wake it leads to reconnection.)

Could you try this on your system, i.e. pulling the plug, waiting until the vlan device is gone, and then reconnecting the plug?

Here is a short syslog extract:
Sep  4 15:55:36 LaptopMB avahi-daemon[1608]: Withdrawing workstation service for eth0.5.
Sep  4 15:55:36 LaptopMB NetworkManager[1595]: nm_system_iface_flush_routes: assertion `iface != NULL' failed
Sep  4 15:55:36 LaptopMB NetworkManager[1595]: (nm-system.c:685):nm_system_iface_get_flags: runtime check failed: (iface != NULL)
Sep  4 15:55:37 LaptopMB dhclient: receive_packet failed on eth0.1: Network is down
Sep  4 15:55:37 LaptopMB avahi-daemon[1608]: Withdrawing workstation service for eth0.1.
Sep  4 15:55:37 LaptopMB NetworkManager[1595]: nm_system_iface_flush_routes: assertion `iface != NULL' failed
Sep  4 15:55:37 LaptopMB NetworkManager[1595]: (nm-system.c:685):nm_system_iface_get_flags: runtime check failed: (iface != NULL)
Sep  4 15:55:37 LaptopMB ntpdate[32553]: Can't find host ntp.ubuntu.com: Name or service not known (-2)
Sep  4 15:55:37 LaptopMB ntpdate[32553]: no servers can be used, exiting
Sep  4 15:55:37 LaptopMB nm-dispatcher.action: Script '/etc/NetworkManager/dispatcher.d/01ifupdown' exited with error status 1.
Sep  4 15:55:37 LaptopMB nm-dispatcher.action: Script '/etc/NetworkManager/dispatcher.d/01ifupdown' exited with error status 1.
Sep  4 15:55:49 LaptopMB kernel: [134435.096917] e1000e: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None
Sep  4 15:57:37 LaptopMB NetworkManager[1595]: (nm-device.c:4396):nm_device_queue_state: runtime check failed: (priv->queued_state.id == 0)
Sep  4 15:57:38 LaptopMB dhclient: Internet Systems Consortium DHCP Client 4.1-ESV-R4
Sep  4 15:57:38 LaptopMB dhclient: Copyright 2004-2011 Internet Systems Consortium.
Sep  4 15:57:38 LaptopMB dhclient: All rights reserved.
Sep  4 15:57:38 LaptopMB dhclient: For info, please visit https://www.isc.org/software/dhcp/
Sep  4 15:57:38 LaptopMB dhclient: 
Sep  4 15:57:38 LaptopMB dhclient: Listening on LPF/eth0.1/00:1f:16:0d:7b:41
Sep  4 15:57:38 LaptopMB dhclient: Sending on   LPF/eth0.1/00:1f:16:0d:7b:41
Sep  4 15:57:38 LaptopMB dhclient: Sending on   Socket/fallback
Sep  4 15:57:38 LaptopMB dhclient: DHCPREQUEST of 172.17.2.103 on eth0.1 to 255.255.255.255 port 67
Sep  4 15:57:38 LaptopMB dhclient: DHCPACK of 172.17.2.103 from 172.17.2.1
Sep  4 15:57:38 LaptopMB dhclient: bound to 172.17.2.103 -- renewal in 704 seconds.
Sep  4 15:57:38 LaptopMB dbus[1527]: [system] Activating service name='org.freedesktop.nm_dispatcher' (using servicehelper)
Sep  4 15:57:38 LaptopMB avahi-daemon[1608]: Joining mDNS multicast group on interface eth0.1.IPv4 with address 172.17.2.103.
Sep  4 15:57:38 LaptopMB avahi-daemon[1608]: New relevant interface eth0.1.IPv4 for mDNS.
Sep  4 15:57:38 LaptopMB avahi-daemon[1608]: Registering new address record for 172.17.2.103 on eth0.1.IPv4.

At 15:55:36 sec, I pulled the plug, at :49 sec I reconnected. Nothing happened except the one kernel line. At 15:57:38 I issued "nmcli con up id VLAN1" on the command line.

When you say "waiting until the vlan device is gone" what exactly do you  mean?  When you pull the plug, can you run:

nmcli dev

and paste the output in here?  Thanks!

(In reply to comment #3)
> When you say "waiting until the vlan device is gone" what exactly do you  mean?
>  When you pull the plug, can you run:
> 
> nmcli dev
> 
> and paste the output in here?  Thanks!

Hi

I did not say "waiting until the vlan device is gone". I said "I pulled the plug, waited 10 sec, then reconnected".

Currently I cannot test the "nmcli dev" command after pulling the plug as I have switched the system to a non-VLAN connection. When I have some time I will reconfigure back to the VLAN and test it.

Thanks

Michael

Autoactivate is based on devices, not connections. So if "eth0.1" gets deleted (as it would when the connection on it is deactivated), then it's not possible to re-autoactivate that connection. (The reason things work at startup is because at startup we preemptively create the virtual devices corresponding to all autoactivate connections.)


I remember some discussion in some context about having NM create "virtual NMDevices" to represent interfaces that *could* exist to support certain connections, but don't yet actually exist. That would be one way of fixing this. (I don't remember the context of that discussion though, or whether we decided it was a good or bad idea.)

I don't think we can currently fix this in an "abstract" way (ie, a way that doesn't involve explicitly treating VLAN specially) without adding something like nm_connection_get_dependent_interfaces(), which would be a virtual function like get_virtual_iface_name(). (Or else which would involve moving NMSettingVlan:parent into NMSettingConnection.)

The simplest (hackiest) fix would be to just have NMPolicy know about VLANs, and so, eg, schedule_activate_check() would look for VLAN connections whose parent was @device, and schedule checks for them as well.

Alternatively, we could have NM try to ensure that the virtual devices for all autoconnect connections *always* exist, rather than only doing that at startup.

Or at least, we could avoid deleting interfaces on deactivation if they have an available autoconnect connection...

(In reply to comment #5)
> Autoactivate is based on devices, not connections. So if "eth0.1" gets deleted
> (as it would when the connection on it is deactivated), then it's not possible
> to re-autoactivate that connection. (The reason things work at startup is
> because at startup we preemptively create the virtual devices corresponding to
> all autoactivate connections.)

Yeah, the issue is that if the device got deleted, it would just be re-created if any 'autoconnect' connection existed for it.  So you'd never be able to get rid of the device...

> I remember some discussion in some context about having NM create "virtual
> NMDevices" to represent interfaces that *could* exist to support certain
> connections, but don't yet actually exist. That would be one way of fixing
> this. (I don't remember the context of that discussion though, or whether we
> decided it was a good or bad idea.)

We decided it was a good idea, and that work is substantially complete and tracked in dcbw/devices-for-all-1 in bug 737458.  But we still have to ensure that a device that is deleted stays gone until manually activated again, but that's a lot easier since now we can track that on the Device object.

> I don't think we can currently fix this in an "abstract" way (ie, a way that
> doesn't involve explicitly treating VLAN specially) without adding something
> like nm_connection_get_dependent_interfaces(), which would be a virtual
> function like get_virtual_iface_name(). (Or else which would involve moving
> NMSettingVlan:parent into NMSettingConnection.)
> 
> The simplest (hackiest) fix would be to just have NMPolicy know about VLANs,
> and so, eg, schedule_activate_check() would look for VLAN connections whose
> parent was @device, and schedule checks for them as well.
> 
> Alternatively, we could have NM try to ensure that the virtual devices for all
> autoconnect connections *always* exist, rather than only doing that at startup.
> 
> Or at least, we could avoid deleting interfaces on deactivation if they have an
> available autoconnect connection...

Yeah, we could do that, and then if the user really wanted it to go away, I suppose they could just set autoconnect=no, but I'm sure we'll get complaints about that too?  Maybe deleting the device outside NM should set autoconnect=no for all relevant connections (and leave them unsaved), or is that going too far?

bugzilla.gnome.org is being shut down in favor of a GitLab instance. 
We are closing all old bug reports and feature requests in GNOME Bugzilla which have not seen updates for a long time.

If you still use NetworkManager and if you still see this bug / want this feature in a recent and supported version of NetworkManager, then please feel free to report it at https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/

Thank you for creating this report and we are sorry it could not be implemented (workforce and time is unfortunately limited).