| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
| |
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.
|
| | | |
|
| |/ |
|
| |
|
|
|
|
|
| |
when adding a route with RTA_PREFSRC some kernel versions will reject
the request if the specified source address is still tentative: be sure
that the just added addresses are no more tentative before adding the
routes.
|
| |
|
|
| |
Fixes: f80d0eb29e5fed5798a3d08b37a235d0ceede451
|
| |
|
|
|
|
|
| |
Without it, clients can wrongly create VLan settings with
ID 4095, which triggers assertions in NetworkManager.
Fixes: 8715d61437060cacc68c156b1c8ed7bbce4b0a78
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
There are a lot of places where we want to either write a number,
or conditionally clear it. Like:
mtu = nm_setting_wireless_get_mtu (s_wireless);
if (mtu)
svSetValueInt64 (ifcfg, "MTU", mtu);
else
svUnsetValue (ifcfg, "MTU");
|
| | |
|
| |
|
|
| |
https://github.com/NetworkManager/NetworkManager/pull/21
|
| |\
| |
| |
| | |
https://bugzilla.redhat.com/show_bug.cgi?id=1445414
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
To support legacy scripts, we want to write out the NETMASK
key whenever the ifcfg file has a NETMASK key previously.
Note, that we anyway always write the relevant PREFIX key.
The NETMASK is redundant, only there to help legacy scripts.
That was broken, because we would svUnsetValue("NETMASK") before
checking whether the NETMASK key is present.
Also, when saving a connection to ifcfg-rh file that was created
by other tools, we might mix up the numbering. E.g. we never
write out IPADDR0. Hence, turn on legacy mode whenever the ifcfg-rh
file has any key starting with "NETMASK".
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| |/ |
|
| |
|
|
| |
Zanata seems to corrupt the translations: https://zanata.atlassian.net/browse/ZNTA-2007
|
| |
|
|
| |
From the Red Hat translators. Fix up the bad msgmerge.
|
| | |
|
| |
|
|
| |
And make -C po update-po to canonicalize them.
|
| |
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=783182
|
