nm_device_generate_connection() was allowing connections for master
devices to have no IP config, but this didn't really make much sense,
since they would just fail at stage3 in that case anyway.
Now that we get multiple tries at generating a connection on a device,
we can just ignore the device until it has a proper connection.
If the initial attempt to assume a connection on a device fails, and
the device remains un-activated, but then something changes its
configuration externally, try to generate a new connection and assume
that.
If the IP config changes on a device that has assumed a generated
connection, then update the connection's NMSettingIP4Config /
NMSettingIP6Config, under the assumption that the configuration of
that device was in progress but incomplete when NM first observed it.
NMIP4Config and NMIP6Config had methods to update an existing
NMSetting. However, the functions would really only work correctly if
the passed-in setting was empty.
Change them from "update_setting" to "create_setting", and have them
create the NMSetting themselves, and update NMDevice for that.
(If we need update_setting later, we can add it, after figuring out
exactly how it's actually supposed to work.)
Some tests want to assert against the messages logged using g_test_expect_message().
In this mode, nmtst will not log anything itself.
Interpret the option no-expect-message which turns g_test_expect_message()
into a NOP and turns logging on. The use of this is for debugging such
tests, without asserting against the messages but printing them instead.
For tests that are not in the assert_message mode, the option has no
effect.
Example:
NMTST_DEBUG=debug,no-expect-message make -C src/settings/plugins/keyfile/tests/ check
Signed-off-by: Thomas Haller <thaller@redhat.com>
In this mode, nmtst itself will not log anything and not set the logging
level. Also, it will set g_log_set_always_fatal().
This is for tests that want to assert against all logged messages via
g_test_expect_message().
In this mode also setting the logging level via NMTST_DEBUG variable has
no effect. The test is expected to manage the logging level itself and
changing the logging level might interfere with the test.
As a showcase, move keyfile/tests/test-keyfile.c to nmtst.
Signed-off-by: Thomas Haller <thaller@redhat.com>
Call to nmtst_reexec_sudo(), which allows you to specify a program
via environment variable to exec the test.
This is useful to exec the test program with sudo.
NMTST_DEBUG="no-debug,sudo-cmd=$PWD/tools/test-sudo-wrapper.sh" make -C src/platform/tests/ check
Signed-off-by: Thomas Haller <thaller@redhat.com>
Always run the linux platform tests, even if called as non-root user.
In such a case, print a message and return 77 (signalizing that the test
was skipped).
Only if we configured with --enable-test=root, we enforce that the
user executes the tests as root.
Co-Authored-By: Pavel Šimerda <psimerda@redhat.com>
Signed-off-by: Thomas Haller <thaller@redhat.com>
In older versions of team (e.g. Fedora 17), the master team device
stays up, even if no slaves are IFF_LOWER_UP. Workaround this bug.
Signed-off-by: Thomas Haller <thaller@redhat.com>
In this case, the fake platform implementation was wrong in that it did
not set the source property of the route/address objects like linux
platform does. Fix the test and the fake platform.
https://bugzilla.gnome.org/show_bug.cgi?id=706293
Signed-off-by: Thomas Haller <thaller@redhat.com>
The handling for announcing links was broken resulting in
duplicate link-added signals from platform.
Co-Authored-By: Thomas Haller <thaller@redhat.com>
Signed-off-by: Thomas Haller <thaller@redhat.com>
When adding a link, the Linux platform implementation raises the
link-changed signal synchronously. Fix the fake platform to behave identically
and also fix all the tests.
This also fixes the Linux platform tests for the most part because now the
test functions (and fake platform) behave like the Linux system
implementation.
https://bugzilla.gnome.org/show_bug.cgi?id=706293
Co-Authored-By: Thomas Haller <thaller@redhat.com>
Signed-off-by: Thomas Haller <thaller@redhat.com>
Firewalld call addInterface() fails with ZONE_CONFLICT if the interface
is already part of another zone. This complicates the code in NM,
because we would have to keep better track of the zone in which the
interface currently is. Which might be quite difficult because
the zone might be changed from an external program (so we would have
to monitor the firewall configuration and work around potential races).
A better and simpler fix is to simply always use the changeZone() call.
This will do the right thing, regardless if the interface is already part
of a zone or not.
https://bugzilla.redhat.com/show_bug.cgi?id=1103782
Signed-off-by: Thomas Haller <thaller@redhat.com>
The firewalld removeInterface call fails with ZONE_CONFLICT when
removing an interface from a wrong zone. This can happen, when the
connection gets modified, while being active (which is related to
bgo#724041).
By not specifying any zone, we remove the interface from the zone
where it currently is added. This behavior was introduced in upstream
firewalld with commit cc3101ab70a3997228be7bc9f45a069c7fccfa36, March 2012,
r0_2_3-1.
This is the behavior we actually want and we don't have to keep proper track
of the current zone.
https://bugzilla.redhat.com/show_bug.cgi?id=1103782
Signed-off-by: Thomas Haller <thaller@redhat.com>
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>
Add an additional address parameter to link_add/bridge_add, to set the
MAC address of software devices.
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>
