wifi: ensure not passing NULL bssid as string to printf logging functions

Signed-off-by: Thomas Haller <thaller@redhat.com>
wifi: avoid assertion in nm_ap_check_compatible() when comparing AP with missing BSSID

Signed-off-by: Thomas Haller <thaller@redhat.com>
wifi: Empty AP BSSID is NULL, not an invalid address

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
platform: add typedef for unions NMPlatformIPXAddress and NMPlatformIPXRoute

Signed-off-by: Thomas Haller <thaller@redhat.com>
policy: refactor NMDefaultRouteManager to use union type NMPlatformIPXRoute

Signed-off-by: Thomas Haller <thaller@redhat.com>
policy: minor fix when having multiple default routes with metric MAXUINT32

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>
policy: remove unused @do_sync argument from NMDefaultRouteManager functions

Signed-off-by: Thomas Haller <thaller@redhat.com>
device: only add default route when having any addresses

This fixes the failure to add a default route because no
addresses are configured yet.

Signed-off-by: Thomas Haller <thaller@redhat.com>
policy: minor refactoring in NMDefaultRouteManager to access routes generically

Signed-off-by: Thomas Haller <thaller@redhat.com>
policy: consider additional assumed routes when synchronizing the default route

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>
policy: resync routes on platform change events

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>
policy: pick up externally configured default routes for managed interfaces

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>
clients: only handle secret requests for connection being explicitly activated

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.
trivial: fix description of route-metric
platform: assert against expected lifetime values of NMPlatformIPAddress

Signed-off-by: Thomas Haller <thaller@redhat.com>
bluetooth: Don't call into bluez5 DUN code when it's not enabled

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
bluez: fix build without bluez5-dun

    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>
bluez: Another bluez5 build fix

Fixes the "unused declaration" warning with -Werror and no bluez-libs.

Fixes: f1c9595311f52d8b79e8d2032e006005613a8fb1
Fixes: 751b52e50be049b53a0b998638a22d4e28a59135
man: fix `make uninstall` to remove the nmtui manual pages

Fixes: 1e8b681d4f10c2b5e9478ec4972cad64aa1f8e7c
Signed-off-by: Thomas Haller <thaller@redhat.com>
tui: fix gateway editing

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