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>
When reinstalling NM on the same location, it would fail with
Making install in data
make[1]: Entering directory `/home/data/src/NetworkManager/data'
make[2]: Entering directory `/home/data/src/NetworkManager/data'
install -d /opt/test/lib/systemd/system/network-online.target.wants
ln -s /opt/test/lib/systemd/system/NetworkManager-wait-online.service /opt/test/lib/systemd/system/network-online.target.wants
ln: failed to create symbolic link ‘/opt/test/lib/systemd/system/network-online.target.wants/NetworkManager-wait-online.service’: File exists
make[2]: *** [install-exec-local] Error 1
https://bugzilla.gnome.org/show_bug.cgi?id=728965
Signed-off-by: Thomas Haller <thaller@redhat.com>
nmtui is long part of the NM main source. Remove the code from the build.sh
script to add 'nmtui' from an external tarball.
Signed-off-by: Thomas Haller <thaller@redhat.com>
Make network-online.target depend on NetworkManager-wait-online.service
just as is done in Fedora. This makes network-online.target work with
NetworkManager as described in systemd documentation.
An alternative way would be to use a combination of setting
Install.WantedBy to network-online.target and enabling the service by
default. This alternative approach is currently used by
systemd-networkd.
https://bugzilla.gnome.org/show_bug.cgi?id=728965
Acked-By: Dan Williams <dcbw@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 allows setting bridge MAC either on command-line
nmcli con add type bridge con-name mybridge mac 11:22:33:44:55:66
or provide it when asked
nmcli -a con add type bridge con-name mybridge
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>
Use nm_utils_hwaddr_ntoa_len() instead of nm_utils_hwaddr_ntoa().
This makes it no longer necessary to determine the type of the MAC
address based on the address length.
This makes the GETTER more accepting towards other lengths.
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>
