We will call the function directly as well. Lets aim to
get the types right.
Also the compiler would warn if the cast to (GDestroyNotify)
would be to a fundamtally different function signature.
GHashTable is optimized for data that has no separate value
pointer. We can use the OpenvswitchBridge structs as key themselves,
by having the id as first field of the structure and only use
g_hash_table_add().
Of course, in practice "mtu" is much smaller than 2^31, and
also is sizeof(int) >= sizeof(uint32_t) (on our systems). Hence,
this was correct. Still, it feels ugly to pass a unsigned integer
where not the entire range is covered.
- rename "id" to something more distinct: "call_id".
- consistently use guint64 type. We don't want nor need
to handle negative values. For CALL_ID_UNSPEC we can use
G_MAXUINT64.
- don't use "i" format string for the call id. That expects
an "int", so it's not clear how this was working correctly
previously. Also, "int" has a smaller range than our 64bits.
Use instead "json_int_t" and cast properly in the variadic
arguments of json_pack().
Also, never update the value to %NULL. If the current
message does not contain a UUID, keep the previous one.
Fixes: 830a5a14cb ('device: add support for OpenVSwitch devices')
"nm-device-logging.h" defines logging macros for a NMDevice instance.
It also expects a "self" variable in the call environment, and that
variable had to be in the type of NMDevice or the NMDevice subclass.
Extend the macro foo, so that @self can be either a NMDevice* pointer
or a NMDevice$SUBTYPE.
Of course, that would have always been possible, if we would simply cast
to "(NMDevice *)" where we need it. The trick is that the macro only
works if @self is one of the two expected types, and not some arbitrary
unrelated type.
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.
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.
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.
For hidden networks, we usually don't have an SSID. We try to match
and fill the SSID based on the profiles that we have:
<debug> [1603798852.9918] device[6b383dca267b6878] (wlp2s0): matched hidden AP AA:BB:CC:DD:EE:FF => "SSID"
However, we should not clear that value again on the next update:
<trace> [1603798856.5724] sup-iface[66c1a0883a262394,0,wlp2s0]: BSS /fi/w1/wpa_supplicant1/Interfaces/0/BSSs/3 updated
<debug> [1603798856.5726] device[6b383dca267b6878] (wlp2s0): wifi-ap: updated AA:BB:CC:DD:EE:FF (none)
Once we have a SSID, we can only update it to a better value,
but not clear it.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/438
Fixes: b83f07916a ('supplicant: large rework of wpa_supplicant handling')
NML3Cfg already handles IPv4 ACD. IPv4LL is just a small additional
layer on top of that, so it makes sense that it also is handled by
NML3Cfg.
Also, the overall goal is that multiple NMDevice and NMVpnConnection
instances can cooperate independently. So if multiple "users" enable
IPv4LL on an interface, then we should only run it once. This is
achieved by NML3IPv4LL's API where users register what they want,
and NML3IPv4LL figures out what that means as a whole.
Also, we thus will no longer need to use sd_ipv4ll/n-ipv4ll, because
we implement it ourself.
On the one hand, we want to keep the private fields internal. On the
other hand, we want to directly expose the NML3AcdAddrTrackInfo, so
that the user can access them without copying or calling a function.
Previously, there was some union ugliness and some padding involved.
That was probably correct, but lets solve this somewhat nicer by
having the private fields in a "_priv" struct and use NML3AcdAddrTrackInfo
throughout.
