| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |\ |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
For IPv4 addresses, the kernel automatically adds a route when
configuring an IP address. Unfortunately, there is no way to control
this behavior or to set the route metric.
Fix this, by adding our own route and removing the kernel provided
one.
Note that this adds a major change in that we no longer call
nm_ip4_config_commit() for assumed devices.
https://bugzilla.gnome.org/show_bug.cgi?id=723178
Signed-off-by: Thomas Haller <thaller@redhat.com>
|
| | |
| |
| |
| | |
Signed-off-by: Thomas Haller <thaller@redhat.com>
|
| |\ \ |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The previous commit made NM enforce the default route on interfaces for
which NM manages a default route.
For interfaces that are configured never-default, NM will now pick up
any externally configured default route, as if it was managed by NM.
This is important, because NMDefaultRouteManager needs a notion of which
is the best device. Without this change, it was agnostic to default routes
on managed, never-default interfaces.
Signed-off-by: Thomas Haller <thaller@redhat.com>
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Monitor default routes from platform, and resync the default routes
on changes.
For one, this fixes the following use-case: have an assumed device em1
with two routes of metric 20 and 21. Activate em2, which will get effective
metric 22.
When externally removing route em1/20, em2 would resync the effective metric to
20. This is correct and already worked before. However, when deleting em1/21,
nothing happened. With this change, em2 would resync to metric 21 to fill the gap.
However this commit has much bigger effects: whenever the user externally adds
a default route to an interface for which NM manages an default route, NM will
delete it.
Also, when deleting the default route (managed by NM), NM would readd
it. Effectivly, the user can no longer mess with the default route on
interfaces for which it manages the default route.
If the connection is configured never-default, the user still can add
default routes and NM will not touch them.
Obviously, this has no effect for assumed devices either and the user
can externally add and remove default routes as he wishes.
https://bugzilla.gnome.org/show_bug.cgi?id=735512
Signed-off-by: Thomas Haller <thaller@redhat.com>
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Not only consider the best route of assumed devices when synching the route
metrics. This fixes the following scenario:
Have em1 assumed, with two default routes (metric 20 and 21).
When activating em2, NMDefaultRouteManager would have determined
21 as the effective metric, thus overwriting the assumed route of em1.
Since we don't want to touch assumed interfaces, it is wrong to
overwrite the default route.
Instead, keep track of all the assumed default routes and consider their
metrics when choosing effective_metric.
Signed-off-by: Thomas Haller <thaller@redhat.com>
|
| | | |
| | |
| | |
| | | |
Signed-off-by: Thomas Haller <thaller@redhat.com>
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | | |
This fixes the failure to add a default route because no
addresses are configured yet.
Signed-off-by: Thomas Haller <thaller@redhat.com>
|
| | | |
| | |
| | |
| | | |
Signed-off-by: Thomas Haller <thaller@redhat.com>
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The case of having a metric MAXUINT32 is special, because in face of
multiple default routes with the same metric, NMDefaultRouteManager
cannot reduce the effective metric (because there is no lower priority
value).
This case works already correct, just when adding such a default route,
ensure that we add it to the *first* entry.
Signed-off-by: Thomas Haller <thaller@redhat.com>
|
| | | |
| | |
| | |
| | | |
Signed-off-by: Thomas Haller <thaller@redhat.com>
|
| | | |
| | |
| | |
| | | |
Signed-off-by: Thomas Haller <thaller@redhat.com>
|
| |\ \ \ |
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
It is simpler to add a parameter @simulate_success to
nm_firewall_manager_add_or_change_zone() instead of handling
these cases specially by the caller.
https://bugzilla.redhat.com/show_bug.cgi?id=1098281
Signed-off-by: Thomas Haller <thaller@redhat.com>
|
| | | | |
| | | |
| | | |
| | | | |
Signed-off-by: Thomas Haller <thaller@redhat.com>
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Not invoking a callback when cancelling the operation is counter
intuitive.
Note that NMPolicy refs the device, cancelling the call would leave
the reference hanging. That was not an issue because the call was
never cancelled. But still the behavior of NMFirewallManager is
unexpected.
Signed-off-by: Thomas Haller <thaller@redhat.com>
|
| | | | |
| | | |
| | | |
| | | | |
Signed-off-by: Thomas Haller <thaller@redhat.com>
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
nm_firewall_manager_add_or_change_zone()
Signed-off-by: Thomas Haller <thaller@redhat.com>
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
The directory firewall-manager/ only contained one source and one
header file. Move them to the parent src/ directory.
Signed-off-by: Thomas Haller <thaller@redhat.com>
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
The kernel does not terminate an ongoing IPv6LL address process when
the IPv6LL address generation mode is set to 'none' (indicating that
userspace wishes to handle IPv6LL). This means that when the kernel
is done with DAD for that address, it announces the address, and
if the device is in the DISCONNECTED state, NetworkManager will
generate an assume an IPv6LL-only connection on the device.
Unfortunately, that behavior also happens if the following is true:
1) IPv6LL addressing takes a while (eg, dad_transmits is high or
the kernel takes a while for some reason)
2) the activated connection fails quickly (dhclient fails or some
other fatal error terminates the activation attempt)
3) the activated connection has ipv6.method=ignore
In this case, when the device is brought up and ipv6.method=ignore,
NetworkManager re-enabled kernel IPv6LL and resets the IPv6 sysctl
properties. The kernel then generates an IPv6LL address and begins
DAD. SELinux prevented dhclient from running, and thus the connection
quickly failed. NM then turned off kernel IPv6LL when deactivating
the device after the activation failed, but the kernel does not
terminate the ongoing DAD. Some time after the device entered the
DISCONNECTED state, the kernel finished DAD and announced the address,
and NetworkManager emitted the 'recheck-assume' signal. This
generated a new IPv6LL-only connection which was then assumed.
Bouncing 'disable_ipv6' when re-enabling userspace IPv6LL during
device deactivation flushes the tentative kernel IPv6LL address,
thus preventing the address from being announced after userspace
IPv6LL is re-enabled.
Reproducer:
- ifconfig eth0 down
- prepare a DHCPv4 connection with ipv6.method=ignore
- set /proc/sys/net/ipv6/conf/all/dad_transmits to "15"
- ensure that DHCPv4 will fail (turn on SELinux + change dhclient's
context, or replace dhclient with a script that exits after 2 seconds)
- run NetworkManager
- activate the DHCP connection and watch it immediately fail
- wait for the kernel to announce the IPv6LL address after DAD finishes
- watch NM "assume" the new IPv6LL connection
|
| |\ \ \ \
| |_|_|/
|/| | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Libraries need to include <gi18n-lib.h>, not <gi18n.h>, so that _()
will get defined to "dgettext (GETTEXT_DOMAIN, string)" rather than
"gettext (string)" (which will use the program's default domain, which
works fine for programs in the NetworkManager tree, but not for
external users). Likewise, we need to call bindtextdomain() so that
gettext can find the translations if the library is installed in a
different prefix from the program using it (and
bind_textdomain_codeset(), so it will know the translations are in
UTF-8 even if the locale isn't).
(The fact that no one noticed this was broken before is because the
libraries didn't really start returning useful translated strings much
until 0.9.10, and none of the out-of-tree clients have been updated to
actually show those strings to users yet.)
|
| |/ / /
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
config.h should be included from every .c file, and it should be
included before any other include. Fix that.
(As a side effect of how I did this, this also changes us to
consistently use "config.h" rather than <config.h>. To the extent that
it matters [which is not much], quotes are more correct anyway, since
we're talking about a file in our own build tree, not a system
include.)
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | | |
Also move enumerating the installed DHCP plugins to the beginning
of nm_dhcp_manager_init().
Signed-off-by: Thomas Haller <thaller@redhat.com>
|
| | | | |
|
| | | |
| | |
| | |
| | | |
It ensures ifcfg-rh doesn't mess up the labels.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
When wifi secrets are missing, NM_DEVICE_STATE_FAILED due to
NM_DEVICE_STATE_REASON_NO_SECRETS is immediately followed by traversal to
NM_DEVICE_STATE_DISCONNECTED as soon as the server makes sure it won't
reconnect automatically. We sometimes aren't quick to handle the first signal
and only get the latter one.
Let's treat all states that aren't ordinarily reached upon activation as bad.
|
| | | |
| | |
| | |
| | |
| | | |
When the Gateway field is empty, we need to set the property to NULL,
not "".
|
| |\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Avoid passing NULL bssid where it does not make sense, fix a couple of bad
asserts.
https://bugzilla.gnome.org/show_bug.cgi?id=739258
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Since 3a54d050 the AP address is not a gbyte[], but a char *. The fake AP BSSID
fixup could trigger an assertion failure:
Oct 26 11:14:45 goatlord.localdomain NetworkManager[540]: nm_ethernet_address_is_valid: assertion 'addr != NULL' failed
https://bugzilla.gnome.org/show_bug.cgi?id=739258
Fixes: 3a54d050985d6ef2067b025571910a8ccd3cbd57
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
missing BSSID
Signed-off-by: Thomas Haller <thaller@redhat.com>
|
| | | | |
| | | |
| | | |
| | | | |
Signed-off-by: Thomas Haller <thaller@redhat.com>
|
| | |/ /
|/| | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Pop-up menus were slightly mis-aligned in the main window, and even
more mis-aligned in slave-editing windows. Fix that.
Also add a bit of padding to the pop-up window, because it just looks
better that way.
|
| | | |
| | |
| | |
| | |
| | | |
Print the result, and make the m4 formatting consistent with the
other kernel checks.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Since adding NMSettingIPConfig:gateway, we were just binding that
property to the Gateway entry as a string. But this caused two
different problems: first, we were trying to set the :gateway property
from the entry even when the IP address in the entry was incomplete
(causing warnings), and second, we were no longer enforcing the rule
that the gateway can only be set when there are static addresses
configured.
Fix this by adding back nm_editor_bind_ip_gateway_to_string(), but
with new semantics reflecting the new way NMSettingIPConfig:addresses
and :gateway work. (Besides just fixing the new bugs, this also makes
the Gateway entry insensitive when there are no addresses; before,
nmtui would allow you to type there, but the value would not be
saved.)
Fixes: Test263_nmtui_ipv4_addresses_delete_ip_and_back_to_auto
https://bugzilla.gnome.org/show_bug.cgi?id=740017
|
| | | |
| | |
| | |
| | |
| | | |
Fixes: 1e8b681d4f10c2b5e9478ec4972cad64aa1f8e7c
Signed-off-by: Thomas Haller <thaller@redhat.com>
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | | |
Fixes the "unused declaration" warning with -Werror and no bluez-libs.
Fixes: f1c9595311f52d8b79e8d2032e006005613a8fb1
Fixes: 751b52e50be049b53a0b998638a22d4e28a59135
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
make[5]: Entering directory `./NetworkManager/_build/src/devices/bluetooth'
CC nm-bluez-device.lo
../../../../src/devices/bluetooth/nm-bluez-device.c: In function 'nm_bluez_device_disconnect':
../../../../src/devices/bluetooth/nm-bluez-device.c:430:5: error: "WITH_BLUEZ5_DUN" is not defined [-Werror=undef]
#if WITH_BLUEZ5_DUN
Fixes: f1c9595311f52d8b79e8d2032e006005613a8fb1
Fixes: 751b52e50be049b53a0b998638a22d4e28a59135
Signed-off-by: Thomas Haller <thaller@redhat.com>
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
It is conditionally compiled depending on presence of bluez-libs.
Results in undefined symbols:
NetworkManager[19346]: <warn> (/libnm-device-plugin-bluetooth.so): failed to
load plugin: /usr/lib64/NetworkManager/libnm-device-plugin-bluetooth.so:
undefined symbol: nm_bluez5_dun_cleanup
|
| | | |
| | |
| | |
| | | |
Signed-off-by: Thomas Haller <thaller@redhat.com>
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
When a connection is being activated, nmcli could ask for secrets for another
connection, which might confuse users. We check the request now and only ask
for secrets of connection being activated.
Test case:
$ nmcli con up my-ethernet0
Passwords or encryption keys are required to access the wireless network 'Red Hat'.
Warning: password for '802-1x.identity' not given in 'passwd-file' and nmcli cannot ask without '--ask' option.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
and remove atomic operations
Upstream glib changed g_clear_pointer() not to use atomic functions.
Update or local definition to b1dd594a22e3499caafdeccd7fa223a032b9e177
glib/gmem.h (glib 2.41.3).
(fixup whitespace to match our style).
See also the related bug https://bugzilla.gnome.org/show_bug.cgi?id=733969
from glib.
Signed-off-by: Thomas Haller <thaller@redhat.com>
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The DRM now affects DNS too, since it determines the "best" IPv4
and IPv6 configs based on it's idea of the default route. The
Policy is also still updating DNS from a state-change handler for
VPN connections.
This led to a situation where the Policy would remove the VPN's
IP config from the DNS manager in vpn_connection_deactivated() and
call update_ip4_dns(), whereupon get_best_ip4_config() returned
the just-removed VPN IPv4 config as "best" because the VPN connection
hadn't yet told the DefaultRouteManager to remove it.
Which meant VPN nameservers stuck around in resolv.conf for a long
time after the VPN was disconnected.
Fixes: a39a3ae4cd72d695f1b5d10eaa79544f2020a54e
|
| | | |
| | |
| | |
| | |
| | |
| | | |
Now that "i" is being used in the first loop over all connections, we
need to reset it before using it again in the loop to find an
available name.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | | |
Previously we were logging:
<debug> [1415715440.639086] [__FILE__:__LINE__] client_set_lease_timeouts(): DHCP CLIENT (0xcf221f86): T1 expires in 11h 59min 53.566147s
Signed-off-by: Thomas Haller <thaller@redhat.com>
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Example (for active connection ethernet-13)
$ nmcli -f active con show ethernet-13
...
IP4.ADDRESS[1]: 10.34.25.205/23
IP4.GATEWAY: 10.34.25.254
IP4.ROUTE[1]: dst = 10.38.5.26/32, nh = 0.0.0.0, mt = 20
...
https://bugzilla.gnome.org/show_bug.cgi?id=739958
|
