| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Previously, we would only set a connection as volatile before
adding it to manager. As we never would set it volatile last on,
there was no need to handle deletion.
Now support that. Watch the volatile flag, and if the connection
has currently not active connection that keeps it alive, delete
it in an idle handler.
|
| | | |
|
| | |
| |
| |
| |
| |
| | |
First, define structs. Then forward declare functions. Reorder code
to have a certain order that is also used by other files (or should
be).
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
function
Previously, NMPolicy would explicitly check whether the connection is not visible,
to skip autoconnect.
We have nm_settings_connection_autoconnect_is_blocked() function, that can do that.
The advantage is, that at various places we call nm_settings_connection_autoconnect_is_blocked()
to determine whether autoconnect is blocked. By declaring invisible connections
as blocked from autoconnect as well, we short-cut various autoconnection attempts,
that previoulsy only failed later during auto_activate_device().
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The accessor functions just look whether a certain flag is set. As these
functions have a different name then the flags, this is more confusing
then helpful. For example, if you want to know where the NM_GENERATED
flag matters, you had to know to grep for nm_settings_connection_get_nm_generated()
in addition to NM_SETTINGS_CONNECTION_FLAGS_NM_GENERATED.
The accessor function hid that the property was implemented as
a connection flag. For example, it was not immediately obvious
that nm_settings_connection_get_nm_generated() is the same
as having the NM_SETTINGS_CONNECTION_FLAGS_NM_GENERATED flag
set.
Drop them.
|
| | |
| |
| |
| |
| |
| | |
It seems more idiomatic to have a mask+value argument, instead
of setting all flags at once. At least, other setters work this
way, so change it for consistency.
|
| | |
| |
| |
| |
| |
| | |
We already need to re-emit the notify::flags signal.
It's cumbersome to do this for boolean properties, so
re-use the flags to also track the visibility state.
|
| | |
| |
| |
| | |
We will need to subscribe to changes to "flags" from NMManager.
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| | |
It doesn't really matter, because in the next step we
are about to remove the connection.
However, once the connection is deleted from file, it's
clear that it has no more file-name.
|
| | | |
|
| | |
| |
| |
| | |
The helper is only used by ifcfg-rh. Move it to the plugin.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Commonly, we don't monitor files and hence don't need the inotify-helper
instance. We already access and construct the instance lazy, by
accessing the singleton getter only when needed.
However, path_watch_stop() would always access the singleton, hence
always create such an instance. In most cases there is nothing to clean,
and no such instance shall be created.
|
| | |
| |
| |
| |
| |
| | |
ifnet shall use the new_connection argument, not NM_CONNECTION(self).
Also, let the caller of the virtual function provide the right new_connection,
not having the virtual function figure that out.
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| | |
The example script touches the stable-id of a connection.
It does so blocking autoconnect, and was originally written
to test that functionality.
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
- only add an async version. I think sync requests are fundamentally flawed
because they mess up the order of D-Bus messages. Hence, also don't
call the function *_async(), like we do for other functions. As there
is only the async form, it doesn't have a suffix.
- Don't accept a NMConnection as @settings argument, but a GVariant.
In general, keep the libnm API closer to the D-Bus API and don't hide
the underlying function with a less powerful form. The user still can
conveniently call the function with
nm_remote_connection_update2 (connection,
nm_connection_to_dbus (NM_CONNECTION (connection),
NM_CONNECTION_SERIALIZE_ALL),
save_to_disk
? NM_SETTINGS_UPDATE2_FLAG_TO_DISK
: NM_SETTINGS_UPDATE2_FLAG_IN_MEMORY,
NULL,
cancellable,
callback,
user_data);
I believe the parts of libnm that invoke D-Bus methods, should be
close to the D-Bus API. Not like nm_remote_connection_commit_changes()
which has no corresponding D-Bus method.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
org.freedesktop.NetworkManager.Settings.Connection.Update2()
We already have Update(), UpdateUnsaved() and Save(), which serve
similar purposes. We will need a form of update with another argument.
Most notably, to block autoconnect while doing the update.
Other use cases could be to prevent reapplying connection.zone and
connection.metered, to to reapply all changes.
Instead of adding a specific update function that only serves that
new use-case, add a extensible Update2() function. It can be extended
to cope with future variants of update.
|
| | |
| |
| |
| |
| |
| |
| |
| | |
commit involves more then just replacing the setting and writing them
out. What? Dunno. It's complex.
But let's not bypass the commit-changes function. That one is supposed
to get it right.
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
It's complicated what happens during a commit/replace/update (whatever
you call it).
It doesn't get simpler by spreading it out to various functions.
Let's have one large function (_commit_changes_full()) which does
all the steps necessary. There should be no alternative ways
how to update a connection.
|
| | |
| |
| |
| |
| |
| | |
All callers of _replace_settings_full() now use _commit_changes_full().
commit-changes should contain all the logic what to do when updating
a connection. Now, the connection might optionally be written to disk.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
emitting signals
_commit_changes_full() calls _replace_settings_full() which already emits signals
about the changed connection. We should mark the connectin as saved earlier.
In fact, we can tell _replace_settings_full() to mark it as not-unsaved
via the persist-mode parameter.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
_replace_settings_full() does more then just replace the settings.
It at least also sets some flags, like saved/unsaved depending
on @persist_mode.
_replace_settings_full() also emits the "updated" signal. Note that
previously it would just return without signal if nm_connection_compare()
indicates that there is no difference. But the caller probably cares
about whether the user tries to change the connection at all, not
whether the change actually introduced a real difference in the
settings. Like, policy might re-set the autoconnect blocked flags.
But it should do so on every user-update, regardless of whether
a change was actually made.
It makes sense to call _replace_settings_full() with a @new_connection
of %NULL, to mean: just update the flags, but keep the current connection.
Extend _replace_settings_full() to allow for that.
Also, update update_auth_cb() to always call _replace_settings_full(),
even if no new connection is provided. In this case, only update
the connection flags accordingly.
|
| | |
| |
| |
| |
| |
| |
| |
| | |
Note how nm_settings_connection_commit_changes() would call
prepare() a second time. Don't do that.
Also, move the prepare step earlier, and call _replace_settings_full()
without preparing the new connection again.
|
| | |
| |
| |
| |
| |
| | |
preparing the new connection
Will be used next.
|
| | |
| |
| |
| |
| |
| | |
The current behavior of update_unsaved is confusing. Give the argument
an enum with a name that describes better what's happening. Also, it
makes the uses grep-able.
|
| |/ |
|
| |
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=791222
|
| |\
| |
| |
| | |
https://bugzilla.redhat.com/show_bug.cgi?id=1518177
|
| | | |
|
| | |
| |
| |
| | |
Evaluate strlen() only once.
|
| | | |
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The wireless-security setting has a 'wep-key-type' property that is
used to specify the WEP key type and is needed because some keys could
be interpreted both as a passphrase or a hex/ascii key.
The ifcfg-rh plugin currently stores the key type implicitly: if
wep-key-type is 'passphrase' it uses the KEY_PASSPHRASE%d variable, if
it's 'key' the KEY%d variable and when it's 'unknown' it uses either
variables depending on the detected type (preferring 'key' in case
both are compatible).
This means that some connections will be read differently from how
they were written, because once the KEY (or KEY_PASSPHRASE) is read
there is no way to know whether the 'wep-key-type' property was 'key'
(or 'passphrase') or 'unknown'.
Fix this by persisting the key type explicitly in the file. The new
variable is redundant in most cases because the variables used for
keys also determine the key type.
https://bugzilla.redhat.com/show_bug.cgi?id=1518177
|
| |
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=791121
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
$ nmcli con add type wifi ifname wlan0 \
wifi-sec.key-mgmt none \
wifi-sec.wep-key0 $ascii_key \
ssid <TAB>
completes the line with:
"Info:\ WEP\ key\ is\ guessed\ to\ be\ of\ '2\ \(passphrase\)'"
The environment warning function should not emit warning when
completing arguments.
|
| |\
| |
| |
| | |
https://bugzilla.redhat.com/show_bug.cgi?id=1517794
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Until now the ifcfg-rh plugin merged the values of 'ipv4.dns-options'
and 'ipv6.dns-options' and wrote the result to the RES_OPTIONS
variable. This is wrong because writing a connection and reading it
back gives a different connection compared to the original.
This behavior existed since when DNS options were introduced, but it
became more evident now that we reread the connection after write,
because after doing a:
$ nmcli connection modify ethie ipv4.dns-options ndots:2
the connection has both ipv4.dns-options and ipv6.dns-options set. In
order to delete the option, an user has to delete it from both
settings:
$ nmcli connection modify ethie ipv4.dns-options "" ipv6.dns-options ""
To improve this let's use different variables for IPv4 and IPv6. To
keep backwards compatibility IPv4 still uses RES_OPTIONS, while IPv6
uses a new IPV6_RES_OPTIONS variable.
https://bugzilla.redhat.com/show_bug.cgi?id=1517794
|
| | |
| |
| |
| |
| | |
We must show the default value "(default)" when the list of
dns-options is initialized but empty.
|
| |/
|
|
| |
sed -i -e 's/inital/initial/g' $(git grep -l inital)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Commit 6a4af482f02c ("nmtui: always create ethernet settings for VLAN
and wireless security for wifi.") changed nmtui to always add the
wireless security setting to the new connection, but without
initializing it. This leads to a crash that was fixed in 40fcf67a8415
("tui: fix crash creating Wi-Fi connection").
There is an additional bug: connections without authentication can't
be saved because the wireless security setting has uninitialized
fields.
To fix this, revert both patches (the first partially) because the
previous code did the right thing as it added the setting only when
needed.
Fixes: 6a4af482f02c4342c69cd38dd46c078aeaf60d0d
https://bugzilla.redhat.com/show_bug.cgi?id=1518167
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
The matching works fuzzy and is not reliable. That is why we store
which connection should be assumed after restart in the state file
of NetworkManager.
In that case, we don't need to do a full check (with the possibility
of a false-reject). Just check for the minimum required properties:
the type and slave-type.
Yes, if the user modifies the connection while restarting NM, then
we might wrongly assume a connection that no longer would match.
But NM should not read minds, it should do as indicated.
|
| | |
|
