summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
* dhcp: switch IPv4 "internal" DHCP client to use "nettools" backend instead ↵th/nettools-n-dhcp4-as-internal-pluginThomas Haller2019-11-011-1/+1
| | | | | | | | | | | | | | | | | | | | | of "systemd" Previously, our "internal" DHCPv4 client is based on a fork of systemd code. This manner of maintaining the fork is problematic. The solution is to use a proper library: n-dhcp4 from the nettools project. We already have these two as undocumented plugins available, by setting either "dhcp=systemd" or "dhcp=nettools". This is only for testing. Users are only supposed to use the "internal" plugin. Up until now, the "internal" DHCPv4 plugin was based on "systemd" code. Change that to use "nettools" instead. Possibly this breaks something, and we need to fix it. But do this early so we have time to test the nettools plugin and identify issues. For the user, this change should be entirely transparant.
* build: add PPPD_PATH to config.h.mesonworldofpeace2019-11-011-0/+3
| | | | | | | | | | Without this using -Dpppd= was completely broken. First observed in NixOS [0] [0]: https://github.com/NixOS/nixpkgs/issues/72330 https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/323
* po/de: fix quotingLubomir Rintel2019-10-311-1/+1
|
* clients/cli: give some hints to the translatorsLubomir Rintel2019-10-301-0/+4
|
* po: merge branch with translation fixes for GermanThomas Haller2019-10-301-7/+8
|\ | | | | | | https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/320
| * fix translationmaxbachmann2019-10-301-1/+2
| |
| * po/de: fix some spelling mistakesmaxbachmann2019-10-301-6/+6
|/ | | | https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/320
* merge: branch 'lr/hotspot-reuse'Lubomir Rintel2019-10-301-102/+179
|\ | | | | | | https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/305
| * devices: reuse the hotspot connection if we find appropriate onelr/hotspot-reuseLubomir Rintel2019-10-301-75/+140
| | | | | | | | | | | | | | Otherwise repeated "nmcli d wifi hotspot" commands create multiple Hostpot connections, which is just sad. We do already reuse existing connections with "nmcli d wifi connect" -- let's just do a similar thing here.
| * cli: split off the update or add-and-activate logicLubomir Rintel2019-10-301-27/+39
|/
* libnm: merge branch 'th/libnm-various-fixes'Thomas Haller2019-10-2732-72/+137
|\ | | | | | | https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/319
| * libnm: add and use _nml_coerce_property_*()Thomas Haller2019-10-2724-43/+74
| | | | | | | | | | | | | | | | | | | | | | Our NMObject implementations should behave in a similar manner. For example, string properties should be coerced the a consistent manner. Add functions _nml_coerce_property_*() for that. Of course, they are trivial. Their value is not that they encapsulate some complex implementation, but that they convey a general concept of how we want to handle certain properties in NMClient's object cache.
| * libnm: add NM_CLIENT_CHECKPOINTS defineThomas Haller2019-10-272-1/+2
| |
| * libnm: don't emit g_warning() from nm_utils_ip6_dns_from_variant()Thomas Haller2019-10-271-8/+5
| | | | | | | | | | | | | | | | The library should not print to stdout/stderr. This function is used to convert untrusted(!!) input to a normalized and sanitized strv array. g_warning() is essentially an assertion, and it's wrong to do that for untrusted data. If the caller had to pre-validate the array, then having this function would be pointless.
| * libnm: add comment about not-implement property NMDeviceVxlan:carrierThomas Haller2019-10-271-3/+6
| | | | | | | | | | The server does not expose this property on D-Bus. It's always FALSE. Add a comment about that.
| * libnm: add comment about not-implement property NMDeviceMacvlan:hw-addressThomas Haller2019-10-271-4/+5
| | | | | | | | | | The server does not expose this property on D-Bus. It's always NULL. Add a comment about that.
| * libnm: change default value for ↵Thomas Haller2019-10-271-2/+2
| | | | | | | | NMClient:{networking,wireless-hardware}-enabled properties
| * libnm: change default value for NMClient:dns-{mode,rc-manager} propertiesThomas Haller2019-10-271-2/+2
| |
| * libnm: change default value for NMDevice:mtu propertyThomas Haller2019-10-271-1/+1
| | | | | | | | | | | | | | | | Default values should preferably be zero and/or a value that indicates that the property is unknown/unset. In practice, this property is not unset because it's present on the D-Bus API.
| * libnm: change default value for NMDevice:autoconnect propertyThomas Haller2019-10-271-1/+1
| | | | | | | | | | | | | | | | | | Yes, by default (server side) devices do autoconnect. But that does not mean an NMObject, that has its GObject property not set via D-Bus shall default to TRUE. Default values preferably should be FALSE, because that is what we get by default (memset(0)).
| * libnm: change default value for NMAccessPoint:mode propertyThomas Haller2019-10-271-1/+1
| | | | | | | | | | | | | | NMAccessPoint is an NMObject, and exclusively created and initialized by NMClient. In practice, the D-Bus property is always present on D-Bus, so the default value is not used. However, a better default is anyway "unknown", also because that has zero numeric value.
| * shared: add NM_IS_REF_STRING() helperThomas Haller2019-10-271-0/+19
| |
| * shared: add @deep_copied argument to nm_utils_strv_dup()Thomas Haller2019-10-274-6/+19
|/
* contrib: fix detection of whether being sourced in NM-log scriptThomas Haller2019-10-261-1/+1
|
* core: merge branch 'bg/prefix-route'Beniamino Galvani2019-10-246-11/+58
|\ | | | | | | | | https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/312 https://bugzilla.redhat.com/show_bug.cgi?id=1700415
| * core: don't add prefix route for /32 addresses without peerbg/prefix-routeBeniamino Galvani2019-10-231-0/+7
| | | | | | | | Kernel doesn't do it either, see function fib_add_ifaddr().
| * core: don't add prefix route for external addressesBeniamino Galvani2019-10-232-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If the user adds an address manually, kernel automatically adds a prefix route for it unless the address has the NOPREFIXROUTE flag. When ip_config_merge_and_apply() gets called, NM also adds its prefix route and so we end up with two routes that differ only for the metric. This is a problem because the route added by NM is not removed if the user removes the previously added address. Also, it seems confusing to have multiple instances of the same routes. This commit skips the addition of a prefix route for addresses added manually outside of NetworkManager.
| * core: track whether IP addresses are externalBeniamino Galvani2019-10-236-11/+46
|/ | | | | | Track whether IP addresses were added by NM or externally. In this way it becomes possible in a later commit to add prefix route only for addresses added by NM.
* device: allow reapply when the device is activatingBeniamino Galvani2019-10-234-30/+48
| | | | | | | | | Allow a reapply of the connection when the device is still activating and ensure that each reapply action is performed only at a given activation stage. For example, the IP configuration is not reactivated if the device is in the prepare stage. https://bugzilla.redhat.com/show_bug.cgi?id=1763062
* libnm: retire deprecated WiMAX NMObject typesThomas Haller2019-10-2310-759/+51
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | WiMAX is deprecated since NetworkManager 1.2.0. Note that also NetworkManager on server side no longer supports this type, hence the server's D-Bus API will never expose devices of this type. Note that NMDeviceWimax and NMWimaxNsp are NMObject types. That means, they are instantiated by NMClient to represent information on the D-Bus interface. As NetworkManager no longer exposes WiMAX devices, such devices are never created. Note that it makes no sense that a user would directly instantiate NMObject types, because they only work together with NMClient. Don't drop the related symbols and definitions from libnm, so that there is no API/ABI change (as far as building and linking is concerned). But make the types defunctional (which of course is a behavioral API change). Calling the API now triggers a g_return_*() warning. Also belatedly mark the WimaxNsp API as deprecated. It should have been done in 1.2. Note that here we deprecate the API and retire it at the same time. Optimally, we would have deprecated it a few releases ago, before retiring it. However, marking something for deprecation is anyway no excuse for anything. I mean, removing or retiring API is usually painful, regardless whether it was marked for deprecation or not. In this case, there is no possibility that a libnm user gets hold on a NMDeviceWimax or NMWimaxNsp instance, because NMClient simply no longer instantiates them. Hence, this change should not affect any user in practice. https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/316
* device/wwan: merge branch 'afaure/protect-self-variable'Thomas Haller2019-10-231-3/+13
|\ | | | | | | https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/303
| * device/wwan: fix leak of "error" variable in connect_ready()Thomas Haller2019-10-231-3/+6
| | | | | | | | Fixes: 105ee6e5a9aa ('device: fix crash by handling connection cancellation')
| * device: fix crash by handling connection cancellationAntoine Faure2019-10-231-3/+10
|/
* dhcp: truncate client-id for n-dhcp4 client at arbitrary limitThomas Haller2019-10-231-1/+3
| | | | | | | | | | | | | | | | | | | | RFC does not define how long the client ID can be. However, n-dhcp4 enforces that the server replies with a client ID that matches the request. Also, the client ID gets encoded as a DHCP option, hence it cannot be longer than 255 bytes. While n-dhcp4 doesn't enforce a certain length, a too long client ID is not going to work. Hence, truncate it at 133 bytes. This is the same limit that also systemd's DHCP client has. It's chosen to fit an RFC4361-complient client ID with a DUID of length MAX_DUID_LEN (which is 128 bytes according to RFC 3315 section 9.1). Fixes-test: @ipv4_set_very_long_dhcp_client_id See-also: https://github.com/nettools/n-dhcp4/pull/6 https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/307
* po/da: merge branch 'scootergrisen:patch-2' (#313)Thomas Haller2019-10-231-251/+345
|\ | | | | | | https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/313
| * Fix missing \nscootergrisen2019-10-231-1/+1
| |
| * Update da.poscootergrisen2019-10-231-251/+345
|/
* libnm: merge branch 'th/libnm-hide-gobject-structs'Thomas Haller2019-10-2287-888/+1027
|\ | | | | | | https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/314
| * libnm: hide GObject structs from public API and embed private dataThomas Haller2019-10-2285-852/+1010
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | These types are all subclasses of NMObject. These instances are commonly created by NMClient itself. It makes no sense that a user would instantiate the type. Much less does it make sense to subclass them. Hide the object and class structures from public API. This is an API and ABI break, but of something that is very likely unused. This is mainly done to embed the private structure in the object itself. This has benefits for performance and debugability. But most importantly, we can obtain a static offset where to access the private data. That means, we can use the information to access the data pointer generically, as we will need later. This is not done for the internal types NMManager, NMRemoteSettings, and NMDnsManager. These types will be dropped later.
| * libnm: hide NMClient struct from public headers and use direct private fieldThomas Haller2019-10-212-36/+17
|/ | | | | | | | | | | | | | | | | | | | | | | | | | Having the NMClient/NMClientClass structs in the public header allows the user to subclass these types. Subclassing this type was never intended, nor is it supported, nor does it seem useful. Subclassing only makes sense if the type has suitable hooks to extend the type in a meaningful way. NMClient hasn't, and everybody trying to derive from this class would better delegate the actions. Also, having these structs in the public header prevents us from embedding the private data in the object structure itself. It has thus an runtime overhead and is less convenient for debugging (it's hard to find the private data pointer in gdb). Most importantly, there is no easy way to find the offset of the private data fields, short of calling NM_CLIENT_GET_PRIVATE() -- which currently is a macro. Later we want to generically lookup the offset of the private data, we would need NM_CLIENT_GET_PRIVATE() as a function. Instead, by having an internally, statically known offset, we can use that offset instead. Also drop all signal hooks. They are also not useful. This is an ABI and API change, but of something that we never wanted to be part of the ABI/API, and which hopefull nobody is using.
* libnm: merge branch 'th/libnm-no-dbus-codegen-2'Thomas Haller2019-10-1854-2588/+2801
|\ | | | | | | https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/309
| * libnm: include "nm-types.h" in "nm-libnm-utils.h"Thomas Haller2019-10-181-0/+4
| | | | | | | | | | | | We now include "libnm/nm-libnm-utils.h" for all compilation of libnm sources. Let that one also include "nm-types.h". In the end, it's anyway needed almost everywhere.
| * libnm: include "nm-libnm-utils.h" by default in libnm sourcesThomas Haller2019-10-186-5/+4
| | | | | | | | | | | | | | The majority of sources in "libnm/" are implementations of NMObject. "nm-libnm-utils.h" will contain common definitions for handling such objects. This means, most of the source files under libnm will require this include. Include it by default.
| * libnm: move wincaps_to_dash() function to "nm-libnm-utils.h"Thomas Haller2019-10-183-23/+30
| | | | | | | | We will need it, if only for testing/asserting.
| * libnm: don't use GSimpleAsyncResult for nm_client_new_async()Thomas Haller2019-10-181-30/+15
| | | | | | | | | | | | As we don't have any data or our own, we don't need a GSimpleAsyncResult/GTask. Just pass the caller's @callback to g_async_initable_new_async().
| * libnm: add logging NML_DBUS_LOG*() for debugging D-Bus for NMClientThomas Haller2019-10-182-0/+171
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commonly, a library (like libnm) is not supposed to log anything. Logging is not a suitable way to notify the calling application about anything. When something of importance happens, then the application must be notified via the library's API. However, logging can be very useful for debugging to see what is going on. Add a logging macro that by default does nothing, but can be turned on via an environment variable "LIBNM_CLIENT_DEBUG=debug". Another point is that libnm relies on the server side NetworkManager D-Bus interface to be in an expected manner. For example, we require a D-Bus object "org.freedesktop.NetworkManager" to be present and certain D-Bus interfaces implemented. However libnm should treat NetworkManager as external and untrusted component. That means, we cannot assert against the expectations we have. There are two reasons for this: - a bug in NetworkManager, dbus-daemon or else may cause such errors. This must not trigger an assertion failure in the client application, at least not unless requested. - libnm must be forward and backward compatible against a different NetworkManager server version. That is only possibly by ignoring anything that is unexpected. Asserting by default might prevent to implement API changes, both on libnm and server side. Note that we also don't notify the calling application via dedicated API. On the one hand, these things *can* happen. On the other hand, what would the calling appication do about it anyway? libnm by default must just behave gracefully and pretend all is good. For testing, development and debugging that is however not useful. We want the user to opt in to strict API validation. The user will be able to do that by setting "LIBNM_CLIENT_DEBUG=warning", which causes API violations being logged with g_warning(). These are assertions when running with G_DEBUG=fatal-warnings. This is inspired by GDBus' G_DBUS_DEBUG variable. Note that LIBNM_CLIENT_DEBUG environment variables is undocumented, unstable API. It's used for debugging and testing of the current libnm version at hand. There is no guaranteed stable behavior how a different libnm version might behave.
| * libnm: add NM_CLIENT_DBUS_NAME_OWNER propertyThomas Haller2019-10-183-1/+39
| | | | | | | | | | | | | | | | It's not yet implemented. But obviously it's interesting to get the name owner to which the NMClient is currently connected. Note only that: the name-owner property really says whether NM is currently running or not.
| * libnm: add NM_CLIENT_DBUS_CONNECTION propertyThomas Haller2019-10-183-27/+97
| | | | | | | | | | | | The used GDBusConnection should be configurable when creating the NMClient instance. Automatically choosing one of the g_bus_get() singletons is fine by default, but it's an unnecessary limitation.
| * libnm: remember the caller's GMainContext when creating NMClientThomas Haller2019-10-181-5/+17
| | | | | | | | | | | | | | | | We will require this later. The NMClient shall be tied to the GMainContext at the moment when the instance gets created. This allows the user to have multiple, indendent NMClient instances (on different threads and GMainContext). Currently this is still unused, it will be later.
| * libnm/trivial: move code in "nm-client.c"Thomas Haller2019-10-181-238/+252
| |
View Lorry Controller Status