This bug was present since a long time, however libnl3-v3.2.23
(commit fdd1ba220dd7b780400e9d0652cde80e59f63572) changed the returned
family of bridge link objects, which breaks NetworkManager.
This resulted in error messages such as:
DBG<4> object.c:207 nl_object_get: New reference to object 0x19c34b0, total 2
DBG<5> route/link.c:895 link_keygen: link 0x19c34b0 key (dev 9 fam 7) keysz 8, hash 0x2b2
DBG<2> hashtable.c:127 nl_hash_table_add: Warning: Add to hashtable found duplicate...
DBG<4> object.c:221 nl_object_put: Returned object reference 0x19c34b0, 1 remaining
NetworkManager[17745]: <error> [1392114373.475432] [platform/nm-linux-platform.c:1328] event_notification(): netlink cache error: Object exists
Even before the change of libnl, I saw the following error lines
<debug> [...] [platform/nm-linux-platform.c:1216] event_notification(): netlink event (type 16) for link: virbr0 (4)
<error> [...] [platform/nm-linux-platform.c:1265] event_notification(): netlink cache error: Object exists
Hence, the caching mechanism for libnl objects already had a bug.
For rtnl link objects, the identifier consists of family and ifindex.
Since in upper layers, we don't easily know the family, we need a way to find
the objects inside the cache. We do this, by only caching links of family
AF_UNSPEC.
Objects that we receive via event_notification() are never cached. They are only used
to trigger refetching the kernel_object. Their family is irrelevant, we
only need to know, that something about this ifindex changed.
For objects retrieved via get_kernel_object(), we only get link objects of
family AF_UNSPEC or AF_BRIDGE. In any case, we reset (coerce) their family
before caching. This way, inside the link cache, there are only objects with
(coerced) family AF_UNSPEC. We loose the information, which family the
link had, however we don't need it anyway.
https://bugzilla.gnome.org/show_bug.cgi?id=719905https://bugzilla.redhat.com/show_bug.cgi?id=1063290
Duplicates:
https://bugzilla.gnome.org/show_bug.cgi?id=724225https://bugzilla.redhat.com/show_bug.cgi?id=1063800
Signed-off-by: Thomas Haller <thaller@redhat.com>
Also, change the logging of nm_platform_ip._address_delete()
to log what we are about to do, *before* checking for existing
addresses.
Signed-off-by: Thomas Haller <thaller@redhat.com>
The previous implementation called nl_object_get() and nl_object_put()
each time in link_get(). As nl_object_get() and nl_object_put()
causes debug logging in libnl, this clutters the output.
Signed-off-by: Thomas Haller <thaller@redhat.com>
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>
