Disable unsupported IPv4/IPv6 methods for wireguard#19337
Disable unsupported IPv4/IPv6 methods for wireguard#19337martinpitt merged 2 commits intocockpit-project:mainfrom
Conversation
pkg/networkmanager/ip-settings.jsx
Outdated
| const unsupported_ipv6_method_values = ['auto', 'dhcp', 'shared']; | ||
| ipv4_method_choices = ipv4_method_choices.filter(item => !unsupported_ipv4_method_values.includes(item.choice)); | ||
| ipv6_method_choices = ipv6_method_choices.filter(item => !unsupported_ipv6_method_values.includes(item.choice)); | ||
| } |
There was a problem hiding this comment.
Changing constants on runtime which are exported feels very brittle.
There was a problem hiding this comment.
Can these be turned into a function ipv4_method_choices(device_type)?
There was a problem hiding this comment.
Using a function indeed sounds better, thanks! I see that the IPv4 methods are a subset of the IPv6 methods:
export let ipv4_method_choices =
[
{ choice: 'auto', title: _("Automatic (DHCP)") },
{ choice: 'link-local', title: _("Link local") },
{ choice: 'manual', title: _("Manual") },
{ choice: 'shared', title: _("Shared") },
{ choice: 'disabled', title: _("Disabled") }
];
export let ipv6_method_choices =
[
{ choice: 'auto', title: _("Automatic") },
{ choice: 'dhcp', title: _("Automatic (DHCP only)") },
{ choice: 'link-local', title: _("Link local") },
{ choice: 'manual', title: _("Manual") },
{ choice: 'ignore', title: _("Ignore") },
{ choice: 'shared', title: _("Shared") },
{ choice: 'disabled', title: _("Disabled") }
];Only difference is "auto" translates to "Automatic (DHCP)" is IPv4 and to just "Automatic" in IPv6. The value "auto" in both IPv4/6 seems to be exactly the same. From NM doc:
NMSettingIP4Config and NMSettingIP6Config both support "disabled", "auto", "manual", and "link-local"...
If we use the same text for "auto" in both IPv4/IPv6, we can also merge the list into one while we're at it...
There was a problem hiding this comment.
yeah, let's use "Automatic (DHCP)" for both, that'll reduce confusion and i18n overhead. Then you can even have a single function with an "ipv6?" flag argument.
There was a problem hiding this comment.
Sorry, I think that was bad advice. "Auto" for IPv6 is often not DHCP, but SLAAC, or possibly some other methods. That's why it has a separate "dhcp" mode. So we may be able to do it the other way around and name both "Automatic", but when in doubt, let's just leave them as-is?
There was a problem hiding this comment.
Thanks for the feedback @martinpitt! I did some research into this and it indeed looks like "auto" in IPv6 doesn't mean DHCP. TIL.
In case of IPv6 it says here:
If "auto" is specified then the appropriate automatic method (PPP, router advertisement, etc) is used for the device
Similar mentioned here as well, which looks like part of a documentation, but I can't find the rendered version.
I also looked into IPv4, and it says:
Enables automatic IPv4 address assignment from DHCP, PPP, or similar services.
So, IPv4 "auto" is more than just DHCP it seems, then your second suggestion of dropping (DHCP) from IPv4, might be the right way to go.
WDYT?
There was a problem hiding this comment.
I think "DHCP" is a very familiar term and will reassure people that they are getting what they think they are getting. But if it is only correct for certain types of interfaces, I don't mind dropping it.
b5762c9 to
8a33e34
Compare
|
This needs a pixel update... |
ffb83c6 to
b536a0c
Compare
martinpitt
left a comment
There was a problem hiding this comment.
Thanks! This looks very reasonable to me now. Strictly speaking, the pixel update should be on the first commit (which drops the "(DHCP)" from the name), not the second one. But if that's too much hassle to rebase, don't worry.
This removes duplicates and reduce i18n overhead. Also drop (DHCP) from IPv4 option "Automtic (DHCP)" in the process. Adjust tests accordingly.
NM only supports a subset of IPv4/IPv6 methods for wireguard, hide them from the UI altogether, instead of showing an error when they are selected.
b536a0c to
b99c29c
Compare
|
Moved the pixel update to the proper commit. Thanks for pointing it out @martinpitt. The tests are green (s390x is still going though). Some flakes I encountered today that might be of interest :) |
|
Thanks @subhoghoshX The metrics pixel failure has been a long-standing one; @mvollmer already brooded over it for a long time, and there's still some vestiges. Thanks for the firewall links, I add them to my list of flakes to look into. |
Follow-up from #19024