| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Since introduction for support of ip6-privacy (use_tempaddr,
RFC4941) with commit d376270bfe673c041e610a981bd6c77c7cb37ba1,
the sysctl value from /etc was always read first.
This is problematic, because an explicit setting in the
connection should not be ignored over a global configuration.
Drop that old behavior. It was also problematic, because we did
not read any files under /etc/sysctl.d (except for sysctl.conf).
Also, we did not honor per-interface configurations.
Now we also use as last fallback the value from
/proc/sys/net/ipv6/conf/default/use_tempaddr
That has the advantage of falling back to the system default value
so that NM doesn't need to have it's own default policy
(Related: https://bugzilla.redhat.com/show_bug.cgi?id=1187525).
This is a change in behavior.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Support default value for setting 'ipv6.ip6-privacy' in
NetworkManager.conf.
If the global value is unset, preserve old behavior of looking into
/etc/sycctl.conf first. That behavior was introduced with commit
d376270bfe673c041e610a981bd6c77c7cb37ba1, since we support ip6-privacy
setting.
If the global value is set to "unknown", add a new fallback
that instead reads the runtime value from
"/proc/sys/net/ipv6/conf/default/use_tempaddr"
This seems more sensible behavior because we fallback to sysctl,
but instead of looking at static files in /etc, read /proc.
But to preserve the old behavior, we only do that when a global
value is configured at all.
https://bugzilla.gnome.org/show_bug.cgi?id=721200
|
| |
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=721200
|
| |
|
|
|
|
|
|
|
|
| |
The route-metric can be configured per connection via the
ipv4.route-metric and ipv6.route-metric fields. When the
value is left at -1 (the default), we would determine the
route-metric based on the device type (nm_device_get_priority()).
Extend that scheme by making the default value overwritable in
NetworkManager.conf.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
connection defaults
Add support for a new section [connection] in NetworkManager.conf.
If the connection leaves an option at "unknown"/"default", we can
support overwriting the value from global configuration.
We also support other sections that are named with "connection"
as a prefix, such as [connection2], [connection-wifi]. This is
to support multiple default values that can be applied depending
on the used device.
I think this has great potential. Only downside is that when
the user looks at a connection value, it will see that it is
unspecified. But the actually used value depends on the device
type and might not be obvious.
https://bugzilla.gnome.org/show_bug.cgi?id=695383
https://bugzilla.redhat.com/show_bug.cgi?id=1164677
|
| | |
|
| |
|
|
|
|
|
| |
Support a device-spec to match by device-type.
This matches on the value as shown by
nmcli -f GENERAL.TYPE device show
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Add a function to get a concise representation of the
device type.
libnm already has nm_device_get_type_description() for that
and it is shown by
nmcli -f GENERAL.TYPE device show
Reimplement that function for nm-core. Just take care that the
two implementations don't diverge.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fixes for example valgrind tests for ./libnm/tests/test-nm-client:
==25772== Conditional jump or move depends on uninitialised value(s)
==25772== at 0x40198D8: index (strchr.S:106)
==25772== by 0x400777C: expand_dynamic_string_token (dl-load.c:369)
==25772== by 0x400777C: fillin_rpath (dl-load.c:439)
==25772== by 0x4007FCF: _dl_init_paths (dl-load.c:816)
==25772== by 0x4002F38: dl_main (rtld.c:1194)
==25772== by 0x401750F: _dl_sysdep_start (dl-sysdep.c:249)
==25772== by 0x4004C20: _dl_start_final (rtld.c:306)
==25772== by 0x4004C20: _dl_start (rtld.c:412)
==25772== by 0x4000C97: ??? (in /usr/lib64/ld-2.21.so)
==25772== by 0x1: ???
==25772== by 0xFFEFFF6B2: ???
==25772== by 0xFFEFFF6EF: ???
==25772==
{
<insert_a_suppression_name_here>
Memcheck:Cond
fun:index
fun:expand_dynamic_string_token
fun:fillin_rpath
fun:_dl_init_paths
fun:dl_main
fun:_dl_sysdep_start
fun:_dl_start_final
fun:_dl_start
obj:/usr/lib64/ld-2.21.so
obj:*
obj:*
obj:*
}
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
NMSecretAgentOld:get_secrets_cb()
The previous patch 9ffcecf86ad2230860cf8fdf5667884782ee64dd was
completely wrong.
It tried to fix callers that provided a floating GVariant reference.
We require the caller to unref @secrets, so the correct fix it to
ensure that the reference is not floating.
Fixes: 9ffcecf86ad2230860cf8fdf5667884782ee64dd
Fixes: 6793a32a8c5445103ba3680bb5e4c31727096099
|
| |
|
|
|
|
| |
NMSecretAgentOld:get_secrets_cb()
Fixes: 6793a32a8c5445103ba3680bb5e4c31727096099
|
| |
|
|
| |
Fixes: 84021454eb0b126fda9cf29c46b7860f75c7ff8c
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add the new configuration option 'assume-ipv6ll-only' which specifies
the devices for which NM will try to assume an existing IPv6LL-only
configuration.
The new default behavior is to ignore such configurations since IPv6LL
addresses are automatically assigned by the kernel when the device is
brought up and thus the presence of an IPv6LL address doesn't mean
that the device was configured by the administrator.
The previous behavior was to always assume IPv6LL-only configurations
but this often had the unwanted effect of preventing other on-disk
configurations to be activated. To preserve the old behavior the
option must be set to '*'.
https://bugzilla.redhat.com/show_bug.cgi?id=1138426
|
| |\
| |
| |
| |
| | |
Some fixes for loading ifcfg-rh files, related to
alias files.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Alias files have a ':' to separate the base name from their
alias. But we didn't always ensure not to write-out files without
colon, and also initscripts doesn't have that restriction.
We should detect alias files and handle them properly (e.g. by
reloading the base file).
This fixes an error that a `nmcli con load` would have tried to
load the alias file. Also extend load_connection() to support
passing filenames other then the base file.
We only have to handle this in plugin.c. Inside reader.c we always
have the normalized base filename.
Or detection of alias files only looks whether the filename has a ':'
and whether a corresponding base file exists.
|
| | |
| |
| |
| | |
A colon indicates an alias file. It should be escaped.
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Previously, if the main ifcfg file doesn't define any
static ip addresses, any alias files would be ignored.
We should also allow alias files with (pure) 'dhcp' connections,
just like initscripts do.
Reported-by: Marek Hulan <mhulan@redhat.com>
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
connection_from_file() used to log a warning about failure,
but only when an @error argument was given.
update_connection() didn't ensure that in several cases,
so we would not log any failure reason when an ifcfg file
failed to read.
This behavior of controlling logging by passing @error (or not)
is unexpected. Instead, refactor the code so that the caller
can do appropriate logging.
Another reason for this refactoring is that PARSE_WARNING() does
not mention the file for which the failure is and uses some extra
indention that looks wrong. IOW, connection_from_file() doesn't
have the context to give the logging line a proper formatting.
|
| |\ |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
It seems like a poor default for various downstream toolchains. We can't
anticipate the compiler warnings for future compiler versions and older
ones are prone to false positives. Also, older gdbus-codegen is known
to generate code that triggers compiler warnings.
Let's keep it enabled for maintainer builds and distcheck so that we're
sure a tool chain that builds releases without warnings exists.
|
| | |
| |
| |
| | |
Just disable systemd-logind session tracking instead.
|
| | |
| |
| |
| |
| | |
The Ubuntu 12.04 introspection data don't contain it. However, the default
constructor works just well and even looks a bit more Python-y.
|
| | |
| |
| |
| |
| |
| | |
It yields completely unpredictable results on Ubuntu 12.04 (the global variable
successfully comparing to NULL despite demonstrably not NULL). Possibly a
toolchain bug.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
Fixes build on Ubuntu 12.04.
systemd/src/libsystemd-network/dhcp-network.c: In function '_bind_raw_socket':
systemd/src/libsystemd-network/dhcp-network.c:75:17: error: 'BPF_XOR' undeclared (first use in this function)
systemd/src/libsystemd-network/dhcp-network.c:75:17: note: each undeclared identifier is reported only once for each function it appears in
make[4]: *** [libsystemd_nm_la-dhcp-network.lo] Error 1
|
| | |
| |
| |
| |
| |
| |
| |
| | |
Fixes build with Ubuntu 12.04.
In file included from ppp-manager/nm-ppp-manager.c:42:0:
/usr/include/linux/if_ppp.h:103:16: error: field 'b' has incomplete type
/usr/include/linux/if_ppp.h:108:21: error: field 'b' has incomplete type
|
| |/
|
|
| |
Ubuntu 12.04 has an ancient version of glib, which we nevertheless support.
|
| |
|
|
|
| |
I did a "ip link set lo name yolo" and now my NetworkManager triggers an
assertion failure. :( Nevertheless, the loopback interface is always ifindex=1.
|
| |
|
|
| |
Just check they're from kernel.
|
| |
|
|
|
|
|
|
|
|
|
| |
We already have "nm-utils*.h" and "NetworkManagerUtils.h" headers. Rename
"include/nm-utils-internal.h" to "nm-macros-internal.h". I think that
name is better, because this file is header-only, internal, and
repository-wide.
Also, it will never contain non-header-only declarations because
there is no backing object file under "include/".
It will only contain macros and inline functions.
|
| | |
|
| |\
| |
| |
| |
| |
| |
| | |
Two improvements for handling default-routes.
https://bugzilla.redhat.com/show_bug.cgi?id=1224291
https://bugzilla.redhat.com/show_bug.cgi?id=1205405
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Previously for assumed connections we would never configure a default route.
That has serious problems for example in the following two scenarios:
- the default-route might have a limited lifetime from a previous
SLAAC/accept_ra setting. In this case, once we assume the connection
we must also ensure that we extend the lifetime of the default
route.
- the gateway could be received via DHCP/RA and it might change.
If we ignore default-routes for assumed connection we miss that
change.
The problem is that the notion of "assumed connection" wrongly combines
two conflicting goals (related bug bgo#746440):
a) have an external device that is entirely unmanged by NM.
b) do a seamless takeover of a previously managed connection at start,
but still fully manage.
This patch changes the handling of default-routes towards meaning b).
https://bugzilla.redhat.com/show_bug.cgi?id=1224291
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
only once
Since da708059dabb2854d11eed1a403398327b31535b, we would pickup the
default-route as configured externally, except at those moments when
NM re-applys the IP configuration of the interface, such as during a
DHCP lease.
That allows the user to add/remove the default-route externally (iproute).
But still, at random times (DHCP lease), we will revert those external
changes.
Extend this, that if the connection is explicitly configured as
'never-default=yes', that it tells NM not to interfere with externally
added default-routes on this device. That means, NM will only remove
any preexisting default-routes when configuring the device a first
time.
On any later attempts, NM will assume whatever is configured there.
That makes sense because the user indicated not wanting NM to
manage a default-route on that device, so if something externally
added a default-route, assume that is what the user wants.
This only affects non-assumed connections, with 'never-default=yes'.
https://bugzilla.redhat.com/show_bug.cgi?id=1205405
|
| |/
|
|
|
|
| |
Also accept a NULL connection in
nm_default_route_manager_ip4_connection_has_default_route() and
nm_default_route_manager_ip6_connection_has_default_route().
|
| |\
| |
| |
| |
| | |
The limit seems to be too low and causes problems in libnm-glib. We increase
the limit and warn in libnm-glib if it was exceeded.
|
| | |
| |
| |
| |
| | |
This causes incorrect application behaviour, so libnm-glib should warn
at least.
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
D-Bus default limit of replies per connection has been lowered to 128 due to
CVE-2014-3638, see:
http://cgit.freedesktop.org/dbus/dbus/commit/?id=5bc7f9519ebc6117ba300c704794b36b87c2194b
https://bugs.freedesktop.org/show_bug.cgi?id=81053
The limit seems to be too low and causes problems in libnm-glib, that will not
return all NetworkManager connection profiles if there are too many of them
(roughly more than the limit). As a consequence, libnm-glib based clients will
not work properly.
Lets increase the limit in our D-Bus org.freedesktop.NetworkManager.conf
configuration as we had it before.
See also older commit d5b31d55fa1536a5bd08cf85929ac63a8f723467 that did the
opposite thing (removing the limit because the default D-Bus limit was 8192 at
that time).
|
| |
|
|
|
| |
No TAP support for previous versions and --tap argument is silently ignored,
confusing the TAP driver.
|
| |
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=737108
Signed-off-by: Jiří Klimeš <jklimes@redhat.com>
|
| |
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=737139
[thaller@redhat.com: modified original patch]
|
| |\
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Values for enumeration-style properties are displayed when setting a property,
and also TAB-completion offers the values.
Later, we plan to improve the handling even more by adding meta-data to libnm.
That would enable offering yes/no values, for example.
https://bugzilla.redhat.com/show_bug.cgi?id=1034126
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Valid values for enumeration-style properties are offered in TAB-completion in
the editor. Thus the user has a quick overview of the possible values and can
edit properties more easily.
Example:
$ nmcli con edit type wifi
nmcli> set wifi-sec.group <TAB>
ccmp tkip wep104 wep40
nmcli> ...
https://bugzilla.redhat.com/show_bug.cgi?id=1034126
|
| | | |
|
| | | |
|
| | | |
|
| |/
|
|
|
|
| |
nmcli 802-11-wireless.mode> set
Allowed values for 'mode' property: infrastructure, adhoc, ap
Enter 'mode' value:
|
| |
|
|
|
|
|
| |
for NM_DEVICE_STATE_REASON_PARENT_CHANGED
and NM_DEVICE_STATE_REASON_PARENT_MANAGED_CHANGED
Fixes: cd3df12c8f8ed6c868c12bc4e7fe6ba162dafc5b
|
| | |
|
