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".
Setting 'lacp_rate' is only possible in '802.3ad' (4) mode.
Otherwise writing to sysctl fails and results in the following
error log:
<error> [1412337854.026285] [platform/nm-linux-platform.c:2093] sysctl_set(): sysctl: failed to set '/sys/class/net/nm-bond/bonding/lacp_rate' to '0': (13) Permission denied
<warn> (nm-bond): failed to set bonding attribute 'lacp_rate' to '0'
Related: https://bugzilla.redhat.com/show_bug.cgi?id=1061702
Fixes: 47555449fa
Signed-off-by: Thomas Haller <thaller@redhat.com>
Cache the private DBUS connection and reuse it. Otherwise we end up
creating several private connnections, as an NMObject instance creates
a new connection (unless it is passed in as NMObject:dbus-connection
property).
We already pass the existing "parent" DBUS connection when creating
the proxy objects. However, when creating two independent objects
(e.g. nm_client_new() and nm_remote_settings_new()), their private
DBUS connections were not shared.
Implement this sharing inside nm-dbus-helpers.c
https://bugzilla.gnome.org/show_bug.cgi?id=737725
Signed-off-by: Thomas Haller <thaller@redhat.com>
Commit b732380d1e removed the gobject
property "NMObject:connection". However, this property is still needed
to inject the DBUS connection when creating new proxy objects. Without it,
we call _nm_dbus_new_connection() in the constructor for every proxy NMObject.
In case of non-private connections, g_bus_get_sync() already returns the same
connection. However for private connections, g_dbus_connection_new_for_address_sync()
would create a separate DBUS connection.
https://bugzilla.gnome.org/show_bug.cgi?id=737725
Signed-off-by: Thomas Haller <thaller@redhat.com>
