It's rather limiting that the only API to access *all* keys
is nm_setting_vpn_foreach_data_item() and nm_setting_vpn_foreach_secret().
API like nm_setting_vpn_get_num_secrets() is not useful, at least as
long as you cannot access the item by index.
The number of authentication retires is useful also for passwords aside
802-1x settings. For example, src/devices/wifi/nm-device-wifi.c also has
a retry counter and uses a hard-coded value of 3.
Move the setting, so that it can be used in general. Although it is still
not implemented for other settings.
This is an API and ABI break.
There is no API to get all settings. You can only ask for
settings explicitly, but that requires you to probe for them
and know which ones may exist.
The alternative API might be nm_connection_for_each_setting_value(),
but that only iterates over settings' properties. If a setting has no
properties, it is ignored.
We added "ipv4.route-table-sync" and "ipv6.route-table-sync" to not change
behavior for users that configured policy routing outside of NetworkManager,
for example, via a dispatcher script. Users had to explicitly opt-in
for NetworkManager to fully manage all routing tables.
These settings were awkward. Replace them with new settings "ipv4.route-table"
and "ipv6.route-table". Note that this commit breaks API/ABI on the unstable
development branch by removing recently added API.
As before, a connection will have no route-table set by default. This
has the meaning that policy-routing is not enabled and only the main table
will be fully synced. Once the user sets a table, we recognize that and
NetworkManager manages all routing tables.
The new route-table setting has other important uses: analog to
"ipv4.route-metric", it is the default that applies to all routes.
Currently it only works for static routes, not DHCP, SLAAC,
default-route, etc. That will be implemented later.
For static routes, each route still can explicitly set a table, and
overwrite the per-connection setting in "ipv4.route-table" and
"ipv6.route-table".
Expose previously internal function nm_ip_route_equal_full(). It's
just useful API.
However, add a @cmp_flags argument, so that in the future we could
extend it.
The new device type represents a PPP interface, and will implement the
activation of new-style PPPoE connections, i.e. the ones that don't
claim the parent device.
When the property is set, it specifies the device on which PPPoE is to
be started. The ppp interface will be named as the
connection.interface-name property.
When the property is not set the previous behavior will be retained,
i.e. the PPPoE connection will be started on connection.interface-name
and the PPP interface will have a random name.
Note that the reason tracking starts as soon as the object exists (which
is immediately after GDBusObject is created), not when the asynchronous
NMObject initialization finishes. That is so that we the reason changes
in between are not lost.
The vpn-connection should probably be doing the same.
It includes a reason code that makes it possible for the clients to be
more reasonable about error messages.
The reason code is essentially copied from the VPN, plus three more
reasons that were useful for non-VPN connections.
This adds definition of a set of known route option attributes to
libnm-core and helper functions.
nm_ip_route_attribute_validate() performs the validation of the
attribute type and, in case of a formatted string attribute, of its
content.
nm_ip_route_get_variant_attribute_spec() returns the attribute format
specifier to be passed to nm_utils_parse_variant_attributes(). Since
at the moment NMIPRoute is the only user of NMVariantAttributeSpec and
the type is opaque to users of the library, the struct is extended to
carry some other data useful for validation.
Various libnm objects (addresses, routes) carry an hash table of
attributes represented as GVariants indexed by name. Add common
routines to convert to and from a string representation.
To parse a string, a knowledge of the supported attributes (and their
types) is needed: we represent it as an opaque type
NMVariantAttributeSpec that callers must query to the library for the
specific object type and pass to the parse function.
Add support for creating dummy devices. This commit adds a D-Bus
interface 'org.freedesktop.NetworkManager.Device.Dummy' which is used
primarily for determining the device type but does not carry any
properties.
The property can be used to tune the authentication timeout. It's
especially useful to speed up the failure in case the port doesn't
support 802.1X and make NM try a different, non-authenticated
connection.
The new NMSettingMacsec contains information necessary to establish a
MACsec connection. At the moment we support two different MACsec
modes, both using wpa_supplicant: PSK and EAP.
PSK mode is based on a static CAK key for the MACsec key agreement
protocol, while EAP mode derives keys from a 802.1x authentication and
thus requires the presence of a NMSetting8021x in the connection.
While technically it's already possible to implement a fail-over
mechanism using multiple connections (for example, defining a higher
priority DHCP connection with short DHCP timeout and a lower priority
one with static address), in practice this doesn't work well as we try
to autoactivate each connection 4 times before switching to the next
one.
Introduce a connection.autoconnect-retries property that can be used
to change the number of retries. The special value 0 means infinite
and can be used to try the connection forever. A -1 value means the
global configured default, which is equal to 4 unless overridden.
https://bugzilla.gnome.org/show_bug.cgi?id=763524
Unnecessary APIs have been removed from nm-setting-proxy, client like
nm-connection-editor are expected to create a PAC script snippet the load
the location of file in NM.
libnm-core has been expanded to include proxy settings which clients
like nmcli, nm-connection-editor use to configure proxy in PacRunner. It
offers three modes i.e 'auto', 'manual'and 'none' and accordingly take
data to configure PacRunner. The modes matches on the PacRunner side too.
The team-config must be valid utf-8. First of all, JSON
is also defined for other unicode encodings, but libjansson
can only handle utf-8. So, just require that.
A file with a '\0' truncates part of the file and is thus
invalid.
Since we possibly already link against libjansson, we can also expose some
helper utils which allows nmcli to do basic validation of JSON without
requiring to duplicate the effort of using libjansson.
Also, tighten up the cecks to ensure that we have a JSON object at hand.
We are really interested in that and not of arrays or literals.
