Commit graph

157 commits

Author SHA1 Message Date
Thomas Haller
6ecf78a19b bluetooth/trivial: rename NetworkServer's network_servers field
The list field should have a unique name and not the same as the
list head. This avoids

    c_list_link_before (&priv->network_servers, &network_server->network_servers);

    c_list_for_each_entry (network_server, &priv->network_servers, network_servers) {
2017-06-07 09:07:18 +02:00
Thomas Haller
40a2955647 bluetooth: split _find_network_server() in two functions
Instead of having a complex _find_network_server() function with several
arguments, split it.

Having multiple optional arguments to a find() function is fine,
if all arguments consistently narrow down the search.
For example nmp_cache_lookup_link_full(), where each argument is
optional, and it restricts the search.
For _find_network_server() that was not the case, because setting
"addr" and "device" together would be non-sensical.
2017-06-07 09:07:18 +02:00
Thomas Haller
abdf9a3673 all: change handling of connection.type for bluetooth NAP and in general
Branch f9b1bc16e9 added bluetooth NAP
support. A NAP connection is of connection.type "bluetooth", but it
also has a "bridge" setting. Also, it is primarily handled by NMDeviceBridge
and NMBridgeDeviceFactory (with help from NMBluezManager).

However, don't let nm_connection_get_connection_type() and
nm_connnection_is_type() lie about what the connection.type is.
The type is "bluetooth" for most purposes -- at least, as far as
the client is concerned (and the public API of libnm). This restores
previous API behavior, where nm_connection_get_connection_type()
and nm_connection_is_type() would be simple accessors to the
"connection.type" property.

Only a few places care about the bridge aspect, and those places need special
treatment. For example NMDeviceBridge needs to be fully aware that it can
handle bluetooth NAP connection. That is nothing new: if you handle a
connection of any type, you must know which fields matter and what they
mean. It's not enough that nm_connection_get_connection_type() for bluetooth
NAP connectins is claiming to be a bridge.

Counter examples, where the original behavior is right:

src/nm-manager.c-        g_set_error (error,
src/nm-manager.c-                     NM_MANAGER_ERROR,
src/nm-manager.c-                     NM_MANAGER_ERROR_FAILED,
src/nm-manager.c-                     "NetworkManager plugin for '%s' unavailable",
src/nm-manager.c:                     nm_connection_get_connection_type (connection));

the correct message is: "no bluetooth plugin available", not "bridge".

src/settings/plugins/ifcfg-rh/nms-ifcfg-rh-writer.c:   if (   (   nm_connection_is_type (connection, NM_SETTING_WIRED_SETTING_NAME)
src/settings/plugins/ifcfg-rh/nms-ifcfg-rh-writer.c:           && !nm_connection_get_setting_pppoe (connection))
src/settings/plugins/ifcfg-rh/nms-ifcfg-rh-writer.c:       || nm_connection_is_type (connection, NM_SETTING_VLAN_SETTING_NAME)
src/settings/plugins/ifcfg-rh/nms-ifcfg-rh-writer.c:       || nm_connection_is_type (connection, NM_SETTING_WIRELESS_SETTING_NAME)
src/settings/plugins/ifcfg-rh/nms-ifcfg-rh-writer.c:       || nm_connection_is_type (connection, NM_SETTING_INFINIBAND_SETTING_NAME)
src/settings/plugins/ifcfg-rh/nms-ifcfg-rh-writer.c:       || nm_connection_is_type (connection, NM_SETTING_BOND_SETTING_NAME)
src/settings/plugins/ifcfg-rh/nms-ifcfg-rh-writer.c:       || nm_connection_is_type (connection, NM_SETTING_TEAM_SETTING_NAME)
src/settings/plugins/ifcfg-rh/nms-ifcfg-rh-writer.c:       || nm_connection_is_type (connection, NM_SETTING_BRIDGE_SETTING_NAME))
src/settings/plugins/ifcfg-rh/nms-ifcfg-rh-writer.c-        return TRUE;

the correct behavior is for ifcfg-rh plugin to reject bluetooth NAP
connections, not proceed and store it.
2017-06-07 09:07:17 +02:00
Lubomir Rintel
bf7e86128c bridge: move the Bluetooth NAP logic to bridge device
The Bluetooth NAP functionality seems only useful for the bridges. Move
it away from NMDevice.
2017-06-01 11:57:42 +02:00
Thomas Haller
1be01bd51f device: don't include header of bluetooth plugin in nm-device.h
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.
2017-06-01 11:28:57 +02:00
Lubomir Rintel
29a0876db6 bluetooth: emit component-added when a network server is added 2017-06-01 11:28:57 +02:00
Lubomir Rintel
d6f2a2e73c bluetooth: expose known HCI adapters to devices
They may register the Bluetooth NAP enabled bridges for Bluez to enslave their
BNEP links to.
2017-06-01 11:28:57 +02:00
Lubomir Rintel
53482c38e2 device: register a bridge for Bluetooth NAP with Bluez
Bluez needs to know about then so that it can eventually enslave the BNEP links
for PANU client connections to it.
2017-05-31 20:18:24 +02:00
Lubomir Rintel
b866a12667 device: retry autoactivation upon a component addition
It might have changed circumstances that were blocking the autoactivation.
2017-05-31 20:18:12 +02:00
Lubomir Rintel
15daf29220 bluez5: avoid leaking the interface dictionary 2017-05-31 20:11:46 +02:00
Lubomir Rintel
1bb751b9d1 bluez5: use _NMLOG 2017-05-31 20:11:15 +02:00
Lubomir Rintel
1a20611f66 bluetooth/trivial: rename the defines 2017-05-31 20:10:30 +02:00
Lubomir Rintel
43c43d5e3a bluetooth: streamline NMBluez5Manager teardown a bit 2017-05-31 20:05:53 +02:00
Lubomir Rintel
0aa2e0bad3 bluetooth: unhook adapter properties callback when the adapter vanishes
https://bugzilla.redhat.com/show_bug.cgi?id=1454654
2017-05-23 11:33:15 +02:00
Thomas Haller
f61b1dadae bt: use logging macros in nm-bluez4-manager.c 2017-05-12 17:29:33 +02:00
Thomas Haller
7d11fe5581 bt: use logging macros in nm-bluez4-adapter.c 2017-05-12 17:29:33 +02:00
Thomas Haller
e68a33d114 bt: create D-Bus proxy for NMBluez4Manager asynchronously
And some fixes:

  - proxy creation may fail. Don't handle it by retrying,
    but at least don't access the invalid proxy instance.

  - quering "DefaultAdapter" did not take a reference to @self
    nor was the operation cancellable. This leads to crash
    if the instance gets destroyed early.
2017-05-12 17:29:33 +02:00
Thomas Haller
44f5e372ce bt: create D-Bus proxy for NMBluez4Adapter asynchronously
And some fixes:

  - proxy creation may fail. Don't handle it by retrying,
    but at least don't access the invalid proxy instance.

  - get_properties_cb() did not take a reference to @self
    nor was the operation cancellable. This leads to crash
    if the instance gets destroyed early.
2017-05-12 17:29:33 +02:00
Thomas Haller
e84a52ea42 bt: track name-owner changes via NMModemManager and create D-Bus proxy asynchronously
Fix two issues of the previous code:

  - the D-Bus proxy for the modem manager should not get created
    synchronously.
  - NMModemManager is a singleton, let it track the name-owner
    change and the D-Bus proxy, instead of having one per NMDeviceBt.
2017-05-12 17:29:33 +02:00
Thomas Haller
7840dde47b bt: minor refactoring of mm_name_owner_changed() function 2017-05-12 17:29:33 +02:00
Thomas Haller
d1ef7f7aac bt: move initialization of NMDeviceBt to constructed()
Don't do non-trivial initialization in nm_device_bt_init(). At
this point, the object is not yet fully created. As we already have
a constructed() implemented, move the initialization there.
2017-05-12 17:29:33 +02:00
Thomas Haller
ce1ae5f458 modem: add define for ModemManager D-Bus path
Also, bluetooth plugin uses NMModem from the wwan plugin. Don't
include such a foreign header in a "nm-device-bt.h". Instead, forward
declare what we need.
2017-05-12 17:29:33 +02:00
Thomas Haller
7b91e8b6db device: don't use platform singleton getter in device subclasses
Reduce the use of NM_PLATFORM_GET / nm_platform_get() to get
the platform singleton instance.

For one, this is a step towards supporting namespaces, where we need
to use different NMNetns/NMPlatform instances depending on in which
namespace the device lives.

Also, we should reduce our use of singletons. They are difficult to
coordinate on shutdown. Instead there should be a clear order of
dependencies, expressed by owning a reference to those singelton
instances. We already own a reference to the platform singelton,
so use it and avoid NM_PLATFORM_GET.

(cherry picked from commit 94d9ee129d)
2017-04-18 15:53:11 +02:00
Thomas Haller
ec2681d4db all: use nm_clear_g_cancellable() 2017-03-13 12:00:23 +01:00
Thomas Haller
ab6e370195 all/trivial: unify construct-only property comments
Unify marking GObject properties that are G_PARAM_CONSTRUCT_ONLY
with a comment

    /* construct-only */
2017-03-08 13:47:00 +01:00
Thomas Haller
72bfe62a9a all: use stack-allocated uuid at various places
No need to create a UUID on the heap in this case.
2017-03-02 12:14:29 +01:00
Thomas Haller
405ee7cad0 device: mark uses of device's state-reason with nm_device_state_reason_check()
The state-change of a device has a reason argument, which is mostly for information
only.

There are many places in code that are the source of a state-reason.
Mostly these are calls to:
  - nm_device_state_changed()
  - nm_device_queue_state()
  - nm_device_queue_recheck_available()
  - nm_device_set_unmanaged_by_*()
  - nm_device_master_release_one_slave()
  - nm_device_ip_method_failed()
  - nm_modem_emit_prepare_result()
  - nm_modem_emit_ppp_failed()
  - nm_manager_deactivate_connection()
  - NM_SET_OUT (out_failure_reason, NM_DEVICE_STATE_REASON_*);

However, there are a few places in code that look at the reason
to decide how to proceed. I think this is a bad pattern, because
cause and effect are decoupled and it gets hard to understand where
a certain reason is set and what consequences that has.

Add a nop-function nm_device_state_reason_check() to mark all uses
of the device state reason that derive decisions from it. That is,
highlight the "effect" part.
2017-02-23 17:07:28 +01:00
Thomas Haller
8e12396b74 modem: remove unused reason argument from nm_modem_device_state_changed()
The reason has pecular meanings during a device state change.
Let's remove the unused reason argument to reduce the noise.
2017-02-23 14:42:36 +01:00
Thomas Haller
434e7b2aa3 modem: cleanup integer types for ppp-stats signal
In practice, guint32 is identical to guint. However, that is not
guaranteed, and we should keep the types separate.
2017-02-23 12:33:41 +01:00
Thomas Haller
20b17910d0 modem: add nm_modem_emit_ppp_failed() function
... instead of emitting the signal by name.
2017-02-23 12:33:41 +01:00
Thomas Haller
0a1fd88d5a modem: add nm_modem_emit_prepare_result() function
... instead of emitting the signal by name. For one,
we get the casting of the NMDeviceStateReason enum right.
Also, emitting by the guint signal-id is faster then
emitting by name.
2017-02-23 12:33:41 +01:00
Thomas Haller
6c8eac1a4c modem: use defines for signal names 2017-02-23 12:20:13 +01:00
Thomas Haller
437c12fc89 device: rename device-state-reason argument to out_failure_reason
This argument is only relevant when the NMActStageReturn argument
indicates NM_ACT_STAGE_RETURN_FAILURE. In all other cases it is ignored.

Rename the argument to make the meaning clearer. The argument is passed
through several layers of code, it isn't obvious that this argument only
matters for the failure case. Also, the distinct name makes it easier
to distinguish from other uses of the "reason" name.

While at it, do some drive-by cleanup:

  - use g_return_*() instead of g_assert() to have a more graceful
    assertion.
  - functions like dhcp4_start() don't need to return a failure reason.
    Most callers don't care, and the caller who does can determine the
    proper reason.
  - allow omitting the out-argument via NM_SET_OUT().
2017-02-22 21:37:47 +01:00
Beniamino Galvani
f37e183442 device: apply the mtu property of gsm and cdma settings 2017-02-20 09:18:25 +01:00
Thomas Haller
2f9166e6b9 device: separately handle NMDevice's autoconnect by user and internal decision
The NMDevice's autoconnect property is settable via D-Bus and is is
also modified by internal decision, like when no PIN is available.

Certain internal actions cause clearing the internal autoconnect flag,
but they should not override the user desicion.

For example, when NM awaks from sleep it would reenable autoconnect,
but it should not reenable it for devices where the user explicitly
said that autoconnect is to be disabled.

Similarly, activating a device alone is not yet an instruction to
re-enable autoconnect. If the user consciously disables autoconnect,
it should stay enabled. On the other hand, activating a device should
reenable autoconnect if it was blocked by internal decision.

We need to track these two flags separately, and set them accordingly.
2017-02-17 14:41:27 +01:00
Thomas Haller
dc40288849 all: use NM_CACHED_QUARK_FCN() to define cached quarks 2017-02-10 14:33:52 +01:00
Thomas Haller
0bb1e9a116 ip[46]-config/trivial: move code around
Move the GObject related functions to the end of the source file.
Similar to how it's done for most other implementations.
2017-01-16 17:24:36 +01:00
Thomas Haller
4bdee37771 all: use O_CLOEXEC for file descriptors 2016-12-13 11:26:59 +01:00
Lubomir Rintel
972e0d2803 all: rename the introspection data to use the interface paths in names
This makes it easier to install the files with proper names.
Also, it makes the makefile rules slightly simpler.

Lastly, the documentation is now generated into docs/api, which makes it
possible to get rid of the awkward relative file names in docbook.
2016-11-23 15:43:42 +01:00
Thomas Haller
44ecb41593 build: don't add subdirectories to include search path but require qualified include
Keep the include paths clean and separate. We use directories to group source
files together. That makes sense (I guess), but then we should use this
grouping also when including files. Thus require to #include files with their
path relative to "src/".

Also, we build various artifacts from the "src/" tree. Instead of having
individual CFLAGS for each artifact in Makefile.am, the CFLAGS should be
unified. Previously, the CFLAGS for each artifact differ and are inconsistent
in which paths they add to the search path. Fix the inconsistency by just
don't add the paths at all.
2016-11-21 14:26:37 +01:00
Thomas Haller
a65762ca33 build: rename "src/ppp-manager" to "src/ppp"
The ppp directory does not only contain the manager
instance, but various files related to ppp.

Rename.
2016-11-21 14:07:47 +01:00
Thomas Haller
3cd56809ed core: drop unused "nm-bt-enum-types.h"
In core, we should not use any generated enum-types. Especially
nm-bt-enum-types.h was unused already.
2016-11-18 16:40:25 +01:00
Thomas Haller
2afc1d7c43 wwan: don't use generated enum-type NM_TYPE_MODEM_STATE 2016-11-18 16:40:25 +01:00
Thomas Haller
ee601ff296 build: merge "src/devices/bluetooth/Makefile.am" into toplevel Makefile 2016-10-21 17:04:06 +02:00
Beniamino Galvani
92a8cfac69 core: introduce default logging macros 2016-10-14 15:57:43 +02:00
Thomas Haller
92f4185575 devices/build: use one linker-script-devices.ver for all device plugins 2016-10-13 21:36:06 +02:00
Thomas Haller
9f5b80d215 build: don't guard check-local with "if ENABLE_TESTS"
We should enable tests by default, probably we even should drop
the configure flags to enable tests and just always build them.

Anyway, at this point there is no use in guarding check-local
with a check for ENABLE_TESTS. A user who does't want to run
the tests, should just not call `make check`.
2016-10-13 21:33:33 +02:00
Thomas Haller
18660604aa device: make NMDeviceFactory a class instead of an interface
An interface would make sense to allow the actual device-factory to inherit
from another type.

However, glib interfaces make code much harder to follow and less
efficient. The device factory shall be a very simple type with meta data
about supported device types and the ability to create device instances.
There is no need to make this an interface implementation, instead just
let the factories inherit from NM_TYPE_DEVICE_FACTORY directly.
2016-10-11 11:45:14 +02:00
Thomas Haller
a63867a40b build: use NetworkManager logging domain for device and settings plugins
First of all, G_LOG_DOMAIN only matters when using g_log() directly.
Inside core, we always want to log via nm-logging. Every call to a
g_log() is a bug in the first place (like a failed assertion that logs
a g_critical() during g_return_if_fail()).

So, for all practic purposes, the logging domain is not used.

For nm-logging, the G_LOG_DOMAIN has no effect. Unless we find a proper
use of this domain, G_LOG_DOMAIN should not differ from what the rest of
core.
2016-10-06 20:41:20 +02:00
Thomas Haller
4d37f7a1e9 core: refactor private data in "src"
- use _NM_GET_PRIVATE() and _NM_GET_PRIVATE_PTR() everywhere.

- reorder statements, to have GObject related functions (init, dispose,
  constructed) at the bottom of each file and in a consistent order w.r.t.
  each other.

- unify whitespaces in signal and properties declarations.

- use NM_GOBJECT_PROPERTIES_DEFINE() and _notify()

- drop unused signal slots in class structures

- drop unused header files for device factories
2016-10-04 09:50:56 +02:00