Make sure NMPlatformGreProperties->path_mtu_discovery is always TRUE
or FALSE, even if the value from the kernel is "2" or "16" or
something. (This makes it consistent with what we do for other boolean
netlink properties.)
If the kernel doesn't tag a modem's ethernet interface with
DEVTYPE=wwan then NetworkManager has no idea that's a modem
(and cannot be used until connected via the control port).
Since DEVTYPE=wwan devices get ignored by NM, so should these
interfaces when NM knows they are modems.
That got broken at some point for ModemManager1, because the
data port isn't read until the modem is connected. NM only
looked for and removed the data-port-as-ethernet-device when
the modem was added, long before the MM1 data port was found.
ModemManager does provide a list of ports owned by the modem
though, which we can use at modem addition time to remove
an ethernet device that is controled by the modem.
Auth requests only happen during activation and there's no need to
request secrets at any other time. Ensure that the device state
won't change to NEED_AUTH except when activating.
(There's a case in NMModemBroadband where set_mm_enabled()
when the modem is locked may cause this, but we'll solve this
a different way later.)
https://bugzilla.redhat.com/show_bug.cgi?id=1058308
When c4fc72c7 began using the DEACTIVATING state, the modem code
wasn't updated to handle this. Because it only checked for
activating or ACTIVATED states to determine whether the modem was
previously connected, and thus when an MM disconnect was needed,
when the device enters the DISCONNECTED state it was no longer
considered previously active, and not disconnected.
Also, remove the NEED_AUTH handling from the modem code's device
state switch, because it does not appear to be needed. The
modem will only enter NEED_AUTH when it requires PAP/CHAP secrets
during the connection attempt or when a PIN is required before
enabling the modem. In both cases the modem won't yet be connected,
so this code will never be hit.
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>
