summaryrefslogtreecommitdiff
path: root/src/nm-manager.h
Commit message (Collapse)AuthorAgeFilesLines
* bluetooth: refactor BlueZ handling and let NMBluezManager cache ↵Thomas Haller2019-09-231-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ObjectManager data This is a complete refactoring of the bluetooth code. Now that BlueZ 4 support was dropped, the separation of NMBluezManager and NMBluez5Manager makes no sense. They should be merged. At that point, notice that BlueZ 5's D-Bus API is fully centered around D-Bus's ObjectManager interface. Using that interface, we basically only call GetManagedObjects() once and register to InterfacesAdded, InterfacesRemoved and PropertiesChanged signals. There is no need to fetch individual properties ever. Note how NMBluezDevice used to query the D-Bus properties itself by creating a GDBusProxy. This is redundant, because when using the ObjectManager interfaces, we have all information already. Instead, let NMBluezManager basically become the client-side cache of all of BlueZ's ObjectManager interface. NMBluezDevice was mostly concerned about caching the D-Bus interface's state, tracking suitable profiles (pan_connection), and moderate between bluez and NMDeviceBt. These tasks don't get simpler by moving them to a seprate file. Let them also be handled by NMBluezManager. I mean, just look how it was previously: NMBluez5Manager registers to ObjectManager interface and sees a device appearing. It creates a NMBluezDevice object and registers to its "initialized" and "notify:usable" signal. In the meantime, NMBluezDevice fetches the relevant information from D-Bus (although it was already present in the data provided by the ObjectManager) and eventually emits these usable and initialized signals. Then, NMBlue5Manager emits a "bdaddr-added" signal, for which NMBluezManager creates the NMDeviceBt instance. NMBluezManager, NMBluez5Manager and NMBluezDevice are strongly cooperating to the point that it is simpler to merge them. This is not mere refactoring. This patch aims to make everything asynchronously and always cancellable. Also, it aims to fix races and inconsistencies of the state. - Registering to a NAP server now waits for the response and delays activation of the NMDeviceBridge accordingly. - For NAP connections we now watch the bnep0 interface in platform, and tear down the device when it goes away. Bluez doesn't send us a notification on D-Bus in that case. - Rework establishing a DUN connection. It no longer uses blocking connect() and does not block until rfcomm device appears. It's all async now. It also watches the rfcomm file descriptor for POLLERR/POLLHUP to notice disconnect. - drop nm_device_factory_emit_component_added() and instead let NMDeviceBt directly register to the WWan factory's "added" signal.
* core: add and use NM_MANAGER_GET macroThomas Haller2019-09-221-0/+1
| | | | | | | For our singleton getters we usually have such a macro. See NM_PLATFORM_GET and NM_SETTINGS_GET. Add such a macro for NMManager and use it.
* all: SPDX header conversionLubomir Rintel2019-09-101-14/+1
| | | | | $ find * -type f |xargs perl contrib/scripts/spdx.pl $ git rm contrib/scripts/spdx.pl
* libnm,core: Add ConnectivityCheckUri property and accessorsIain Lane2019-07-221-0/+1
| | | | | | | So that applications like GNOME Shell can hit the same URI to show the captive portal login page. https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/209
* all: drop emacs file variables from source filesThomas Haller2019-06-111-1/+0
| | | | | | | | | | | | | | | | | | | | | | We no longer add these. If you use Emacs, configure it yourself. Also, due to our "smart-tab" usage the editor anyway does a subpar job handling our tabs. However, on the upside every user can choose whatever tab-width he/she prefers. If "smart-tabs" are used properly (like we do), every tab-width will work. No manual changes, just ran commands: F=($(git grep -l -e '-\*-')) sed '1 { /\/\* *-\*- *[mM]ode.*\*\/$/d }' -i "${F[@]}" sed '1,4 { /^\(#\|--\|dnl\) *-\*- [mM]ode/d }' -i "${F[@]}" Check remaining lines with: git grep -e '-\*-' The ultimate purpose of this is to cleanup our files and eventually use SPDX license identifiers. For that, first get rid of the boilerplate lines.
* core: improve and fix keeping connection active based on ↵Thomas Haller2018-12-091-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | "connection.permissions" By setting "connection.permissions", a profile is restricted to a particular user. That means for example, that another user cannot see, modify, delete, activate or deactivate the profile. It also means, that the profile will only autoconnect when the user is logged in (has a session). Note that root is always able to activate the profile. Likewise, the user is also allowed to manually activate the own profile, even if no session currently exists (which can easily happen with `sudo`). When the user logs out (the session goes away), we want do disconnect the profile, however there are conflicting goals here: 1) if the profile was activate by root user, then logging out the user should not disconnect the profile. The patch fixes that by not binding the activation to the connection, if the activation is done by the root user. 2) if the profile was activated by the owner when it had no session, then it should stay alive until the user logs in (once) and logs out again. This is already handled by the previous commit. Yes, this point is odd. If you first do $ sudo -u $OTHER_USER nmcli connection up $PROFILE the profile activates despite not having a session. If you then $ ssh guest@localhost nmcli device you'll still see the profile active. However, the moment the SSH session ends, a session closes and the profile disconnects. It's unclear, how to solve that any better. I think, a user who cares about this, should not activate the profile without having a session in the first place. There are quite some special cases, in particular with internal activations. In those cases we need to decide whether to bind the activation to the profile's visibility. Also, expose the "bind" setting in the D-Bus API. Note, that in the future this flag may be modified via D-Bus API. Like we may also add related API that allows to tweak the lifetime of the activation. Also, I think we broke handling of connection visiblity with 37e8c53eeed "core: Introduce helper class to track connection keep alive". This should be fixed now too, with improved behavior. Fixes: 37e8c53eeed579fe34a68819cd12f3295d581394 https://bugzilla.redhat.com/show_bug.cgi?id=1530977
* core: add nm_manager_for_each_active_connection_safe() and ↵Thomas Haller2018-12-091-0/+26
| | | | | | | nm_manager_for_each_device_safe() Analog to c_list_for_each_safe(), which allows to delete the current instance while iterating. Note that modifying the list any other way is unsafe.
* device/shared: set ANDROID_METERED option 43 for shared connectionsThomas Haller2018-12-031-0/+2
| | | | | | | | | The problem is that updating the metered value of a shared connection is not implemented. The user needs to fully reactivate the profile for changes to take effect. That is unfortunate, especially because reapplying the route metric works in other other cases.
* core: extend nm_manager_get_activatable_connections() for autoconnect and ↵Thomas Haller2018-08-081-2/+3
| | | | | | | | | | | | | multi-connect In general, a activatable connection is one that is currently not active, or supports to be activatable multiple times according to multi-connect setting. In addition, during autoconnect, a profile which is marked as multi-connect=manual-multiple will not be avalable. Hence, add an argument "for_auto_activation". The code is mostly unused but will be used next (except for connections, which set connection.multi-connect=multiple).
* manager: rename nm_manager_write_device_state()Beniamino Galvani2018-08-021-1/+2
| | | | | | Rename nm_manager_write_device_state() to nm_manager_write_device_state_all(), and split out the code to write a single device state to a new function.
* all: remove consecutive empty linesBeniamino Galvani2018-04-301-1/+0
| | | | | | | Normalize coding style by removing consecutive empty lines from C sources and headers. https://github.com/NetworkManager/NetworkManager/pull/108
* shared: drop duplicate c-list.h headerBeniamino Galvani2018-04-181-1/+1
| | | | Use the one from the project just imported.
* core: specify an activation reason for active connectionsBeniamino Galvani2018-04-081-0/+1
| | | | | | Specify a reason when creating active connections. The reason will be used in the next commit to tell whether slaves must be reconnected or not if a master has autoconnect-slaves=yes.
* core: add macro for iterating CList of devices of NMManagerThomas Haller2018-04-041-1/+14
| | | | | | I find it slightly nicer and explict. Also, the list elements are strictly speaking private, we should better not explicitly use them outside of NMManager/NMDevice. The macro hides this.
* core: track devices in manager via embedded CListThomas Haller2018-03-271-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Instead of using a GSList for tracking the devices, use a CList. I think a CList is in most cases the more suitable data structure then GSList: - you can find out in O(1) whether the object is linked. That is nice, for example to assert in NMDevice's destructor that the object was unlinked, and we will use that later in nm_manager_get_device_by_path(). - you can unlink the element in O(1) and you can unlink the element without having access to the link's head - Contrary to GSList, this does not require an extra slice allocation for the link node. It quite possibliy consumes slightly less memory because the CList structure is embedded in a struct that we already allocate. Even if slice allocation would be perfect to only consume 2*sizeof(gpointer) for the link note, it would at most be as-good as CList. Quite possibly, there is an overhead though. - CList possibly has better memory locality, because the link structure and the data are close to each other. Something which could be seen as disavantage, is that with CList one device can only be tracked in one NMManager instance at a time. But that is fine. There exists only one NMManager instance for now, and even if we would ever introduce multiple managers, we probably would not associate one NMDevice instance with multiple managers. The advantages are arguably not huge, but CList is IMHO clearly the more suited data structure. No need to stick to a suboptimal data structure for the job. Refactor it.
* core/dbus: rework D-Bus implementation to use lower layer GDBusConnection APIThomas Haller2018-03-121-5/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously, we used the generated GDBusInterfaceSkeleton types and glued them via the NMExportedObject base class to our NM types. We also used GDBusObjectManagerServer. Don't do that anymore. The resulting code was more complicated despite (or because?) using generated classes. It was hard to understand, complex, had ordering-issues, and had a runtime and memory overhead. This patch refactors this entirely and uses the lower layer API GDBusConnection directly. It replaces the generated code, GDBusInterfaceSkeleton, and GDBusObjectManagerServer. All this is now done by NMDbusObject and NMDBusManager and static descriptor instances of type GDBusInterfaceInfo. This adds a net plus of more then 1300 lines of hand written code. I claim that this implementation is easier to understand. Note that previously we also required extensive and complex glue code to bind our objects to the generated skeleton objects. Instead, now glue our objects directly to GDBusConnection. The result is more immediate and gets rid of layers of code in between. Now that the D-Bus glue us more under our control, we can address issus and bottlenecks better, instead of adding code to bend the generated skeletons to our needs. Note that the current implementation now only supports one D-Bus connection. That was effectively the case already, although there were places (and still are) where the code pretends it could also support connections from a private socket. We dropped private socket support mainly because it was unused, untested and buggy, but also because GDBusObjectManagerServer could not export the same objects on multiple connections. Now, it would be rather straight forward to fix that and re-introduce ObjectManager on each private connection. But this commit doesn't do that yet, and the new code intentionally supports only one D-Bus connection. Also, the D-Bus startup was simplified. There is no retry, either nm_dbus_manager_start() succeeds, or it detects the initrd case. In the initrd case, bus manager never tries to connect to D-Bus. Since the initrd scenario is not yet used/tested, this is good enough for the moment. It could be easily extended later, for example with polling whether the system bus appears (like was done previously). Also, restart of D-Bus daemon isn't supported either -- just like before. Note how NMDBusManager now implements the ObjectManager D-Bus interface directly. Also, this fixes race issues in the server, by no longer delaying PropertiesChanged signals. NMExportedObject would collect changed properties and send the signal out in idle_emit_properties_changed() on idle. This messes up the ordering of change events w.r.t. other signals and events on the bus. Note that not only NMExportedObject messed up the ordering. Also the generated code would hook into notify() and process change events in and idle handle, exhibiting the same ordering issue too. No longer do that. PropertiesChanged signals will be sent right away by hooking into dispatch_properties_changed(). This means, changing a property in quick succession will no longer be combined and is guaranteed to emit signals for each individual state. Quite possibly we emit now more PropertiesChanged signals then before. However, we are now able to group a set of changes by using standard g_object_freeze_notify()/g_object_thaw_notify(). We probably should make more use of that. Also, now that our signals are all handled in the right order, we might find places where we still emit them in the wrong order. But that is then due to the order in which our GObjects emit signals, not due to an ill behavior of the D-Bus glue. Possibly we need to identify such ordering issues and fix them. Numbers (for contrib/rpm --without debug on x86_64): - the patch changes the code size of NetworkManager by - 2809360 bytes + 2537528 bytes (-9.7%) - Runtime measurements are harder because there is a large variance during testing. In other words, the numbers are not reproducible. Currently, the implementation performs no caching of GVariants at all, but it would be rather simple to add it, if that turns out to be useful. Anyway, without strong claim, it seems that the new form tends to perform slightly better. That would be no surprise. $ time (for i in {1..1000}; do nmcli >/dev/null || break; echo -n .; done) - real 1m39.355s + real 1m37.432s $ time (for i in {1..2000}; do busctl call org.freedesktop.NetworkManager /org/freedesktop org.freedesktop.DBus.ObjectManager GetManagedObjects > /dev/null || break; echo -n .; done) - real 0m26.843s + real 0m25.281s - Regarding RSS size, just looking at the processes in similar conditions, doesn't give a large difference. On my system they consume about 19MB RSS. It seems that the new version has a slightly smaller RSS size. - 19356 RSS + 18660 RSS
* core: persist aspired default route-metric in device's state fileThomas Haller2017-12-201-3/+0
| | | | | | | | | | | | | | | | NMManager tries to assign unique route-metrics in an increasing manner so that the device which activates first keeps to have the best routes. This information is also persisted in the device's state file, however we not only need to persist the effective route-metric which was eventually chosen by NMManager, but also the aspired metric. The reason is that when a metric is chosen for a device, the entire range between aspired and effective route-metric is reserved for that device. We must remember the entire range so that after restart the entire range is still considered to be in use. Fixes: 6a32c64d8fb2a9c1cfb78ab7e2f0bb3a269c81d7
* device: generate unique default route-metrics per interfaceThomas Haller2017-12-151-0/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In the past we had NMDefaultRouteManager which would coordinate adding the default-route with identical metrics. That especially happened, when activating two devices of the same type, without explicitly specifying ipv4.route-metric. For example, with ethernet devices, the routes on both interfaces would get a metric of 100. Coordinating routes was especially necessary, because we added routes with NLM_F_EXCL flag, akin to `ip route replace`. We not only had to avoid that activating two devices in NetworkManager would result in a fight over the default-route, but more importently to preserve externally added default-routes on unmanaged interfaces. NMDefaultRouteManager would ensure that in case of duplicate metrics, that the device that activated first would keep the best default-route. It would do so by bumping the metric of the second device to find a unused metric. The bumping itself was not very important -- MDefaultRouteManager could also just not configure any default-routes that show up as second, the result would be quite similar. More important was to keep the best default-route on the first activating device until the device deactivates or a device activates that really has a better default-route.. Likewise, NMRouteManager would globally manage non-default-routes. It would not do any bumping of metrics, but it would also ensure that the routes of the device that activates first are not overwritten by a device activating later. However, the `ip route replace` approach has downsides, especially that it messes with routes on other interfaces, interfaces that are possibly not managed by NetworkManager. Another downside is, that binding a socket to an interface might not result in correct routes, because the route might just not be there (in case of NMRouteManager, which wouldn't configure duplicate routes by bumping their metric). Since commit 77ec302714795f905301d500b9aab6c88001f32e we would no longer use NLM_F_EXCL, but add routes akin to `ip route append`. When activating for example two ethernet devices with no explict route metric configuration, there are two routes like default via 10.16.122.254 dev eth0 proto dhcp metric 100 default via 192.168.100.1 dev eth1 proto dhcp metric 100 This does not only affect default routes. In case of a multi-homing setup you'd get 192.168.100.0/24 dev eth0 proto kernel scope link src 192.168.100.1 metric 100 192.168.100.0/24 dev eth1 proto kernel scope link src 192.168.100.1 metric 100 but it's visible the most for default-routes. Note that we would append the routes that are activated later, as the order of `ip route show` confirms. One might hence expect, that kernel selects a route based on the order in the routing tables. However, that isn't the case, and activating the second interface will non-deterministically re-route traffic via the new interface. That will interfere badly with with NAT, stateful firewalls, and existing connections (like TCP). The solution is to have NMManager keep a global index of the default route-metrics currently in use. So, instead of determining the default-route metric based solely on the device-type, we now in addition generate default metrics that do not overlap. For example, if you activate eth0 first, it gets route-metric 100, and if you then activate eth1, it gets 101. Note that if you deactivate and re-activate eth0, then it will get route-metric 102, because the best route should stick on eth1 (which reserves the range 100 to 101). Note that when a connection explititly selects a particular metric, then that choice is honored (contrary to NMDefaultRouteManager which was more concerned with avoiding conflicts, then keeping the exact metric). https://bugzilla.redhat.com/show_bug.cgi?id=1505893
* core: track NMActiveConnection in manager with CListThomas Haller2017-11-271-1/+14
| | | | | | | | | | Using CList, we embed the list element in NMActiveConnection struct itself. That means for example, that you couldn't track a NMActiveConnection more then once. But we anyway never want that. The advantage is, that removing an active connection from the list is O(1), and we safe additional GSlice allocations for each node element.
* core: export checkpoint list over D-BusBeniamino Galvani2017-11-091-0/+1
|
* checkpoint: don't include unrealized devicesBeniamino Galvani2017-11-091-1/+0
| | | | | | | | Don't include unrealized devices in checkpoint because, as the name says, they are not real. While at it, remove nm_manager_get_device_paths() as it is no longer used.
* manager: add a method to get a particular device of given typeLubomir Rintel2017-10-301-1/+6
| | | | And also make the remove_device() method use it behind the scenes.
* manager: add connectivity-check-{available,enabled} properties.James Henstridge2017-08-171-0/+2
| | | | https://bugzilla.gnome.org/show_bug.cgi?id=785117
* core: implement activation of PPP devicesBeniamino Galvani2017-08-051-0/+2
| | | | | | | | | | | | Add code to NMPppDevice to activate new-style PPPoE connections. This is a bit tricky because we can't create the link as usual in create_and_realize(). Instead, we create a device without ifindex and start pppd in stage2; when pppd reports a new configuration, we rename the platform link to the correct name and set the ifindex into the device. This mechanism is inherently racy, but there is no way to tell pppd to create an arbitrary interface name.
* hostname: cache hostname-manager's hostname propertyThomas Haller2017-05-121-1/+0
| | | | | | | | | | | | | | | | A property preferably only emits a notify-changed signal when the value actually changes and it caches the value (so that between property-changed signals the value is guaranteed not to change). NMSettings and NMManager both already cache the hostname, because NMHostnameManager didn't guarantee this basic concept. Implement it and rely on it from NMSettings and NMPolicy. And remove the copy of the property from NMManager. Move the call for nm_dispatcher_call_hostname() from NMHostnameManager to NMManager. Note that NMPolicy also has a call to the dispatcher when set-transient-hostname returns. This should be cleaned up later.
* core: add activation-type property to active-connectionThomas Haller2017-03-161-0/+1
| | | | | It is still unused, but will be useful to mark a connection whether it is a full activation or assumed.
* core: refactor nm_manager_get_activatable_connections() to return an arrayThomas Haller2017-02-101-1/+4
| | | | ... instead of a GSList.
* manager: avoid an extra path to ac translationLubomir Rintel2017-01-271-1/+1
| | | | | The ac might already be unexported which would lead to a crash. In any case, it's just unnecessary.
* ifcfg-rh: write the master device name even if the master property is an UUIDlr/ifcfg-device-rh1369008Lubomir Rintel2016-12-151-0/+3
| | | | | | | | | | | | | | We used MASTER, BRIDGE and TEAM_MASTER keys for a differnet purpose than the network.service did, confusing the legacy tooling. Let's do our best to write compatible configuration files: * Add *_UUID properties that won't clash with initscripts * Ignore non-*_UUID keys on read if *_UUID is present * If the connection.master is an UUID of a connection with a connection.interface-name, write the uuid into the *_UUID key while setting the non-*_UUID key to the interface name for compatibility https://bugzilla.redhat.com/show_bug.cgi?id=1369091
* build: don't add subdirectories to include search path but require qualified ↵Thomas Haller2016-11-211-1/+1
| | | | | | | | | | | | | | | 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.
* core: allow passing an applied connection to nm_act_request_new()Beniamino Galvani2016-09-261-0/+1
| | | | | This is useful for the checkpoint/restore functionality to revert both the applied and the settings connections.
* manager: add nm_manager_get_device_paths()Beniamino Galvani2016-09-261-0/+1
|
* config: store and load device runtime state to fileThomas Haller2016-09-261-0/+2
| | | | | | | | | The data is still unused, the actual fields might change. Note that the actual state we store is subject to change, according to which data we need. The file format is non stable, as the files don't survive reboot. So there is no backward compatibility to maintain and the format can be changed later.
* core: use binary-search for nm_manager_set_capability()Thomas Haller2016-09-231-1/+0
| | | | | | | And drop the unused function nm_manager_check_capability(). I don't think we need such a function server-side, as the server usually has better ways to check whether a capability is supported.
* manager: Add "Capabilities" propertyMarius Vollmer2016-09-231-0/+3
|
* checkpoint: add create, rollback and destroy D-Bus APIBeniamino Galvani2016-08-171-0/+2
| | | | Co-authored-by: Thomas Haller <thaller@redhat.com>
* manager: make NMManager's structs privateThomas Haller2016-04-281-8/+0
| | | | | They are only useful when we want to derive a class from NM_TYPE_MANAGER -- which we clearly don't.
* manager: remove unused signal slots from NMManagerClassThomas Haller2016-04-281-5/+0
|
* config: let NMConfig handle "NetworkManager.state" file (bgo#764474)Thomas Haller2016-04-071-5/+1
| | | | | | | | | | | | | Move reading and writing of the state file to NMConfig ("/var/lib/NetworkManager/NetworkManager.state" file). Originally, I intended to persist more state, thus it made sense to cleanup handling of the state file and move it all at one place. Now, it's not clear that will happen anytime soon. Still, the change is a worthy cleanup, so do it anyway. https://bugzilla.gnome.org/show_bug.cgi?id=764474
* manager: use defines for signal namesThomas Haller2016-04-041-1/+9
|
* manager: export nm_manager_get_connection_iface()Lubomir Rintel2016-02-171-0/+6
| | | | | We'll need the actual device name that should be used for a connection activated on a given device when checking the connection availability.
* manager: refactor construction of manager singleton instanceThomas Haller2016-01-181-0/+1
| | | | | nm_manager_setup() should only call g_object_new() and leave most of the initialization to the GObject constructor.
* core: use define for NMManager's "state-changed" signal nameThomas Haller2015-12-071-0/+1
|
* api/manager: add GetAllDevices() method and AllDevices propertyDan Williams2015-12-041-0/+1
| | | | Returns both realized and un-realized devices.
* manager: export DNS global configuration D-Bus propertyBeniamino Galvani2015-10-011-0/+1
|
* core: separate active and applied connectionLubomir Rintel2015-09-181-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Clone the connection upon activation. This makes it safe for the user to modify the original connection while it is activated. This involves several changes: - NMActiveConnection gets @settings_connection and @applied_connection. To support add-and-activate, we constructing a NMActiveConnection with no connection set. Previously, we would set the "connection" field to a temporary NMConnection. Now NMManager piggybacks this temporary connection as object-data (TAG_ACTIVE_CONNETION_ADD_AND_ACTIVATE). - get rid of the functions nm_active_connection_get_connection_type() and nm_active_connection_get_connection_uuid(). From their names it is unclear whether this returns the settings or applied connection. The (few) callers should figure that out themselves. - rename nm_active_connection_get_id() to nm_active_connection_get_settings_connection_id(). This function is only used internally for logging. - dispatcher calls now get two connections as well. The applied-connection is used for the connection data, while the settings-connection is used for the connection path. - needs special handling for properties that apply immediately when changed (nm_device_reapply_settings_immediately()). Co-Authored-By: Thomas Haller <thaller@redhat.com> https://bugzilla.gnome.org/show_bug.cgi?id=724041
* manager: remove WiMAX rfkill flag from NMMangerThomas Haller2015-08-131-2/+1
| | | | | | WiMAX support was dropped in commit 721e917cb6c3f6bea7e856aaed0cd49626887db1. Also, remove support for the WiMAX rfkill flag and only preserve the D-Bus property for backward compatibility.
* core: make NMManager singleton more like othersDan Winship2015-08-101-4/+4
| | | | | | | | | Rename nm_manager_new() to nm_manager_setup(), and change the local @singleton variable to @singleton_instance. (Also, add a local @self variable inside nm_manager_setup().) Also, make NMManager own NMSettings rather than having them both owned by main().
* core: fix NMManager in private-bus-only caseDan Winship2015-08-101-2/+1
| | | | | | | | | | | NMManager was failing to initialize if there was only a private bus, despite the fact that this is exactly the use case that the private bus was added for. The only other potentially-failing code in nm_manager_new() was adding prop_filter to the D-Bus connection, but this can't really fail, so just assert that it doesn't. And now, nm_manager_new() always succeeds, so update the caller for that.
* core: add an NMExportedObject base classDan Winship2015-07-241-5/+3
| | | | | | | | | | | | | | | Add NMExportedObject, make it the base class of all D-Bus-exported types, and move the nm-properties-changed-signal logic into it. (Also, make NMSettings use the same properties-changed code as everything else, which it was not previously doing, presumably for historical reasons). (This is mostly just shuffling code around at this point, but NMExportedObject will be more important in the gdbus port, since gdbus-codegen doesn't do a very good job of supporting objects that export multiple interfaces [as each NMDevice subclass does, for example], so we will need more glue/helper code in NMExportedObject then.)
View Lorry Controller Status