Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix(nm): "unmanaged", "unknown" and "disabled" interface status handling inside NMSettingsConverter #4785

Merged
merged 10 commits into from
Jul 27, 2023

Conversation

mattdibi
Copy link
Contributor

@mattdibi mattdibi commented Jul 25, 2023

Warning
Wait #4786 before merging to avoid merge conflicts on that PR

This PR fixes two issues related to the net.interface.%s.config.ip4.status and net.interface.%s.config.ip6.status.

Unmanaged handling

The first one concerns a wrong behaviour that was encoded in the unit tests: in the buildSettings tests, when the interface is set as Unmanaged we still check for the settings to be sent to NetworkManager. This is wrong at the design level. When the device is set as Unmanaged none of the buildSettings 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 the Unmanaged property.

To prevent similar issues, in addition to updating the tests, I added an exception for when the buildSettings methods are called with an Unmanaged interface.

Disabled handling

Due to the fact that, until now, ip6.status was always set to Disabled or Unmanaged 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 corresponding ipvX.method as disabled.

This PR adds a simple check inside the buildIp4Settings and buildIp6Settings methods so that when the corresponding ip is disabled they will set the correct NetworkManager property.

Unknown handling

Similarly to what happened to the Unmanaged status we're not correctly handling the Unknown status in the buildSettings. Again, this is due to the fact that buildSettings assumes the statuses it sees were already checked by the NMDbusConnector. 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 an Unknown status.

@mattdibi mattdibi changed the title fix(nm): "unmanaged" and "disabled" interface status handling fix(nm): "unmanaged", "unknown" and "disabled" interface status handling Jul 26, 2023
@mattdibi mattdibi changed the title fix(nm): "unmanaged", "unknown" and "disabled" interface status handling fix(nm): "unmanaged", "unknown" and "disabled" interface status handling inside NMSettingsConverter Jul 26, 2023
@mattdibi mattdibi marked this pull request as ready for review July 26, 2023 16:28
@mattdibi
Copy link
Contributor Author

@sfiorani please take a look at this

@MMaiero MMaiero merged commit 1c58f65 into eclipse-kura:develop Jul 27, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants