Return the extended ack message from the WaitForNlResponse delayed
action so that the caller can print a detailed reason with the
appropriate logging level.
From v4.12 the kernel appends some attributes to netlink acks
containing a textual description of the error and other fields (see
commit [1]). Parse those attributes and print the error message.
Examples:
platform-linux: netlink: recvmsg: error message from kernel: Network is unreachable (101) "Nexthop has invalid gateway" for request 12
platform-linux: netlink: recvmsg: error message from kernel: Invalid argument (22) "Local address cannot be multicast" for request 21
[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=2d4bc93368f5a0ddb57c8c885cdad9c9b7a10ed5
If an operation is cancelled through the GCancellable, then the idiom is
that the operation is always cancelled, even if it has finished
successfully. To ensure this is the case, add calls to
g_simple_async_result_set_check_cancellable everywhere.
Without this, e.g. gnome-control-center will crash when switching away
from the power panel quickly, as the NMClient creation finishes
asynchronously and g-c-c assume that G_IO_ERROR_CANCELLED is returned to
ensure it doesn't access the now invalid user_data parameter.
https://bugzilla.gnome.org/show_bug.cgi?id=794088
NAP connections are a bit special, in that they also have a [bridge]
setting, but their connection.type is "bluetooth".
The canonical way to check whether a bluetooth connection is of NAP type
is by calling _nm_connection_get_setting_bluetooth_for_nap().
So, instead of checking for bluetooth.type "pan" or "dun", check the
opposite and whether the connection is of NAP type. In practice it's the
same, but let'check for NAP consistently via get_setting_bluetooth_for_nap().
Bluetooth tethering using DUN or PANU is a common way to expose a
metered 3G or 4G connection from a phone to a laptop. We deliberately
ignore NAP connections, which is where we’re sharing internet from the
laptop to another device.
We could also set GUESS_YES for WiMAX connections, but NetworkManager
doesn’t support them any more. Add a comment about that.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=794120
The condition was obviosly inverted, blocking autoconnect when
it should not, and not blocking it when it should.
[thaller@redhat.com: modified original patch and rewrite commit message]
Fixes: e2c8ef45achttps://bugzilla.gnome.org/show_bug.cgi?id=794014
IPv4 routes that are a response to RTM_GETROUTE must have the cloned
flag while IPv6 routes don't have to. Don't check the flag for IPv6
routes and add a test case to verify that RTM_GETROUTE works for IPv6.
https://bugzilla.gnome.org/show_bug.cgi?id=793962
Latest versions of meson require now Python 3.5+. Not only that meson requires Python3
and thus makes building on some systems cumbersome (RHEL7), it also eagerly bumps
Python3.y requirements.
Install the last working release which works with Python3.4. This fixes
the the travis build failure on Ubuntu 14.04 (trusty):
Meson works correctly only with python 3.5+.
You have python 3.4.3 (default, Nov 28 2017, 16:41:13)
[GCC 4.8.4].
Please update your environment
If SSID is an empty string there's no need to call nm_wifi_ap_set_ssid
as it won't do anything. It also has an assert checking that NULL is
passed for an empty SSID and we were passing a non-NULL pointer.
This bug was not causing a crash for me because of the !IS_NM_DEVICE_IWD
check and because my glib version probably had the assertion within
NM_IWD_MANAGER_GET_PRIVATE disabled.
While there, change the g_signal_connect line to use the macro for the
signal name.
Make sure .set_enabled uses the Device.Powered property to basically
bring the netdev UP and DOWN as I understand is expected by the
nm_device logic.
Device.Powered should generally reflect the UP state immediately but
just to avoid possible race conditions .is_available() will now return
a value that is an AND of the local "enabled" state and IWD's Powered
property.
Change from the default dbus call timeout (-1) to infinite (G_MAXINT)
because the call may now include the secret requests which have their
own timeout policies.
Remove the code (mostly copied from nm-device-wifi.c) that handles
checking if the secrets were provided and requesting missing secrets
before starting a connection attempt. Instead, request secrets when
we're asked for them by IWD through its agent interface. This happens
while the dbus Connect call is running. We change the NMDevice from
the CONFIG state to NEED_AUTH and then change back to CONFIG once we
sent the secrets back to IWD.
The current code would require the secrets only based on whether a
network is a KnownNetwork but IWD may need a new passwords even for
KnownNetworks if the last connection attempt has failed.
The parsing of the certificate consists of a series of checks, and if a
check matches, we determine the type and are done.
Moving these checks to different functions (that are only called once)
makes it more complicated to understand what really happens. Merge them
all together.
Refactor cert_parser() to return early.
Also, rework handle_as_scheme() and handle_as_path() to check for
success first and return early. This in the next step will allow
to merge the functions.
Always read and load ipv4 property values when method is shared also if
they will not be used: instead of dropping them at connection update,
keep their values in the ifcfg file.
Exceptions: ipv4.dns and ipv4.dns-search. They will be not read, otherwise
they may trigger a failure in nm-setting-ip4-config.c:verify() on load.
https://bugzilla.redhat.com/show_bug.cgi?id=1519299
../libnm/tests/test-general.c: In function ‘test_fixup_vendor_string’:
../libnm/tests/test-general.c:70:3: error: initializer element is not constant
T_DATA ("3Com", "3Com"),
^
../libnm/tests/test-general.c:70:3: error: (near initialization for ‘data[0]’)
../libnm/tests/test-general.c: In function ‘test_fixup_product_string’:
../libnm/tests/test-general.c:365:3: error: initializer element is not constant
T_DATA ("10/100BaseTX [RTL81xx]", "RTL81xx"),
...
Fixes: 817fce917b
CC libnm/tests/libnm_tests_test_general-test-general.o
libnm/tests/test-general.c: In function ‘test_fixup_product_string’:
libnm/tests/test-general.c:328:1: note: variable tracking size limit exceeded with -fvar-tracking-assignments, retrying without
test_fixup_product_string (void)
^~~~~~~~~~~~~~~~~~~~~~~~~
Fixes: 8e32d8fc23
Passing ownership with a function call is confusing. Don't do that.
Since we have the cleanup attribute, it doesn't significantly
complicate the callers, as all they need to do is marking the
@msg variable to free the message when going out of scope.
That results in the function that allocates the message also being
responsible to free it.
The callers expect _nl80211_send_and_recv() to free @msg.
This was broken by the previous commit, which wrongly removed
the nm_auto_nlmsg cleanup attribute.
Fix the compiler warning differently.
Fixes: d7108d9362
It's very likely that the product said something that was filtered out
by the fixup, such as "PCI Ethernet" or "Wi-Fi Adapter". Use a generic
type name in place of it.
The product names are generally of rather poor quality. The product name
is no place to enumerate product capabilities, the bus it's attached on
and similar nonsense.
If there's a [<string>] that survived the substitution, then the string
is supposed to be a short form that is generally preferrable.
That's great in theory, but actually it's rather often pure garbage for
product names. Let's prefer it just for vendors and provide an option to
drop it (will be useful for fixing up product names).
The hwdb generally contains the strings of rather poor quality,
especially when it comes to sensibly presenting them to the user and
they need various cleanups.
While the following patches add fixups, this one splits out vendor
fixups, because it turns out that a different set of fixups is needed
than for products.
systemd commit f11cba7479fe ("libsystemd-network: fix unaligned loads
(issue #7654)") changed the way in which the MAC address is read to
use native endiannes:
htobe32(*((uint32_t *)x) -> unaligned_read_ne32(x)
This is wrong because loads done with BPF_LD + BPF_ABS are big-endian, as it
can be seen for the ethertype and arp-operation loads above in the
filter. Also, the same commit changed:
htobe32(*((unsigned int *)x) -> unaligned_read_be32(x)
in _bind_raw_socket(), which is the correct form.
The commit broke IPv4LL in presence of loops, as the sender now considers its
own packets as conflicting.
systemd commit: 6afe9046d570fd86dbc04526b5685c64d7958086
Now that every call to nm_device_set_ip_iface() and nm_device_set_ip_ifindex()
is checked, and setting an interface that does not exist causes the device
state to fail, we no longer need to allow setting an ip-iface if we are
unable to retrieve the ip-ifindex.
Depending on the bearer's configuration method, the data-port is
either a networking interface, or an tty for ppp.
Let's treat them strictily separate.
Also, rework how NM_MODEM_DATA_PORT was used in both contexts.
Instead, use the that we actually care about.
Also, when nm_device_set_ip_ifindex() fails, fail activation
right away.
Also, we early try to resolve the network interface's name to
an ifindex. If that fails, the device is already gone and we
fail early.
