summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
* contrib: remove dbus/dbus-glib requires from libnm sub-packageDan Williams2016-02-021-3/+0
| | | | | | libnm doesn't use dbus-glib or dbus at all. (cherry picked from commit 5e892819fcebb0ffe8e6797b3be8debb0aede335)
* contrib/rpm: make build more configurable by using conditionalsThomas Haller2016-02-023-43/+90
| | | | | | | | | | | Also add a new conditional "debug" to enable more assertions and more logging, which is disabled by default. Also add a conditional "test" to disable running the unit tests (make check) while building the package. http://rpm.org/wiki/PackagerDocs/ConditionalBuilds (cherry picked from commit 87dc14476b81d6f540abbd935b611c4910dc91cd)
* contrib: sync fedora/rpm/NetworkManager.specDan Winship2016-02-021-9/+0
| | | | | | We're building the plugins on s390 these days (cherry picked from commit 20a56fa9a25cc95099c64a550e24dd9f3496c214)
* contrib/rpm: remove NetworkManager-devel packageThomas Haller2016-02-021-28/+15
| | | | | | | | | | | | | | | | | | | | | | NetworkManager-devel package contained development headers that are useful without libnm-glib and without glib. But it is also based on the legacy libnm-glib library as it has headers like "/usr/include/NetworkManager/NetworkManager.h". A glib-free devel package based on the new libnm library would be needed to provide "/usr/include/libnm/nm-dbus-interface.h". But that would amount to 4 devel packages. Instead, just move the content of NetworkManager-devel into NetworkManager-glib-devel package. Note that NetworkManager-devel already contained several truely libnm-glib dependent files, like the vala bindings (which require libnm-glib). So that was another bug in the packaging and is fixed by moving it all to NetworkManager-glib-devel. https://bugzilla.gnome.org/show_bug.cgi?id=755938 (cherry picked from commit e01c17523a85a2f238850aa8591888548e231e7e)
* contrib/rpm: sync from Fedora gitLubomir Rintel2016-02-021-69/+47
| | | | (cherry picked from commit de5d98197f751c4ff4eed36af27131a024e47b73)
* contrib/rpm: add comment to NetworkManager.conf about debug logfilesThomas Haller2016-02-021-1/+19
| | | | (cherry picked from commit bb78d14467c2bb5c85d2efbe84e521148322b1ca)
* contrib/rpm: add --no-build option to build_clean.shThomas Haller2016-02-021-13/+20
| | | | | | | Option to skip building the source package. Useful if you already have a source tarball from a previous run. (cherry picked from commit 3b01d25561d95974e6473c51b56103ce92e51af7)
* device/team: fix tiny memory leakBeniamino Galvani2016-02-011-0/+1
| | | | | Fixes: 10f9b6c58bcf3679a117ea75913cdf3aeee15578 (cherry picked from commit dc4d0a4200f878656559c8292c1c3bc34cd3da27)
* connectivity: fix calling parent dispose()Thomas Haller2016-02-011-6/+5
| | | | (cherry picked from commit 2bf4960ec127cf5ab7fd00d93be8743e4116a408)
* platform: ignore permanent MAC addresses of all ones (FF:FF:FF:FF:FF:FF)Dan Williams2016-01-291-1/+8
| | | | | | | | | | | Drivers are stupid, and just like the platform ignores an all zeros permanent address, so should it ignore all ones. NetworkManager[509]: <debug> [1453743778.854919] [devices/nm-device.c:8885] nm_device_update_hw_address(): [0x190370] (eth0): hardware address now 86:18:52:xx:xx:xx NetworkManager[509]: <debug> [1453743778.855438] [devices/nm-device.c:9138] constructed(): [0x190370] (eth0): read initial MAC address 86:18:52:xx:xx:xx NetworkManager[509]: <debug> [1453743778.861602] [devices/nm-device.c:9148] constructed(): [0x190370] (eth0): read permanent MAC address FF:FF:FF:FF:FF:FF (cherry picked from commit d442dcd1747ea33d2322472faa744256a77a8fea)
* ifcfg,keyfile: fix temporary file races (CVE-2016-0764)Lubomir Rintel2016-01-292-22/+14
| | | | | | | | | | | | | | | | | | | Two of these raised Coverity's eyebrows. CID 59389 (#1 of 1): Insecure temporary file (SECURE_TEMP) 5. secure_temp: Calling mkstemp without securely setting umask first. CID 59388 (#1 of 1): Insecure temporary file (SECURE_TEMP) 1. secure_temp: Calling mkstemp without securely setting umask first. Last one raised mine. When a connection is edited and saved, there's a small window during which and unprivileged authenticated local user can read out connection secrets (e.g. a VPN or Wi-Fi password). The security impact is perhaps of low severity as there's no way to force another user to save their connection. (cherry picked from commit 60b7ed3bdc3941a3b7c56824fba4b7291e79041f)
* wwan: retry connect on some errors and save them for log messagesDan Williams2016-01-281-7/+15
| | | | | | | | | | | | | | | | | | | | | | First, cb751012a2f4b8ef236eab2a7c65687c99205806 mistakenly converted the act_stage_context_step() in connect_ready() to connect_context_clear() instead of connect_context_step(). This would cause the IP Type retry logic to fail and no further types to be tried. It also throws away the ctx->first_error and causes all errors that MM returns on the connect attempt to be dropped on the floor. Second, not all errors should cause an advance to the next IP Type, since some errors aren't related to it. Specifically, MM_CORE_ERROR_RETRY when using Simple.Connect() means that a timeout was reached in the internal connect logic, not a modem or network error. In that case, try the connect again with the same IP Type before advancing to the next type. Fixes: cb751012a2f4b8ef236eab2a7c65687c99205806 Tested-by: Ladislav Michl <ladis@linux-mips.org> Tested-by: Tore Anderson <tore@fud.no> (cherry picked from commit 1cf47277662eda3bf3e049dc26c78f1022100169)
* bluez: own reference to connection provider in NMBluezDeviceThomas Haller2016-01-271-5/+9
| | | | (cherry picked from commit 53233bb04ccb65cc24ad186c98a46963f437850e)
* bluez: own reference to connection provider in NMBluezManagerThomas Haller2016-01-271-2/+3
| | | | (cherry picked from commit 94dcffc4758e3c14f56e7cb45436056318fb11d9)
* bluez: fix invoking parent dispose() function in NMBluezManagerThomas Haller2016-01-271-0/+2
| | | | | Fixes: bf5a6ad4431c50b19ca954071900c4235c0f44a3 (cherry picked from commit 7cc54d5bb90102d8a563b51a50fd0bc81e833769)
* libnm-glib: fix another memory leak around update_permissions()Thomas Haller2016-01-261-13/+6
| | | | | | | | This time in init_async_got_permissions(). Thereby, just use gs_unref_hash and gs_free_error for cleanup. (cherry picked from commit 8029f59e4fcefe9786fb79d04ede5ea10e3c33c2)
* libnm-glib: fix crash due to uninitalized pointer in get_permissions_reply()Thomas Haller2016-01-261-1/+1
| | | | | | | | | If the D-Bus call failed with error, @permissions would stay uninitialized. Fixes: f2399a69760e8d14b91e523127eb187d6337530f Fixes: 808f0126035a09c946c559c9b1c464c4523a8a0e (cherry picked from commit e0601d501a09d2ea24c7d9d966056cb8042a49b3)
* libnm-glib: fix leak in get_permissions_reply()Dan Williams2016-01-261-0/+2
| | | | (cherry picked from commit f2399a69760e8d14b91e523127eb187d6337530f)
* wwan: rework connection flow to send PIN earlier and fix autoconnectDan Williams2016-01-252-115/+234
| | | | | | | | | | | | | | | | | | | | | | | | | Modems often don't expose all the required properties until they have been unlocked, and that includes the IP types supported by the modem. With an autoconnect WWAN connection where the SIM requires a PIN, there were two problems: 1) the PIN is a secret and we don't have it until it's explicitly requested during the activation process, so we cannot gate GSM connection availability on whether a PIN is present since this happens long before we request secrets 2) when the modem is locked it may not report the supported IP types, which caused an auto-activation to fail early becuase IP compatibility is checked before the PIN is sent to the modem Rework connection activation flow into a series of concrete steps, where the PIN is sent to the modem if required, and only after the modem is actually unlocked does the connection proceed. This does mean that any connection marked 'autoconnect' can theoretically enable a PIN-locked modem even if the connection has no PIN defined, but there's no good way around that. NetworkManager would activate the connection (cherry picked from commit cb751012a2f4b8ef236eab2a7c65687c99205806)
* core: only run availability recheck transition if requiredDan Williams2016-01-251-6/+10
| | | | | | | | | | | | | | Device subclasses can call nm_device_recheck_available() at any time, and the function would change the device's state to UNKNOWN in cases where the device was available already. For WWAN devices, availability is rechecked every time the modem state changes, resulting in: NetworkManager[28919]: <info> (ttyUSB4): modem state changed, 'disabled' --> 'enabling' (reason: user-requested) NetworkManager[28919]: <debug> [1445538582.116727] [devices/nm-device.c:2769] recheck_available(): [0x23bd710] (ttyUSB4): device is available, will transition to unknown NetworkManager[28919]: <info> (ttyUSB4): modem state changed, 'enabling' --> 'searching' (reason: user-requested) NetworkManager[28919]: <debug> [1445538582.776317] [devices/nm-device.c:2769] recheck_available(): [0x23bd710] (ttyUSB4): device is available, will transition to unknown (cherry picked from commit d9c6b9f3dd8463dc636115c20e2d84a1a07b4fbe)
* systemd: order NetworkManager.serivce after network-pre.targetThomas Haller2016-01-231-1/+1
| | | | | https://bugzilla.gnome.org/show_bug.cgi?id=761001 (cherry picked from commit 9c3187027c9435e2c0007335e1c8503098cbce7c)
* manager: cleanup active connections upon exitBeniamino Galvani2016-01-231-0/+2
| | | | | | | | | | | | When connection sharing is enabled, the removal of iptables rules is delegated to the NMActRequest destructor; but for this to work it is required that the object is properly dereferenced upon NM termination. Clean up the active connections which are in DEACTIVATED state when quitting, so that they are unexported and destroyed. https://bugzilla.gnome.org/show_bug.cgi?id=692673 (cherry picked from commit e3a6ba6756620b5ed64459141567dd7a760e2c30)
* core: list iptables sharing rules in the right orderBeniamino Galvani2016-01-232-10/+10
| | | | | | | | | | | The rules were added to the list using g_slist_append() and then applied one at time using "iptables --insert" which puts them at the beginning of the chain, reversing the initial order. Instead, list them in the desired order and use g_slist_prepend() to achieve the same result. This has no functional changes. (cherry picked from commit 8cba3e046eb8e3db9ab0bd55bbadc6cb8043096d)
* linux-platform: treat gadget devices as ethernet devicesLubomir Rintel2016-01-212-7/+18
| | | | | | | Also, don't manage them by default. Whatver created it should take care of management. (cherry picked from commit c1cf3c25c836f5beeecc4589b0aea52da7379587)
* wifi: assert against returning cached NMSupplicantInterface instancesThomas Haller2016-01-211-1/+4
| | | | | | | | | | | | | | | nm_supplicant_manager_iface_get() returning a cached instance leads to a crash when the first owner releases the object, as no ownership is transferred. That was fixed on master by commit f1fba3eb02c5d102a1b0e85c371dce81e5bd0d3b. Instead of backporting the entire refactoring (which also asserts against reuse), just disallow reusing here. The assertion should not be hit. If it would we need to investigate. Also, this way the assertion avoids a hard crash. https://bugzilla.redhat.com/show_bug.cgi?id=1298007
* systemd: add "After=dbus.service" to NetworkManager.serviceThomas Haller2016-01-211-0/+1
| | | | | | | | | | Order NetworkManager after dbus. Otherwise during shutdown, both service are killed together and possibly NetworkManager can no longer use D-Bus during shutdown. It will need it however to communicate with VPN plugins and wpa-supplicant. Related: https://bugs.freedesktop.org/show_bug.cgi?id=89847#c14 Related: https://bugzilla.redhat.com/show_bug.cgi?id=1214466 (cherry picked from commit bf54a5bfbaf05021fe738a7da254760a5bcf1e97)
* build: remove spurious comma from configure.acDan Williams2016-01-201-1/+1
| | | | (cherry picked from commit 701c05ad692566527322db6dade4f7d363d9de02)
* device: clear queued_state callback in disposeThomas Haller2016-01-191-1/+8
| | | | | | | | | | | | | | | dispose() calls _cleanup_generic_pre() which in turn already calls nm_device_queued_state_clear(). So we would expect that at the end of dispose() no queued-state is pending. However, there there are crashes reports in queued_set_state() with the device instance already destructed (rh#1270247). Add this check trying to avoid the crash and closing in on the cause. Related: https://bugzilla.redhat.com/show_bug.cgi?id=1180827 Related: https://bugzilla.redhat.com/show_bug.cgi?id=1270247 Related: https://bugzilla.redhat.com/show_bug.cgi?id=1298009 (cherry picked from commit 76f90812f456dd5dc2bfd12b1d56573a7c65f3d0)
* device: merge branch 'bg/device-zero-mac-fix-rh1288110'Beniamino Galvani2016-01-114-47/+77
|\ | | | | | | https://bugzilla.redhat.com/show_bug.cgi?id=1288110
| * device: wait for valid MAC before making ethernet devices availableBeniamino Galvani2016-01-113-5/+45
| | | | | | | | | | | | | | | | | | | | | | | | | | In certain situations, ethernet links first appear with a zero MAC address and then the MAC changes some time later. Currently NM does not deal correctly with this scenario since it initializes wrong @initial_hwaddr and @permanent_hwaddr on the device and tries to immediately activate it. To fix this, initialize the device's addresses only when the MAC becomes valid and make the device available only at that point. (cherry picked from commit 92149f223fbd4068f30f31d14c6aa6c8e2146161)
| * device/trivial: split out nm_device_update_initial_hw_address()Beniamino Galvani2016-01-111-21/+29
| | | | | | | | (cherry picked from commit 2a0a9aa2e45b064304f827c7eed49bc80c6e3702)
| * core: simplify generation of default connection for new devicesBeniamino Galvani2016-01-112-23/+5
|/ | | | | | | | | | | Instead of using a signal for triggering the generation of a default connection when the device becomes managed, let the manager wait for a transition to UNAVAILABLE or DISCONNECTED states. This partially reverts b3b0b4625053 ("device: retry creation of default connection after link is initialized"). (cherry picked from commit 44789e32912c48358dbb7971be57682bd330719d)
* build: fix missing <gio/gio.h> include for "nm-dns-manager.c"Matthew Millar2016-01-111-0/+1
| | | | | | | | | | | | | | | When compiling with ./configure \ --without-libsoup \ --disable-concheck \ --with-resolvconf=/xx/yy/resolvconf we must explicitly include <gio/gio.h>. https://bugzilla.gnome.org/show_bug.cgi?id=760447 [thaller@redhat.com: original patch modified to always include gio.h]
* build: minor change creating symlinks in install-exec-hook for nmtuiThomas Haller2016-01-071-2/+2
| | | | (cherry picked from commit 39d6976e89e97249cda9a2d915bc399541ee9d46)
* build: use symlinks for nmtuiMichael Biebl2016-01-072-1/+3
| | | | | | | Make /usr/bin/nmtui-* symbolic links to /usr/bin/nmtui. https://bugzilla.gnome.org/show_bug.cgi?id=759824 (cherry picked from commit 39fc73eed9a2f63638f8736b3f9f9d4e816207db)
* wifi: merge branch 'th/wifi-device-creation-bgo760154'Thomas Haller2016-01-064-61/+55
|\ | | | | | | | | | | https://bugzilla.gnome.org/show_bug.cgi?id=760154 (cherry picked from commit 06e0595401e6eb16ac527e54af8ca09c72245672)
| * wifi: refactor creation of NMDeviceWifi/NMDeviceOlpcMesh to initialize in ↵Thomas Haller2016-01-062-34/+13
| | | | | | | | | | | | constructed() method (cherry picked from commit 1a835ad3d03ffe39a3caf4796027baaba73bf9b8)
| * wifi: don't fail construction of NMDeviceWifi in constructorThomas Haller2016-01-064-25/+30
| | | | | | | | | | | | | | | | | | | | | | | | We cannot abort the construction of a GLib object instance like we did for NMDeviceWifi and NMDeviceOlpcMesh when nm_platform_wifi_get_capabilities() failed. Instead, check the capabilities first (in the factory method) and only create the object instance when the device can be handled. https://bugzilla.gnome.org/show_bug.cgi?id=760154 (cherry picked from commit 044de4cea2c82d289033e75f1e12c7d346dc5537)
| * wifi-olpc: refactor NMDeviceOlpcMesh to hold pointer to NMManagerThomas Haller2016-01-061-5/+15
|/ | | | | | | Objects that register to a signal of a singleton should own a reference to the singleton to ensure the proper lifetime of the singleton upon shutdown. (cherry picked from commit e2e22eb574d0c18ccd79bf8b3cee883418632a96)
* device/infiniband: take interface down to set transport modeBeniamino Galvani2016-01-051-1/+4
| | | | | | | | With some drivers it is necessary to take the interface down to set the transport mode. https://bugzilla.redhat.com/show_bug.cgi?id=1281301 (cherry picked from commit 5bf0697f659b262d7d385ff5903f3b86611a8c35)
* device: update @ip_iface only if IP interface existsBeniamino Galvani2016-01-051-3/+4
| | | | | | | | | | | | | | | If @ip_ifindex is zero, the IP interface has disappeared and there's no point in updating @ip_iface. Actually, unconditionally updating @ip_iface is dangerous because it breaks the assumption used by other functions (as nm_device_get_ip_ifindex()) that a non-NULL @ip_iface implies a valid @ip_ifindex. This was causing the scary failure: devices/nm-device.c:666:get_ip_iface_identifier: assertion failed: (ifindex) https://bugzilla.redhat.com/show_bug.cgi?id=1268617 (cherry picked from commit ed536998f9530698ff3082fc5587dbeb7d3a594f)
* ppp-manager: clear @ppp_watch_id upon pppd terminationBeniamino Galvani2016-01-051-0/+1
| | | | | | | | Set @ppp_watch_id to zero upon pppd termination, otherwise the call to g_source_remove(priv->ppp_watch_id) in dispose() could trigger a failed assertion. (cherry picked from commit 5f93f0101538db39efe0f9ea2316e63bff953bf0)
* core: fix failure to configure routes due to wrong device-route for IPv4 ↵Thomas Haller2016-01-051-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | peer-addresses As in the case of a OpenVPN connection, we might add an address like: 10.8.0.58/32 ptp 10.8.0.57 In this case, kernel would automatically add a device-route like: 10.8.0.57/32 via 0.0.0.0 dev 32 metric 0 mss 0 src rtprot-kernel scope link pref-src 10.8.0.58 nm_ip4_config_commit() checks all IP addresses to figure out the present device-routes. Then the routes are synced by NMRouteManager. Due to a bug, we would not consider the peer-address, but the local-address and configure a route 10.8.0.58/32, instead of 10.8.0.57/32. That stays mostly unnoticed, because usually the peer and the local-address are in the same subnet, so that there is no difference (/32 is an example of the peer-address being in a different subnet). It also seems that due to a bug fixed by df4e5357521 this issue didn't surface. Probably because we would not notice the 10.8.0.57/32 right away and thus nm_route_manager_ip4_route_sync() would not wrongly delete it. https://bugzilla.gnome.org/show_bug.cgi?id=759892 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=809195 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=809494 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=809526 https://bugs.archlinux.org/task/47535 https://bugzilla.redhat.com/show_bug.cgi?id=1294309 https://mail.gnome.org/archives/networkmanager-list/2015-December/msg00059.html
* man: fix typosBeniamino Galvani2015-12-246-10/+10
| | | | (cherry picked from commit 2ef3c1047d6b3c044ae6caf1ba7c0d8af6cc6bf9)
* release: bump version to 1.0.101.0.10Lubomir Rintel2015-12-234-15/+4
|
* release: update NEWSLubomir Rintel2015-12-231-0/+23
|
* po: fix some typos in Galician translationLubomir Rintel2015-12-231-2/+2
| | | | (cherry picked from commit dff1829c999477813637e67cd22caa5a94dddfee)
* po: merge in master translationsLubomir Rintel2015-12-235-1003/+994
|
* po: update-poLubomir Rintel2015-12-2365-76730/+377497
|
* po: update Brazilian Portuguese translationRafael Fontenelle2015-12-231-2770/+7129
| | | | https://bugzilla.gnome.org/show_bug.cgi?id=759747
View Lorry Controller Status