Platform has it's own, simple implementation of object types:
NMPObject. Extract a base type and move it to "shared/nm-utils/nm-obj.h"
so it can be reused.
The base type is trival, but it allows us to implement other objects
which are compatible with NMPObjects. Currently there is no API for generic
NMObjBaseInst type, so compatible in this case only means, that they
can be used in the same context (see example below).
The only thing that you can do with a NMObjBaseInst is check it's
NMObjBaseClass.
Incidentally, NMObjBaseInst is also made compatible to GTypeInstance.
It means, an NMObjBaseInst is not necessarily a valid GTypeInstance (like NMPObject
is not), but it could be implemented as such.
For example, you could do:
if (NMP_CLASS_IS_VALID ((NMPClass *) obj->klass)) {
/* is an NMPObject */
} else if (G_TYPE_CHECK_INSTANCE_TYPE (obj, NM_TYPE_SOMETHING)) {
/* it a NMSometing GType */
} else {
/* something else? */
}
The reason why NMPObject is not implemented as proper GTypeInstance is
because it would require us to register a GType (like
g_type_register_fundamental). However, then the NMPClass struct can
no longer be const and immutable memory. But we could.
NMObjBaseInst may or may not be a GTypeInstance. In a sense, it's
a base type of GTypeInstance and all our objects should be based
on it (optionally, they we may make them valid GTypes too).
Since commit 0922a17738 ("manager: avoid that auto-activations
preempt user activations") the manager doesn't allow a internal
activation to disconnect the same connection already active on the
device. Thus, during a rollback we must ensure that the device is
deactivated before.
Fixes: 0922a17738
The default value for miimon, when missing in the setting, is 0 if
arp_interval is != 0, and 100 otherwise. So, when generating a
connection, let's ignore miimon=0 (which means that miimon is
disabled) and accept any other value. Adding miimon=100 does not cause
any harm to the connection assumption.
While at it, slightly improve the code: ignore_if_zero() is not useful
for 'updelay','downdelay','arp_interval' because zero is their default
value, so introduce a new function that checks if the value is the
default (and specially handles 'miimon').
Reported-by: Taketo Kabe <rkabe@vega.pgw.jp>
https://bugzilla.redhat.com/show_bug.cgi?id=1463077
For master devices, instead of ignoring loss of carrier entirely,
handle it.
First of all, master devices are now by default ignore-carrier=yes.
That means, without explict user configuration in NetworkManager.conf,
the previous behavior in carrier_changed() does not change.
If the user decides to configure the master device like
[device-with-carrier]
match-device=type:bond,type:bridge,type:team
ignore-carrier=no
then, master device will disconnect on carrier loss like
regular devices.
https://github.com/NetworkManager/NetworkManager/pull/18
Co-authored-by: Thomas Haller <thaller@redhat.com>
Commit 348452f1e0 (device: renew DHCP
lease for active "ignore-carrier" devices on carrier-on (bgo #743368))
added this behavior for non-master devices.
The same reasoning applies here too.
https://github.com/NetworkManager/NetworkManager/pull/18
Based-on-patch-by: Nikolay Martynov <mar.kolya@gmail.com>
Previously, master device types like bridge, bond, and team
would overwrite is_available() and check_connection_available()
and always return TRUE.
The device already expresses via nm_device_is_master() that it
is of a master kind. Refactor the code, so, instead of having these
device types overwrite is_available() and check_connection_available(),
let the parents implementation react on nm_device_is_master().
There is no change in behavior at all. Instead, the knowledge how to
treat a master device moves from the device implementation to the
parent class.
Currently, device types like Bond hack around ignore-carrier
setting, as they always want to ignore-carrier.
Prepare so that also for such master types, we rely and honor the
ignore-carrier setting better. In the next commit, bond, bridge and
team devices they will get ignore-carrier turned on by default.
When a user forces up a connection on a device, mark earlier the
device as managed: this would allow proper clean-up on the device also
when it was previously unmanaged or assumed.
This would avoid skipping IPv6LL address generation when instead it was
needed.
Fixes: adbf383628https://bugzilla.redhat.com/show_bug.cgi?id=1452046
In _internal_activate_device(), we try to find an existing master AC
for the slave AC, and we create a new one in case of failure. The
master AC may already exist, but it may not be detected by
find_master() because it is undergoing authorization.
The result is that we auto-activate the master when there is already a
user activation in place, and the auto-activation will cancel the user
one. This is bad, as user-activation should always have precedence.
To fix this, introduce a last-minute check before activating internal
connections.
https://bugzilla.redhat.com/show_bug.cgi?id=1450219
No need to clone the list anymore. Unfortunately, GPtrArray is not NULL
terminated (without extra effort), so we have to pass on the GPtrArray
instance for the length.
A negative ipv4.dns-priority and ipv6.dns-priority has the meaning to configure
the DNS information of the connection exclusively. With systemd-resolved, that means
we must explicitly unset the configuration from other interfaces.
https://bugzilla.gnome.org/show_bug.cgi?id=783569
The code was correct previously, but it was confusing to me,
because
- once @skip gets set to TRUE, it stays TRUE for the rest
of the loop.
- in each additional skipped iteration, it would still set
plugin_confs[i] to NULL. Which is not wrong, but confusing.
- it would set "prev_prio = prio;" in each iteration.
After @skip is set to TRUE, that doesn't matter anymore,
but is confusing. Before @skip is set to TRUE it also
doesn't really matter to set it more then once, because
we only care about the very first priority.
- @skip sounded to me like the current iteration would
be skipped. But really all remaining will be skipped too.
For externally managed interfaces, we create an in-memory connection
and keep the device with sys-iface-state=external.
When the user actively modifies the connection, we persist it to
storage. But we also must take over managing the device.
One problem is that nm_device_reapply() errors out if the device
is still activating. It's unclear how to reapply the connection
while the device is in the process of activation. So, if the user
modifies the created connection very quickly, reapplying the settings
will fail.
https://bugzilla.redhat.com/show_bug.cgi?id=1462223
We react on changes to NMSettingsConnection.flags, so that we can update
from an external activation to a managed one.
However, previously we would only register the _settings_connection_notify_flags
callback during _set_settings_connection(). So, if via constructor properties
we first set PROP_SETTINGS_CONNECTION and later PROP_ACTIVATION_TYPE, we wouldn't
register the callback.
This drops some redundant rules and orderes the remaining ones by
precedence.
The 'root' rules take precedence over the 'default' rules, so order
the file accordingly.
It is not necessary to repeat send_destination rules, as the default
rules already allows everyone to send to the interface.
Moreover, it is not necessary to restrict the ownership of the name
in the default context, as this is already done by the system-wide
default rule.
Reviewed-by: David Herrmann <dh.herrmann@gmail.com>
lease_to_ip6_config() calls the GString temporary buffer "str".
That makes sense, use the same name in lease_to_ip4_config().
For that, we have to rename other local variables too.
Don't have pending asynchronous requests in parallel, like setting
"ProcessCredentials" and "Start", or "Cancel" and "Start".
Instead, "Start" is only scheduled after "ProcessCredentials" completed
and "ProcessCredentials" is only scheduled after "Cancel" completed.
Also, handle the async response of these requests. For one, to achive the
chaining mentioned above and to log what happens and possible errors.
Upon new enrollment, a previously created GDBusProxy is now reused,
where the first operation is to Cancel the previous action.
Also, consistently <trace> log what is happening.
Not doing all of this is less lines of code. It's also simpler, and
faster. But in my opinion, it is (usually) better to check and wait for
return values, instead of firing off async requests uncontrolled. It
allows us to better know where we are and to log about each individual
step. This also makes all operations cancellable.
Undoubtedly, correctness and handling failures conflicts with simplicity
in this case -- or at least: what I think is "correctness" conflicts.
When IPv4 addresses are synchronized to platform, the order of IPv4
addresses matters because the first address is considered the primary
one. Thus, nm_ip4_config_capture() should put the primary address as
first, otherwise during synchronization addresses will be removed and
added back with a different primary/secondary role.
https://bugzilla.redhat.com/show_bug.cgi?id=1459813
Since commit 2b51d3967 "device: merge branch 'th/device-mtu-bgo777251'",
we always set the MTU for certain device types during activation. Even
if the MTU is neither specified via the connection nor other means, like
DHCP.
Revert that change. On activation, if nothing explicitly configures the
MTU, leave it unchanged. This is like what we do with ethernet's
cloned-mac-address, which has a default value "preserve".
So, as last resort the default value for MTU is now 0 (don't change),
instead of depending on the device type.
Note that you also can override the default value in global
configuration via NetworkManager.conf.
This behavior makes sense, because whenever NM actively resets the MTU,
it remembers the previous value and restores it when deactivating
the connection. That wasn't implemented before 2b51d3967, and the
MTU would depend on which connection was previously active. That
is no longer an issue as the MTU gets reset when deactivating.
https://bugzilla.redhat.com/show_bug.cgi?id=1460760
- don't use assert but be more graceful with g_return_if_fail().
- in case of failure, don't log a debug message after the warning.
One message is sufficient, drop "pppd pid %d cleaned up".
- print GPid type as long long.
- increase log level to warning. pppd dying unexpectedly warrants a
warning.
ppp_exit_code() does too much or too little. Either it should log
about all reasons why pppd exited, including signals, or it should
just do the status to string conversion. Split it.
It's useless (and in some cases also harmful) to commit the
configuration to update the default route metric when the device has
no default route. Also, don't commit configuration for externally
activated devices.
https://bugzilla.redhat.com/show_bug.cgi?id=1459604
Don't log in a function that basically just inspects state, without
mutating it. Instead, pass the reason why a connection could not be
generated to the caller so that we have one sensible log message.
The device's RECHECK_ASSUME signal has only NMManager as subscriber
and it immediately calls recheck_assume_connection().
With the previous commit, recheck_assume_connection() always logs
a debug message, so we don't need this duplicate message anymore.
