The autoconnect priority has only any relevance, if the connection
is autoconnect too.
The priority defaults to zero, with higher numbers meaning preferred.
The valid range is limited to [-999,999].
Signed-off-by: Thomas Haller <thaller@redhat.com>
If the assertion in verifies_without_normalization() fails due to
@was_modified, the error message is not helpful.
Assert first against the content of the connection. This prints
most likely the settings that were actually modified.
Signed-off-by: Thomas Haller <thaller@redhat.com>
nm_client_new_async() got broken in the NMManager split. Fix it, and
use it from one of the tests in test-nm-client to make sure it's
getting tested in the future.
NMActiveConnection:connection was an object path rather than an
NMRemoteConnection because in the past the NMObject property system
wasn't capable of handling NMRemoteConnection-valued properties.
NMActiveConnection:master was an object path rather than an NMDevice
entirely by accident. Fix both.
NMActiveConnection:specific-object can't currently be converted to an
object, because we don't know ahead of time what object type it is,
and NMObject can't deal with that. Instead, we rename it to
:specific-object-path (and likewise for its get function), both to
emphasize that it doesn't behave like other properties, and to leave
the old name open for an actual object-valued property later on.
Add a single function to check if NM is running and set a GError if
not, then use it as appropriate.
Don't bother to check if NM is running in get_*() functions if
nm_running_changed_cb() would have reset the field anyway (and fix
that up to reset a few more fields).
Rearrange the NMClient function declarations and the functions
themselves, and group them into "general", "device", and "active
connection" sections.
No code changes, just moving things around.
All callers only pass a PID that previously was returned from
spawning a process. AFAIS, there is no officially reserved range
for lower PIDs that would enforce valid PIDs to be larger then 25.
Relax this check.
Signed-off-by: Thomas Haller <thaller@redhat.com>
nm_utils_kill_child_sync() is not able to reap the external process.
This causes NM to hang for 500 ms and logs the following error:
<debug> [1412167360.400201] [NetworkManagerUtils.c:534] nm_utils_kill_child_sync(): kill child process 'dhcp-client' (7109): waiting up to 500 milliseconds for process to terminate normally afte
<debug> [1412167360.900298] [NetworkManagerUtils.c:549] nm_utils_kill_child_sync(): kill child process 'dhcp-client' (7109): sending SIGKILL...
<error> [1412167360.900369] [NetworkManagerUtils.c:576] nm_utils_kill_child_sync(): kill child process 'dhcp-client' (7109): after sending SIGTERM (15) and SIGKILL, waitpid failed with No child
Signed-off-by: Thomas Haller <thaller@redhat.com>
This utility function is for killing other processes.
Contrary to nm_utils_kill_child_*() which is for killing
and reaping child processes.
Signed-off-by: Thomas Haller <thaller@redhat.com>
The supplicant has a custom parsing function for freq_list which
handles the list as a string. Having NM marshal the option
as TYPE_BYTES causes the supplicant to interpret the values that
NM passes (which are in ASCII) as a byte-array and thus the
supplicant gets a bogus frequency list. Instead, NM should
marshal freq_list as a simple string (using TYPE_KEYWORD without
value checking).
https://bugzilla.gnome.org/show_bug.cgi?id=737795
- fix memleaks if the script contains duplicate lines
- only accept either dhclient or dhcpcd syntax, depending
on the file
- be more strikt in parsing:
- don't use strstr() when parsing dhcpcd.conf. It wrongly
accepts "# send dhcp-client-identifier".
- enfore that keyword are terminated by space. Would no longer
accept "hostnameHOSTNAME"
- be less strict in parsing:
- accept any number of spaces between "send" and "host-name"/
"dhcp-client-identifier"
https://bugzilla.gnome.org/show_bug.cgi?id=738125
Signed-off-by: Thomas Haller <thaller@redhat.com>
If a master is deleted but its slaves are left behind, show those
slaves in the appropriate part of the connection list, so they can be
deleted. (This code is just copied from nm-connection-editor.)
nmt_newt_grid_size_allocate() depends on nmt_newt_grid_size_request()
having been called immediately prior, which would normally be true,
except that NmtNewtSection adjusts the label widgets in its border to
match its allocation, so when its size changes, it will end up calling
size_allocate() on the border with out-of-date requisition data. Fix
that by re-size_requesting the border after modifying it.
https://bugzilla.gnome.org/show_bug.cgi?id=738010
The messages logged by nm-dbus-manager.c are not very useful, but amount to
a significant part of DEBUG logging. Log those messages with the lower TRACE priority.
Signed-off-by: Thomas Haller <thaller@redhat.com>
nm_client_activate_connection() and
nm_client_add_and_activate_connection() return when the activation has
*started*, not when it *finishes*. Clarify this a bit more in the
libnm docs, and copy that clarification to libnm-glib as well.
https://bugzilla.gnome.org/show_bug.cgi?id=736233
NMSettingSerial:parity was defined as a char-typed property that could
have the (case-sensitive!) values 'n', 'E', or 'o'. This is zany. Add
an NMSettingSerialParity enum, and use that instead.
Make enum- and flags-valued properties use GParamSpecEnum and
GParamSpecFlags, for better introspectability/bindability.
This requires no changes outside libnm-core/libnm since the expected
data size is still the same with g_object_get()/g_object_set(), and
GLib will internally convert between int/uint and enum/flags GValues
when using g_object_get_property()/g_object_set_property().
Redo the HANDLE_TYPE macro in demarshal_generic() in a more
syntactically-sane way (both to help the editor with indentation and
to make it not look so weird).
Also, if demarshal_generic() is asked to handle a property of a type
that it doesn't know how to handle, that's a programmer error, so do a
g_warning() in that case (as opposed to being asked to demarshal a
value of the wrong D-Bus type, which could just be a bug in the peer
that sent the data, so that stays as a debug message).
The code was mistakenly still using G_VALUE_TYPE_NAME() instead of
g_variant_get_type_string().
Also, refer to the properties with standard gtk-doc punctuation:
"TypeName:property-name".
