summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
* dhcp: abort DHCP on devices without MAC address earlyth/dhcp-error-reasonThomas Haller2018-09-111-0/+17
| | | | | | | | | | Internal DHCPv4 client requires a valid MAC address for functioning. Just always require a MAC address to start DHCP, both v4 and v6. We have no MAC address for example on Layer3 devices like tun or wireguard. Also, if we try to start sd_dhcp_client without setting a MAC address, previously we would have triggered an assertion.
* systemd/dhcp: fix assertion starting DHCP client without MAC addressThomas Haller2018-09-111-2/+0
| | | | | | | | | | | | | | | | | | | | | An assertion in dhcp_network_bind_raw_socket() is triggered when starting an sd_dhcp_client without setting setting a MAC address first. - sd_dhcp_client_start() - client_start() - client_start_delayed() - dhcp_network_bind_raw_socket() In that case, the arp-type and MAC address is still unset. Note that dhcp_network_bind_raw_socket() already checks for a valid arp-type and MAC address below, so we should just gracefully return -EINVAL. Maybe sd_dhcp_client_start() should fail earlier when starting without MAC address. But the failure here will be correctly propagated and the start aborted. See-also: https://github.com/systemd/systemd/pull/####10054
* dhcp: return error reason from DHCP client startThomas Haller2018-09-1010-214/+319
|
* shared: add nm_errno() and nm_utils_error_set_errno() helperThomas Haller2018-09-102-5/+29
|
* dhcp: fix leak in dhclient's dhclient_start()Thomas Haller2018-09-101-2/+6
| | | | Fixes: 5d6d5cd136e36ed2815b7c719ada32bc6d22b481
* device: mark wireguard devices as unmanagedThomas Haller2018-09-101-1/+5
| | | | | | | | | Later we want to fully support wireguard devices. Also, possibly activating a generic profile in a wireguard device would make sense. Anyway, for the moment, just prevent that from happening by explicitly marking the device as unmanaged.
* device: rename NM_UNMANAGED_LOOPBACK to NM_UNMANAGED_BY_TYPEThomas Haller2018-09-102-6/+6
| | | | It is generally useful, not only for loopback. Rename.
* device: detect loopback device explicitlyThomas Haller2018-09-101-2/+11
| | | | Don't use NM_UNMANAGED_LOOPBACK for that.
* device: make device incompatible with profiles by defaultThomas Haller2018-09-101-0/+8
| | | | | | | | | Currently, NMDeviceWireguard does neither set connection_type_check_compatible nor implement check_connection_compatible. That means, it appears to be compatible with every connection profile, which is obviously wrong. Allow devices not to implement check_connection_compatible() and avoid the issue by rejecting profiles by default.
* release: bump version to 1.15.0 (development)1.15.0-devThomas Haller2018-09-084-3/+18
|
* release: bump version to 1.13.90 (1.14-rc1)1.14-rc1Thomas Haller2018-09-082-2/+2
|
* wifi/iwd: merge branch 'balrog-kun/iwd-fixes' (part 2)Thomas Haller2018-09-081-30/+96
|\ | | | | | | https://github.com/NetworkManager/NetworkManager/pull/194
| * wifi/iwd: use the new 'Station' DBus interfaceAndrew Zaborowski2018-09-081-30/+96
|/ | | | | | | | | The following commit between IWD 0.7 and 0.8 splits the previous Device interface into two interfaces with no functional changes: https://git.kernel.org/pub/scm/network/wireless/iwd.git/commit/doc?id=0453308134a3aadb6a2ec6a78ea642e19427704c Try using this new API but fall back to the old one if the State property is found still on the Device interface.
* shared: change nm_utils_strbuf_seek_end() handling truncated stringsThomas Haller2018-09-072-63/+57
| | | | | | | | | | Ok, I changed my mind. The new behavior seems to make more sense to me. Not that it matters, because we always use nm_utils_strbuf*() API with buffers that we expect to be large enough to contain the result. And when truncation occurs, we usually don't care much about it. That is, there is no code that uses nm_utils_strbuf*() API and handles string truncation in particular.
* wifi/iwd: merge branch 'balrog-kun/iwd-fixes' (partial)Thomas Haller2018-09-073-23/+35
|\ | | | | | | https://github.com/NetworkManager/NetworkManager/pull/194
| * wifi/iwd: add new DBus interface name definesAndrew Zaborowski2018-09-071-0/+3
| | | | | | | | New IWD DBus interfaces added before 0.4 and before 0.8
| * wifi/iwd: use NM_IN_STRSET for stringsAndrew Zaborowski2018-09-071-1/+1
| | | | | | | | | | | | | | NM_IN_SET will only compare string pointers and isn't useful for checking if nm_setting_wireless_get_mode (s_wifi) is infrastructure. Fixes: 570e1fa75b3369eb324afceb32d15f2ba2051df7
| * wifi/iwd: fix leaking agent DBus objectsAndrew Zaborowski2018-09-071-22/+31
|/ | | | | | | | | | | | | | Make sure we free our IWD agent objects whenever we're freeing the IWD Object Manager. We're registering those objects on the same DBus connection as the Object Manager so that they're visible to IWD, and our only reference to that connection is through priv->object_manager so even though the connection isn't changing when we free the object manager and create a new one, we still need to free the agent object. We could maybe keep a reference to the connection, but I'm not sure there's any warranty that it doesn't get closed. We could also use nm_dbus_manager_get_connection (nm_dbus_manager_get ()) and only register and free the agent once, since it happens to be the same connection but it'd perhaps be a hack to rely on this.
* release: update NEWSThomas Haller2018-09-071-0/+10
|
* libnm/docs: clarify which interface to share with ipvx.method=sharedThomas Haller2018-09-072-3/+5
|
* platform: merge branch 'th/platform-wireguard'Thomas Haller2018-09-0716-791/+1086
|\ | | | | | | | | | | Various cleanups. Also fixes a crash. https://github.com/NetworkManager/NetworkManager/pull/193
| * platform/wireguard: rework parsing wireguard links in platformThomas Haller2018-09-077-367/+555
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | - previously, parsing wireguard genl data resulted in memory corruption: - _wireguard_update_from_allowedips_nla() takes pointers to allowedip = &g_array_index (buf->allowedips, NMWireGuardAllowedIP, buf->allowedips->len - 1); but resizing the GArray will invalidate this pointer. This happens when there are multiple allowed-ips to parse. - there was some confusion who owned the allowedips pointers. _wireguard_peers_cpy() and _vt_cmd_obj_dispose_lnk_wireguard() assumed each peer owned their own chunk, but _wireguard_get_link_properties() would not duplicate the memory properly. - rework memory handling for allowed_ips. Now, the NMPObjectLnkWireGuard keeps a pointer _allowed_ips_buf. This buffer contains the instances for all peers. The parsing of the netlink message is the complicated part, because we don't know upfront how many peers/allowed-ips we receive. During construction, the tracking of peers/allowed-ips is complicated, via a CList/GArray. At the end of that, we prettify the data representation and put everything into two buffers. That is more efficient and simpler for user afterwards. This moves complexity to the way how the object is created, vs. how it is used later. - ensure that we nm_explicit_bzero() private-key and preshared-key. However, that only works to a certain point, because our netlink library does not ensure that no data is leaked. - don't use a "struct sockaddr" union for the peer's endpoint. Instead, use a combintation of endpoint_family, endpoint_port, and endpoint_addr. - a lot of refactoring.
| * platform/trivial: rename local variables for nla_policy/nlattrThomas Haller2018-09-071-37/+37
| | | | | | | | | | We have such variables with similar purpose at various places. Name them all the same.
| * platform: fix resusing ext-data from cache in _new_from_nl_link()Thomas Haller2018-09-071-0/+1
| |
| * platform/trivial: move code in nm-linux-platform.c aroundThomas Haller2018-09-071-213/+209
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Move NMLinuxPlatformPrivate earlier. In the past, I moved the declaration of NMLinuxPlatformPrivate after utility functions which are independent from platform instance. However, parsing netlink messages actually requires NMLinuxPlatformPrivate, because we want to access the "genl" socket. So, move the types to the beginning of the file, like we do for most other source files.
| * platform: let _lookup_cached_link() also return cached links that are not in ↵Thomas Haller2018-09-071-7/+11
| | | | | | | | | | | | | | | | | | | | | | netlink The _lookup_cached_link() function, should not skip over links which are currently in the cache, but not in netlink. Instead, let the callers skip them, as they see fit. No change in behavior, because the few callers now explicitly check for this.
| * platform: cleanup error pathsThomas Haller2018-09-073-179/+127
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | - drop "goto error_label" in favor of returning right away. At most places, there was no need to do any cleanup or the cleanup is handled via nm_auto(). - adjust the return types of wireguard functions to return a boolean success/failure, instead of some error code which we didn't use. - the change to _wireguard_get_link_properties() is intentional. This was wrong previously, because in _wireguard_get_link_properties() obj is always a newly created instance, and never has a genl family ID set. This will be improved later.
| * platform/netlink: assert that callbacks don't return positive error codeThomas Haller2018-09-071-2/+8
| |
| * platform/netlink: drop ref-counting for "struct nl_msg"Thomas Haller2018-09-071-11/+2
| | | | | | | | It was unused.
| * platform/trivial: reorder codeThomas Haller2018-09-071-30/+36
| |
| * platform/netlink: drop nlmsg_alloc_inherit() functionThomas Haller2018-09-072-28/+7
| | | | | | | | | | | | | | It's only used internally, and it seems not very useful to have. As it is confusing to have multiple functions for doing something similar, drop it -- since it's not really used. I also cannot imagine a good use-case for it.
| * platform: fix printing all-info about NMPObjectLink instancesThomas Haller2018-09-071-17/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When we print info about the link, we also want to print info about the referenced lnk instance, which commonly contains link-specific data. For NMP_OBJECT_TO_STRING_PUBLIC this was done correctly, by calling to-string of public fields on the lnk object. For NMP_OBJECT_TO_STRING_ALL, we wrongly just delegated to the public to-string function, this means, for the lnk object we would not print all fields. Fix that.
| * shared: add nm_utils_strbuf_seek_end() helperThomas Haller2018-09-073-2/+126
| |
| * shared: add nm_utils_mem_all_zero()Thomas Haller2018-09-071-0/+16
| |
| * all: avoid g_memdup()Thomas Haller2018-09-075-10/+11
| | | | | | | | | | | | | | By using nm_memdup(). Except in shared/nm-utils/nm-compat.c, which may not include "shared/nm-utils/nm-shared-utils.h".
| * shared: add nm_memdup() as replacement for g_memdup()Thomas Haller2018-09-071-0/+31
| | | | | | | | | | | | I think g_memdup() is dangerous for integer overflow. There is no need for accepting this danger, just use our own nm_memdup() which does not have this flaw.
| * platform/netlink: fix nl_errno() to get absolute error number valueThomas Haller2018-09-071-1/+1
|/
* core: fix wireless bitrate property name on D-BusBeniamino Galvani2018-09-071-1/+1
| | | | | | | | | | | | In commit 297d4985abcc ("core/dbus: rework D-Bus implementation to use lower layer GDBusConnection API") the Device.Wireless 'Bitrate' property on D-Bus was accidentally changed to 'BitRate'. Revert the old name. Reported-by: Joseph Conley <joseph.j.conley@gmail.com> Fixes: 297d4985abcc7b571b8c090ee90622357fc60e16 https://mail.gnome.org/archives/networkmanager-list/2018-September/msg00004.html
* platform/trivial: add FIXME comment to use new ethtool API to set link settingsThomas Haller2018-09-061-0/+4
|
* merge: branch 'bg/llmnr'Beniamino Galvani2018-09-0623-720/+1065
|\ | | | | | | | | https://gitlab.freedesktop.org/NetworkManager/NetworkManager/issues/13 https://github.com/NetworkManager/NetworkManager/pull/192
| * device: allow the reapply of mdns and llmnr propertiesbg/llmnrBeniamino Galvani2018-09-061-1/+3
| |
| * core: nm-ip4-config: consider dns-related differences as relevantBeniamino Galvani2018-09-062-2/+31
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The DNS manager reacts to NM_DEVICE_IP4_CONFIG_CHANGED events, which are generated when there is a relevant change to an IP4 configuration. Until now, changes to the mdns,llmnr properties were not considered relevant (and neither minor, this is already a bug). Promote them to relevant so that the DNS manager is notified and will rewrite the DNS configuration when one of this properties changes. Note that the DNS priority should be considered relevant and added into the checksum as well, but is a problem right now because in the DNS manager we rely on the fact that an empty configuration (i.e. just created) has a zero checksum. This is needed to avoid rewriting resolv.conf when there is no change. The DNS priority initial value depends on the connection type (VPN or not), so it's a bit difficult to add it to checksum maintaining the assumption of checksum(empty)=0. This should be improved in the future.
| * ifcfg-rh: add support for connection.llmnrBeniamino Galvani2018-09-063-0/+24
| |
| * cli: add support for connection.llmnrBeniamino Galvani2018-09-064-512/+656
| |
| * core: add support for connection.llmnrBeniamino Galvani2018-09-066-4/+85
| |
| * libnm-core: add connection.llmnr propertyBeniamino Galvani2018-09-065-3/+91
| |
| * libnm-core: fix documentation for connection.mdnsBeniamino Galvani2018-09-062-5/+3
| | | | | | | | | | | | | | | | | | After an update of the connection.mdns property, a reactivation is needed to apply the new value. Also, the ifcfg-rh variable name was wrong. Fixes: 2e2ff6f27aa1bfa7a27d49980b319873240ec84b
| * core: add nm_config_data_get_connection_default_int64()Beniamino Galvani2018-09-067-196/+175
|/
* settings: merge branch 'th/settings-cleanup'Thomas Haller2018-09-0615-1156/+924
|\ | | | | | | https://github.com/NetworkManager/NetworkManager/pull/190
| * settings/ifupdown: use _NMLOG() macros for loggingThomas Haller2018-09-063-58/+88
| | | | | | | | | | | | | | | | Does not address the issues that the existing logging is much too verbose and does not provide necessary context for what it's complaining. The logging messages should be improved. At least, the logging macro gives all messages a "ifupdown: " prefix.
View Lorry Controller Status