| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Don't have pending asynchronous requests in parallel, like setting
"ProcessCredentials" and "Start", or "Cancel" and "Start".
Instead, "Start" is only scheduled after "ProcessCredentials" completed
and "ProcessCredentials" is only scheduled after "Cancel" completed.
Also, handle the async response of these requests. For one, to achive the
chaining mentioned above and to log what happens and possible errors.
Upon new enrollment, a previously created GDBusProxy is now reused,
where the first operation is to Cancel the previous action.
Also, consistently <trace> log what is happening.
|
| | |
|
| |\ |
|
| | |
| |
| |
| |
| |
| | |
We don't need this flexibility of having a full fledged GObject
property for is-master. The property value only depends on the
device's class.
|
| | |
| |
| |
| |
| | |
This gives a third return value: whether the device did not
match.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
activate_stage5_ip4_config_result()
We have nm_device_activate_schedule_ip4_config_result(). The name
should match.
Note, this affects logging, as we log the function name.
|
| | |
| |
| |
| | |
It's easier to search in the logfile.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
A better name is link_speed_update(), because it re-reads and
sets the speed value.
Also, move _notfiy() after logging. It doesn't matter in this
case, but we should first log, and then do actions that have potentially
complex side-effects.
|
| | |
| |
| |
| |
| |
| | |
Now, that NMDeviceClass:carrier_changed_notify() is no longer called as
deferred action, we can check for DCB state there, instead or registering
to the NM_DEVICE_CARRIER notifications.
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Note that:
- carrier_changed_notify() has only one implementation: NMDeviceEthernet
to call get_link_speed() when carrier comes back.
- currently, calling carrier_changed_notify() with carrier=FALSE
has no effect, because NMDeviceEthernet only acts on carrier=TRUE.
- when carrier appears, nm_device_set_carrier() will call
carrier_changed() right away. We only call carrier_changed()
with carrier=TRUE only at one place. The change merley moves
carrier_changed_notify() out of the function. Apart from
that it has no effect.
- when carrier disappears, previoulsy we would delay action for
4 seconds. Hence, we would delay carrier_changed_notify() as well
-- although it has no effect.
The last point is at least ugly. Fix it by moving
carrier_changed_notify() to nm_device_set_carrier().
|
| |
|
|
|
| |
Otherwise the daemon would hang waiting for us while we respond with awkward
silence. That is not a healthy kind of communication.
|
| |
|
|
|
|
|
|
|
| |
Coverity complains about not checking the return value:
src/settings/nm-settings-connection.c:2329: check_return: Calling "g_key_file_load_from_file" without checking return value (as is done elsewhere 6 out of 7 times).
While at it, refactor the code and check whether the timestamp
is valid.
|
| | |
|
| |
|
|
|
|
| |
g_async_initable_init_finish()
NetworkManager-1.8.0/src/supplicant/nm-supplicant-interface.c:232: check_return: Calling "g_async_initable_init_finish" without checking return value (as is done elsewhere 7 out of 8 times).
|
| |
|
|
| |
NetworkManager-1.8.0/src/supplicant/tests/test-supplicant-config.c:528: check_return: Calling "nm_setting_802_1x_set_ca_cert" without checking return value (as is done elsewhere 13 out of 16 times).
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
commit a955639 (connectivity: don't do periodic checks on interval=0)
broke scheduling connectivity checks.
That is because the timer is on only scheduled if
nm_connectivity_check_enabled(), which in turn only returns TRUE
if curl_mhandle is set. However, nm_connectivity_init() would only
initialize curl_mhandle after update_config(), missing to schedule
the periodic task.
https://mail.gnome.org/archives/networkmanager-list/2017-May/msg00076.html
Fixes: a95563996f07641e9877eb1760cac24415b65070
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
rpmdiff complains about uses of inet_aton, inet_makeaddr, inet_netof,
inet_ntoa under the IPv6 section:
usr/sbin/NetworkManager on aarch64 i686 x86_64 ppc ppc64 ppc64le s390 s390x uses function inet_aton, which may impact IPv6 support
I think the warning is bogus, but refactor our code to avoid it.
Note that systemd code still uses them, so it don't avoid the rpmdiff
warning. But let's not diverge our systemd import from upstream for this.
- for NMSettingBond:validate_ip() also avoid g_strsplit_set() which
allocates a full strv. Instead, we can do with one g_strdup().
- for test-resolvconf-capture.c, replace the functions with macros.
Macros should be avoided usually, but for test asserts they are
more convenient as they preserved the __FILE__:__LINE__ of where
the assertion fails.
|
| |
|
|
|
|
|
|
| |
Teamd is not happy about them and would fail anyway. Worse even, if we
json_loads() such a JSON, which is precisely what happens when we inject the
"hwaddr" key, we turn bad JSON into a good one in a lossy matter. Not good.
https://bugzilla.redhat.com/show_bug.cgi?id=1455130
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When building with -flto, we need to use linker plugins.
In case of binutils' nm, it means to prefer gcc-nm if
available.
Like for ranlib and ar, prefer gcc-nm.
- replace AC_PATH_TOOL() by AC_CHECK_TOOLS(). That is consistent
with what we do for ar,ranlib and suggested on bgo#783311.
- instead of using the variable $BINUTILS_NM, replace it by
$NM, which is more common according to bgo#783311.
- Keep recognizing $BINUTILS_NM environment, which was introduced
by commit 8bc88bcc7c. This is purely to keep previous build
scripts working. Originally I named it "$BINUTILS_NM" because
using $NM in NetworkManager seemed confusing. But well...
https://bugs.gentoo.org/show_bug.cgi?id=620052
https://bugzilla.gnome.org/show_bug.cgi?id=782525
https://bugzilla.gnome.org/show_bug.cgi?id=783311
|
| |
|
|
| |
Fixes: ba05819c89d913ad1bc6b86e62c7704d173ef534
|
| |\
| |
| |
| | |
https://bugzilla.gnome.org/show_bug.cgi?id=783013
|
| | |
| |
| |
| |
| | |
The Bluetooth NAP functionality seems only useful for the bridges. Move
it away from NMDevice.
|
| | |
| |
| |
| |
| |
| | |
If there is value in such a helper function (there is), then
it should go alongside the other nm_connection_get_setting*()
helpers. NMDevice is already large enough.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The plugins may use stuff from core, but not the other way around.
Including "bluetooth/nm-bluez-common.h" is wrong.
The UUID argument is always "nap" in the NAP case. We don't need
the flexibility that it might be anything else. Just drop it.
As far as NMDevice is concerned, it anyway wouldn't (or shouldn't
know what the uuid is. It says register, and NMBluez5Manager should
figure out the details.
|
| | | |
|
| | |
| |
| |
| |
| | |
They may register the Bluetooth NAP enabled bridges for Bluez to enslave their
BNEP links to.
|
| | |
| |
| |
| |
| | |
Bluez needs to know about then so that it can eventually enslave the BNEP links
for PANU client connections to it.
|
| | |
| |
| |
| | |
It might have changed circumstances that were blocking the autoactivation.
|
| | |
| |
| |
| |
| |
| |
| |
| | |
We'll use this to let the devices know they can retry autoactivation
because some component became available without actually having any
data that would be useful for that device.
Adjust the comment.
|
| | | |
|
| | |
| |
| |
| | |
Will be useful for Bluetooth NAP.
|
| | |
| |
| |
| |
| |
| |
| |
| | |
For the Bluetooth NAP we need a Bridge link for the BlueZ to assign the BNEP
links for PANU client connections into.
Let's disable STP by default -- it adds extra delay for the Bridge when the
BNEP link is assigned and is likely not useful for a typical client.
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| | |
When the two base settings are present, use one of higher priority.
This will pick the "bridge" setting when both "bridge" and "bluetooth" are
present for a Bluetooth NAP connection.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
We'll need two "base" settings for Bluetooth NAP connections: bridge to set up
the actual link and bluetooth to identify the HCI to register the network
server with.
Let's use two priorities for base setting, with "1" marking one of higher
priority and "2" of lower priority when both are present.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
We will need multiple base settings for Bluetooth NAP servers: bluetooth and
bridge. We want to identify the device as "bluetooth" to the user, but leave
the Bridge factory handle it.
The "connection.type" is somewhat redundant -- let's keep it for what the user
sees. And identify the actual base setting to pick the right factory by the
actually present setting.
|
| | | |
|
| | | |
|
| | |
| |
| |
| | |
Fixes: 2198f73b0ec810b6b9084c0e00dcf07d4a6ee8e3
|
| | | |
|
| | | |
|
| |/ |
|
| | |
|
| |
|
|
|
| |
For better or worse, there is a platform argument. Use it instead
of the singleton.
|
| |\ |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
- no need to call nm_platform_process_events() after
nmtstp_wait_for_signal(). The latter processes all events
that are pending.
- with addr_n number of addresses, we still only want to wait
a maximum time, not for each addresss individually. Basically,
the for-loop must be inside NMTST_WAIT(), not the other way around.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
Having an unsigned "guint timeout_ms" argument is very inconvenient, because
nmtstp_wait_for_signal (NM_PLATFORM_GET (), end_time - now_time);
might easily be negative. In such a case, the correct behavior
is to wait not at all.
|
| | |
| |
| |
| |
| |
| | |
The previous behavior, of treating timeout_ms as *no timeout*, makes
no sense. At least not for unit tests. If you have a really long timeout,
then set it. "0" should really mean to schedule a zero timeout.
|
| | | |
|
| |/ |
|
