Add an accessor for device rfkill type and use that instead of
GObject properties, and also use that accessor when claiming a
new device instead of checking NM_IS_DEVICE_xxxx(). Allows us
to move one step closer to making WiMAX a plugin.
For a slave to be activatetable the master connection must be present.
Activation of the slave is postponed until this condition is met.
Once the slave is being activated, a reference to the master connection
is acquired and held for the lifetime of the bond.
Changes v2:
- Made check_master_dependency() return TRUE/FALSE
Signed-off-by: Thomas Graf <tgraf@redhat.com>
Creates virtual kernel devices as needed. Since the manager is
initialized after the connections have been loaded no
CONNECTIONS_ADDED notification is received for connections parsed
at startup.
Therefore walks the loaded connections looking for bonding
connections.
Connections added on the fly are handled via the notifications.
Connection renaming and deleting is not supported yet.
Signed-off-by: Thomas Graf <tgraf@redhat.com>
If the caller passed "/" to indicate that NM should choose the default
active connection as the parent of the VPN, make sure we pass that
active connection's object path to the VPN for its specific object
path instead of leaving it "/".
Active VPN connections exported their own active path instead of active path of
base connection in 'SpecificObject' property. It's a regression caused by commit
bc6fc7b910 that split VPN connections to
NMVPNConnectionBase and NMVPNConnection.
Previously, specific object used to be obtained from NMActRequest of parent
connection. The NMActRequest object served also for getting secrets. Commits
0e6a5365d4 and 832e64f8bc
removed NMActRequest from VPN connection because it's not necessary any more.
This commit fixes the issue by passing specific object path explicitly.
OLPC Mesh code now doesn't have to be updated every time we change
the manager's creation arguments. We could make all these arguments
GObject properties of the manager too, but that's more code and
we'd eventually like to figure out a better solution for letting
non-NMManager code listen for device addition/removal.
"mac-address-blacklist" property is added to the ethernet and WiFi connections.
It is the MAC addresses list of devices on which the connection won't be
activated.
Original patch (NM_0_8 branch) from Thomas Bechtold <thomasbechtold@jpberlin.de>
Previously (in NM 0.8.x) most WiFi connection were from user settings service.
And the service updated 'seen-bssids' property when got connected.
But the settings service in 0.9 don't do that. That inhibits auto-connecting to
hidden networks. This commit takes care of updating 'seen-bssids'. However, we
don't want to write out the conection each time it's activated (touching /etc).
So, seen BSSIDs are kept separately from the connection in a look-aside file.
Signed-off-by: Jiří Klimeš <jklimes@redhat.com>
'vperic' had an interesting problem on IRC where every 10 minutes
the ethernet would change state from ACTIVATED -> DISCONNECTED with
a reason code of 0; the only thing I can find is that something was
telling NM to activate a connection periodically, becasue that appears
to be the only place that changes state to DISCONNECTED with a
reason code of 0. No logging; no apparent carrier changes.
So log this condition just in case we run into it later.
Use one global PolkitAuthority object; we only really need to use it
in one place anyway. So consolidate the code that uses polkit into
nm-manager-auth.c.
This commit changes rfkill state handling slightly in the following
ways:
- when checking whether a user toggle request can change radio state,
ignore states we can change in radio_enabled_for_rstate() as a result
of the toggle; this fixes WiMAX enable/disable because a softblock
can be changed by telling wimaxd to enable the radio. As a side-effect
this also fixes handling of WiFi when altering the rfkill state as well.
- make WiFi user toggle requests change wifi killswitch state; this has
been long requested and on the TODO list for a while and it turns out
to be a lot easier to do these days. This provides the expected
behavior when disabling wireless from user agent menus since there's
not an easy way to do this other than dropping to shell and running
rfkill.
Allow clients to get a device by its IP interface name instead
of having to get the device list and iterate through each one,
and read the interface name to get what they want.
Since the user state stuff got committed in 0.8.2, WWAN enable
state has been somewhat broken. The problem is that we want two
things: (1) that the current modem enabled state is reflected
in the WwanEnabled property, and (2) that enabled state should not
affect the user's ability to enable the modem via the UI.
The code did not properly separate these two. For all automatic
decisions and properties (ie the WwanEnabled property, setting the
initial enabled state on startup or hotplug, etc) the ModemManager
enabled state should be respected. But the user should be able
to override that state by turn WWAN on.
This calls for a fourth enabled check that modems have, the 'daemon'
state, distinct from the hardware and software kernel rfkill states
and from the user's chosen enabled/disabled state. Add that new
check.
The actual problem was in manager_radio_user_toggled() where after
updating the user enabled state, new_enabled still equaled
old_enabled, because the kernel rfkill state was a combination of
both the kernel rfkill state *and* the ModemManager enabled state,
so the manager_update_radio_enabled() call would never happen and
the modem would never become enabled as a result of a user request.
NM updates timestamp for active connections every 5 min. We don't
want to touch files in /etc due to this. This commit solves that
by not updating timestamp in the connection's property. Rather it
updates the timestamp internally. All timestamps are also kept track
of in /var/lib/NetworkManager/timestamps file.
When settings are requested via D-Bus GetSettings(), the proper
timestamp is put in the connection setting before returning.
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.
DISCONNECTING: the only active network connection is now being disconnected
LOCAL, SITE, GLOBAL: one-stop items for level of connectivity, which
we'll use to show when we think we're actually connected to the internet
or behind a captive portal or something
sleep, wake, StateChange, all deprecated in 0.8, are now removed.
sleep & wake are replaced with the Sleep() method, while
StateChange is replaced with the StateChanged signal which has
the same arguments.
This policy will allow users to modify their personal connections (ie
maybe VPN connections, etc) distinctly from system-wide connections that
affect more than just their user. It makes sense to be more lenient when
making changes to settings that don't affect other users.
Meaning stays the same, but this will allow us to differentiate
in the future between personal connections (ie, just visible to
one user) and system connections (visible to more than one user).
It's the thing that owns the secrets anyway, and it simplifies things to
have the secrets handling there instead of half in NMActRequest and
half in NMManager. It also means we can get rid of the ugly signals
that NMSettingsConnection had to emit to get agent's secrets, and
we can consolidate the requests for the persistent secrets that the
NMSettingsConnection owned into NMSettingsConnection itself instead
of also in NMAgentManager.
Since the NMActRequest and the NMVPNConnection classes already tracked
the underlying NMSettingsConnection representing the activation, its
trivial to just have them ask the NMSettingsConnection for secrets
instead of talking to the NMAgentManager. Thus, only the
NMSettingsConnection now has to know about the agent manager, and it
presents a cleaner interface to other objects further up the chain,
instead of having bits of the secrets request splattered around the
activation request, the VPN connection, the NMManager, etc.
When a user makes an explicit request for secrets via GetSecrets
or activates a device, don't ask other users' agents for secrets.
Restrict secrets request to agents owned by the user that made the
initial activate or GetSecrets request.
Automatic activations still request secrets from any available agent.
