The core problem was the nm_connection_need_secrets() call in nm-agent-manager.c's get_start() function; for VPN settings this always returns TRUE. Thus if a VPN connection had only system secrets, when the agent manager checked if additional secrets were required, they would be, and agents would be asked for secrets they didn't have and couldn't provide. Thus the connection would fail. nm_connection_need_secrets() simply can't know if VPN secrets are really required because it doesn't know anything about the internal VPN private data; only the plugin itself can tell us if secrets are required. If the system secrets are sufficient we shouldn't be asking any agents for secrets at all. So implement a three-step secrets path for VPN connections. First we retrieve existing system secrets, and ask the plugin if these are sufficient. Second we request both existing system secrets and existing agent secrets and again ask the plugin if these are sufficient. If both those fail, we ask agents for new secrets.
Make it clearer what's going on instead of using flags here and there and numbers elsewhere.
Not used yet, but will be when device deactivating state gets used. Should be 100% backwards compatible with users that don't know about it for now.
These days more and more devices are showing up that support a number of different access technology families in the same hardware, like Qualcomm Gobi (CDMA and GSM), Pantech UM190 (CDMA and GSM), Pantech UML290 (CDMA and LTE), LG VL600 (CDMA and LTE), Sierra 320U (GSM and LTE), etc. The previous scheme of having device classes based on access technology family simply cannot handle this hardware and attempting to add LTE to both the CDMA and GSM device classes would result in a bunch of code duplication that we don't want. There's a better way... Instead, combine both CDMA and GSM device classes into a generic "Modem" device class that provides capabilities indicating what access technology families a modem supports, and what families it supports immediately without a firmware reload. (Gobi devices for example require a firmware reload before they can switch between GSM and CDMA). This provides the necessary flexibility to the client and allows us to keep the API stable when the same consolidation change is made in ModemManager. The current code doesn't yet allow multi-mode operation internally, but the API is now what we want it to be and won't need to be changed.
Will be used for things like activating a VPN connection before signaling that the device is activated, or maybe for bridges and bonds, to ensure that applications don't think the system has connectivity before everything is set up.
alias for NM_STATE_CONNECTED_GLOBAL