summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
* wifi: support WPA2 ad-hoc (ibss-rsn)bg/ibss-rsnBeniamino Galvani2019-08-236-123/+153
| | | | | | | | If the device supports it, allow usage of WPA2 in ad-hoc networks. Based-on-patch-by: Nicolas Cavallari <cavallar@lri.fr> https://gitlab.freedesktop.org/NetworkManager/NetworkManager/issues/184
* wifi: drop support for wpa-none key-mgmtBeniamino Galvani2019-08-2317-258/+23
| | | | | | | | NM didn't support wpa-none for years because kernel drivers used to be broken. Note that it wasn't even possible to *add* a connection with wpa-none because it was rejected in nm_settings_add_connection_dbus(). Given that wpa-none is also deprecated in wpa_supplicant and is considered insecure, drop altogether any reference to it.
* wifi: expose IBSS_RSN capabilityBeniamino Galvani2019-08-235-634/+836
| | | | | | | The new capability indicates whether the device supports WPA2/RSN in an IBSS (ad-hoc) network. https://bugzilla.gnome.org/show_bug.cgi?id=757823
* bluetooth: fix leak in get_managed_objects_cb()Thomas Haller2019-08-231-1/+3
| | | | Fixes: 1ae5d5335417 ('bluez: add support for BlueZ 5')
* shared/hash: implement nm_hash_obfuscate_ptr() as inline function instead of ↵Thomas Haller2019-08-231-9/+9
| | | | | | | | | | | | | | macro There is really no reason for this to be a macro. Our hash-related helpers (like nm_hash_update_val()) are macros because they do some shenigans to accept arguments of different (compile-time) types. But the arguments for nm_hash_obfuscate_ptr() are well known and expected of a certain form. Note that with "-O2" some quick testing shows that the compiler no longer inlines the function. But I guess that's fine, probably the compiler knows best anyway.
* core/logging: don't log plain pointer value from nm_log_ptr()Thomas Haller2019-08-231-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Logging pointer values might reveal information that can be used to defeat ASLR. We should avoid that. On the other hand, it's useful to tag a logging message with the pointer value of the "source" of the message. It helps to correlate messages and search for relevant messages in the log. As a compromise, use NM_HASH_OBFUSCATE_PTR(), like we do at several places already. For example, we also log <debug> [1566550899.7901] setup NMPlatform singleton (29a6af9867f2e5d0) This obfuscated value is a 64 bit unsigned integer with the siphash24 hash of the raw value with a randomized seed. Of course, contrary to the pointer value, there is a tiny chance that two different pointers hash to the same identifier. However, that seems unlikely enough to be of no concern. Note that this pointer value is only logged to aid debugging. It is sufficiently unlikely that this causes confusion. One other downside of printed the obfuscated value, is that you can no longer read the pointer from the log and use it in gdb directly. That might be sometimes convenient, but making this impossible is kinda the purpose of this change. As such, nm_log_ptr() becomes a bit of a misnomer. But not too bad, it still is a good name. For example, if we wanted we could redefine the NM_HASH_OBFUSCATE_PTR* macros when building "--with-more-asserts".
* contrib/rpm: install our dispatcher scripts into /usr/lib/NetworkManagerLubomir Rintel2019-08-231-6/+10
| | | | That's where they always should have been.
* cli: include BSSID to NMC_FIELDS_DEV_WIFI_LIST_COMMONMaciek Borzecki2019-08-223-925/+1315
| | | | | | | | When using WiFi in an environment with multiple APs of the same SSID (eg. conference venue, hotels), it is often useful to be able to identify particular APs by their BSSID. https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/235
* cli: prefer nm_assert() to g_assert*()Francesco Giudici2019-08-221-3/+3
|
* cli: fix bad indentationFrancesco Giudici2019-08-221-2/+2
|
* meson: fix build_clean.sh -w meson -w testFrancesco Giudici2019-08-221-0/+6
| | | | Fixes: 00bb6cdb4f93 ('build: fix meson warning about path separator in target')
* shared: allow negative timestamps for nm_utils_monotonic_timestamp_as_boottime()Thomas Haller2019-08-211-7/+11
|
* wifi: detect FT support per interface and avoid enabling itThomas Haller2019-08-201-9/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously we only cared whether supplicant is build with support for FT. In that case we would pass FT-PSK to supplicant, like Config: added 'key_mgmt' value 'WPA-PSK WPA-PSK-SHA256 FT-PSK' Supplicant would then always try FT with preference, regardless whether the interface/driver support it. That results in a failure to associate, if the driver does not support it. NetworkManager[1356]: <info> [1566296144.9940] Config: added 'key_mgmt' value 'WPA-PSK WPA-PSK-SHA256 FT-PSK' ... wpa_supplicant[1348]: wlan0: WPA: AP key_mgmt 0x42 network profile key_mgmt 0x142; available key_mgmt 0x42 wpa_supplicant[1348]: wlan0: WPA: using KEY_MGMT FT/PSK ... wpa_supplicant[1348]: * akm=0xfac04 ... kernel: ERROR @wl_set_key_mgmt : kernel: invalid cipher group (1027076) Since we pass a list of acceptable "key_mgmt" options to supplicant, FT-PSK should not be used when supplicant knows it's not supported. That is a supplicant bug. Regardless, work around it by checking the per-interface capability, and avoid it if support is apparently not present.
* cli: cleanup unique_master_iface_ifname()Thomas Haller2019-08-201-12/+12
| | | | | | | - use appropriate types for integer variables - rework the confusing loop which would reset the loop-counter to start again.
* cli: cleanup setting default interface-nameThomas Haller2019-08-201-17/+22
|
* data: fix the ID_NET_DRIVER udev ruleLubomir Rintel2019-08-161-1/+1
| | | | | | | | | | | | Systemd v243 is complaining about the wrong substitution there. That is sort of harmless, because systemd-udevd in that version doesn't need the rule anyway. But still fix it, to avoid a warning. Also, newer udevd's $PATH doesn't include sbin. That is also okay, because we don't need the rule to actually work there. But fix it anyway. https://bugzilla.redhat.com/show_bug.cgi?id=1740655
* cli: merge branch 'th/cli-modify-enums-and-cleanup'Thomas Haller2019-08-168-126/+249
|\ | | | | | | https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/234
| * man/cli: better explain modifying properties regarding +/- modifiersThomas Haller2019-08-161-10/+12
| |
| * cli: fix handling modifier in nmc_read_connection_properties() for aliasesThomas Haller2019-08-161-31/+28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Various cleanups: - after detecting the modifier, remove it from the string right away. It's redundant and confusing to do it later. - rename variables and move to inner scope. - don't use g_str_split() to split the property name at the first dot. strchr() is sufficient. Also, now that we strip the modifier from option early, they start also working for aliases. There is no need to not support (or behave differently) w.r.t. whether aliases support modifiers or not. This fixes: $ nmcli connection modify r +ip4 192.168.5.2/24 Error: invalid <setting>.<property> 'ip4'.
| * cli: add NMMetaAccessorModifier enum instead of using "char" typeThomas Haller2019-08-165-74/+175
| | | | | | | | | | | | | | | | | | | | | | The enum values are unique throughout the source code so they can easier be searched (e.g. with grep), compared to '\0'. It is often interesting where a certain modifier is used, so searching the source code is important to give relevant results. Also, the modifier is really an enum and we shouldn't misuse char type. If that would be a good idea in general, we wouldn't need any enums at all. But we use them for good reasons.
| * cli: reorder checks in nmc_setting_set_property() for modifier typeThomas Haller2019-08-161-6/+7
| | | | | | | | No notable change in behavior, but makes more sense this way.
| * cli: support +/- modifiers for flags propertiesThomas Haller2019-08-161-9/+29
| |
| * libnm: fix NMSetting8021xAuthFlags to be a flags typeThomas Haller2019-08-161-1/+4
| | | | | | | | | | This is an API break, but probably not too bad. A lot of things when using the type will work as before.
| * shared: use nm_auto_unref_gtypeclass in _nm_utils_enum_from_str_full()Thomas Haller2019-08-161-2/+1
|/
* Revert "po: add Zanata configuration"Lubomir Rintel2019-08-151-16/+0
| | | | | | Not useful anymore. This reverts commit c5f40c701ed65bf378d3a14a9309fe316d9f5a90.
* contrib/rpm: enable IWD (outside RHEL)Lubomir Rintel2019-08-151-1/+5
| | | | | | Let's enable the option to use IWD as an alternative to wpa_supplicant for Wi-Fi support. People have been asking for this, it works, and is well maintained.
* po: RHEL 8.1 translationsLudek Janda2019-08-154-13419/+11232
| | | | | https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/242 (cherry picked from commit 9e57873e9c5cda8976d0cf00e08283ae080c52a9)
* po: update Ukrainian translationYuri Chornoivan2019-08-151-1900/+2074
| | | | https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/240
* cli: don't require "ifname" when adding connectionThomas Haller2019-08-131-1/+0
| | | | | | | | | | | | | $ nmcli connection add type ethernet con-name t autoconnect no Error: ifname argument is required. This reverts commit a91eafdf95bc ('cli: 'con add': make ifname mandatory (except bond,bridge,vlan) (bgo #698113)'). Apparently ifname argument was required to avoid confusion (unexpected behavior). But I don't agree that is an issue, it's just annoying. Often you really have just one ethernet or Wi-Fi device, so this does not seem helpful. https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/222
* all: merge branch 'th/static-default-route'Thomas Haller2019-08-138-53/+59
|\ | | | | | | https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/229
| * all: allow configuring default-routes as manual, static routesThomas Haller2019-08-137-40/+33
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Up until now, a default-route (with prefix length zero) could not be configured directly. The user could only set ipv4.gateway, ipv4.never-default, ipv4.route-metric and ipv4.route-table to influence the setting of the default-route (respectively for IPv6). That is a problematic limitation. For one, whether a route has prefix length zero or non-zero does not make a fundamental difference. Also, it makes it impossible to configure all the routing attributes that one can configure otherwise for static routes. For example, the default-route could not be configured as "onlink", could not have a special MTU, nor could it be placed in a dedicated routing table. Fix that by lifting the restriction. Note that "ipv4.never-default" does not apply to /0 manual routes. Likewise, the previous manners of configuring default-routes ("ipv4.gateway") don't conflict with manual default-routes. Server-side this all the pieces are already in place to accept a default-route as static routes. This was done by earlier commits like 5c299454b49b ('core: rework tracking of gateway/default-route in ip-config'). A long time ago, NMIPRoute would assert that the prefix length is positive. That was relaxed by commit a2e93f2de4ac ('libnm: allow zero prefix length for NMIPRoute'), already before 1.0.0. Using libnm from before 1.0.0 would result in assertion failures. Note that the default-route-metric-penalty based on connectivity checking applies to all /0 routes, even these static routes. Be they added due to DHCP, "ipv4.gateway", "ipv4.routes" or "wireguard.peer-routes". I wonder whether doing that unconditionally is desirable, and maybe there should be a way to opt-out/opt-in for the entire profile or even per-routes. https://bugzilla.redhat.com/show_bug.cgi?id=1714438
| * libnm: avoid heap allocation for checking valid routes in ↵Thomas Haller2019-08-131-11/+14
| | | | | | | | nm_ip_route_attribute_validate()
| * libnm: set errno in nm_key_file_get_boolean() to distinguish between missing ↵Thomas Haller2019-08-131-3/+13
|/ | | | | | | key and error This is also what nm_keyfile_plugin_kf_get_int64() does. It's useful to know whether a value was missing or invalid.
* dhcp: merge branch 'th/dhcp-factory-cleanup'Thomas Haller2019-08-1310-35/+79
|\ | | | | | | https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/221
| * dhcp: minor refactoring to switch default IPv4 DHCP plugin to "nettools" ↵Thomas Haller2019-08-133-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | with one-line change Minor refactoring so that there is only a one-line change necessary to flip the implementation of the "internal" DHCP plugin for IPv4 from "systemd" to "nettools". We don't do that yet, because there are still some issues (e.g. the lease is not persisted for nettools plugin). Eventually we want to switch, so prepare the code to be almost there.
| * dhcp: make "systemd" DHCP plugin configurableThomas Haller2019-08-1310-18/+42
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We have the "internal" DHCP plugin. That's our preferred plugin, and eventually we may drop all other plugins. Currently, the "internal" plugin is based on code from systemd-networkd and implemented in "src/dhcp/nm-dhcp-systemd.c". As this code is forked we eventually want to switch to nettools' n-dhcp4 library (for IPv4). For that reason we already have "src/dhcp/nm-dhcp-nettools.c". Note that "nettools" can be configured as a DHCP plugin, but this configuration is only experimental and for testing. There is never supposed to be a "nettools" plugin, but eventually the "internal" plugin will switch implementation. We don't want to replace systemd-based implementation right away. Not until we are sure that nettools works well. For that reason we keep them both in parallel for a while. This commit makes "systemd" DHCP plugin explicitly configurable in NetworkManager.conf. Like "nettools" this is an undocumented option, only for testing. If you choose "internal" (the default), you get one of the implementations (currently the "systemd" one). But by selecting "systemd" or "nettools" explicitly, you can select the exact plugin.
| * dhcp: log effectively used DHCP plugin typeThomas Haller2019-08-131-8/+26
| |
| * dhcp: cleanup selecting GType from DHCP client factoryThomas Haller2019-08-131-14/+14
|/ | | | | Instead of returning a client-factory, return the GType right away.
* bluetooth: merge branch 'th/bluez-rework-1'Thomas Haller2019-08-1212-1239/+156
|\ | | | | | | https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/236
| * NEWS: mention removal of BlueZ 4 supportThomas Haller2019-08-121-0/+2
| |
| * bluetooth: add _NMLOG() logging macro to NMBluezDeviceThomas Haller2019-08-121-31/+50
| |
| * bluetooth: pass GDBusConnection to NMBluezDeviceThomas Haller2019-08-123-34/+18
| | | | | | | | | | | | No need to let NMBluezDevice ask for glib's G_BUS_TYPE_SYSTEM connection. We already have the right D-Bus connection at hand, just use it.
| * bluetooth: drop BlueZ 4 support (2)Thomas Haller2019-08-125-235/+88
| |
| * bluetooth: drop BlueZ 4 support (1)Thomas Haller2019-08-127-944/+3
|/ | | | | | | BlueZ 5.0 was released in December 2012 and broke API with BlueZ 4. NetworkManager supports Bluez 5 for years already. Of course, version 4 is long gone by now, so remove it.
* libnm/doc: fix typoThomas Haller2019-08-121-1/+1
|
* libnm/doc: clarify NMMetered enum and how metered state in NetworkManager worksThomas Haller2019-08-121-0/+27
|
* po: update Polish (pl) translationPiotr Drąg2019-08-121-4314/+1725
| | | | https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/239
* auth: drop unused idle-reason for NMAuthManagerCallIdThomas Haller2019-08-101-24/+5
| | | | | | | | We now only call the idle action with the same reason: authorized. That is since we no longer use GDBusProxy, there are no other reasons where we would fail. Drop the unused code.
* NEWS: update header for future 1.22 releaseThomas Haller2019-08-101-3/+12
| | | | Also, mark 1.20 as stable.
* settings: merge branch 'th/settings-improvements'Thomas Haller2019-08-0918-202/+271
|\ | | | | | | https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/224
View Lorry Controller Status