Fixes the following g_warn():
#0 0x0000003370c504e9 in g_logv () from /lib64/libglib-2.0.so.0
#1 0x0000003370c5063f in g_log () from /lib64/libglib-2.0.so.0
#2 0x0000003370c50956 in g_warn_message () from /lib64/libglib-2.0.so.0
#3 0x0000000000439962 in carrier_changed (device=0x1d94300, carrier=1) at devices/nm-device.c:1021
#4 0x0000000000488f12 in carrier_changed (device=0x1d94300, carrier=1) at devices/nm-device-ethernet.c:1646
#5 0x0000000000434c94 in nm_device_set_carrier (device=device@entry=0x1d94300, carrier=1) at devices/nm-device.c:1104
#6 0x0000000000434dd5 in check_carrier (device=device@entry=0x1d94300) at devices/nm-device.c:1298
#7 0x0000000000434ef8 in constructed (object=0x1d94300) at devices/nm-device.c:550
#8 0x0000003371c15d87 in g_object_new_internal () from /lib64/libgobject-2.0.so.0
#9 0x0000003371c17814 in g_object_new_valist () from /lib64/libgobject-2.0.so.0
#10 0x0000003371c17c11 in g_object_new () from /lib64/libgobject-2.0.so.0
#11 0x000000000048bc2e in nm_device_ethernet_new (platform_device=platform_device@entry=0x1d82e58) at devices/nm-device-ethernet.c:336
#12 0x000000000047c600 in platform_link_added (self=0x1d70150, ifindex=ifindex@entry=2, plink=plink@entry=0x1d82e58, reason=reason@entry=NM_PLATFORM_REASON_INTERNAL) at nm-manager.c:1954
#13 0x000000000047c7db in platform_link_cb (platform=<optimized out>, ifindex=2, plink=0x1d82e58, change_type=<optimized out>, reason=NM_PLATFORM_REASON_INTERNAL, user_data=0x1d70150) at nm-manager.c:2038
#14 0x0000003371805d8c in ffi_call_unix64 () from /lib64/libffi.so.6
#15 0x00000033718056bc in ffi_call () from /lib64/libffi.so.6
#16 0x0000003371c10ad8 in g_cclosure_marshal_generic () from /lib64/libgobject-2.0.so.0
#17 0x0000003371c10298 in g_closure_invoke () from /lib64/libgobject-2.0.so.0
#18 0x0000003371c2235d in signal_emit_unlocked_R () from /lib64/libgobject-2.0.so.0
#19 0x0000003371c2a0f2 in g_signal_emit_valist () from /lib64/libgobject-2.0.so.0
#20 0x0000003371c2a3af in g_signal_emit () from /lib64/libgobject-2.0.so.0
#21 0x000000000044f6ba in nm_platform_query_devices () at platform/nm-platform.c:330
#22 0x000000000047de4c in nm_manager_start (self=0x1d70150) at nm-manager.c:4025
#23 0x0000000000429d31 in main (argc=1, argv=0x7fffb4c31628) at main.c:654
https://mail.gnome.org/archives/networkmanager-list/2014-June/msg00000.html
Signed-off-by: Thomas Haller <thaller@redhat.com>
The logging routines are not thread-safe in general, so there is no
need for trying to make nm_logging_syslog_openlog() thread-safe.
Also nm_logging_syslog_openlog() is only called by the main() routine.
Signed-off-by: Thomas Haller <thaller@redhat.com>
When starting firewall, NMPolicy would fail the following assertion:
NetworkManager[1462]: <debug> [1401708294.250829] [firewall-manager/nm-firewall-manager.c:218] name_owner_changed(): firewall started
(NetworkManager:1462): libnm-util-CRITICAL **: nm_connection_get_setting_connection: assertion 'NM_IS_CONNECTION (connection)' failed
#0 0x0000003370c504e9 in g_logv () from /lib64/libglib-2.0.so.0
#1 0x0000003370c5063f in g_log () from /lib64/libglib-2.0.so.0
#2 0x00007f306f960e11 in nm_connection_get_setting_connection (connection=0x0) at nm-connection.c:1441
#3 0x0000000000482319 in firewall_started (manager=<optimized out>, user_data=<optimized out>) at nm-policy.c:1881
#4 0x0000003371c104c7 in _g_closure_invoke_va () from /lib64/libgobject-2.0.so.0
#5 0x0000003371c29749 in g_signal_emit_valist () from /lib64/libgobject-2.0.so.0
#6 0x0000003371c2a3af in g_signal_emit () from /lib64/libgobject-2.0.so.0
#7 0x0000000000445d39 in name_owner_changed (dbus_mgr=<optimized out>, name=<optimized out>, old_owner=0x1452660 "", new_owner=0x1536720 ":1.175", user_data=<optimized out>) at firewall-manager/nm-firewall-manager.c:220
...
Signed-off-by: Thomas Haller <thaller@redhat.com>
The script is called synchronously from NetworkManager so it can handle
asynchronicity itself. The long-term plan is to incorporate the script
partially into the new plugin and partially into a dnssec-trigger
library which will be used instead of dnssec-trigger daemon.
https://bugzilla.gnome.org/show_bug.cgi?id=699810
Acked-By: Thomas Haller <thaller@redhat.com>
Acked-By: Dan Williams <dcbw@redhat.com>
When doing a lookup for an libnl route, the cache comparison function
for routes takes into account 'family', 'tos', 'table', 'dst', and 'prio'.
In NetworkManager we don't use all of these properties for a route, so
at several places when doing a cache lookup we don't have all identifying
properties. Usually we only have 'family' and 'dst' ('table' is
implicit 0, because NM does currently not care about any other tables).
The problem is that NM sees routes with different 'tos', 'prio', but it
cannot look them up in the cache. Add a hack to search the cache
fuzzy.
This is similar to the hack for link, where the identifying properties
are 'family' and 'ifindex', but we only have 'ifindex' at hand. However,
contrary to this hack, we coerce the 'family' to AF_UNSPEC for every link cache
operation. This is not viable in this case, because we internally need
the 'tos' field.
We need the 'tos' field because when deleting an IPv4 route, the 'tos' field must
match. See fib_table_delete(). This was already partially fixed by commit
f0daf90298, but before the lookup to the
cached object would fail for any non-zero 'tos'.
Signed-off-by: Thomas Haller <thaller@redhat.com>
check_cache_items() iterated over all items and called refresh_object().
But refresh_object() might remove the current object from the cache, so
this would break the iteration.
Instead check the items in two steps. First find all the objects we care
about and build a list of them. Then check them.
Signed-off-by: Thomas Haller <thaller@redhat.com>
By passing INADDR_ANY as a gconstpointer, we actually always passed NULL
as gateway. Maybe this was not intended, but it seems correct now
and is proven to work. So this fixe has no behavioral change.
Signed-off-by: Thomas Haller <thaller@redhat.com>
This feature requires recent support from the kernel.
Most notably these upstream kernel commits are required:
- 92c0574f11598c8036f81e27d2e8bdd6eed7d76d
- 43598813386f6205edf3c21f1fe97f731ccb4f15
- 30313a3d5794472c3548d7288e306a5492030370
The latter of them was merged to upstream kernel version 3.15-rc5.
https://bugzilla.gnome.org/show_bug.cgi?id=729844
Signed-off-by: Thomas Haller <thaller@redhat.com>
It's only ever used as an MAC address array, so we might as well
make it one instead of a string. Saves a memory allocation and
some cycles converting back and forth.
This also fixes a bug, where NMDeviceBt:check_connection_compatible()
would not set GError on mismatch of bdaddr.
Signed-off-by: Thomas Haller <thaller@redhat.com>
If we had a connection with IPv6.method = ignore, we simply ignored IPv6. So
we should assume this connection even if there is an SLAAC address on the
interface.
https://bugzilla.redhat.com/show_bug.cgi?id=1083196
When reading a hardware address in keyfile plugin, check for the
expected length already in mac_address_parser().
Before, we would call the deprecated function nm_utils_hwaddr_type()
to see if it can be some kind of MAC address. In that case, the error
was caught later during NMSetting:verify().
Signed-off-by: Thomas Haller <thaller@redhat.com>
When converting the MAC address to keyfile value, simply accept
any given byte array and pass it to nm_utils_hwaddr_ntoa_len().
This no longer restricts the length of accepted addresses as known by
nm_utils_hwaddr_type(). It is up to the caller to perform any validation
of the MAC address.
Signed-off-by: Thomas Haller <thaller@redhat.com>
- nm_utils_hwaddr_len() and nm_utils_hwaddr_type() no longer assert
against known input types/lengths. Now they can be used to detect the
hwaddr type, returning -1 on unknown.
- more checking of input arguments in nm_utils_hwaddr_aton() and
related. Also note, that nm_utils_hwaddr_aton_len() has @len of type
gsize, so we cannot pass on the output of nm_utils_hwaddr_len()
without checking for -1.
Signed-off-by: Thomas Haller <thaller@redhat.com>
Don't call nm_utils_hwaddr_type () with random len, because it causes ugly
(NetworkManager:25325): libnm-util-CRITICAL **: file nm-utils.c: line 1989 (nm_utils_hwaddr_type): should not be reached
And add a testcase.
https://bugzilla.gnome.org/show_bug.cgi?id=730514
When deleting an IPv4 route, several fields must match (or be left
unspecified/zero). See fib_table_delete().
Previously, NM would look into the cache and use that object for
deletion. This was changed recently, thereby breaking the deletion
of routes by not specifying all properties as needed.
Fixes regression introduced by commit 019bf7512d.
Related: https://bugzilla.gnome.org/show_bug.cgi?id=726273
Signed-off-by: Thomas Haller <thaller@redhat.com>
Thomas points out that the previous refactoring moved the
link_changed() virtual method invocation relative to
update_for_ip_ifname_change(), which could have weird side effects
given the things that can happen there. So move it back.
Previously, we always lookup the cache for libnl objects and used those for
delete_object(). This was necessary, because libnl guesses and overwrites
the IPv4 route scope.
Newer libnl no longer overwrites the scope if set explicitly to RT_SCOPE_NOWHERE.
So, this workaround is no longer needed. Indeed there might be cases, where it is
harmful, because we might guess the wrong scope.
This was fixed in libnl3 in commits
85ec9c7ad8015c4ee59bhttps://bugzilla.gnome.org/show_bug.cgi?id=726273
Signed-off-by: Thomas Haller <thaller@redhat.com>
The libnl function nl_has_capability() was only added recently, so don't depend on it
at compile time. Instead use dlopen to load the function if the libnl library contains it.
Signed-off-by: Thomas Haller <thaller@redhat.com>
Bond, bridge, and team were notifying their "slaves" properties before
the slave actually got removed from priv->slaves, meaning that
anything that looked at the property directly from a notify::slaves
handler would see the old value. Fix that.
Keep priv->slaves in the order that slaves were attached, rather than
in reverse order.
Among other things, this makes the errors from
nm_device_master_check_slave_physical_port() more consistent.
For the factory, the only public symbols should be the factory functions.
For the WWAN library, the only public symbols should be those that
NMDeviceModem and NMDeviceBt use.
Instead of having a GObject property and a factory function to get
the plugin's device type, just use the factory function, since it
always has to be around.
