"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.
A client calling GetSecrets on the connection should also request
secrets from agents in that client's session. ie, a connection
editor should be able to call GetSecrets, and get the secrets
stored by the agent in that session (the applet).
Given connection details, complete the connection as well as possible
using the given specific object and device, add it to system
settings, and activate it all in one method.
Heavily modify Inaky's Intel WiMAX SDK glue (originally from connman)
to be more generic and more thread-safe, and suitable for use with
NetworkManager instead of rolling our own client code. Rewrite the
NMDeviceWimax code to mostly work.
Still to be done: actual connection logic, DHCP handling, spawning
wimaxd if it's not started yet
We're just going to quit here anyway, so we don't need to
make sure the property filter is unregistered. Fixes a
crash on exit if D-Bus has quit before NM has.
Instead of a bizare mechanism of signals back to the manager
object that used to be required because of the user/system settings
split, let each place that needs secrets request those secrets
itself. This flattens the secrets request process a ton and
the code flow significantly.
Previously the get secrets flow was something like this:
nm_act_request_get_secrets ()
nm_secrets_provider_interface_get_secrets ()
emits manager-get-secrets signal
provider_get_secerts ()
system_get_secrets ()
system_get_secrets_idle_cb ()
nm_sysconfig_connection_get_secrets ()
system_get_secrets_reply_cb ()
nm_secrets_provider_interface_get_secrets_result ()
signal failure or success
now instead we do something like this:
nm_agent_manager_get_secrets ()
nm_agent_manager_get_secrets ()
request_start_secrets ()
nm_sysconfig_connection_get_secrets ()
return failure or success to callback
Don't bother trying to initialize the user settings proxy when it
isn't even active. Would trigger a warning to syslog if PolicyKit
permissions changed via changes to /usr/share/polkit-1/actions/.
By the time we get the udev device removal notification we may not
be able to read properties, since the device has already been
removed from sysfs. That means we can't get the ifindex, so we need
to fall back to the interface name. But we always want to prefer
the ifindex since that will never change as long as the device is
connected, unlike the interface name.
This patch updates timestamps in system connections. The update occurs on
connection activation and then periodically every 5 mins while the connection
is active. It only works for plugins having write support and for writable
connections (not read-only).
