summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
* fixup! dbus: fix emitting D-Bus NetworkManager's old-style PropertiesChange ↵th/dbus-property-changed-source-iface-bgo770629-v2Thomas Haller2016-09-021-3/+3
| | | | signal
* NEWS: update file with changes to PropertiesChanged signalThomas Haller2016-09-021-0/+10
|
* exported-object: use _NMLOG2() macro for logging property-changed signalThomas Haller2016-09-021-7/+16
|
* exported-object: use @self variable instead of @objectThomas Haller2016-09-021-5/+5
|
* dbus: deprecated NM specific PropertiesChanged signalsThomas Haller2016-09-0231-5/+59
| | | | | Nowadays, users should use the standard "PropertiesChanged" signal on "org.freedesktop.DBus.Properties" interface.
* dbus: fix emitting D-Bus NetworkManager's old-style PropertiesChange signalThomas Haller2016-09-022-12/+81
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Before switching to gdbus (before 1.2.0), NetworkManager used dbus-glib. Most objects in the D-Bus API with properties had a signal NetworkManager-specific "PropertiesChanged" signal. Nowadays, this way of handling of property changes is deprecated for the common "PropertiesChanged" signal on the "org.freedesktop.DBus.Properties" interface. There were a few pecularities in 1.0.0 and earlier: (1) Due to the implementation with dbus-glib, a property-changed signal was emitted on *all* interfaces. For example: - a change on a NMDeviceVeth of "NMDeviceEthernet.HwAddress" would be emitted both for the interfaces "fdo.NM.Device.Ethernet" and "fdo.NM.Device.Veth". Note that NMDeviceVeth is derived from NMDeviceEthernet and there is no "HwAddress" on veth device. - a change of "NMVpnConnection.VpnState" was emitted on both interfaces "fdo.NM.VPN.Connection" and "fdo.NM.Connecion.Active". Note that NMActiveConnection is the parent type of NMVpnConnection and only the latter has a property "VpnState". (2) NMDevice's "fdo.NM.Device" interface doesn't have a "PropertiesChanged" signal. From (1) follows that all property-changes for this type were instead invoked with an interface like "fdo.NM.Device.Ethernet" (or multiple interfaces in case of NMDeviceVeth). 1.2.0 introduced gdbus, which gives us the standard "fdo.DBus.Properties" signal. However, it made the mistake of not realizing (1), thus instead of emitting the signal once for each interface, it would pick the first one in the inheritance tree. With 1.4.0, a bug from merge commit 844345e caused signals for devices to be only emitted for the interface "fdo.NM.Device.Statistics", instead of "fdo.NM.Device.Ethernet" or "fdo.NM.Device.Veth" (or both). The latter is what bgo#770629 is about and what commit 82e9439 tried to fix. However, the fix was wrong because it tried to do the theoretically correct thing of emitting the property-changed signal exactly once for the interface that actually ontains the property. In addition, it missed that NMDevice doesn't have a PropertiesChanged signal, which caused signals for "fdo.NM.Device" to get lost *sigh*. Now, restore the (broken) behavior of 1.0.0. These old-style property changed signals are anyway considered deprecated and exist solely to satisfy old clients and preserve the old API. Fixes: 63fbfad3705db5901e6a2a6a2fc332da0f0ae4be https://bugzilla.gnome.org/show_bug.cgi?id=770629 https://bugzilla.redhat.com/show_bug.cgi?id=1371920
* man: fix wording in NetworkManager.conf for "rc-manager"Thomas Haller2016-09-021-3/+3
|
* doc: add comment to systemd's NetworkManager.service about ibft requiring ↵Thomas Haller2016-09-022-0/+7
| | | | | | | | | | CAP_SYS_ADMIN We don't want to enable this upstream, but make the requirement more discoverable by documenting it and put a comment to NetworkManager.service. https://bugzilla.redhat.com/show_bug.cgi?id=1371201
* wwan: fix memory leaksBeniamino Galvani2016-09-022-1/+3
|
* device: don't try to start LLDP listener if no link is availableBeniamino Galvani2016-09-021-1/+1
| | | | | | | L3-only devices don't have an ifindex during stage2, don't try to start LLDP on them. Fixes: 07a9364d9c151bc3086a863759d31d0857ae011e
* doc: fix mistake in documenting Reload D-Bus callThomas Haller2016-09-011-2/+3
|
* device: manage firewall zone for assumed persistent connectionsBeniamino Galvani2016-08-311-5/+5
| | | | | | | | | | | | | | | | | | | | | | | After the fix in [1], if the connection is assumed we don't update its firewall zone. The goal of that change was to prevent NM from interfering with the configuration done externally on devices not created by NM. However if there is an assumed persistent connection active on the device NM touches the configuration in other ways, for example it configures DHCP and manages the default route. So it seems correct to also update the firewall zone. OTOH, if the connection is assumed-generated there is no persistent connection specifying a firewall zone and updating it makes no sense. Bug [1] was about not interfering with devices unknown to NM (for which there is no persistent connection) and so this change should not conflict with the previous fix. [1] https://bugzilla.redhat.com/show_bug.cgi?id=1098281 https://bugzilla.redhat.com/show_bug.cgi?id=1366288
* core: merge branch 'th/dbus-property-changed-source-iface-bgo770629'Thomas Haller2016-08-311-53/+55
|\ | | | | | | https://bugzilla.gnome.org/show_bug.cgi?id=770629
| * exported-object: cleanup logging about properties-changedThomas Haller2016-08-311-5/+5
| |
| * exported-object: fix source interface for PropertiesChanged D-Bus signalThomas Haller2016-08-311-51/+53
|/ | | | | | | | | | | | | | | | | | | | | | | | | | nm_exported_object_notify() hooks GObject's property-change signal and searches for the D-Bus interface to which to send the PropertiesChanged signal. Then it would enqueue the value encoded as GVariant in pending_notifications. However, thereby the association between the property that changed and the interface was lost. So later in idle_emit_properties_changed() it would just pick the first interface with a properties-changed-id. That is wrong. pending_notifications must be associated with the D-Bus interface that we are going to notify. That is, each InterfaceData must have its own separate list. This is broken since introducing NMExportedObject and moving to gdbus. Only now it was discovered as NMDevice itself has two D-Bus interfaces: "Device" and "Device.Statistics". Note that the order of the PropertiesChanged in our D-Bus API is not defined so that later signals can reach the receiver before earlier signals. Also, multiple change signals for one property may be combined. That is not changed by this patch and is not considered a bug, but something that our D-Bus API wrt. PropertiesChanged does not guarantee. https://bugzilla.gnome.org/show_bug.cgi?id=770629
* device: don't let external changes cause a release of the slaveLubomir Rintel2016-08-311-1/+6
| | | | | | | | | At this point we don't know if the slave has been using an assumed connection that just vanished -- the best bet is to let the device be. If it's meant to be unenslaved, it won't be due to an external event. https://bugzilla.redhat.com/show_bug.cgi?id=1357738
* build/trival: remove misleading code comment in NetworkManager.verThomas Haller2016-08-311-5/+1
| | | | https://bugzilla.gnome.org/show_bug.cgi?id=770515
* team: merge branch 'bg/team-config-validation'Beniamino Galvani2016-08-3011-20/+124
|\ | | | | | | Restore the validation on team and team port configuration.
| * libnm: restore verify() comments in team/team-port settingsBeniamino Galvani2016-08-302-0/+6
| | | | | | | | | | Restore the comments removed in commit a524091966afb884cdb8db48067d5599a685a8eb.
| * team: normalize invalid configuration during loadBeniamino Galvani2016-08-308-3/+118
| | | | | | | | | | | | | | | | Now that we validate the JSON syntax of a team/team-port configuration, any existing connection with invalid JSON configuration would fail to load and disappear upon upgrade. Instead, modify the setting plugins to emit a warning but still load the connection with empty configuration.
| * Revert "libnm-core/team: normalize invalid config to NULL"Beniamino Galvani2016-08-303-23/+6
|/ | | | | | | It's better to fail the validation of any invalid configuration instead of silently ignoring it. This reverts commit 476810c29016d569ac3885542a6c91e7af8a7f6d.
* device: forget unmanaged-flag "user-explicit" for unrealized devicesThomas Haller2016-08-301-13/+15
| | | | | | | | | | | | | When a software device unrealizes, we want to forget about the "user-explict" unmanaged state. It means, that after a software device is deleted, the "user-explict" managed flag will be cleared for that device. It might be nice to preserve the managed-state after deletion of the device. However, the unrealized-device only exists as long as we have a connection for the device. That means, before this patch whether the unmanaged flag was forgotten depends on whether the user had some connections that keep the device alive as unrealized. That behavior was complicated, just don't do that.
* platform: fix return value for error case in do_change_link_request()Thomas Haller2016-08-301-2/+2
| | | | | | | | There is a "goto retry" in do_change_link_request(), at that point, seq_result has the value -EOPNOTSUPP, instead of WAIT_FOR_NL_RESPONSE_RESULT_UNKNOWN. Fixes: 02fb3eff481f79d3caa67fdde20b2ae7aa5e640b
* platform: fix buildLubomir Rintel2016-08-301-2/+2
| | | | Fixes: 471521ca84187cd32afcd20aebe5a369fe7368dc
* doc: clearify deprecated "cloned-mac-address" field in documentationThomas Haller2016-08-302-3/+10
|
* device: merge branch 'th/platform-set-address-enfile-bgo770456-v2'Thomas Haller2016-08-301-3/+25
|\ | | | | | | https://bugzilla.gnome.org/show_bug.cgi?id=770456
| * device: add hack to wait after changing MAC addressth/platform-set-address-enfile-bgo770456-v2Thomas Haller2016-08-291-3/+25
| | | | | | | | | | | | | | | | | | | | | | It seems some drivers return success for nm_platform_link_set_address(), but at that point the address did not yet actually change *sigh*. It changes a bit later, possibly after setting the device up. Add a workaround to retry reading the MAC address when platform indicates success but the address still differs at first. https://bugzilla.gnome.org/show_bug.cgi?id=770456
| * device: fix spelling in loggingThomas Haller2016-08-291-1/+1
|/
* platform: merge branch 'th/platform-set-address-enfile-bgo770456'Thomas Haller2016-08-291-9/+53
|\ | | | | | | https://bugzilla.gnome.org/show_bug.cgi?id=770456
| * platform: workaround kernel wrongly returning ENFILE when changing MAC addressThomas Haller2016-08-291-1/+26
| | | | | | | | https://bugzilla.gnome.org/show_bug.cgi?id=770456
| * platform: split processing result from do_change_link()Thomas Haller2016-08-291-8/+27
|/
* platform/tests: avoid test failure setting bridge forward_delayThomas Haller2016-08-281-4/+4
| | | | | | | | Seems odd numbers may be coerced to the next-smaller even number. Avoid that by using an even number for the test, as the number has no particular meaning. https://bugzilla.gnome.org/show_bug.cgi?id=765835
* build: export _IO_stdin_used symbol in NetworkManager.verMichael Biebl2016-08-281-0/+10
| | | | | | | | | | This symbol is required to decide which version of certain IO functions to use on various architectures. So we can't strip away the symbol from the NetworkManager binary as this will lead to segfaults on those architectures. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=835550 https://bugzilla.gnome.org/show_bug.cgi?id=770515
* settings: remove wrong comment about selinux labelingBeniamino Galvani2016-08-261-3/+0
| | | | | The code does the right thing as g_file_set_contents() will create the temporary file using the label set by setfscreatecon().
* man: NetworkManager.conf: fix link syntaxBeniamino Galvani2016-08-261-1/+1
| | | | Fixes: c7cee12189d8fe64bc9037d5b9daaf1c887e0466
* po: update Ukrainian (uk) translation (bgo#770447)Yuri Chornoivan2016-08-261-1575/+1793
| | | | https://bugzilla.gnome.org/show_bug.cgi?id=770447
* all: fix typos in documentation and translated stringsYuri Chornoivan2016-08-263-3/+3
| | | | https://bugzilla.gnome.org/show_bug.cgi?id=770445
* man: fix reference in NetworkManager.confThomas Haller2016-08-261-1/+1
| | | | | | | | | | Without this, it reads: See the section called “Sections” for details. but there are multiple sections called “Sections” and it should explicitly refer to the one from the other top-level section. With this change, it reads: See “Sections” under the section called “CONNECTION SECTION” for details.
* ifcfg-rh: merge branch 'th/ifcfg-rh-read-team-rh1367180'Thomas Haller2016-08-268-42/+62
|\ | | | | | | https://bugzilla.redhat.com/show_bug.cgi?id=1367180
| * ifcfg-rh: accept TEAM connections also without DEVICETYPE settingThomas Haller2016-08-267-30/+51
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Allow omitting DEVICETYPE=Team or DEVICETYPE=TeamPort and accept team connections based on the presence of TEAM_CONFIG/TEAM_MASTER alone. Also, check first for a team slave before checking for bond slave. That is what initscripts do and matters if somebody wrongly sets MASTER and TEAM_MASTER. libteam: https://github.com/jpirko/libteam/commit/20d45a1e026c27f4ec37383d4bb2c446a2744c02 initscripts: https://git.fedorahosted.org/cgit/initscripts.git/commit/?id=3235be4a3da91bc91c698b318935240dbdf81aac https://bugzilla.redhat.com/show_bug.cgi?id=1367180
| * ifcfg-rh: make out_unhandled argument non-optionalThomas Haller2016-08-263-12/+11
|/ | | | | | | | | | Depending on the connection we are about to read, we would assert that the user provided a @out_unhandled argument. That means, the user must always provide a valid @out_unhandled pointer, because he cannot know beforehand how the reading of the ifcfg file goes.
* ifcfg-rh: clear IP settings for slave connectionsThomas Haller2016-08-264-67/+72
| | | | | | | | | | | | Clear some IP related entries from the ifcfg-rh file if the connection is a slave connection. Also, drop utils_ignore_ip_config(). It is guaranteed, that writer only handles connections that verify(). Such connections have an IPv4/IPv6 setting if (and only if) they are not slave types. https://bugzilla.redhat.com/show_bug.cgi?id=1368761
* platform: silence error reading sysctl for non existing deviceThomas Haller2016-08-251-0/+1
| | | | https://bugzilla.gnome.org/show_bug.cgi?id=770378
* release: bump version to 1.5.1-dev after 1.4.0 release1.5.1-devThomas Haller2016-08-254-4/+33
|\ | | | | | | | | | | | | | | | | | | | | | | | | After 1.4.0 is released, merge it back into master so that 1.4.0 is part of the history of master. That means, $ git log --first-parent master will also traverse 1.4.0 and 1.4.0-rc1. Also, the closest branch parent of master and nm-1-4 branch becomes 1.4.0 tag. Also bump the micro version to 1.5.1-dev to indicate that this is after 1.4.0 is out, otherwise `git describe` uses the 1.4.0 tag.
| * dhcp/systemd: honor timeout for DHCPv6Beniamino Galvani2016-08-241-0/+2
| | | | | | | | https://bugzilla.gnome.org/show_bug.cgi?id=770329
| * cli: only connect handlers for property changes in interactive editLubomir Rintel2016-08-242-3/+8
| | | | | | | | Fixes: c5324ed285aff7d6d58212e4b030a0fc556eb43b
| * cli: default to method=manual when adding an addressLubomir Rintel2016-08-241-2/+43
| | | | | | | | | | | | | | This restores accidentally changed behavior for "nmcli c add ... ip[46] <address>" Fixes: c5324ed285aff7d6d58212e4b030a0fc556eb43b
| * team: merge branch 'th/team-invalid-config-rh1366300'Thomas Haller2016-08-244-12/+66
| |\ | | | | | | | | | https://bugzilla.redhat.com/show_bug.cgi?id=1366300
| | * libnm-core/team: normalize invalid config to NULLThomas Haller2016-08-243-6/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | A user may very well have connections on disk with bogus json. Such connections may have failed to activate before, but rejecting them now as invalid means that we stop loading them from disk. That is, they disappear after upgrade. Instead of doing that, also accept invalid json (beside "") and normalize/coerce it to NULL. https://bugzilla.redhat.com/show_bug.cgi?id=1366300
| | * libnm-core/team: treat "" team config as no configLubomir Rintel2016-08-243-11/+48
| | | | | | | | | | | | https://bugzilla.redhat.com/show_bug.cgi?id=1366300
View Lorry Controller Status