Some initscripts variables can use "0" or "1" instead of more common
"yes", "no", for example REORDER_HDR.
And we also write REORDER_HDR=0|1 in writer.c, so we did not read REODER_HDR
correctly.
Fixes: ccea442504
The kernel defaults REORDER_HDR to 1 when creating a new VLAN, but
NetworkManager's VLAN flags property defaulted to 0. Thus REORDER_HDR was not
set for NM-created VLANs with default values.
We want to match the kernel default, so we change the default value for the
vlan.flags property. However, we do not want to change the flags for existing
connections if the property is missing in connection files. Thus we have to
update plugins for that. We also make sure that vlan.flags is always written
by 'keyfile' when the value is default. That way new connections have flags
property explicitly written and it will be loaded as expected.
https://bugzilla.redhat.com/show_bug.cgi?id=1250225
Don't handle master-ready at the beginning of stage2, but instead while
scheduling (and then possibly delaying the scheduling of stage2).
This seems more idiomatic:
When inside a stage and your part is done: call schedule-next-stage.
That is, always schedule the next stage, not the current one.
schedule-next-stage then might delay to really scheduling until the
device is ready for the next state.
Fixes: 85ac903bb8
During stage2, if the slave detected that it would need to wait for
the master, it would return FALSE (which removes the g-idle-handler).
However, it would not clear the activation-source, so later, when
the master becomes ready, its attempt to schedule stage2 again would
result in an error-log and the idle-handler would not be scheduled
again.
Fixes: 85ac903bb8https://bugzilla.redhat.com/show_bug.cgi?id=1268797https://bugzilla.redhat.com/show_bug.cgi?id=1183444
No longer support disabling the global-dns configuration via the
"enable" option.
Instead, the user can put the entire dns-configuration in one separate
snippet, and disable it altogether with ".config.enable".
Support a new configuration option
[.config]
enable=<ENABLED>
for configuration snippets.
This new [.config] section is only relevant within the snippet itself
and it is not merged into the combined configuration.
Currently only the "enable" key is supported. If the "enable" key is
missing, it obviously defaults to being enabled. It allows snippets
to be skipped from loading. The main configuration "NetworkManager.conf"
cannot be skipped.
<ENABLED> can be a boolean value (false), to skip a configuration
snippet from loading.
It can also be a string to match against the NetworkManager version,
like "enable=nm-version-min:1.1,nm-version-min:1.0.6"
There are several motivations for this:
- the user can disable an entire configuration snippet by toggeling
one entry.
This generalizes the functionality of the global-dns.enable
setting, but in a way that applies to configuration on a per-file
basis.
- for developing, we often switch between different versions of
NetworkManager. Thus, we might want to use different configuration.
E.g. before global-dns options, I want to use "dns=none" and manage
resolv.conf myself. Now, I can use global-dns setting to do that.
That can be achieved with something like the following (not exactly,
it's an example only):
[.config]
enable=nm-version-min:1.1
[main]
dns=default
[global-dns-domain-*]
nameserver=127.0.0.1
Arguably, this would be more awesome, if we would bump our micro devel
version (1.1.0) more often while developing 1.2.0 (*hint*).
- in principle, packages could drop configuration snippets and enable
them based on the NetworkManager version.
- with the "env:" spec, you can enable/disable snippets by configuring
an environment variable. Again, useful for testing and developing.
This is effectively the same as nm_config_parse_boolean(). The difference is,
that "nm-config.c" is not available to the interface-helper, thus any
code used by interface-helper (like "NetworkManager.c") cannot use this
function.
Still don't drop nm_config_parse_boolean() entirely, because it's better
to have the explicit notion of parsing a string in the config-context.
I ended up not using the function. But I'd still keep this patch.
Allows to enable more-asserts more granularly.
Unfortunately, the old check was "${enable_more_asserts} == "yes", thus
we cannot extend "--enable-more-assert=level" because that would mean
that the same build script cannot set the option on both old and new
NetworkManager.
Thus, add a new option --with-more-asserts=level. If you put the
following in your build script, it will work as expected whether
you build a new or an old version of NetworkManager.
./configure --enable-more-asserts --with-more-asserts=5
The 'new-connection' signal of a GDBusServer is emitted by default
through an idle source and the actual message processing starts only
after a signal handler returns TRUE.
Thus, before the signal handler has the chance to run, the GDBus
worker thread may detect that the connection is closed and schedule
the delivery of the 'closed' signal through another idle source.
After the termination of the 'new-connection' handler, the 'closed'
handler is executed, which cancels the subscription to GDBus signals
before any message has been processed.
This looks like a bug in GDBusServer; to work around it, just delay
the close of connection to let the signal dispatch run first.
https://bugzilla.gnome.org/show_bug.cgi?id=755170
When activating for example a team device which is to be enslaved to a
bridge, nm_device_activate_stage1_device_prepare() will postpone
stage 2.
In that case, we didn't register the "master-ready" of the team
device and thus never progressed the slave from stage2.
Reproduce:
# nmcli connection delete t-br0
# nmcli connection delete t-team0
nmcli connection add type bridge con-name t-br0 autoconnect no ifname i-br0 ip4 192.168.177.100/24 gw4 192.168.177.1
nmcli connection add type team con-name t-team0 autoconnect no ifname i-team0
nmcli connection modify id t-team0 connection.master i-br0 connection.slave-type bridge
nmcli connection up t-team0
Otherwise I get the following error (iwhile building in Jenkins):
In file included from ../include/nm-default.h:45:0,
from nm-config.c:27:
nm-config.c: In function 'nm_config_set_global_dns':
../include/gsystem-local-alloc.h:31:10: error: 'group_name' may be used uninitialized in this function [-Werror=maybe-uninitialized]
func (*(Type*)v); \
^
nm-config.c:1483:17: note: 'group_name' was declared here
gs_free char *group_name;
^
When a Wi-Fi is switched to AP mode, NMDeviceWifi forgets the AP scan list.
Later, when the device goes back to normal managed mode, the device was not
able to acquire the AP list again (for a long time), because the list is only
populated when a new BSS is signalled. And that could take very long or never
happen as the supplicant would have to lost the BSS and announce it later.
Fix the problem by announcing known BSSs as a response to ScanDone signal.
Testcase:
$ nmcli con add type wifi ifname wlan0 con-name my-wifi-ap autoconnect off ssid MYSSID
$ nmcli con modify my-wifi-ap wifi.mode ap ipv4.method shared
$ nmcli con up my-wifi-ap
$ nmcli con down my-wifi-ap
$ nmcli device wifi list
https://bugzilla.redhat.com/show_bug.cgi?id=1267327
Modify the DNS manager to use the static global DNS configuration when
available. In addition, change DNS plugins interface to accept a new
argument for global configuration and add support for this new
parameter to the dnsmasq plugin.
For libnm library, "nm-dbus-interface.h" contains defines like the D-Bus
paths of NetworkManager. It is desirable to have this header usable without
having a dependency on "glib.h", for example for a QT application. For that,
commit c0852964a8 removed that dependancy.
For libnm-glib library, the analog to "nm-dbus-interface.h" is
"NetworkManager.h", and the same applies there. Commit
159e827a72 removed that include.
However, that broke build on PackageKit [1] which expected to get the
version macros by including "NetworkManager.h". So at least for libnm-glib,
we need to preserve old behavior so that a user including
"NetworkManager.h" gets the version macros, but not "glib.h".
Extract the version macros to a new header file "nm-version-macros.h".
This header doesn't include "glib.h" and can be included from
"NetworkManager.h". This gives as previous behavior and a glib-free
include.
For libnm we still don't include "nm-version-macros.h" to "nm-dbus-interface.h".
Very few users will actually need the version macros, but not using
libnm.
Users that use libnm, should just include (libnm's) "NetworkManager.h" to
get all headers.
As a special case, a user who doesn't want to use glib/libnm, but still
needs both "nm-dbus-interface.h" and "nm-version-macros.h", can include
them both separately.
[1] https://github.com/hughsie/PackageKit/issues/85
Fixes: 4545a7fe96
The 9b79e6c73 commit moved setting of the MTU from IP4Config to NMDevice, but
VPN connections don't have a NMDevice instance (yet). Set the MTU also from the
VPN connection. Also, copying of the MTU to the IP4Config is no longer needed
as the ip4_config_commit no longer sets the MTU.
Fixes: 9b79e6c732https://bugzilla.gnome.org/show_bug.cgi?id=754781
For certain types of connection as PPP and WWAN the IP interface is
created during stage3 (IP config) but we are setting the firewall zone
at the beginning of stage3 and thus the zone is only set on the
underlying interface.
Add a check at the start of IP check phase to ensure that the firewall
zone is set again if the device interface is different from IP
interface.
https://bugzilla.redhat.com/show_bug.cgi?id=1110465
Depending on the network and the values of the 'dad_transmits' and
'retrans_timeout_ms' sysctls, DAD for the IPv6LL address can take
quite a while. Obviously there must be some upper bound on the
timeout, but 5 seconds seems a bit low. In this case it was observed
to be ~12 seconds but the sysctl values are unknown. In any case,
we can't predict the network/config so being a bit more lenient here
makes sense.
https://bugzilla.redhat.com/show_bug.cgi?id=1101809
Always take a reference to the manager when scheaduling an asynchronous
operations. In fact, all callers want to keep the manager alive as long
as there are operations in progress.
Refactor NMFirewallManager to have consistent semantics about
asynchronous calls.
- the callback is always invoked exactly once, but never
synchronously when starting the operation.
- while cancelling the request, the callback is invoked
synchronously with respect to the cancel operation.
- you can cancel a request once (and once only).
- you cannot cancel the request once the callback is invoked.
- when disposing the object with requests pending, the
callbacks are invoked synchronously.
- Add a callback argument to nm_firewall_manager_remove_from_zone().
Otherwise, the user never knows whether a call is still pending and
cancellable (as complete operations cannot be cancelled).
In fact, it makes no sense trying to cancel a call if you don't care
about when it completes.
- get rid of PENDING_CALL_DUMMY. The dummy callback allows cancellation
any number of times. We want to catch wrong usage by asserting that an
operation is only cancelled once.
- nm_firewall_manager_cancel_call() doesn't need the manager argument.
Either the call-id is valid (and has a valid pointer to the manager),
or there is a bug and it is a dangling pointer.
Give it a proper NMFirewallManager* prefix to make it clear where the type belongs.
Also, we will add a similar callback for nm_firewall_manager_remove_from_zone(),
so reflect that in the name.
