| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
|
| |
This is going to be useful for UIs to know which plan we're actually
using.
|
| | |
|
| |
|
|
|
| |
This is going to be useful for UIs to find out which network is the
device actually registered with.
|
| | |
|
| |
|
|
|
|
| |
The device id is useful to pinpoint the connection to a particular
device. However, we don't expose it anywhere and it's sort of hard to
guess.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
| |
Use an ifname instead.
This also fixes creation of default wired connections for cheapo USB
ethernet adapters that come with the EEPROM footprint unpopulated.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/137/
|
| |
|
|
|
|
|
|
|
|
|
| |
We must compare the UUID with the one on the *parent* device.
Also, simplify the checks to only return TRUE at the end of function.
Fixes: 27c281ac5a5c ('device: deduplicate match_parent()')
https://bugzilla.redhat.com/show_bug.cgi?id=1716438
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/176
|
| | |
|
| |\
| |
| |
| | |
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/169
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
When parsing a NMSettingTeam/NMSettingTeamPort from GVariant, the JSON
"config" is always preferred. If that field is present, all other
attributes are ignored (aside from validating that the individual fields
are as expected).
The idea is that the JSON config anyway must contain everything that artificial
properties could. In this mode, also no validation is performed and the setting is
always accepted (regardless whether libnm thinks the setting verifies).
When a libnm client created the setting via the artificial properties,
only send them via D-Bus and exclude the JSON config. This turns on
strict validation server side.
Now we actually get validation of the settings:
$ nmcli connection add type team team.runner-tx-hash l3
Error: Failed to add 'team' connection: team.runner: runner-tx-hash is only allowed for runners loadbalance,lacp
this is obviously a change in behavior as previously all settings
would have been accepted, regardless whether they made sense.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
runner-tx-hash
This is fixed in libnm. Resetting the GObject property clears the list
of watchers and tx-hashes.
Since nmcli requires a libnm version >= itself, this workaround
is no longer necessary.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
For each artifical team property we need to track whether it was
explicitly set (i.e., present in JSON/GVariant or set by the user
via NMSettingTeam/NMSettingTeamPort API).
--
As a plus, libnm is now no longer concerned with the underling default values
that teamd uses. For example, the effective default value for "notify_peers.count"
depends on the selected runner. But libnm does not need to care, it only cares
wheher the property is set in JSON or not. This also means that the default (e.g. as
interesting to `nmcli -o con show $PROFILE`) is independent from other properties
(like the runner).
Also change the default value for the GObject properties of
NMSettingTeam and NMSettingTeamPort to indicate the "unset" value.
For most properties, the default value is a special value that is
not a valid configuration itself.
For some properties the default value is itself a valid value, namely,
"runner.active", "runner.fast_rate", "port.sticky" and "port.prio".
As far as NMTeamSetting is concerned, it distinguishes between unset
value and set value (including the default value). That means,
when it parses a JSON or GVariant, it will remember whether the property
was present or not.
When using API of NMSettingTeam/NMSettingTeamPort to set a property to the
default value, it marks the property as unset. For example, setting
NM_SETTING_TEAM_RUNNER_ACTIVE to TRUE (the default), means that the
value will not be serialized to JSON/GVariant. For the above 4
properties (where the default value is itself a valid value) this is a
limitation of libnm API, as it does not allow to explicitly set
'"runner": { "active": true }'. See SET_FIELD_MODE_SET_UNLESS_DEFAULT,
Note that changing the default value for properties of NMSetting is problematic,
because it changes behavior for how settings are parsed from keyfile/GVariant.
For team settings that's not the case, because if a JSON "config" is
present, all other properties are ignore. Also, we serialize properties
to JSON/GVariant depending on whether it's marked as present, and not
whether the value is set to the default (_nm_team_settings_property_to_dbus()).
--
While at it, sticter validate the settings. Note that if a setting is
initialized from JSON, the strict validation is not not performed. That
means, such a setting will always validate, regardless whether the values
in JSON are invalid according to libnm. Only when using the extended
properties, strict validation is turned on.
Note that libnm serializes the properties to GVariant both as JSON "config"
and extended properties. Since when parsing a setting from GVariant will
prefer the "config" (if present), in most cases also validation is
performed.
Likewise, settings plugins (keyfile, ifcfg-rh) only persist the JSON
config to disk. When loading a setting from file, strict validation is
also not performed.
The stricter validation only happens if as last operation one of the
artificial properties was set, or if the setting was created from a
GVariant that has no "config" field.
--
This is a (another) change in behavior.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
The order of the fields in the JSON object does not really matter.
Note that with the recent rework the order changed. Before it was
arbitrarily, now it still is arbitrary.
Reorder again, to follow the same order as `man teamd.conf`.
|
| |/
|
|
|
|
|
|
|
|
| |
Generate the following:
{ "runner": { "sys_prio": 10 }, "link_watch": { "name": "ethtool" } }
instead of:
{ "runner": { "sys_prio": 10 }, "link_watch": { "name": "ethtool"} }
|
| |
|
|
|
|
| |
Otherwise we can get a build failiure:
../libnm/NetworkManager.h:61:27: fatal error: nm-enum-types.h: No such file or directory
|
| |
|
|
|
|
|
|
|
| |
This matters for properties that don't have 0/NULL/FALSE as
default value and when setting an empty property with
$ nmcli connection modify "$PROFILE" setting.property ''
Fixes: 3c82db710f50 ('cli: reset default value of properties via set_fcn()')
|
| |
|
|
|
|
|
|
|
| |
The early boot tooling gets the root-path from our state file due to a
lack of a better way to do that. However, when booting with NFS root,
the root path alone is not sufficient; the server address is communicated
via the next-server option. Save that one in the state file as well.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/168
|
| | |
|
| | |
|
| |\
| |
| |
| | |
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/170
|
| | | |
|
| | |
| |
| |
| |
| | |
Fedora 28 is no longer supported at this point. Run the "checkpatch"
test on a Fedora 29 image instead.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
clang on CentOS 7.6 (3.4.2-9.el7) warns:
CC clients/tui/newt/clients_tui_newt_libnmt_newt_a-nmt-newt-button.o
In file included from ../clients/tui/newt/nmt-newt-button.c:26:
In file included from ../shared/nm-default.h:280:
../shared/nm-glib-aux/nm-macros-internal.h:1617:2: error: unknown warning group -Wstringop-truncation, ignored [-Werror,-Wunknown-pragmas]
NM_PRAGMA_WARNING_DISABLE ("-Wstringop-truncation");
^
../shared/nm-glib-aux/nm-macros-internal.h:419:9: note: expanded from macro NM_PRAGMA_WARNING_DISABLE
_Pragma(_NM_PRAGMA_WARNING_DO(warning))
^
<scratch space>:109:25: note: expanded from here
GCC diagnostic ignored "-Wstringop-truncation"
^
This warning totally defeats the purpose of why we use the pragma in the
first place.
|
| | |
| |
| |
| |
| |
| | |
I saw this timeout reached in our gitlab-ci. I think it was due to the machine
being busy and taking more than 2 seconds. Assuming the timeout was just too short,
increase it to 4 seconds.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
nm_hash_update_vals()
Clang (3.4.2-9.el7) on CentOS 7.6 fails related to nm_hash_update_vals().
Clang seems to dislike passing certain complex arguments to typeof().
I'd prefer to fix nm_hash_update_vals() to not have this problem,
but I don't know how.
This works around the issue.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
clang (3.4.2-9.el7) on CentOS 7.6 fails related to nm_hash_update_vals().
I am not even quoting the error message, it's totally non-understandable.
nm_hash_update_vals() uses typeof(), and in some obscure cases, clang dislikes
when the argument itself is some complex macro. I didn't fully understand why,
but this works around it.
I would prefer to fix nm_hash_update_vals() to not have this limitation.
But I don't know how.
There is probably no downside to have this an inline function instead of
a macro.
|
| |/
|
|
|
|
|
|
|
|
| |
Clang 3.4.2-9.el7 on CentOS7.6 complains about missing generic type match:
../dispatcher/nm-dispatcher.c:243:2: error: controlling expression type 'const Request *const' (aka 'const struct Request *const') not compatible with any generic association type
_LOG_R_D (request, "start running ordered scripts...");
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Fixes: 17dc6a9da68a ('shared: add _NM_ENSURE_TYPE_CONST()')
|
| |\
| |
| |
| | |
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/160
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This code is now unused.
Also, it does not seem state of the art to me
anymore.
Drop it, it could always be resurrected if need by, but maybe
GFileMonitor could be used instead.
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
"main.monitor-connection-files"
It's deprecated and off by default for a long time.
It is bad to automatically reload connection profiles. For example, ifcfg
files may consist of multiple files, there is no guarantee that we
pick up the connection when it's fully written.
Just don't do this anymore.
Users should use D-Bus API or `nmcli connection reload` or `nmcli
connection load $FILENAME` to reload profiles from disk.
|
| |\
| |
| |
| | |
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/136
|
| | |
| |
| |
| |
| | |
There doesn't seem to be a better way to pinpoint a CDMA connection to a
device. This will have to do for now.
|
| | |
| |
| |
| |
| |
| | |
If the AddAndActivate() caller didn't explicitely a MAC address, default
to pinpointing the connection to the device by the means of an interface
name. This makes more sense than a MAC address with stable device names.
|
| | |
| |
| |
| |
| |
| | |
If the AddAndActivate() caller didn't explicitely a MAC address, default
to pinpointing the connection to the device by the means of an interface
name. This makes more sense than a MAC address with stable device names.
|
| | |
| |
| |
| |
| |
| | |
If the AddAndActivate() caller didn't explicitely a MAC address, default
to pinpointing the connection to the device by the means of an interface
name. This makes more sense than a MAC address with stable device names.
|
| | |
| |
| |
| |
| |
| | |
It's a common thing to complete a connection with an interface name;
adding it to the common path is goint to save as a few tens of lines
later on.
|
| | |
| |
| |
| |
| | |
nm_device_complete_connection() now calls check_connection_compatible()
which has a redundant check.
|
| | |
| |
| |
| |
| | |
nm_device_complete_connection() now calls check_connection_compatible()
which has a redundant check.
|
| | |
| |
| |
| |
| | |
nm_device_complete_connection() now calls check_connection_compatible()
which has a redundant check.
|
| |/ |
|
| |
|
|
|
|
|
|
|
| |
The daemon is already responsible for pinning the connection to a
particular device. In fact, it may choose to use a different means than
an interface name, such as a MAC address or a gsm.device-id. Remove it
from the client.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/140
|
| |
|
|
|
|
|
|
| |
[lkundrak@v3.sk: make update-po]
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/164
(cherry picked from commit 548bacd24e1b7d1d5b37dd83768c1e425a6b5cee)
|
| |
|
|
| |
(cherry picked from commit 9de7c0542c6ee44cb0c54c0fcdb5155d00ef3a31)
|
| |
|
|
|
|
|
|
|
|
| |
This is used to indicate the network dracut module should fall back to
configure network automatically (as with ip=dhcp was specified) if
there's no other network configuration present on the command line.
The option is documented in dracut.cmdline(7).
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/167
|
| |\
| |
| |
| |
| | |
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/148
https://bugzilla.redhat.com/show_bug.cgi?id=1705054
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Before commit e3ac45c02610 the reader set the private key in the
setting using the libnm function, which also set the key as client
certificate if it was in PKCS #12 format.
After the commit, existing connections with a PKCS #12 private key but
without a client certificate became invalid. Restore the old behavior.
Fixes: e3ac45c02610 ('ifcfg-rh: don't use 802-1x certifcate setter functions')
|
| | |
| |
| |
| | |
Let the setting check it in verify().
|
