This is the "juice" of the patch series. Initial cut at carrier handling
(by polling /sys/class/atm/$iface/carrier) and also support for calling
pppd with the proper command-line to achieve a connection.
Also implement the necessary boilerplate for the NM state machine to
be happy with our device.
This is a "duct tape and gum" implementation, i.e., prefer copy&paste
over proper refactoring, due to limited time, but the foundations are
now there, so we can make it work right slowly-slowly :)
With this patch, you can already test carrier management but not yet
make a complete connection.
Relevant extract from logs:
<info> (ueagle-atm0): carrier now ON (device state 20)
<info> (ueagle-atm0): device state change: unavailable -> disconnected (reason 'carrier-changed') [20 30 40]
Signed-off-by: Pantelis Koukousoulas <pktoss@gmail.com>
Allows better encapsulation of the functionality of the NMSettings
object that we want to expose to the device class. They don't need
the whole object so to keep things simple and contained we'll just
give them a smaller interface to use.
The kernel is broken for Ad-Hoc WPA, and creates the connections
as open connections instead. Yeah, eventually we can use
wpa_supplicant with RSN support, but for now we just have to
disable Ad-Hoc WPA because it's a problem to say we're creating
a protected network but then have the kernel not do that for
us. Will be re-enabled once all the necessary bits have been
fixed.
Note that Ad-Hoc WPA has been broken since at least 2.6.32 with
mac80211-based drivers, which is what most users will be using.
Some connection types such as bonding, bridging and VLAN require
specific virtual kernel interfaces identified by name to be auto
connected to the connection.
The function nm_connection_get_virtual_iface_name() returns the name
of the kernel interface if the connection type requires this
functionatlity.
Each connection base type settings class can implement the function
get_virtual_iface_name() if the connection needs to be auto connected
to a specific kernel interface.
Signed-off-by: Thomas Graf <tgraf@redhat.com>
We have to send agent-owned secrets to agents via SaveSecrets() D-Bus call for
newly created connections, the same way we do for connection updates.
Without the change secrets aren't saved for new created VPN connections,
only after a connection update.
A bonding device is like a virtual ethernet device. We therefore reuse
nm-device-ethernet and add some special handling to detect bonding
connections.
Changes v2:
- Fixed memory leak
Signed-off-by: Thomas Graf <tgraf@redhat.com>
When a default wired connection is saved, it gets deleted first since it
has to be re-created using a settings plugin. But with the settings
rework in 0.9, default wired refcounting changed and the default
wired connection wasn't kept alive in default_wired_try_update()
over the removal/readd. This caused a use-after-free.
Use case:
A user has an auto-activatable connection with secrets in a keyring. While
booting NM starts and tries to activate the connection, but it fails because of
missing secrets. Then the user logs in, but the connection is marked as invalid
and is not tried again.
This commit solves the issue by removing invalid flag and activating the
connection when a secret agent registers.
Signed-off-by: Jiří Klimeš <jklimes@redhat.com>
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>
Commit e083cd5c63 stopped openconnect from
saving its secrets. It'd been working for a whole three minutes since my
previous commit.
We need to have at least one secret with an *extant* flags setting of
NM_SETTING_SECRET_FLAG_NONE, in order to trigger a write-out of the new
set of secrets. And we might as well list all the secrets we *know* the
auth-dialog is going to use, although we know there will be some secrets
that we cannot predict in advance (the form entry boxes).
Evil hack; but the problem is that before this commit anyone who
migrated connections wouldn't have the right secrets flag set in
their openconnect connections. Figuring out some way of updating
those connections now is harder and we don't want people to have
to go through the delete-connection-file-change-applet-stamp-rerun
dance. So we'll live with this for now...
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.
If the client knows the UUID, add a convenience function to get
the connection path directly, instead of having to iterate the
whole connection list and get each connection's details and then
check the UUID.
Due to an error in the loop logic, if there were no connections yet (like
a fresh install or a livecd or whatever) no default name would be returned
and thus ethernet devices wouldn't come up automatically. Fix that loop
error and add testcases for it.
Where 'x' is a number that's not yet used by any existing connection.
And clean up the default wired class initialization. This name is
more friendly than "Auto eth0" which was confusing to quite a few
people. This also checks to ensure there's no other connection with
the same name, which the old method did not.
Suggested by Jon McCann.
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.
We can't unregister the object with the bus during the remove signal,
because dbus-glib doesn't send the signal out over the bus until late
in the signal emission process, after we've unregisterd the object.
Thus the signal doesn't go out. Fix that.
When a connection is visible only to one user, check 'own' instead
of 'system', allowing 'own' to be less restrictive since the change
won't affect any 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.
Since settings storage is now handled by NetworkManager, we must
have the ability to read/write all connection types at all times.
Since the 'keyfile' plugin is the only plugin that can handle all
connection types, build it into NetworkManager.
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.
New connections should not be pushed out in the Updated signal
because signals cannot be restricted to particular clients, and
some clients may not have permission to view the connection.
Upon receiving the Updated signal, clients should re-read the
connection using GetSettings to ensure that the client still
has permissions to view the connection, and to get the updated
settings.
Since user interaction is allowed when the permission for SaveHostname
is requested, if the user didn't authorize completely when polkit
returns, we don't want to proceed with the request. Otherwise we might
get into a situation where it's possible for the user to authorize,
but they didn't, and previously the code would allow the request.
