| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
| |
It allows us to clean up the nmcli "c add" section considerably.
We list the old-fashioned aliases in a separate section that applies to both
"nmcli c add" and "nmcli c modify".
The section is now nicely cross-linked with nm-settings in HTML
rendering.
|
| |
|
|
|
|
|
|
| |
This improves the HTML rendering.
But it also causes a lot of non-resolvable linkends warning when rendering a
separate manual pages into roff/mman. The messages are harmless, but still
a bit ugly.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a huge refactoring in attempt to 1.) reduce the horrible redundancy in
the connection addition path and 2.) reduce confusion between various sources
of property value (command line, properties, interactive mode).
* The conversions from the strings was done all over the place:
settings.c already does for all sensible properties.
The rest is removed.
* The validations are done randomly and redundantly:
server does some validation, and per-property client validations
useful for interactive mode are done in settings.c
The rest is removed.
* The information about defaults and required options was redundantly
scattered in per-type completion functions and interactive mode
questionnaries. This is now driven by the option_info[] table.
In general, we do our best to just map the command line options to
properties and allow mixing them. For the rest there's the
check_and_set() callbacks (basically to keep compatibility with previous
nmcli versions). This this is now all possible:
$ nmcli c add type ethernet ifname '*'
This always worked
$ nmcli c add type bond-slave save no -- connection.autoconnect no
The "save" and "--" still work
$ nmcli c add connection.type ethernet ifname eth0
Properties can now be used
$ nmcli c add type ethernet ip4 1.2.3.4 mac 80:86:66:77:88:99 con-name whatever
There's no implementation mandated order of the properties (the type
still must be known to determine which properties make sense)
$ nmcli --ask c add type ethernet ip4 1.2.3.4 mac 80:86:66:77:88:99 con-name whatever
The interactive mode asks only for properties that weren't specified
on command line
|
| | |
|
| |\
| |
| |
| | |
https://bugzilla.gnome.org/show_bug.cgi?id=765851
|
| | |
| |
| |
| |
| | |
An assertion seems a bit harsh, especially, because the platform
cache cannot be always in sync with the device state.
|
| | |
| |
| |
| | |
No need to perform multiple cache lookups.
|
| | |
| |
| |
| |
| | |
...as opposed to directly from the platform. If the token was set in
platform, it was picked up when generating a connection anyway.
|
| | | |
|
| | |
| |
| |
| |
| |
| | |
We don't need the token set in platform for our address mode generation,
but having it set makes it possible to correctly generate and assume
connections that use tokens.
|
| | | |
|
| | | |
|
| | | |
|
| | |
| |
| |
| | |
No need for the extra cache lookup.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The only user of platform who accesses this field is NMDevice,
when calling nm_platform_link_get_ipv6_token(). It cares more
about whether the token is all-zero or set to something.
Another use of inet6_token.is_valid was so that when we receive a
netlink message without IFLA_INET6_TOKEN attribute, that we don't
treat the value as zero, although it is just unknown. Fix that
instead in a better way by setting the value from the cache, if
IFLA_AF_SPEC doesn't provide it.
Also, when printing the token in nm_platform_link_to_string()
treat it as an IPv6 address (inet_ntop).
|
| | |
| |
| |
| | |
From/to strings and interface identifiers.
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The DNS priority property of a IP configuration determines how the
configuration compares to others when deciding their order, but
doesn't specify directly parameters to be applied. In other words, two
configurations which differs only for the dns-priority should have the
same hash as applying them will give the same result.
Especially, when the DNS manager computes the hash of IP
configurations, the ones without real configuration data (servers,
domans, options...) should not change the hash value.
Thus, exclude the property from the hash computation and dowgrade any
modification to 'minor change'.
Fixes: bfabfb05ae642112b7fde23da0d78689c2046745
Fixes: f09f5e1ec84b1e8b0e6231f72655f6446ae4646a
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
internal systemd code produces logging messages by itself, like
libsystemd: DHCP CLIENT (0x9204b5ce): ACK
Let's log the pointer value initially, to associate the logged "xid"
with the pointer value of the client.
Now we get:
<trace> [1464520695.7655] dhcp4 (enp0s25): dhcp-client4: set 0x556cdd9d6800
<debug> [1464520695.7658] libsystemd: DHCP CLIENT (0x9d87b7c5): STARTED on ifindex 2
|
| |
|
|
|
|
|
|
|
| |
When the list of DNS servers changes, old DNS entries cached by
dnsmasq must be invalidated as the answers returned by new servers may
be different (especially, old NXDOMAIN entries may now be valid). Call
the dnsmasq "ClearCache" D-Bus method to achieve this.
https://bugzilla.redhat.com/show_bug.cgi?id=1338731
|
| |
|
|
|
| |
There might be a pending "SetServersEx" D-Bus call when the plugin is
destroyed, ensure it gets canceled.
|
| |\
| |
| |
| |
| |
| |
| | |
nm-libreswan VPN has no own IP interface. Thus we got an
assertion failure in nm_dns_manager_add_ip_config().
Fix that, by using the IP interface of the parent device.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
device
Since 027f4c65ace4ad52ee9ccf4c1d9adad01eb67735, the ip_iface for
nm_dns_manager_add_ip_config() must be set.
Wit interface-less VPN types like libreswan, we thus hit the assertion
nm_dns_manager_add_ip_config: assertion 'iface && iface[0]' failed
Fix that, by fallback to the interface name of the parent device.
Fixes: 027f4c65ace4ad52ee9ccf4c1d9adad01eb67735
|
| | |
| |
| |
| |
| |
| |
| |
| | |
nm_vpn_connection_get_ip_iface()
and nm_vpn_connection_get_ip_ifindex(). For VPN types that have no own
IP interface, we often want instead lookup the IP interface from the
parent device.
|
| |/
|
|
|
| |
ip_iface and ip_ifindex come as a pair. They must be either set both, or not
at all. Ensure that whenever setting one, the other is set too (or cleared).
|
| |
|
|
|
|
|
| |
When a VPN server doesn't push any DNS domain, we want to use the
received servers for all queries.
https://bugzilla.gnome.org/show_bug.cgi?id=766769
|
| |
|
|
|
|
|
|
| |
Add a new "Config" property to the D-Bus interface for team devices
and show its value through "nmcli device show". The property contains
the full JSON configuration from teamd for the device.
https://bugzilla.redhat.com/show_bug.cgi?id=1310435
|
| |
|
|
|
|
|
| |
TURBONETT is the default network name of a very popular internet
provider in Guatemala, so roaming should be disabled.
https://bugzilla.gnome.org/show_bug.cgi?id=766845
|
| |
|
|
| |
Fixes: adbba0fb395b9910c4615e7be91ffe5b3ef70d6a
|
| |
|
|
|
|
|
| |
Sometimes the netlink event lacks the IFLA_ADDRESS attribute with
the MAC address of the link. In this case, take the value from
the cached link instance. A missing netlink attribute should have the
meaning of reusing the previous value, not clearing the address.
|
| |\
| |
| |
| | |
https://bugzilla.gnome.org/show_bug.cgi?id=766816
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Introduce two environment variables to configure logging
for the VPN plugins:
- NM_VPN_LOG_LEVEL: when set, a syslog logging level (0-7).
- NM_VPN_LOG_SYSLOG: either 0 or 1, whether the plugin should
log to stdout or syslog. Basically, if NetworkManager itself
runs in the forground, we also want that the plugin logs
to stdout.
|
| | |
| |
| |
| |
| |
| |
| | |
This logging domain will be used to enable debugging of the VPN plugins.
However, the plugins might expose sensitive data in this mode, so exclude
the new domain from "LOGD_ALL".
|
| | |
| |
| |
| |
| | |
We want to know, whether running in debug-mode (logging to stdout)
or whether we log to syslog.
|
| |/ |
|
| |
|
|
|
| |
Instead of defining multiple all-zero-ethernet-address variables, use
nm_ip_addr_zero.addr_eth.
|
| | |
|
| |
|
|
|
|
|
|
|
| |
nmp_utils_ethtool_get_permanent_address()
Don't like the static fields.
Also, don't assert against return values from the ethtool call.
And check that the length is positive.
|
| | |
|
| |\
| |
| |
| | |
https://bugzilla.gnome.org/show_bug.cgi?id=766560
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This is not C# but glib. Using interfaces is so cumbersome, that they
don't simplify code but make it more complicated.
E.g. following signals and its subscribers is complicated enough. It gets
more complicated by having NM_SETTINGS_SIGNAL_CONNECTION_ADDED and
NM_CP_SIGNAL_CONNECTION_ADDED. Of course, your favorite IDE has no idea
about glib interfaces, so figuring out who calls who gets more
complicated.
This undoes commit 4fe48b1273cff8dde3688a1dc4b7bcbf0a9e16f4. Originally,
NMConnectionProvider had only one function get_best_connection(). But it
kept growing and more functions were added.
If we want to ~hide~ certain part of the NMSettings API, we should move them
to a separate header which gives internal access.
|
| | |
| |
| |
| | |
... in favor of nm_settings_get_best_connections().
|
| | |
| |
| |
| |
| |
| | |
Instead of accessing the singleton getter nm_settings_get(), obtain
the settings instance from the device instance itself via
nm_device_get_settings().
|
| | | |
|
| | | |
|
