Missing initializers together with automatic cleanup seem to annoy GCC's
-Werror=maybe-uninitialized, breaking the --enable-more-warnings=error
builds.
Synopsis:
nmcli agent { secret | polkit | all }
The command runs separate NetworkManager secret agent or session polkit agent, or both.
It is useful when
- no other secret agent is available (such as GUI nm-applet, gnome-shell, KDE applet)
- no other polkit agent is available (such as polkit-gnome-authentication-agent-1,
polkit-kde-authentication-agent-1 or lxpolkit)
https://bugzilla.gnome.org/show_bug.cgi?id=739568
It is useful for running nmcli without --ask option, i.e. non-interactively.
Example contents of the file:
wifi.psk: s e c r e t 12345
802-1x.password:kili manjaro
802-1x.pin:987654321
We must also remove -Waggregate-return from m4/compiler-warnings.m4 because systemd
uses aggregate return (correctly) in a couple cases, and we cannot keep single-level
makefiles and override aggregate-return only for the systemd sub-library.
This client currently only supports DHCPv4 because the base systemd code
does not yet fully support DHCPv6.
The systemd code was modified to add "#if 0 /* NM_IGNORED */"
around lines that cause problems for compilation or code that is
not actually used in the library.
An adaptation layer (nm-sd-adapt) was added for glue between
systemd functions and NetworkManager, but changes to the actual
systemd code have been kept to a minimum.
The sd_event/sd_event_source functions of systemd have been
re-implemented on top of the GLib main loop.
client->secs wasn't getting set in the REBOOT state, causing
an assertion. REBOOT should work the same way as INIT, per
RFC 2131:
secs 2 Filled in by client, seconds elapsed since client
began address acquisition or renewal process.
REBOOT is necessary because many DHCP servers (especially on
home routers) do not hand back the same IP address when in
response to a DISCOVER packet, even if the same client ID is used.
The raw socket sd_event_source used for DHCP server solicitations
was simply dropped on the floor when creating the new UDP socket
after a lease has been acquired. Clean it up properly so we're
not still listening and responding to events on it.
Non-ethernet interface types use different client identifier formats,
plus when doing DHCPv4 and DHCPv6 on the same interface, the client
identifier should be related per RFC 4361. Thus let the caller
override the existing MAC-based client identifier if necessary.
The plugin can indicate that this connection can persist across link
changes and other connectivity dropouts by passing this option
back in the SetConfig() calls.
If the VPN re-enters the STARTING state to indicate that it has
disconnected from the VPN server and is trying to reconnect, change
the VPN connection's state to indicate that connectivity may be
limited. Wait for the VPN to provide updated IP configuration
information from the reconnect to change back to the ACTIVATED
state.
This property will indicate that the user wishes the VPN connection
to stay active until explicitly disconnected, even across link changes
or other interruptions.
Property notifications are queued during object initialization and
reloading, but the added/removed signals were emitted immediately
even before the object was fully initialized.
Additionally, depending on how long asynchronous initialization took,
the notifications could have been emitted before the object was
fully initialized as deferred_notify_cb() wasn't being suppressed
until all the properties were complete.
For synchronous intialization, signals could be emitted at various
times during initialization and not all of the object's properties
may be read. Furthermore property notifications were queued in an
idle handler, which breaks users that may not use a mainloop. All
signals and notifications should be emitted immediately after
initialization is complete for synchronous initialization.
To make things consistent and ensure that all signals and notifications
are emitted only when initialization is complete, queue signals for
deferred emission and only run notifications/signals when all the
object's properties have been read. For synchronous initialization,
emit all notifications and signals immediately after initialization
and not from an idle handler.
If the operation isn't canceled it returns an error, printing this:
/libnm/client-nm-running:
(/home/dcbw/Development/fdo/NetworkManager/libnm/tests/.libs/lt-test-nm-client:17983): libnm-WARNING **: updated_properties: error reading NMRemoteSettings properties: GDBus.Error:org.freedesktop.DBus.Error.NoReply: Message did not receive a reply (timeout by message bus)
/bin/sh: line 5: 17983 Trace/breakpoint trap ./libnm-test-launch.sh ${dir}$tst
FAIL: test-nm-client
which screws up testcases because they don't expect this message.
And in this case, since libnm knows that NM is exiting and will
just clear out the properties anyway, it's useless to print the message.
Test case:
nmcli> goto ipv4.addresses
nmcli ipv4.addresses> set 1.1.1.1
Do you also want to set 'ipv4.method' to 'manual'? [yes]: no
nmcli ipv4.addresses> set 3.3.3.3/99
Error: failed to set 'addresses' property: invalid prefix '99'; <1-32> allowed
Do you also want to set 'ipv4.method' to 'manual'? [yes]:
The second question (after failed 'set') should not be asked.
while editing an existing commention.
It was broken by commit 45590f809a that called
nm_connection_replace_settings_from_connection() which replaces settings with
connected signal handlers.
They are defined as gint32 but are assigned a guint32 value and
then immediately passed back to the caller of _address_get_lifetime()
as guint32. They can never be negative, and may receive values
greater than G_MAXINT32, so they should be unsigned.
nm-dbus-helpers-private.h is a private header file to libnm-glib/.
nm-settings-connection-glue.h and nm-settings-glue.h are not part
of libnm-glib/, they are inside src/.
Signed-off-by: Thomas Haller <thaller@redhat.com>
When the DHCP server address is not on the same subnet, we used
to add a /32 route to the server IP address via the gateway.
Do not add this route, if we already got a direct route from DHCP.
https://bugzilla.gnome.org/show_bug.cgi?id=738590
Signed-off-by: Thomas Haller <thaller@redhat.com>
add two functions nm_ip4_config_get_direct_route_for_host()
and nm_ip6_config_get_direct_route_for_host() to check if we have
a direct (non-gw) route to a certain host.
Signed-off-by: Thomas Haller <thaller@redhat.com>
https://bugzilla.gnome.org/show_bug.cgi?id=738590
