In the next commit nm_device_bring_up() will be extended with a new
argument. Most callers just want to bring up the device synchronously
and don't care about the "no_firmware" argument. Introduce a
nm_device_bring_up_full() for callers that need special behavior.
Currently VPNs always apply the configuration sent by the server for
both address families. So, even if users set e.g. ipv6.method=disabled,
they might end up with IPv6 configured.
Change that and apply the automatic configuration only when the method
is "auto".
This is a change in behavior and as such it might be disruptive for
users that had a method different from "auto" and expected to have the
interface configured. However, that scenario seems unlikely and can be
easily fixed by setting the right method.
When creating NMPlatformRoutingRule from NMIPRouteRule object, the
protocol is being set to RTPROT_UNSPEC. According to linux kernel
documentation FRA_PROTOCOL indicates the originator of the rule.
In this case the route rule is coming from a connection and therefore
the originator of the rule is the user. The correct value is
RTPROT_STATIC which means the rule is installed by the administrator.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1457
Fixes: 3f9347745b ('core: add handling of IP routing rules to NMDevice')
This wasn't used. It also doesn't make much sense, because
g_dbus_connection_call() accepts a reply type argument. So if you want
to check the reply type, you can do so when making the call.
That differs from g_dbus_proxy_call(), where this might make some sense
and is actually used.
While at it, also drop _nm_dbus_typecheck_response() from the header
file. It seems not general purpose enough and is not necessarily a great
pattern. Because,
- for g_dbus_connection_call() you either specify the reply_type when making
the call, or you do some more elaborate handling of the result -- not merely
_nm_dbus_typecheck_response().
- for g_dbus_proxy_call(), you can use _nm_dbus_proxy_call_finish() to
get it, or again, you want some non-trivial type checking.
These are helpers for GDBusProxy. I think we should avoid GDBusProxy where possible,
and these functions too. Give the function a more specific name to show that this
is only for the proxy.
These are just general purpose D-Bus utils, based on glib and GDBus.
They fit perfectly to libnm-glib-aux. Move the code.
Also, there is already the file "src/core/nm-dbus-utils.c", having two
files with the same name on our source tree is just confusing.
Most users included this by accident, by including nm-connection.h. That
is not too great, becuase stuff it contains is by no means specific to
NMConnection.
Anyways, it's not like it would matter too that. I mainly care about it
being included in NetworkManager.h, so that there's one less special
case in a test that makes sure useful stuff from NetworkManager.h ends up
in gtk-doc (a separate commit).
libnm-core-impl/nm-setting-bond.c:1276: warning: Symbol name not found at the start of the comment block.
libnm-core-impl/nm-setting-vpn.c:1135: warning: Symbol name not found at the start of the comment block.
libnm-core-impl/nm-setting-vpn.c:1158: warning: Symbol name not found at the start of the comment block.
libnm-core-impl/nm-setting-wired.c:1560: warning: Symbol name not found at the start of the comment block.
libnm-client-impl/nm-dhcp-config.c:149: warning: Symbol name not found at the start of the comment block.
libnm-client-impl/nm-secret-agent-old.c:967: warning: Symbol name not found at the start of the comment block.
libnm-client-impl/nm-secret-agent-old.c:1010: warning: Symbol name not found at the start of the comment block.
libnm-client-impl/nm-secret-agent-old.c:1037: warning: Symbol name not found at the start of the comment block.
libnm-core-impl/nm-setting-bond.c:602: warning: Parameter description
for nm_setting_bond_validate_option::value (allow-none) is not used
from source code comment block.
Makes gtk-doc grumpy (but it likes getting grumpy too often for us to
actually pay attention, it seems):
libnm-core-impl/nm-utils.c:4342: warning: nm_utils_is_uuid is deprecated
in the inline comments, but no deprecation guards were found around
the declaration. (See the --deprecated-guards option for gtkdoc-scan.)
libnm-client-impl/nm-device-ovs-bridge.c:36: warning:
nm_device_ovs_bridge_get_slaves is deprecated in the inline comments,
...
libnm-client-impl/nm-device-ovs-port.c:36: warning:
nm_device_ovs_port_get_slaves is deprecated in the inline comments,
...
libnm-client-impl/nm-device-team.c:77: warning:
nm_device_team_get_slaves is deprecated in the inline comments,
...
gtk-doc gets confused by these, ignore them:
common.py:ParseFunctionDeclaration:541:WARNING:Cannot parse args for
function in "nm_device_get_hw_address) const char
*nm_device_dummy_get_hw_address(NMDeviceDummy *device
common.py:ParseFunctionDeclaration:541:WARNING:Cannot parse args for
function in "nm_device_get_ports) const GPtrArray
*nm_device_ovs_port_get_slaves(NMDeviceOvsPort *device
For some reason it's still confused if NM_AVAILABLE_* comes first.
I refuse to look into that, just reorder them.
These went out of date and now all sorts of useless junk is included in
the libnm documentation
They contain everything outside *-public/ (perhaps they could be generated,
but I'm not doing that) and nm-core-types.h (because that one confuses
gtk-doc in an outrageous manner).
We got a typedef of the same name, and that causes gtk-doc to generate
invalid docbook and complain aloud:
../xml/nm-client.xml:4118: element refsect2: validity error : ID NMDnsEntry already defined
<refsect2 id="NMDnsEntry" role="typedef" condition="since:1.6">
Warning: multiple "IDs" for constraint linkend: NMDnsEntry.
gtk-doc (and perhaps other tools) treat pound sign in comments
specially:
html/NMSetting8021x.html:1501: warning: no link for: "11" -> (<span class="type">11</span>).
In case the D-Bus interfaces start dropping off (typically all off them go
one by one when the object is being deleted), don't reset all the properties.
In particular, keep most properties around, only tear down "o" and "ao",
so that the object dependencies get torn down, but we still get enough
properties around to identify what the dead object was its heyday.
One example of where this is not good is when the device-removed signal
is emmitted, the device no longer has the ifname:
$ nmcli monitor
<quit NetworkManager>
(null): device removed
(null): device removed
...
Currently we assert that properties are reset on client teardown. That
is not the right thing to do and we're not going to do that in future.
However, what is important to test is that the properties are reset when
the daemon goes away. Test that.
The part where a device was created and its cleanup on client
description was only run randomly.
This is silly and gave me hard time. No reason not to be always running
it.
Previously we'd note if NM is stopped, but not if it's running.
I suppose it's nice for the user to know that the monitor started
running, but, it's also important for the monitor to be testable (so
that we know that we are ready to start adding mock objects, etc.)
This also gets rids of some duplication at expense of a little less
nuanced message.
NMSettingWired does not reject invalid flags. Filter them out in wake_on_lan_enable().
In practice, it makes no difference, the unknown flags were ignored anyway.
If there were any pause options and any non-pause options,
the created setting was invalid.
I don't think it's reasonably possible to parse the broken settings.
So there is no workaround trying to read the existing broken settings
from disk. Luckily, the broken setting was just silently ignored by
the parser, so you simply could not persist certain settings.
https://bugzilla.redhat.com/show_bug.cgi?id=2134569
Fixes: 652ddca04c ('ethtool: Introducing PAUSE support')
It's possible that the modem is enabled outside of NM. If not
re-check, device could stay disabled throughout until something else
about the modem changes again.
If modem is not at least "registered", a connection is not happening, which
means IP settings change is probably not interesting. Avoid trying to
parse it, so that we don't trigger connection failure when there isn't
one.
