| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
| |
NetworkManager only responds to the last D-Bus call when called delete/down
for the same connection in quick succession. (It should be fixed later).
So do not issue the call multiple times to prevent that. Otherwise nmcli would
stall waiting for the response.
https://bugzilla.redhat.com/show_bug.cgi?id=1168657
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
It would subtract the configuration from device confguration that's not yet
applied. This a the race where the loose the address while activating a
connection that has both IPv6 and IPv4 configuration.
Fixes: 557667df12fc05b76326d6406553985effeeb2ac
https://bugzilla.gnome.org/show_bug.cgi?id=746066
|
| |
|
|
|
| |
Just move it upwards, we'll need it in
nm_device_activate_schedule_ip4_config_result().
|
| |
|
|
|
|
|
|
| |
These functions will sometimes get called on updates to the device's IP
config due to external changes, or when addresses get flushed from the
device when activating it. If the device is a slave device, then at
this point its NMConnection won't have an IP settings. Suppress the
warning that gets printed when s_ip == NULL, because it's expected.
|
| |
|
|
| |
Fixes: 5149fd120d24e7622fb264fffaa4bed04eb579d6
|
| | |
|
| |
|
|
|
| |
When iterating over a container variant, the children values
must be unrefed when no longer used.
|
| |
|
|
|
|
| |
It appears that the .isra and .part pieces can change depending on
how glib was built, so ignore those parts. Add some new suppressions
for newer glib too.
|
| |\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Move basic keyfile functionality from settings plugin to libnm-core.
This is a first step to have a semi-standard way to stringify
connections back and forth, which is also available to libnm users.
Still the new functions are internal API (nm-keyfile-internal.h).
Let's decide later how the public API should really look like.
https://bugzilla.gnome.org/show_bug.cgi?id=744699
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
keyfile should become our main import/export format. It is desirable,
that a keyfile can contain every aspect of a connection.
For blob certificates, the writer in core daemon would always write
them to a file and convert the scheme to path.
This behavior is not great for a (hyptetical) `nmcli connection export`
command because it would have to export them somehow outside of keyfile,
e.g. by writing them to temporary files.
Instead, if the write handler does not handle a certificate, use a
default implementation in nm_keyfile_write() which adds the blob inside
the keyfile.
Interestingly, keyfile reader already supported reading certificate
blobs. But this legacy format accepts the blob as arbitrary
binary without marking the format and without scheme prefix.
Instead of writing the binary data directly, write it with a new
uri scheme "data:;base64," and encode it in base64.
Also go through some lengths to make sure that whatever path
keyfile plugin writes, can be read back again. That is, because
keyfile writer preferably writes relative paths without prefix.
Add nm_keyfile_detect_unqualified_path_scheme() to encapsulate
the detection of pathnames without file:// prefix and use it to
check whether the path name must be fully qualified.
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| | |
These headers are not entirely private to libnm-core as they are also
used by keyfile plugin. Merge them to a new header file
nm-keyfile-internal.h so that the name makes the internal nature of the
header more apparent.
|
| | |
| |
| |
| | |
https://bugzilla.gnome.org/show_bug.cgi?id=744699
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This is the first step to move keyfile to libnm. For now, only
copy the files to make later changes nicer in git-history.
/bin/cp src/settings/plugins/keyfile/reader.c libnm-core/nm-keyfile-reader.c
/bin/cp src/settings/plugins/keyfile/reader.h libnm-core/nm-keyfile-reader.h
/bin/cp src/settings/plugins/keyfile/utils.c libnm-core/nm-keyfile-utils.c
/bin/cp src/settings/plugins/keyfile/utils.h libnm-core/nm-keyfile-utils.h
/bin/cp src/settings/plugins/keyfile/writer.c libnm-core/nm-keyfile-writer.c
/bin/cp src/settings/plugins/keyfile/writer.h libnm-core/nm-keyfile-writer.h
|
| | | |
|
| | |
| |
| |
| | |
_nm_utils_uuid_generate_from_strings()
|
| | | |
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| | |
nm_keyfile_plugin_kf_get_integer_list() should always set
@length to zero when returning no integer list. So, this
is probably correct. Still, just to be explicit, anticipate
and handle a missing @tmp_list.
|
| | |
| |
| |
| |
| | |
When interpreting a blob as filename, ensure that it contains
no NUL character (except the last char).
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
When setting the certificate glib properties directly,
we raise a g_warning() when the binary data is invalid.
But since the caller has no access to the validation function,
he cannot easily check whether his action will result
in a warning. Add nm_setting_802_1x_check_cert_scheme() for
that.
|
| | | |
|
| | |
| |
| |
| | |
Also assert that path is not empty.
|
| | |
| |
| |
| |
| | |
If we go through the lengths of clearing the allocated
memory, we must not forget @contents.
|
| | |
| |
| |
| |
| |
| |
| | |
A valid blob cannot start with "file://", otherwise it would
break the implementation of the certificate properties in
NMSetting8021x. Simply reject every blob in nm_setting_802_1x_set_ca_cert()
et al. that is not valid according to get_cert_scheme().
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
for NMSetting8021x
get_cert_scheme() would return PATH scheme for binary data that
later will be rejected by verify_cert(). Even worse, get_cert_scheme()
would not check whether the path is NUL terminated, hence the following
can crash for an invalid connection:
if (nm_setting_802_1x_get_ca_cert_scheme (s_8021x) == NM_SETTING_802_1X_CK_SCHEME_PATH)
g_print ("path: %s", nm_setting_802_1x_get_ca_cert_path (s_8021x))
Combine the two functions so that already get_cert_scheme() does
the same validation as verify_cert().
Also change behavior and be more strict about invalid paths:
- Now, the value is considered a PATH candidate if it starts with "file://",
(sans NUL character).
A change is that before, the "file://" (without NUL) would have
been treated as BLOB, now it is an invalid PATH (UNKNOWN).
- If the binary starts with "file://" it is considered as PATH but it
is only valid, if all the fllowing is true:
(a) the last character must be NUL.
(b) there is no other intermediate NUL character.
Before, an intermediate NUL character would have been accepted
and the remainder would be ignored.
(c) there is at least one non-NUL character after "file://".
(d) the string must be fully valid utf8.
The conditions (b) and (c) are new and some invalid(?) paths
might no longer validate.
Checking (d) moved from verify_cert() to get_cert_scheme().
As set_cert_prop_helper() already called verify_cert(), this
causes no additional change beyond (b).
|
| | |
| |
| |
| | |
g_critical()
|
| | | |
|
| |/ |
|
| |
|
|
|
| |
Taken from libgsystem:src/gsystem-local-alloc.c
(commit ad3a28c5f2520d0688730aa83eaee815fb9a5762).
|
| | |
|
| | |
|
| |
|
|
| |
and unquote strings in the array if required.
|
| |
|
|
| |
Fixes: 4c3ba29b4041a0644c7605898ac9c56efc2dafb2
|
| |
|
|
|
|
|
| |
Current Python NM example has a very crude connection state output
and the global NM connectivity is not used in them either.
https://bugzilla.gnome.org/show_bug.cgi?id=746045
|
| | |
|
| | |
|
| |
|
|
|
|
| |
Stupid C&P error made everything look like WPA1.
Fixes: 59c8192b22778ad4e025db7e60828ac8ccbcb070
|
| |
|
|
|
|
|
|
| |
The supplicant interface's proxy may outlive the interface object
itself, so we must ensure that all signal handlers are disconnected.
Fixes a crash on suspend/resume.
Fixes: 59c8192b22778ad4e025db7e60828ac8ccbcb070
|
| |
|
|
|
|
| |
https://mail.gnome.org/archives/networkmanager-list/2015-March/msg00024.html
Signed-off-by: Petr Vorel <petr.vorel@gmail.com>
|
| | |
|
| |\
| |
| |
| | |
Don't allow setting MTU to invalid values.
|
| | |
| |
| |
| |
| | |
Ensure it's always (before address configuration starts and on updates) >= 1280
and not higher than the device MTU.
|
| | |
| |
| |
| |
| | |
Just a refactoring, no functional change. This will make it easier to
coordinate the device MTU with IPv6 MTU.
|
| |/
|
|
|
|
| |
Just a refactoring, doesn't make any actual difference. It is consistent with
IPv4 and will make it easier to implement a policy to recover from incorrect
MTUs settings.
|
| | |
|
