fix(nm): "unmanaged", "unknown" and "disabled" interface status handling inside NMSettingsConverter #4785
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR fixes two issues related to the
net.interface.%s.config.ip4.status
andnet.interface.%s.config.ip6.status
.Unmanaged
handlingThe first one concerns a wrong behaviour that was encoded in the unit tests: in the
buildSettings
tests, when the interface is set asUnmanaged
we still check for the settings to be sent to NetworkManager. This is wrong at the design level. When the device is set asUnmanaged
none of thebuildSettings
method should be called because we shouldn't set anything. If we do we would overwrite what the user set and thus lose the meaning of theUnmanaged
property.To prevent similar issues, in addition to updating the tests, I added an exception for when the
buildSettings
methods are called with anUnmanaged
interface.Disabled
handlingDue to the fact that, until now,
ip6.status
was always set toDisabled
orUnmanaged
we did not take into account the case in which one ip version is enabled and one disabled. Therefore we collapsed the concept of interface disabled with ipv4 disabled. In reality, when only one ip version is disabled, the interface is enabled we just need to set the correspondingipvX.method
as disabled.This PR adds a simple check inside the
buildIp4Settings
andbuildIp6Settings
methods so that when the corresponding ip is disabled they will set the correct NetworkManager property.Unknown
handlingSimilarly to what happened to the
Unmanaged
status we're not correctly handling theUnknown
status in thebuildSettings
. Again, this is due to the fact thatbuildSettings
assumes the statuses it sees were already checked by theNMDbusConnector
. Unfortunately in the tests these assumptions are violeted and there are some curious behaviour.See: https://github.com/eclipse/kura/blob/1acc7838278e6dbe430bc9d6d70cfb00bcbf2059/kura/test/org.eclipse.kura.nm.test/src/test/java/org/eclipse/kura/nm/configuration/NMSettingsConverterTest.java#L745
netIPv4StatusManagedLan
is not correct, but the tests works anyway.To prevent similar issues, in addition to updating the tests, I added an exception for when the
buildSettings
methods are called with anUnknown
status.