NMPolicy's auto_activate_device() was immediately removing the device
from priv->pending_activation_checks, which meant that if
nm_manager_activate_connection() had some side effect that would cause
schedule_activation_check() to be called again, another
auto-activation check could be queued while the first was still in
progress (causing a warning). Fix this by not removing the device from
the list until the activation attempt is complete.
This requires some additional minor changes to correctly handle the
possibility of remove_device() being triggered as a side effect of
nm_manager_activate_connection().
Also merge activate_data_new() into schedule_activation_check() so
that all the "start an auto-activation" code is in one place.
This change removed the "autoactivate" pending action too soon,
creating a window where the device had no pending actions, allowing
the manager to declare startup complete while devices were still being
activated.
This reverts commit a16b7a8253.
So far NetworkManager didn't tell which option it didn't know about:
Invalid option. Please use --help to see a list of valid options.
Now it is a bit more informative:
Unknown option --asdf. Please use --help to see a list of valid options.
The "Unknown option" string is marked as translatable in glib so i18n
doesn't suffer.
Signed-off-by: Thomas Haller <thaller@redhat.com>
Before, nm_platform_ip4_address_exists(), et al. look into the cache to see
whether the address/route already exists and returned an error if it
did.
Change the semantic of the delete functions, to return success in case of
"nothing to delete". Also always try to delete the object in the
kernel. The reason is, that the cache might be out of date and the
caller really wants to delete it. So, to be sure, we always delete.
In most cases the object is actually in the cache (because that is
how the caller came to know that such an object might exist).
In those cases, the lookup was not useful either, because the object
was actually cached.
Signed-off-by: Thomas Haller <thaller@redhat.com>
- refactor delete_object() by merging with delete_kernel_object()
- allow deletion of object that we cannot find in the cache
currently. The kernel might have such an address, even if we don't
have it currently cached. In this case, fall back to @obj.
Also try to work around an issue, that we cannot delete an IPv4 route without
knowing its scope.
- suppress logging error message for NLE_NOADDR, which is a common
failure when deleting an address. But at the same time, add some more
debug logging, for NLE_NOADDR and NLE_OBJ_NOTFOUND.
Signed-off-by: Thomas Haller <thaller@redhat.com>
Adding IPv4 routes, with a non-zero host identifer fails with an
error message. Adding IPv6 addresses, does not return an error,
but it seems to have no effect.
Thus we have to make sure that the host part of routes
is always zero.
Signed-off-by: Thomas Haller <thaller@redhat.com>
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.)
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.
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>
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>
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>
This feature needs support from the kernel and libnl.
If there is no system support, NM acts as before, adding the
autoconf address as /128. It does so, to prevent the kernel
from adding a route for this prefix. With system support, we
add the address as /64 and set the flag IFA_F_NOPREFIXROUTE.
https://bugzilla.redhat.com/show_bug.cgi?id=1044590https://bugzilla.redhat.com/show_bug.cgi?id=1045118
Signed-off-by: Thomas Haller <thaller@redhat.com>
The kernel adds a new capability to allow user space to manage
temporary IPv6 addresses. We need to detect this capability
to act differently, depending on whether NM has an older kernel
at hand.
This capability got introduced together when extending the
ifa_flags to 32 bit. So, we can check the netlink message,
whether we have such an nl attribute at hand.
Signed-off-by: Thomas Haller <thaller@redhat.com>
The kernel and libnl adds two new flags IFA_F_MANAGETEMPADDR
and IFA_F_NOPREFIXROUTE. Older versions of libnl do not recognize
this flag, so add a workaround to nm_platform_ip6_address_to_string()
to show "mngtmpaddr" and "noprefixroute", respectively.
Also, add function nm_platform_check_support_libnl_extended_ifa_flags()
that checks whether libnl supports extended ifa_flags that were
added recently.
Extended flags and the two ifa-flags above were added to libnl in close
succession.
Signed-off-by: Thomas Haller <thaller@redhat.com>
