summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
* fixup! device: detect duplicate IPv4 addresses when method=manualbg/ipv4-dad-rh1259063Thomas Haller2016-01-131-2/+4
| | | | | | | | | | | | Taking an additional reference is potentially harmful, because it means that a pending DAD keeps NMDevice alive. That brings up issues with the lifetime and the signal-handler. There are at least three solutions (which all have downsides): - register arping_data->device with g_object_add_weak_pointer(). - disconnect the signal when cleaning up the arping_manager. - ensure we don't take an addtional reference and add a code comment about that.
* fixup! device: detect duplicate IPv4 addresses when method=manualThomas Haller2016-01-131-2/+2
|
* fixup! device: detect duplicate IPv4 addresses when method=manualBeniamino Galvani2016-01-131-23/+9
|
* fixup! core: add NMArpingManagerBeniamino Galvani2016-01-132-34/+7
|
* fixup! core: add test for NMArpingManagerBeniamino Galvani2016-01-131-7/+6
|
* fixup! device: detect duplicate IPv4 addresses when method=manualBeniamino Galvani2016-01-121-2/+16
|
* device: detect duplicate IPv4 addresses when method=autoBeniamino Galvani2016-01-121-3/+28
|
* fixup! device: detect duplicate IPv4 addresses when method=manualThomas Haller2016-01-121-1/+1
|
* fixup! device: detect duplicate IPv4 addresses when method=manualThomas Haller2016-01-121-4/+6
|
* fixup! device: detect duplicate IPv4 addresses when method=manualThomas Haller2016-01-121-5/+2
| | | | Leaked the list
* fixup! device: detect duplicate IPv4 addresses when method=manualThomas Haller2016-01-121-8/+5
| | | | | | | Ensure that the arping manager is also reset by using nm_arping_manager_free(). Also, dispose() must clear the dangling pointer arping.announce.
* device: detect duplicate IPv4 addresses when method=manualBeniamino Galvani2016-01-122-76/+248
|
* fixup! core: add test for NMArpingManagerThomas Haller2016-01-121-10/+2
|
* core: add test for NMArpingManagerBeniamino Galvani2016-01-122-2/+165
|
* fixup! core: add NMArpingManagerThomas Haller2016-01-121-2/+1
| | | | | | | The AddressInfo item is stored in priv->addresses, and thus has a smaller lifetime then the NMArpingManager. No need to take an additional reference -- actually it could be bad because it extends the lifetime of the instance.
* fixup! core: add NMArpingManagerThomas Haller2016-01-121-2/+2
| | | | Use slice allocator.
* fixup! core: add NMArpingManagerThomas Haller2016-01-122-0/+16
|
* core: add NMArpingManagerBeniamino Galvani2016-01-124-0/+512
| | | | | | | Add a new object which implements the logic for announcing IP addresses and detecting duplicates using arping. Based-on-patch-by: Jiří Klimeš <jklimes@redhat.com>
* cli: add support for new ipv4.dad-timeout propertyJiří Klimeš2016-01-121-1/+31
|
* ifcfg-rh: read/write ipv4.dad-timeout using ARPING_WAITJiří Klimeš2016-01-123-3/+29
| | | | ARPING_WAIT is used for DAD by Red Hat initscrips (ifup-eth).
* libnm: add NMSettingIPConfig 'dad-timeout' propertyJiří Klimeš2016-01-124-0/+52
| | | | | | | | | The property is used to control duplicate address detection: * -1 means default value * 0 means no DAD is performed * > 0 means timeout (in milliseconds) for arping responses [bgalvani: moved setting from NMSettingIP4Config]
* core: merge branch 'bg/vlan-hwaddr-ipv6-rh1286105'Beniamino Galvani2016-01-123-33/+71
|\ | | | | | | https://bugzilla.redhat.com/show_bug.cgi?id=1286105
| * device/vlan: reapply IPv6 configuration after MAC changeBeniamino Galvani2016-01-121-0/+6
| | | | | | | | https://bugzilla.redhat.com/show_bug.cgi?id=1286105
| * device: export nm_device_reactivate_ip{4,6}_config functionsBeniamino Galvani2016-01-122-33/+65
|/ | | | | nm_device_reactivate_ip6_config() will be used to reconfigure IPv6 addressing when a VLAN interface changes MAC.
* libnm: add versioning comments and macros to nm_device_reapply*()Beniamino Galvani2016-01-122-1/+9
| | | | Fixes: 278fd4fb0fde3f290e366dab91fb6a49f9ff186c
* libnm: keep symbols sorted in libnm.verBeniamino Galvani2016-01-121-6/+6
|
* trivial: fix whitespaceThomas Haller2016-01-111-4/+4
|
* core/device: merge branch 'th/device-realize-bgo760450'Thomas Haller2016-01-1122-278/+220
|\ | | | | | | https://bugzilla.gnome.org/show_bug.cgi?id=760450
| * device: refactor virtual function NMDevice:unrealize_notify() to only clear ↵Thomas Haller2016-01-116-24/+23
| | | | | | | | | | | | | | properties Change the meaning of unrealize_notify() similar to realize_start_notify(), which only resets device properites during unrealize.
| * device/trivial: rename virtual function NMDevice:unrealize() to ↵Thomas Haller2016-01-116-18/+18
| | | | | | | | unrealize_notify()
| * device: pass NMPlatformLink instance as const pointerThomas Haller2016-01-1121-22/+22
| |
| * device/trivial: rename realize/setup function in NMDeviceThomas Haller2016-01-113-19/+19
| |
| * device: remove unused virtual function NMDevice:realize()Thomas Haller2016-01-112-27/+0
| | | | | | | | | | | | | | | | | | | | | | | | The idea of NMDevice:realize() was to (1) update the device properties (2) fail realization if some critical properties are missing (1) is already done during nm_device_setup_start(). (2) was only implemented by NMDeviceVlan:realize(), but it basically was just checking whether such a platform device exists. Other implementations don't do that either and it opens up for a race when the device gets deleted externally.
| * device/vlan: refactor handling platform properties for NMDeviceVlanThomas Haller2016-01-111-75/+69
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Extract a function update_properties() similar to other device implementations. It reads the device specific data from platform and raises property-changed notifications. update_properties() is now called by realize_start_notify(). NMDeviceVlan:realize() -- which previously implemented something like update_properties() -- now does nothing. Note that previously realize() might have failed, but this is different from other device implementations and it was unclear what a failure really meant. Ok, it might fail because the link was not found in the platform cache. But other implementations don't check that either, so why vlan? And how to handle that properly anyway? Therefore realize()'s implementation is no longer needed because nm_device_realize() already calls realize_start_setup(), which calls realize_start_notify() and update_properties(). update_connection() no longer refreshes the device properties. Instead it only modifies the passed-in NMConnection. It's a bit ugly that update_connection() uses both cached properties from NMDeviceVlan (vlan_id) and platform properties (xgress maps). Also, update_connection() doesn't return early on error but continues trying to update the NMConnection. The reason is that update_connection() cannot return a failure status.
| * device/vlan: remove unreachable code from realize()Thomas Haller2016-01-111-7/+1
| | | | | | | | plnk->id is unsigned. It cannot be negative.
| * device: remove unneeded implementations of realize()Thomas Haller2016-01-114-35/+0
| | | | | | | | | | | | | | | | The virtual function NMDevice:realize() is only called by nm_device_realize() and immediately followed by nm_device_setup_start(). Devices already overwrite setup_start_notify() to update their properties. No need to duplicate that in realize().
| * device: move implementation of NMDevice:setup_start() to realize_start_setup()Thomas Haller2016-01-1110-45/+62
| | | | | | | | | | | | | | All implementations of NMDevice:setup_start() in derived classes invoke the parent implementation first. Enforce that by moving NMDevice:setup_start() to realize_start_setup() and only notify derived classes afterwards via NMDevice:realize_start_notify().
| * device: remove unused virtual function NMDevice:setup_finish()Thomas Haller2016-01-112-22/+13
| |
| * device: add realize_start_setup() functionThomas Haller2016-01-111-2/+11
| | | | | | | | | | Don't call the virtual function directly. Instead add a wrapper function.
| * trivial: fix whitespaceThomas Haller2016-01-112-8/+8
|/
* merge: branch 'lr/reapply'Lubomir Rintel2016-01-1010-40/+637
|\ | | | | | | https://bugzilla.gnome.org/show_bug.cgi?id=758463
| * device: refactor reapply_connection()lr/reapplyThomas Haller2016-01-102-237/+195
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Reapplying a connection should not be done by iterating over and (unsorted) @diffs array. Instead the order matters! E.g. first layer 2 before IP settings. Thus extracting those individual updates on a per-setting base to different reapply_*() functions is more complicated, albeit incorrect in complex cases. We need full control over how to reapply changes, one after the other. Also, once we start applying changes, we cannot really abort on error. We can only continue best-effort and hope for the best. Also, always reapply certain settings, even if the configuration doesn't change. That means, if the user externally deletes a static IP address, he can call reapply() to restore it. Even though he doesn't provide a different setting to apply. Also revert the changes to nm_device_reapply_settings_immediately(). Effectively there is little code that can be reused. Add audit logging.
| * audit: allow passing GDBusMethodInvocation context to audit methodsThomas Haller2016-01-102-16/+28
| |
| * device: apply the firewall zone and metered state on Reapply()Lubomir Rintel2016-01-101-30/+63
| | | | | | | | Reuse some code with the immediate reapply mechanism.
| * device: add possibility to reapply the ipv6 settingsLubomir Rintel2016-01-101-0/+53
| |
| * device: add possibility to reapply the ipv4 settingsLubomir Rintel2016-01-101-10/+66
| |
| * cli: add nmcli d reapplyLubomir Rintel2016-01-103-3/+138
| | | | | | | | Client support for O.FD.NM.Device.Reapply().
| * libnm: add nm_device_reapply()Lubomir Rintel2016-01-103-0/+140
| | | | | | | | Client support for O.FD.NM.Device.Reapply().
| * device: add O.FD.NM.Device.Reapply() callLubomir Rintel2016-01-102-0/+191
| | | | | | | | | | The introspection data and daemon stub. There's no settings that can be reapplied at the moment.
| * device: refactor the ip cleanupLubomir Rintel2016-01-101-21/+40
|/ | | | | Split it up and move upwards. It will be useful for runtime reconfig of IPv4 configuration.
View Lorry Controller Status