When config is NULL libteam will use its own default configuration.
Commit 76c3bd9898 changed that and refused to
create 'team' setting making connection invalid. It didn't set an error as
well, which resulted in
ifcfg-rh: parsing /etc/sysconfig/network-scripts/ifcfg-team ...
ifcfg-rh: error: (unknown)
GLib-CRITICAL **: g_propagate_error: assertion `src != NULL' failed
If we are assuming a connection at startup, the NMManager:startup
state doesn't need to wait for that activation to complete, since the
underlying device isn't going to change its configuration as a result
of it.
(In particular, NM considers virbr0 to be stalled at
NM_DEVICE_STATE_IP_CONFIG when it assumes it, since if it has no real
slaves, it won't yet have carrier. But this shouldn't block startup.)
We were setting GLIB_VERSION_MAX_ALLOWED to 2.34, since we provide
reimplementations of a few 2.34 functions in nm-glib-compat.h. But
this was turning off warnings for the 2.34+ APIs we *didn't* have
compat versions of too.
Fix this by setting MAX_ALLOWED to 2.32 (same as MIN_REQUIRED), and
defining macros to wrap calls to compat-ified functions and disable
deprecation warnings around them.
This points out several places where we were accidentally using 2.34
APIs without noticing, which need to be fixed now.
Add versioned NM_DEPRECATED_IN_* and NM_AVAILABLE_IN_* macros, and tag
new/deprecated functions accordingly. (All currently-deprecated
functions are assumed to have been deprecated in 0.9.10.)
Add NM_VERSION_MIN_REQUIRED and NM_VERSION_MAX_ALLOWED macros which
can be set to determine which versions will cause warnings.
With the current settings, external consumers of the
libnm-util/libnm-glib APIs will have MIN_REQUIRED and MAX_ALLOWED both
set to NM_VERSION_0_9_8 by default, meaning they will get warnings
about functions added in 0.9.10. NM internally sets
NM_VERSION_MAX_ALLOWED to NM_VERSION_NEXT_STABLE to ensure that it is
always allowed to use all APIs.
Most of these warnings are things libnm-glib can't do anything
about, and they are pretty annoying when running nmcli or nmtui,
and libraries usually shouldn't print random warnings anyway.
So downgrade them to debug messages that can be enabled if we
need to see them.
See also https://bugzilla.redhat.com/show_bug.cgi?id=886432, where
firewalld was changed, not to return ZONE_ALREADY_SET for 'changeZone'.
However, 'addInterface' can still fail with this error.
Suppress the following error lines:
<debug> [1392290031.179280] [firewall-manager/nm-firewall-manager.c:117] nm_firewall_manager_add_or_change_zone(): (em1) firewall zone add -> (null)
...
<warn> (em1) firewall zone add/change failed: (32) ZONE_ALREADY_SET
Signed-off-by: Thomas Haller <thaller@redhat.com>
$ nmcli dev connect wlan0
This can happen for example when some other process disconnects
the connection being connected.
Also fix printing a message on success.
https://bugzilla.redhat.com/show_bug.cgi?id=1064333
Avoid printing "nl_recvmsgs() error: (-33) Dump inconsistency detected,
interrupted". DUMP_INTR error is harmless for scan (see in code
comments).
Signed-off-by: Thomas Haller <thaller@redhat.com>
`make dist` packs the 'configure' file in the tarball, so this is
useful, to include the commit id into the release tarball.
Signed-off-by: Thomas Haller <thaller@redhat.com>
The [main] section is not mandatory.
Clarify in several places that the keyfile plugin is always used for
fallback, and that the [keyfile] section is normally only used if you
aren't using any other plugin.
Fix some erroneous references to "keyfile" and "ifdown" in the
ifupdown section.
Update the ifcfg-rh docs to list all currently-supported connection
types.
Swap the order of ifcfg-suse and ifupdown to make them alphabetical.
(Note that ifnet is currently missing.)
https://bugzilla.gnome.org/show_bug.cgi?id=720841
At critical times during the connection process, especially during
DHCP and EAPOL, the driver can increase the reliability of communication
in an attempt to increase the possibility of success. This could be
done by suppressing bluetooth for a short period, or locking in a low
(and thus more reliable) bitrate, or enforcing some other interference
protection. The 3.10 kernel added nl80211 support for this, so lets
use it if we can.
According to documentation, nl_rtgen_request() returns 0 on success.
Due to a bug (fixed upstream) in older libnl versions, nl_rtgen_request()
returns the number of bytes sent, which caused logging although
succeeding.
Signed-off-by: Thomas Haller <thaller@redhat.com>
Make it more clear, what the current monotonic_timestamp is and
what's it's offset to CLOCK_BOOTTIME.
Signed-off-by: Thomas Haller <thaller@redhat.com>
Add new functions nm_utils_get_monotonic_timestamp_*() to provide
means to get timestamps for calculating durations.
At several places, we used time() or clock_gettime() for that purpose.
Update and unify those places to make use of the new functions.
The new functions have the advantage, that the timestamps are guaranteed
to be positive and the timestamp is independent of clock adjustments.
Internally it uses CLOCK_BOOTTIME/clock_gettime.
https://bugzilla.gnome.org/show_bug.cgi?id=720833
Signed-off-by: Thomas Haller <thaller@redhat.com>
Make all the signals RUN_FIRST instead of RUN_LAST. In particular,
this fixes a crash when creating a new connection and activating the
listbox directly, in which case nmt_newt_listbox_activated() was
running after NmtAddConnection:create_connection() had already quit
the form and unrealized the listbox.
