While technically it's already possible to implement a fail-over
mechanism using multiple connections (for example, defining a higher
priority DHCP connection with short DHCP timeout and a lower priority
one with static address), in practice this doesn't work well as we try
to autoactivate each connection 4 times before switching to the next
one.
Introduce a connection.autoconnect-retries property that can be used
to change the number of retries. The special value 0 means infinite
and can be used to try the connection forever. A -1 value means the
global configured default, which is equal to 4 unless overridden.
https://bugzilla.gnome.org/show_bug.cgi?id=763524
We connect signal handlers to devices when they appear, but don't
disconnect the handlers when the manager instance is destroyed. This
can cause crashes as device_ac_changed() is called on an invalid
manager instance.
Disconnect the handlers from dispose().
https://bugzilla.redhat.com/show_bug.cgi?id=1383758
The @assoc_cancellable was never initialized and thus ineffective; fix
this.
Furthermore, we only cancel it in nm_supplicant_interface_disconnect()
as we expect that clients call the function before destroying the
interface. Don't assume this and also cancel it in dispose().
https://bugzilla.redhat.com/show_bug.cgi?id=1383628
Make link domain settings more conventional. If an IP Config only has no
search entries, use domains for search instead otherwise ignore domains.
Also on connections which are never the default, setup the
search/domains as routing-only meaning that only dns queries for those
domains will be done on this link. Prevents quering DNS information for
on-vpn host with other namservers and using the VPN DNS server for host
not on the VPN.
This is also fixes issues with a recent change in systemd-resolved where
links with a routing domain will only be used for those domains, which
meant that the previous strategry with a typical ip configuration (no
search only domains) resulted in no usable name resolution.
Signed-off-by: Sjoerd Simons <sjoerd.simons@collabora.co.uk>
https://bugzilla.gnome.org/show_bug.cgi?id=772343
Originally, the "callouts" directory contained various programs
that NetworkManager would call, for example the dhcp helper.
For a while, it only contains nm-dispatcher. Thus rename the directory
to indicate that it's for dispatcher.
Backported symbols only make sense for libnm itself, not for
libnm-core which is statically linked with NetworkManager and
nm-ifcace-helper. Declaring the symbols in libnm-core, means
that NetworkManager binary also contains them, although there
are not used.
Move them to libnm.
- this allows the linker to drop unused symbols via link-time optimization
or with --gc-sections:
git clean -fdx
./autogen.sh --enable-ld-gc --enable-ifcfg-rh --enable-ifupdown \
--enable-ifnet --enable-ibft --enable-teamdctl --enable-wifi \
--with-modem-manager-1 --with-ofono --with-more-asserts \
--with-more-logging
make -j20
strip ./src/NetworkManager
gives 2822840 vs. 2625960 bytes (-7%).
- this also gives more control over the symbols that are used by the
plugins. Yes, it means if you modify a plugin to use a new symbols,
you have to extend NetworkManager.ver file.
You can run the script to create the version file:
$ ./tools/create-exports-NetworkManager.sh update
but be sure that your current configuration enables all plugins
and debugging options to actually use all symbols that are in use.
- If you compile with certain plugins enabled, you could theoretically
re-compile NetworkManager to expose less symbols. Try:
$ ./tools/create-exports-NetworkManager.sh build
- note that we have `make check` tests to ensure that all used
symbols of the plugins can be found. So, it should not be possible
to accidentally forget to expose a symbol.
We should enable tests by default, probably we even should drop
the configure flags to enable tests and just always build them.
Anyway, at this point there is no use in guarding check-local
with a check for ENABLE_TESTS. A user who does't want to run
the tests, should just not call `make check`.
Pacrunner uses the interface information to implement a myIpAddress()
function which returns the first IPv4 address of the interface
associated to a proxy. That function doesn't deal with multiple
addresses per interface, and so in case of a VPN which configures
addresses on the parent interface (e.g. IPsec), we currently pass a
NULL interface. That is correct, but triggers the following assertion:
GLib-CRITICAL **: g_variant_new_variant: assertion 'value != NULL' failed
#0 g_logv () from target:/lib64/libglib-2.0.so.0
#1 g_log () from target:/lib64/libglib-2.0.so.0
#2 g_variant_new_string () from target:/lib64/libglib-2.0.so.0
#3 nm_pacrunner_manager_send (self=0xab3230, iface=iface@entry=0x0, proxy_config=proxy_config@entry=0xc83470, ip4_config=ip4_config@entry=0x7f66b4002710, ip6_config=ip6_config@entry=0x0) at nm-pacrunner-manager.c:334
#4 _set_vpn_state (self=self@entry=0xd0c120, vpn_state=vpn_state@entry=STATE_ACTIVATED, reason=reason@entry=NM_VPN_CONNECTION_STATE_REASON_NONE, quitting=quitting@entry=0) at vpn-manager/nm-vpn-connection.c:571
#5 dispatcher_pre_up_done (call_id=<optimized out>, user_data=<optimized out>) at vpn-manager/nm-vpn-connection.c:460
#6 dispatcher_done_cb (proxy=0x988870, result=<optimized out>, user_data=0xae1740) at nm-dispatcher.c:444
Ignore the interface parameter when it's NULL.
In some places we use g_file_set_contents() after a umask() to limit
the permissions of the created file. Unfortunately if the containing
directory has a default ACL the umask will be ignored and the new file
will have a mode equal to the default ACL (since g_file_set_contents()
opens the file with mode 0666).
Calling a chmod() after the file gets created is insecure (see commit
60b7ed3bdc) and so the only solution seems to be to reimplement
g_file_set_contents() and accept a mode as parameter.
We already had similar functions in the tree, consolidate them into a
new generic utility function.
https://bugzilla.gnome.org/show_bug.cgi?id=769702
g_assert() uses G_LIKELY(), which in turn uses _G_BOOLEAN_EXPR().
As glib's version of _G_BOOLEAN_EXPR() uses a local variable
_g_boolean_var_, we cannot nest a G_LIKELY() inside a G_LIKELY(),
or inside a g_assert(), or a g_assert() inside a g_assert().
Workaround that, by redefining the macro.
I already encountered this problem before, when having a nm_assert()
inside a ({...}) block, inside a g_assert(). Then I just avoided that
combination, but this situation is quite easy to encounter.
