Kernel does a auto-mtu adjusting process whenever a port is added/removed from
the bridge, this can cause issues when NM wants to explicitly set an MTU which is
equal to the bridge default one (1500) because if later a port is added with a
different MTU the kernel will assign the bridge that port's MTU resulting in the bridge
runtime configuration differing from the bridge's NM connection profile.
What we can do is to always apply the MTU manually for the bridge (if explicitly
set by the profile), after doing so the kernel won't modify the MTU anymore,
which is what we want, problem is that kernel won't actually apply the MTU
to the netdev if it's not actually changing so we first apply it to
MTU-1 and then to the desired value.
https://bugzilla.redhat.com/show_bug.cgi?id=1778590
Signed-off-by: Antonio Cardace <acardace@redhat.com>
(cherry picked from commit e23798a5e5)
Add a parameter to the 'link_add()' virtual function so that
the MTU will be configured (via netlink) by the kernel when
creating the link.
https://bugzilla.redhat.com/show_bug.cgi?id=1778590
Signed-off-by: Antonio Cardace <acardace@redhat.com>
(cherry picked from commit ba2ee46254)
Kernel does a auto-mtu adjusting process whenever a port is added/removed from
the bridge, this can cause issues when NM wants to explicitly set an MTU which is
equal to the bridge default one (1500) because if later a port is added with a
different MTU the kernel will assign the bridge that port's MTU resulting in the bridge
runtime configuration differing from the bridge's NM connection profile.
What we can do is to always apply the MTU manually for the bridge (if explicitly
set by the profile), after doing so the kernel won't modify the MTU anymore,
which is what we want, problem is that kernel won't actually apply the MTU
to the netdev if it's not actually changing so we first apply it to
MTU-1 and then to the desired value.
https://bugzilla.redhat.com/show_bug.cgi?id=1778590
Signed-off-by: Antonio Cardace <acardace@redhat.com>
Add a parameter to the 'link_add()' virtual function so that
the MTU will be configured (via netlink) by the kernel when
creating the link.
https://bugzilla.redhat.com/show_bug.cgi?id=1778590
Signed-off-by: Antonio Cardace <acardace@redhat.com>
- we commonly use "int addr_family" as parameters to functions.
But then inside the function, we often need to do something for
IPv4 or IPv6 specifically. Instead of having lots of redundant
"if (addr_family == AF_INET)" checks, prefer to have a variable
IS_IPv4 and/or use NM_IS_IPv4() macro.
- don't make the "IS_IPv4" variable a gboolean but an int. gboolean
is a typedef for int, so it's in practice exactly the same. However,
we use "IS_IPv4" as index to arrays of length 2, where at position
"1" we have the value related to IPv4. Using a gboolean to index
an array is a bit odd. Maybe a "int" is preferable here.
This is more about doing consistently one or the other. There are
no strong reasons to prefer gboolean or int.
Apparently it is not actually used, but the function implements
a return value for AF_UNSPEC, while also asserting that the addr_family
is AF_INET/AF_INET6. Drop the assertions.
If there are multiple NM_CON_DEFAULT() mentionings on the same line,
previously the script would not parse them all. Adjust, by first wrapping
the line.
These macros are consistent with NMP_OBJECT_TYPE_IP_ADDRESS()
and NMP_OBJECT_TYPE_IP_ROUTE(), in name and usage.
Replace the previous functions that had inconsistent and a verbose
naming.
Like what was done for activating an active connection, so
some state change are simulated and a dbus test method is added
Signed-off-by: Frederic Martinsons <frederic.martinsons@sigfox.com>
Add reason for device state change.
Add dbus test method to force failure of activation, set the
device state and the active connection state.
Signed-off-by: Frederic Martinsons <frederic.martinsons@sigfox.com>
The modem device will have hardcoded capability which make it
compatible with GSM connection settings.
It will be seen with hardcoded ModemManager manager dbus object path
for the UDI property.
Add also a dbus test method to add the modem device.
Signed-off-by: Frederic Martinsons <frederic.martinsons@sigfox.com>
To be consistent with dbus.DbusException classes which do the
following in __init__:
def __init__(self, *args, **kwargs):
name = kwargs.pop('name', None)
if name is not None or getattr(self, '_dbus_error_name', None) is None:
self._dbus_error_name = name
if kwargs:
raise TypeError('DBusException does not take keyword arguments: %s'
% ', '.join(kwargs.keys()))
Exception.__init__(self, *args)
Signed-off-by: Frederic Martinsons <frederic.martinsons@sigfox.com>
It's a bit ugly that NMActRequest also tracks the shared rules.
Why? It's just some additional state (the rules) and some additional
actions that should be done when activating/deactivating the profile.
NMActRequest also doesn't track the NMDhcpClient, so why these shared
rules?
Also, removing the rules from an object destructor is ugly. NMActRequest
is a GObject and ref-counted. We should not make assumptions when the
last reference gets releases, at least not in cases like this, where
we hand out the reference and the object is passed around through large
parts of the source code.
For now, still let NMActRequest keep track of NMUtilsShareRules.
Later this will be refactored too.
A static const array is marked as immutable by the linker.
This is what we want, because there is no need to change this
array.
Also, the tailing %NULL entry is not necessary, we can just
iterate over the fixed number of elements.
NML3Cfg is the manager instance for one interface (ifindex). For one
interface, it is not supported (nor useful) to run IPv4LL multiple
times. Hence, let NML3Cfg manage and return a single instance.
We may want to handle cases where we cannot assign a IPv4LL address
even after multiple attempts.
Add a new property nm_l3_ipv4ll_is_timed_out() to get into a failed
state. The user may choose to fail the activation or ignore it.
Also, remove some unused code and fix minor issues in NML3IPv4LL.
