[Touch-packages] [Bug 1977619] Re: NetworkManager 1.36.6 no longer prefers DHCPv6 addresses over SLAAC
It's fixed upstream as well now: https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/commit/6920b6ceb1c2e7856ad76e118ee5b4dd36130735 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1977619 Title: NetworkManager 1.36.6 no longer prefers DHCPv6 addresses over SLAAC Status in NetworkManager: New Status in network-manager package in Ubuntu: Fix Released Status in network-manager source package in Jammy: Fix Committed Bug description: * Impact The recent SRU created a regression in IPv6 routing order * Test Case 1. Connect to a network where the router sends "A" and "M" bits in the RA's and has a DHCPv6 server running (e.g. any OpenWrt router). 2. When running `ip -6 a`, the list now sorts SLAAC addresses above DHCPv6 addresses. With NetworkManager 1.36.4 and earlier, this was not the case. (The Linux kernel uses the address highest in the list as preferred.) 3. When running something like `curl ifconfig.co`, the SLAAC address is being returned, which makes sense as that is now preferred by the kernel. (But it shouldn't be.) Desired behaviour: NetworkManager should always sort DHCPv6 addresses above SLAAC addresses, as is the case for all versions prior to 1.36.6 and also corrected again in 1.38.0. In case static addresses are manually set, those should take first priority, with DHCPv6 second and SLAAC/autoconf last. * Regression potential The patch change the IPv6 addresses order to match the behaviour from the previous version. If that was buggy the routing order would still be wrong, so we should check that IPv6 setups behave as expected. --- Situation: My network has both DHCPv6 and SLAAC (autoconf) for IPv6. From a privacy perspective, for readability reasons and for network management policies, DHCPv6 should *always* be preferred over SLAAC addresses when available. And according to RFC 6724, the smaller /128 scope of the DHCPv6 address should be chosen over the larger /64 scope of the SLAAC address. NetworkManager has always been able to adhere to that by simply setting ip6.privacy=0 for the connection (in nm-connection-editor *not* selecting "Prefer temporary address" for IPv6 privacy extensions). Then it would use the DHCPv6 address as the source for all outgoing traffic. So if you would - for instance - run `curl ifconfig.co`, the DHCPv6 address would be used to connect to the outside world and be echoed back. Regression: Since the update to 1.36.6, this is no longer the case. NetworkManager now routes outgoing traffic through the SLAAC address, even if ip6.privacy=0 is set for the connection. Constantly removing the SLAAC addresses with `ip addr del` or disabling SLAAC RA's on the router are now the only ways to stop NetworkManager from preferring SLAAC over DHCPv6. None of the local options in NetworkManager 1.36.6 are able to restore the previous, desired and correct way of working: the SLAAC address should never be used as the preferred address if a DHCPv6 lease is given. Looking at the changelog of NetworkManager 1.36.6, multiple things regarding IP address order and temporary addresses have been changed in that release, any of them (or a combination) introducing this bug: * Fix a bug in synchronization of IP addresses with kernel that could lead to a wrong address order. * Ignore addresses from DHCPv6 when the Otherconf router advertisement flag is set. * Ensure temporary IPv6 addresses are removed on disconnect and reapply. https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/blob/nm-1-36/NEWS Steps to reproduce: 1. Connect to a network where the router sends "A" and "M" bits in the RA's and has a DHCPv6 server running (e.g. any OpenWrt router). 2. When running `ip -6 a`, the list now sorts SLAAC addresses above DHCPv6 addresses. With NetworkManager 1.36.4 and earlier, this was not the case. (The Linux kernel uses the address highest in the list as preferred.) 3. When running something like `curl ifconfig.co`, the SLAAC address is being returned, which makes sense as that is now preferred by the kernel. (But it shouldn't be.) Desired behaviour: NetworkManager should always sort DHCPv6 addresses above SLAAC addresses, as is the case for all versions prior to 1.36.6 and also corrected again in 1.38.0. In case static addresses are manually set, those should take first priority, with DHCPv6 second and SLAAC/autoconf last. Implications: This can break many real-life use cases. For instance, my router gives out static leases to my machines. Those addresses are whitelisted in all kinds of firewalls to allow me to access servers for my work. Now that the "wrong" address is being preferred for outgoing traffic (a SLAAC address
[Touch-packages] [Bug 1977619] Re: NetworkManager 1.36.6 no longer prefers DHCPv6 addresses over SLAAC
kevin@arcadia:~$ apt info network-manager Package: network-manager Version: 1.36.6-0ubuntu2 kevin@arcadia:~$ apt info libnm0 Package: libnm0 Version: 1.36.6-0ubuntu2 I have installed network-manager and libnm0 version 1.36.6-0ubuntu2 from jammy-proposed. After connecting to a network with both SLAAC and DHCPv6 enabled, the DHCPv6 address was selected as the source address again, like it was in version 1.36.4, prior to the update introducing this bug. This restores the original and desired behaviour. ** Tags removed: verification-needed verification-needed-jammy ** Tags added: verification-done-jammy -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1977619 Title: NetworkManager 1.36.6 no longer prefers DHCPv6 addresses over SLAAC Status in NetworkManager: New Status in network-manager package in Ubuntu: Fix Released Status in network-manager source package in Jammy: Fix Committed Bug description: * Impact The recent SRU created a regression in IPv6 routing order * Test Case 1. Connect to a network where the router sends "A" and "M" bits in the RA's and has a DHCPv6 server running (e.g. any OpenWrt router). 2. When running `ip -6 a`, the list now sorts SLAAC addresses above DHCPv6 addresses. With NetworkManager 1.36.4 and earlier, this was not the case. (The Linux kernel uses the address highest in the list as preferred.) 3. When running something like `curl ifconfig.co`, the SLAAC address is being returned, which makes sense as that is now preferred by the kernel. (But it shouldn't be.) Desired behaviour: NetworkManager should always sort DHCPv6 addresses above SLAAC addresses, as is the case for all versions prior to 1.36.6 and also corrected again in 1.38.0. In case static addresses are manually set, those should take first priority, with DHCPv6 second and SLAAC/autoconf last. * Regression potential The patch change the IPv6 addresses order to match the behaviour from the previous version. If that was buggy the routing order would still be wrong, so we should check that IPv6 setups behave as expected. --- Situation: My network has both DHCPv6 and SLAAC (autoconf) for IPv6. From a privacy perspective, for readability reasons and for network management policies, DHCPv6 should *always* be preferred over SLAAC addresses when available. And according to RFC 6724, the smaller /128 scope of the DHCPv6 address should be chosen over the larger /64 scope of the SLAAC address. NetworkManager has always been able to adhere to that by simply setting ip6.privacy=0 for the connection (in nm-connection-editor *not* selecting "Prefer temporary address" for IPv6 privacy extensions). Then it would use the DHCPv6 address as the source for all outgoing traffic. So if you would - for instance - run `curl ifconfig.co`, the DHCPv6 address would be used to connect to the outside world and be echoed back. Regression: Since the update to 1.36.6, this is no longer the case. NetworkManager now routes outgoing traffic through the SLAAC address, even if ip6.privacy=0 is set for the connection. Constantly removing the SLAAC addresses with `ip addr del` or disabling SLAAC RA's on the router are now the only ways to stop NetworkManager from preferring SLAAC over DHCPv6. None of the local options in NetworkManager 1.36.6 are able to restore the previous, desired and correct way of working: the SLAAC address should never be used as the preferred address if a DHCPv6 lease is given. Looking at the changelog of NetworkManager 1.36.6, multiple things regarding IP address order and temporary addresses have been changed in that release, any of them (or a combination) introducing this bug: * Fix a bug in synchronization of IP addresses with kernel that could lead to a wrong address order. * Ignore addresses from DHCPv6 when the Otherconf router advertisement flag is set. * Ensure temporary IPv6 addresses are removed on disconnect and reapply. https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/blob/nm-1-36/NEWS Steps to reproduce: 1. Connect to a network where the router sends "A" and "M" bits in the RA's and has a DHCPv6 server running (e.g. any OpenWrt router). 2. When running `ip -6 a`, the list now sorts SLAAC addresses above DHCPv6 addresses. With NetworkManager 1.36.4 and earlier, this was not the case. (The Linux kernel uses the address highest in the list as preferred.) 3. When running something like `curl ifconfig.co`, the SLAAC address is being returned, which makes sense as that is now preferred by the kernel. (But it shouldn't be.) Desired behaviour: NetworkManager should always sort DHCPv6 addresses above SLAAC addresses, as is the case for all versions prior to 1.36.6 and also corr
[Touch-packages] [Bug 1977619] Re: NetworkManager 1.36.6 no longer prefers DHCPv6 addresses over SLAAC
This seems to restore previous behaviour yes. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1977619 Title: NetworkManager 1.36.6 no longer prefers DHCPv6 addresses over SLAAC Status in NetworkManager: New Status in network-manager package in Ubuntu: In Progress Bug description: Situation: My network has both DHCPv6 and SLAAC (autoconf) for IPv6. From a privacy perspective, for readability reasons and for network management policies, DHCPv6 should *always* be preferred over SLAAC addresses when available. And according to RFC 6724, the smaller /128 scope of the DHCPv6 address should be chosen over the larger /64 scope of the SLAAC address. NetworkManager has always been able to adhere to that by simply setting ip6.privacy=0 for the connection (in nm-connection-editor *not* selecting "Prefer temporary address" for IPv6 privacy extensions). Then it would use the DHCPv6 address as the source for all outgoing traffic. So if you would - for instance - run `curl ifconfig.co`, the DHCPv6 address would be used to connect to the outside world and be echoed back. Regression: Since the update to 1.36.6, this is no longer the case. NetworkManager now routes outgoing traffic through the SLAAC address, even if ip6.privacy=0 is set for the connection. Constantly removing the SLAAC addresses with `ip addr del` or disabling SLAAC RA's on the router are now the only ways to stop NetworkManager from preferring SLAAC over DHCPv6. None of the local options in NetworkManager 1.36.6 are able to restore the previous, desired and correct way of working: the SLAAC address should never be used as the preferred address if a DHCPv6 lease is given. Looking at the changelog of NetworkManager 1.36.6, multiple things regarding IP address order and temporary addresses have been changed in that release, any of them (or a combination) introducing this bug: * Fix a bug in synchronization of IP addresses with kernel that could lead to a wrong address order. * Ignore addresses from DHCPv6 when the Otherconf router advertisement flag is set. * Ensure temporary IPv6 addresses are removed on disconnect and reapply. https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/blob/nm-1-36/NEWS Steps to reproduce: 1. Connect to a network where the router sends "A" and "M" bits in the RA's and has a DHCPv6 server running (e.g. any OpenWrt router). 2. When running `ip -6 a`, the list now sorts SLAAC addresses above DHCPv6 addresses. With NetworkManager 1.36.4 and earlier, this was not the case. (The Linux kernel uses the address highest in the list as preferred.) 3. When running something like `curl ifconfig.co`, the SLAAC address is being returned, which makes sense as that is now preferred by the kernel. (But it shouldn't be.) Desired behaviour: NetworkManager should always sort DHCPv6 addresses above SLAAC addresses, as is the case for all versions prior to 1.36.6 and also corrected again in 1.38.0. In case static addresses are manually set, those should take first priority, with DHCPv6 second and SLAAC/autoconf last. Implications: This can break many real-life use cases. For instance, my router gives out static leases to my machines. Those addresses are whitelisted in all kinds of firewalls to allow me to access servers for my work. Now that the "wrong" address is being preferred for outgoing traffic (a SLAAC address that I have no influence on and cannot centrally configure), I am being locked out of the servers in question unless I forcefully remove the addresses or disable SLAAC on my router, so my outgoing traffic is being routed through the DHCPv6 address again. Note that "just disabling SLAAC RA's on the router" is not something everybody can do, as it requires root access to the device. Moreover, it would break IPv6 connectivity entirely for devices that don't support DHCPv6 (read: Android). Conclusion: So this update introduces a very breaking change in IPv6 source address selection to an LTS release, while LTS releases should be stable. I should note that the bug is not present in NetworkManager 1.38.0 on Debian sid. That just prefers DHCPv6 addresses when available, like it should. As that version is also used in Ubuntu kinetic, most likely this bug is not present there. Looking at the changelog of 1.38.0: * Fix bug setting priority for IP addresses. * Static IPv6 addresses from "ipv6.addresses" are now preferred over addresses from DHCPv6, which are preferred over addresses from autoconf. This affects IPv6 source address selection, if the rules from RFC 6724, section 5 don't give a exhaustive match. https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/blob/nm-1-38/NEWS It looks like Ubuntu just introduced tha
[Touch-packages] [Bug 1977619] Re: NetworkManager 1.36.6 no longer prefers DHCPv6 addresses over SLAAC
Unfortunately I was not tracking jammy-proposed, so I only found out about this bug when it entered jammy-updates. I don't think my configuration is that exotic to be honest. Many companies use DHCPv6 servers giving out static leases, and many companies use firewalls to restrict incoming (SSH) connections to their servers. And not many network administrators disable SLAAC as that would break IPv6 for all Android users. So corporate and home networks with DHCPv6 and SLAAC enabled are quite common. How viable would it be to create something like 1.36.7~really1.36.4 or something like that, which would be the previous version with only commit 6a82dd18 cherry picked to fix the hotspot issue and not introduce the source address selection bug? I suppose upstream would at some point release 1.36.9, which will hopefully have this bug fixed, and also have commit 6a82dd18 included, so Ubuntu can go back to the upstream version then. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1977619 Title: NetworkManager 1.36.6 no longer prefers DHCPv6 addresses over SLAAC Status in NetworkManager: New Status in network-manager package in Ubuntu: Triaged Bug description: Situation: My network has both DHCPv6 and SLAAC (autoconf) for IPv6. From a privacy perspective, for readability reasons and for network management policies, DHCPv6 should *always* be preferred over SLAAC addresses when available. And according to RFC 6724, the smaller /128 scope of the DHCPv6 address should be chosen over the larger /64 scope of the SLAAC address. NetworkManager has always been able to adhere to that by simply setting ip6.privacy=0 for the connection (in nm-connection-editor *not* selecting "Prefer temporary address" for IPv6 privacy extensions). Then it would use the DHCPv6 address as the source for all outgoing traffic. So if you would - for instance - run `curl ifconfig.co`, the DHCPv6 address would be used to connect to the outside world and be echoed back. Regression: Since the update to 1.36.6, this is no longer the case. NetworkManager now routes outgoing traffic through the SLAAC address, even if ip6.privacy=0 is set for the connection. Constantly removing the SLAAC addresses with `ip addr del` or disabling SLAAC RA's on the router are now the only ways to stop NetworkManager from preferring SLAAC over DHCPv6. None of the local options in NetworkManager 1.36.6 are able to restore the previous, desired and correct way of working: the SLAAC address should never be used as the preferred address if a DHCPv6 lease is given. Looking at the changelog of NetworkManager 1.36.6, multiple things regarding IP address order and temporary addresses have been changed in that release, any of them (or a combination) introducing this bug: * Fix a bug in synchronization of IP addresses with kernel that could lead to a wrong address order. * Ignore addresses from DHCPv6 when the Otherconf router advertisement flag is set. * Ensure temporary IPv6 addresses are removed on disconnect and reapply. https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/blob/nm-1-36/NEWS Steps to reproduce: 1. Connect to a network where the router sends "A" and "M" bits in the RA's and has a DHCPv6 server running (e.g. any OpenWrt router). 2. When running `ip -6 a`, the list now sorts SLAAC addresses above DHCPv6 addresses. With NetworkManager 1.36.4 and earlier, this was not the case. (The Linux kernel uses the address highest in the list as preferred.) 3. When running something like `curl ifconfig.co`, the SLAAC address is being returned, which makes sense as that is now preferred by the kernel. (But it shouldn't be.) Desired behaviour: NetworkManager should always sort DHCPv6 addresses above SLAAC addresses, as is the case for all versions prior to 1.36.6 and also corrected again in 1.38.0. In case static addresses are manually set, those should take first priority, with DHCPv6 second and SLAAC/autoconf last. Implications: This can break many real-life use cases. For instance, my router gives out static leases to my machines. Those addresses are whitelisted in all kinds of firewalls to allow me to access servers for my work. Now that the "wrong" address is being preferred for outgoing traffic (a SLAAC address that I have no influence on and cannot centrally configure), I am being locked out of the servers in question unless I forcefully remove the addresses or disable SLAAC on my router, so my outgoing traffic is being routed through the DHCPv6 address again. Note that "just disabling SLAAC RA's on the router" is not something everybody can do, as it requires root access to the device. Moreover, it would break IPv6 connectivity entirely for devices that don't support DHCPv6 (read: Andro
[Touch-packages] [Bug 1977619] Re: NetworkManager 1.36.6 no longer prefers DHCPv6 addresses over SLAAC
@seb128 What is the plan for the network-manager package in Ubuntu jammy-updates? Is it to be left broken until upstream fixes this bug? Because I think that the problem this last version introduces is a lot bigger than the problem(s) it solves. Therefore I would say that it can be defended to upload a new version that restores 1.36.4-2ubuntu1 for the time being, and then re-sync with upstream when (or if) this bug is fixed. As far as I'm aware, the update from 1.36.4 to 1.36.6 did not close any outstanding Launchpad bugs, so it didn't fix anything from Ubuntu's perspective. It just introduced this regression. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1977619 Title: NetworkManager 1.36.6 no longer prefers DHCPv6 addresses over SLAAC Status in NetworkManager: New Status in network-manager package in Ubuntu: Triaged Bug description: Situation: My network has both DHCPv6 and SLAAC (autoconf) for IPv6. From a privacy perspective, for readability reasons and for network management policies, DHCPv6 should *always* be preferred over SLAAC addresses when available. And according to RFC 6724, the smaller /128 scope of the DHCPv6 address should be chosen over the larger /64 scope of the SLAAC address. NetworkManager has always been able to adhere to that by simply setting ip6.privacy=0 for the connection (in nm-connection-editor *not* selecting "Prefer temporary address" for IPv6 privacy extensions). Then it would use the DHCPv6 address as the source for all outgoing traffic. So if you would - for instance - run `curl ifconfig.co`, the DHCPv6 address would be used to connect to the outside world and be echoed back. Regression: Since the update to 1.36.6, this is no longer the case. NetworkManager now routes outgoing traffic through the SLAAC address, even if ip6.privacy=0 is set for the connection. Constantly removing the SLAAC addresses with `ip addr del` or disabling SLAAC RA's on the router are now the only ways to stop NetworkManager from preferring SLAAC over DHCPv6. None of the local options in NetworkManager 1.36.6 are able to restore the previous, desired and correct way of working: the SLAAC address should never be used as the preferred address if a DHCPv6 lease is given. Looking at the changelog of NetworkManager 1.36.6, multiple things regarding IP address order and temporary addresses have been changed in that release, any of them (or a combination) introducing this bug: * Fix a bug in synchronization of IP addresses with kernel that could lead to a wrong address order. * Ignore addresses from DHCPv6 when the Otherconf router advertisement flag is set. * Ensure temporary IPv6 addresses are removed on disconnect and reapply. https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/blob/nm-1-36/NEWS Steps to reproduce: 1. Connect to a network where the router sends "A" and "M" bits in the RA's and has a DHCPv6 server running (e.g. any OpenWrt router). 2. When running `ip -6 a`, the list now sorts SLAAC addresses above DHCPv6 addresses. With NetworkManager 1.36.4 and earlier, this was not the case. (The Linux kernel uses the address highest in the list as preferred.) 3. When running something like `curl ifconfig.co`, the SLAAC address is being returned, which makes sense as that is now preferred by the kernel. (But it shouldn't be.) Desired behaviour: NetworkManager should always sort DHCPv6 addresses above SLAAC addresses, as is the case for all versions prior to 1.36.6 and also corrected again in 1.38.0. In case static addresses are manually set, those should take first priority, with DHCPv6 second and SLAAC/autoconf last. Implications: This can break many real-life use cases. For instance, my router gives out static leases to my machines. Those addresses are whitelisted in all kinds of firewalls to allow me to access servers for my work. Now that the "wrong" address is being preferred for outgoing traffic (a SLAAC address that I have no influence on and cannot centrally configure), I am being locked out of the servers in question unless I forcefully remove the addresses or disable SLAAC on my router, so my outgoing traffic is being routed through the DHCPv6 address again. Note that "just disabling SLAAC RA's on the router" is not something everybody can do, as it requires root access to the device. Moreover, it would break IPv6 connectivity entirely for devices that don't support DHCPv6 (read: Android). Conclusion: So this update introduces a very breaking change in IPv6 source address selection to an LTS release, while LTS releases should be stable. I should note that the bug is not present in NetworkManager 1.38.0 on Debian sid. That just prefers DHCPv6 addresses when available, like it should
[Touch-packages] [Bug 1977619] Re: NetworkManager 1.36.6 no longer prefers DHCPv6 addresses over SLAAC
** Summary changed: - NetworkManager 1.36.6 orders IPv6 addresses incorrectly + NetworkManager 1.36.6 no longer prefers DHCPv6 addresses over SLAAC -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1977619 Title: NetworkManager 1.36.6 no longer prefers DHCPv6 addresses over SLAAC Status in network-manager package in Ubuntu: Confirmed Bug description: Situation: My network has both DHCPv6 and SLAAC (autoconf) for IPv6. From a privacy perspective, for readability reasons and for network management policies, DHCPv6 should *always* be preferred over SLAAC addresses when available. And according to RFC 6724, the smaller /128 scope of the DHCPv6 address should be chosen over the larger /64 scope of the SLAAC address. NetworkManager has always been able to adhere to that by simply setting ip6.privacy=0 for the connection (in nm-connection-editor *not* selecting "Prefer temporary address" for IPv6 privacy extensions). Then it would use the DHCPv6 address as the source for all outgoing traffic. So if you would - for instance - run `curl ifconfig.co`, the DHCPv6 address would be used to connect to the outside world and be echoed back. Regression: Since the update to 1.36.6, this is no longer the case. NetworkManager now routes outgoing traffic through the SLAAC address, even if ip6.privacy=0 is set for the connection. Constantly removing the SLAAC addresses with `ip addr del` or disabling SLAAC RA's on the router are now the only ways to stop NetworkManager from preferring SLAAC over DHCPv6. None of the local options in NetworkManager 1.36.6 are able to restore the previous, desired and correct way of working: the SLAAC address should never be used as the preferred address if a DHCPv6 lease is given. Looking at the changelog of NetworkManager 1.36.6, multiple things regarding IP address order and temporary addresses have been changed in that release, any of them (or a combination) introducing this bug: * Fix a bug in synchronization of IP addresses with kernel that could lead to a wrong address order. * Ignore addresses from DHCPv6 when the Otherconf router advertisement flag is set. * Ensure temporary IPv6 addresses are removed on disconnect and reapply. https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/blob/nm-1-36/NEWS Steps to reproduce: 1. Connect to a network where the router sends "A" and "M" bits in the RA's and has a DHCPv6 server running (e.g. any OpenWrt router). 2. When running `ip -6 a`, the list now sorts SLAAC addresses above DHCPv6 addresses. With NetworkManager 1.36.4 and earlier, this was not the case. (The Linux kernel uses the address highest in the list as preferred.) 3. When running something like `curl ifconfig.co`, the SLAAC address is being returned, which makes sense as that is now preferred by the kernel. (But it shouldn't be.) Desired behaviour: NetworkManager should always sort DHCPv6 addresses above SLAAC addresses, as is the case for all versions prior to 1.36.6 and also corrected again in 1.38.0. In case static addresses are manually set, those should take first priority, with DHCPv6 second and SLAAC/autoconf last. Implications: This can break many real-life use cases. For instance, my router gives out static leases to my machines. Those addresses are whitelisted in all kinds of firewalls to allow me to access servers for my work. Now that the "wrong" address is being preferred for outgoing traffic (a SLAAC address that I have no influence on and cannot centrally configure), I am being locked out of the servers in question unless I forcefully remove the addresses or disable SLAAC on my router, so my outgoing traffic is being routed through the DHCPv6 address again. Note that "just disabling SLAAC RA's on the router" is not something everybody can do, as it requires root access to the device. Moreover, it would break IPv6 connectivity entirely for devices that don't support DHCPv6 (read: Android). Conclusion: So this update introduces a very breaking change in IPv6 source address selection to an LTS release, while LTS releases should be stable. I should note that the bug is not present in NetworkManager 1.38.0 on Debian sid. That just prefers DHCPv6 addresses when available, like it should. As that version is also used in Ubuntu kinetic, most likely this bug is not present there. Looking at the changelog of 1.38.0: * Fix bug setting priority for IP addresses. * Static IPv6 addresses from "ipv6.addresses" are now preferred over addresses from DHCPv6, which are preferred over addresses from autoconf. This affects IPv6 source address selection, if the rules from RFC 6724, section 5 don't give a exhaustive match. https://gitlab.freedesktop.org/NetworkManager/NetworkMa
[Touch-packages] [Bug 1977619] Re: NetworkManager 1.36.6 orders IPv6 addresses incorrectly
** Description changed: Situation: - My network has both DHCPv6 and SLAAC for IPv6. From a privacy + My network has both DHCPv6 and SLAAC (autoconf) for IPv6. From a privacy perspective, for readability reasons and for network management policies, DHCPv6 should *always* be preferred over SLAAC addresses when available. And according to RFC 6724, the smaller /128 scope of the DHCPv6 address should be chosen over the larger /64 scope of the SLAAC address. NetworkManager has always been able to adhere to that by simply setting ip6.privacy=0 for the connection (in nm-connection-editor *not* selecting "Prefer temporary address" for IPv6 privacy extensions). Then it would use the DHCPv6 address as the source for all outgoing traffic. So if you would - for instance - run `curl ifconfig.co`, the DHCPv6 address would be used to connect to the outside world and be echoed back. Regression: Since the update to 1.36.6, this is no longer the case. NetworkManager now routes outgoing traffic through the SLAAC address, even if ip6.privacy=0 is set for the connection. Constantly removing the SLAAC addresses with `ip addr del` or disabling SLAAC RA's on the router are now the only ways to stop NetworkManager from preferring SLAAC over DHCPv6. None of the local options in NetworkManager 1.36.6 are able to restore the previous, desired and correct way of working: the SLAAC address should never be used as the preferred address if a DHCPv6 lease is given. Looking at the changelog of NetworkManager 1.36.6, multiple things regarding IP address order and temporary addresses have been changed in that release: * Fix a bug in synchronization of IP addresses with kernel that could lead to a wrong address order. * Ignore addresses from DHCPv6 when the Otherconf router advertisement flag is set. * Ensure temporary IPv6 addresses are removed on disconnect and reapply. https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/blob/nm-1-36/NEWS Steps to reproduce: 1. Connect to a network where the router sends "A" and "M" bits in the RA's and has a DHCPv6 server running (e.g. any OpenWrt router). 2. When running `ip -6 a`, the list now sorts SLAAC addresses above DHCPv6 addresses. With NetworkManager 1.36.4 and earlier, this was not the case. (The Linux kernel uses the address highest in the list as preferred.) 3. When running something like `curl ifconfig.co`, the SLAAC address is being returned, which makes sense as that is now preferred by the kernel. (But it shouldn't be.) Desired behaviour: NetworkManager should always sort DHCPv6 addresses above SLAAC addresses, as is the case for all versions prior to 1.36.6 and also corrected again in 1.38.0. In case static addresses are manually set, - those should take first priority, with DHCPv6 second and SLAAC last. + those should take first priority, with DHCPv6 second and SLAAC/autoconf + last. Implications: This can break many real-life use cases. For instance, my router gives out static leases to my machines. Those addresses are whitelisted in all kinds of firewalls to allow me to access servers for my work. Now that the "wrong" address is being preferred for outgoing traffic (a SLAAC address that I have no influence on and cannot centrally configure), I am being locked out of the servers in question unless I forcefully remove the addresses or disable SLAAC on my router, so my outgoing traffic is being routed through the DHCPv6 address again. Note that "just disabling SLAAC RA's on the router" is not something everybody can do, as it requires root access to the device. Moreover, it would break IPv6 connectivity entirely for devices that don't support DHCPv6 (read: Android). Conclusion: So this update introduces a very breaking change in IPv6 source address selection to an LTS release, while LTS releases should be stable. I should note that the bug is not present in NetworkManager 1.38.0 on Debian sid. That just prefers DHCPv6 addresses when available, like it should. As that version is also used in Ubuntu kinetic, most likely this bug is not present there. Looking at the changelog of 1.38.0: * Fix bug setting priority for IP addresses. * Static IPv6 addresses from "ipv6.addresses" are now preferred over addresses from DHCPv6, which are preferred over addresses from autoconf. This affects IPv6 source address selection, if the rules from RFC 6724, section 5 don't give a exhaustive match. https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/blob/nm-1-38/NEWS It looks like Ubuntu just introduced that bug by upgrading to 1.36.6. Please either backport the fix from 1.38.0 or revert to 1.36.4, which was working fine. System information: /etc/os-release: PRETTY_NAME="Ubuntu 22.04 LTS" NAME="Ubuntu" VERSION_ID="22.04" VERSION="22.04 LTS (Jammy
[Touch-packages] [Bug 1977619] Re: NetworkManager 1.36.6 orders IPv6 addresses incorrectly
** Description changed: Situation: My network has both DHCPv6 and SLAAC for IPv6. From a privacy perspective, for readability reasons and for network management policies, DHCPv6 should *always* be preferred over SLAAC addresses when available. And according to RFC 6724, the smaller /128 scope of the DHCPv6 address should be chosen over the larger /64 scope of the SLAAC address. NetworkManager has always been able to adhere to that by simply setting ip6.privacy=0 for the connection (in nm-connection-editor *not* selecting "Prefer temporary address" for IPv6 privacy extensions). Then it would use the DHCPv6 address as the source for all outgoing traffic. So if you would - for instance - run `curl ifconfig.co`, the DHCPv6 address would be used to connect to the outside world and be echoed back. - Regression: Since the update to 1.36.6, this is no longer the case. NetworkManager now routes outgoing traffic through the SLAAC address, even if ip6.privacy=0 is set for the connection. Setting net.ipv6.conf.all.use_tempaddr=0 and net.ipv6.conf..use_tempaddr=0 with sysctl also no longer has any effect. Removing the SLAAC addresses with `ip addr del` or disabling SLAAC RA's on the router is the only way to stop NetworkManager from preferring SLAAC over DHCPv6 now. None of the local options in NetworkManager 1.36.6 are able to restore the previous, desired and correct way of working. Looking at the changelog of NetworkManager 1.36.6, multiple things regarding IP address order and temporary addresses have been changed in that release: * Fix a bug in synchronization of IP addresses with kernel that could lead to a wrong address order. * Ignore addresses from DHCPv6 when the Otherconf router advertisement flag is set. * Ensure temporary IPv6 addresses are removed on disconnect and reapply. https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/blob/nm-1-36/NEWS - Steps to reproduce: 1. Connect to a network where the router sends "A" and "M" bits in the RA's and has a DHCPv6 server running (e.g. any OpenWrt router). 2. When running `ip -6 a`, the list now sorts SLAAC addresses above DHCPv6 addresses. With NetworkManager 1.36.4 and earlier, this was not the case. (The Linux kernel uses the address highest in the list as preferred.) 3. When running something like `curl ifconfig.co`, the SLAAC address is being returned, which makes sense as that is now preferred by the kernel. (But it shouldn't be.) - Desired behaviour: NetworkManager should always sort DHCPv6 addresses above SLAAC addresses, as is the case for all versions prior to 1.36.6 and also corrected again in 1.38.0. In case static addresses are manually set, those should take first priority, with DHCPv6 second and SLAAC last. - Implications: This can break many real-life use cases. For instance, my router gives out static leases to my machines. Those addresses are whitelisted in all kinds of firewalls to allow me to access servers for my work. Now that the "wrong" address is being preferred for outgoing traffic (a SLAAC address that I have no influence on and cannot centrally configure), I am being locked out of the servers in question unless I forcefully remove the addresses or disable SLAAC on my router, so my outgoing traffic is being routed through the DHCPv6 address again. + Note that "just disabling SLAAC RA's on the router" is not something + everybody can do, as it requires root access to the device. Moreover, it + would break IPv6 connectivity entirely for devices that don't support + DHCPv6 (read: Android). Conclusion: So this update introduces a very breaking change in IPv6 source address selection to an LTS release, while LTS releases should be stable. I should note that the bug is not present in NetworkManager 1.38.0 on Debian sid. That just prefers DHCPv6 addresses when available, like it should. As that version is also used in Ubuntu kinetic, most likely this bug is not present there. Looking at the changelog of 1.38.0: * Fix bug setting priority for IP addresses. * Static IPv6 addresses from "ipv6.addresses" are now preferred over addresses from DHCPv6, which are preferred over addresses from autoconf. This affects IPv6 source address selection, if the rules from RFC 6724, section 5 don't give a exhaustive match. https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/blob/nm-1-38/NEWS So it looks like Ubuntu just introduced that bug by upgrading to 1.36.6. Please either backport the fix from 1.38.0 or revert to 1.36.4, which was working fine. - System information: /etc/os-release: PRETTY_NAME="Ubuntu 22.04 LTS" NAME="Ubuntu" VERSION_ID="22.04" VERSION="22.04 LTS (Jammy Jellyfish)" VERSION_CODENAME=jammy ID=ubuntu ID_LIKE=debian HOME_URL="https://www.ubuntu.com/"; SUPPORT_URL="ht
[Touch-packages] [Bug 1977619] Re: NetworkManager 1.36.6 orders IPv6 addresses incorrectly
** Description changed: - My network has both DHCPv6 and SLAAC for IPv6. From both a privacy - perspective and readability reasons, DHCPv6 should *always* be preferred - over SLAAC addresses when available. And according to RFC 6724 the - smaller /128 scope of the DHCPv6 address should be chosen over the - larger /64 scope of the SLAAC address. + Situation: + + My network has both DHCPv6 and SLAAC for IPv6. From a privacy + perspective, for readability reasons and for network management + policies, DHCPv6 should *always* be preferred over SLAAC addresses when + available. And according to RFC 6724, the smaller /128 scope of the + DHCPv6 address should be chosen over the larger /64 scope of the SLAAC + address. NetworkManager has always been able to adhere to that by simply setting ip6.privacy=0 for the connection (in nm-connection-editor *not* selecting "Prefer temporary address" for IPv6 privacy extensions). Then it would use the DHCPv6 address as the source for all outgoing traffic. So if you would - for instance - run `curl ifconfig.co`, the DHCPv6 address would be used to connect to the outside world and be echoed back. + + Regression: + Since the update to 1.36.6, this is no longer the case. NetworkManager now routes outgoing traffic through the SLAAC address, even if ip6.privacy=0 is set for the connection. Setting net.ipv6.conf.all.use_tempaddr=0 and net.ipv6.conf..use_tempaddr=0 with sysctl also no longer has any effect. Removing the SLAAC addresses with `ip addr del` or disabling SLAAC RA's - altogether is the only way to stop NetworkManager from preferring SLAAC - over DHCPv6 now. + on the router is the only way to stop NetworkManager from preferring + SLAAC over DHCPv6 now. None of the local options in NetworkManager + 1.36.6 are able to restore the previous, desired and correct way of + working. - Looking at the changelog of NetworkManager 1.36.6, things regarding IP - address order and temporary addresses have been changed in that release: + Looking at the changelog of NetworkManager 1.36.6, multiple things + regarding IP address order and temporary addresses have been changed in + that release: * Fix a bug in synchronization of IP addresses with kernel that could lead to a wrong address order. * Ignore addresses from DHCPv6 when the Otherconf router advertisement flag is set. * Ensure temporary IPv6 addresses are removed on disconnect and reapply. https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/blob/nm-1-36/NEWS - When running `ip -6 a`, the list now sorts SLAAC addresses above DHCPv6 - addresses. With NetworkManager 1.36.4 this was not the case. (The Linux - kernel uses the address highest in the list as preferred.) + + Steps to reproduce: + + 1. Connect to a network where the router sends "A" and "M" bits in the + RA's and has a DHCPv6 server running (e.g. any OpenWrt router). + + 2. When running `ip -6 a`, the list now sorts SLAAC addresses above + DHCPv6 addresses. With NetworkManager 1.36.4 and earlier, this was not + the case. (The Linux kernel uses the address highest in the list as + preferred.) + + 3. When running something like `curl ifconfig.co`, the SLAAC address is + being returned, which makes sense as that is now preferred by the + kernel. (But it shouldn't be.) + + + Desired behaviour: + + NetworkManager should always sort DHCPv6 addresses above SLAAC + addresses, as is the case for all versions prior to 1.36.6 and also + corrected again in 1.38.0. In case static addresses are manually set, + those should take first priority, with DHCPv6 second and SLAAC last. + + + Implications: This can break many real-life use cases. For instance, my router gives out static leases to my machines. Those addresses are whitelisted in all kinds of firewalls to allow me to access servers for my work. Now that the "wrong" address is being preferred for outgoing traffic (a SLAAC - address that I have no influence on), I am being locked out of the - servers in question unless I forcefully remove the addresses or disable - SLAAC on my router, so my outgoing traffic is being routed through the - DHCPv6 address again. + address that I have no influence on and cannot centrally configure), I + am being locked out of the servers in question unless I forcefully + remove the addresses or disable SLAAC on my router, so my outgoing + traffic is being routed through the DHCPv6 address again. + + + Conclusion: So this update introduces a very breaking change in IPv6 source address selection to an LTS release, while LTS releases should be stable. I should note that the bug is not present in NetworkManager 1.38.0 on Debian sid. That just prefers DHCPv6 addresses when available, like it - should. + should. As that version is also used in Ubuntu kinetic, most likely this + bug is not present there. + + Looking at the changelog of 1.38.0: + + * Fix bug setting priority for IP addresses. + * Static
[Touch-packages] [Bug 1977619] Re: NetworkManager 1.36.6 orders IPv6 addresses incorrectly
** Description changed: My network has both DHCPv6 and SLAAC for IPv6. From both a privacy perspective and readability reasons, DHCPv6 should *always* be preferred over SLAAC addresses when available. And according to RFC 6724 the smaller /128 scope of the DHCPv6 address should be chosen over the larger /64 scope of the SLAAC address. NetworkManager has always been able to adhere to that by simply setting ip6.privacy=0 for the connection (in nm-connection-editor *not* selecting "Prefer temporary address" for IPv6 privacy extensions). Then it would use the DHCPv6 address as the source for all outgoing traffic. So if you would - for instance - run `curl ifconfig.co`, the DHCPv6 address would be used to connect to the outside world and be echoed back. Since the update to 1.36.6, this is no longer the case. NetworkManager now routes outgoing traffic through the SLAAC address, even if ip6.privacy=0 is set for the connection. Setting net.ipv6.conf.all.use_tempaddr=0 and net.ipv6.conf..use_tempaddr=0 with sysctl also no longer has any effect. Removing the SLAAC addresses with `ip addr del` or disabling SLAAC RA's altogether is the only way to stop NetworkManager from preferring SLAAC over DHCPv6 now. Looking at the changelog of NetworkManager 1.36.6, things regarding IP address order and temporary addresses have been changed in that release: + + * Fix a bug in synchronization of IP addresses with kernel that could lead to a wrong address order. + * Ignore addresses from DHCPv6 when the Otherconf router advertisement flag is set. + * Ensure temporary IPv6 addresses are removed on disconnect and reapply. + https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/blob/nm-1-36/NEWS When running `ip -6 a`, the list now sorts SLAAC addresses above DHCPv6 addresses. With NetworkManager 1.36.4 this was not the case. (The Linux kernel uses the address highest in the list as preferred.) This can break many real-life use cases. For instance, my router gives out static leases to my machines. Those addresses are whitelisted in all kinds of firewalls to allow me to access servers for my work. Now that the "wrong" address is being preferred for outgoing traffic (a SLAAC address that I have no influence on), I am being locked out of the servers in question unless I forcefully remove the addresses or disable SLAAC on my router, so my outgoing traffic is being routed through the DHCPv6 address again. So this update introduces a very breaking change in IPv6 source address selection to an LTS release, while LTS releases should be stable. I should note that the bug is not present in NetworkManager 1.38.0 on Debian sid. That just prefers DHCPv6 addresses when available, like it should. /etc/os-release: PRETTY_NAME="Ubuntu 22.04 LTS" NAME="Ubuntu" VERSION_ID="22.04" VERSION="22.04 LTS (Jammy Jellyfish)" VERSION_CODENAME=jammy ID=ubuntu ID_LIKE=debian HOME_URL="https://www.ubuntu.com/"; SUPPORT_URL="https://help.ubuntu.com/"; BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"; PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"; UBUNTU_CODENAME=jammy nmcli -v: nmcli tool, version 1.36.6 Looking at the changelog of 1.38.0: * Fix bug setting priority for IP addresses. * Static IPv6 addresses from "ipv6.addresses" are now preferred over addresses from DHCPv6, which are preferred over addresses from autoconf. This affects IPv6 source address selection, if the rules from RFC 6724, section 5 don't give a exhaustive match. https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/blob/nm-1-38/NEWS So it looks like Ubuntu just introduced that bug by upgrading to 1.36.6. Please either backport the fix from 1.38.0 or revert to 1.36.4, which was working fine. More background here: https://bugs.launchpad.net/ubuntu/+source/network- manager/+bug/1974428/comments/11 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1977619 Title: NetworkManager 1.36.6 orders IPv6 addresses incorrectly Status in network-manager package in Ubuntu: Confirmed Bug description: My network has both DHCPv6 and SLAAC for IPv6. From both a privacy perspective and readability reasons, DHCPv6 should *always* be preferred over SLAAC addresses when available. And according to RFC 6724 the smaller /128 scope of the DHCPv6 address should be chosen over the larger /64 scope of the SLAAC address. NetworkManager has always been able to adhere to that by simply setting ip6.privacy=0 for the connection (in nm-connection-editor *not* selecting "Prefer temporary address" for IPv6 privacy extensions). Then it would use the DHCPv6 address as the source for all outgoing traffic. So if you would - for i
[Touch-packages] [Bug 1977619] Re: NetworkManager 1.36.6 orders IPv6 addresses incorrectly
** Description changed: My network has both DHCPv6 and SLAAC for IPv6. From both a privacy perspective and readability reasons, DHCPv6 should *always* be preferred - over SLAAC addresses when available. + over SLAAC addresses when available. And according to RFC 6724 the + smaller /128 scope of the DHCPv6 address should be chosen over the + larger /64 scope of the SLAAC address. NetworkManager has always been able to adhere to that by simply setting - ip6.privacy=0 for the connection. Then it would not generate temporary - addresses and use the DHCPv6 address as the source for outgoing traffic. + ip6.privacy=0 for the connection (in nm-connection-editor called "Prefer + temporary address"). Then it would use the DHCPv6 address as the source + for all outgoing traffic. So if you would - for instance - run `curl ifconfig.co`, the DHCPv6 address would be used to connect to the outside world and be echoed back. Since the update to 1.36.6, this is no longer the case. NetworkManager now routes outgoing traffic through the SLAAC address, even if ip6.privacy=0 is set for the connection. Setting net.ipv6.conf.all.use_tempaddr=0 and net.ipv6.conf..use_tempaddr=0 with sysctl also no longer has any effect. Removing the SLAAC addresses with `ip addr del` or disabling SLAAC RA's altogether is the only way to stop NetworkManager from preferring SLAAC over DHCPv6 now. Looking at the changelog of NetworkManager 1.36.6, things regarding IP address order and temporary addresses have been changed in that release: https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/blob/nm-1-36/NEWS When running `ip -6 a`, the list now sorts SLAAC addresses above DHCPv6 addresses. With NetworkManager 1.36.4 this was not the case. (The Linux kernel uses the address highest in the list as preferred.) This can break many real-life use cases. For instance, my router gives out static leases to my machines. Those addresses are whitelisted in all kinds of firewalls to allow me to access servers for my work. Now that the "wrong" address is being preferred for outgoing traffic (a SLAAC address that I have no influence on), I am being locked out of the servers in question unless I forcefully remove the addresses or disable SLAAC on my router, so my outgoing traffic is being routed through the DHCPv6 address again. So this update introduces a very breaking change in IPv6 source address selection to an LTS release, while LTS releases should be stable. I should note that the bug is not present in NetworkManager 1.38.0 on Debian sid. That just prefers DHCPv6 addresses when available, like it should. /etc/os-release: PRETTY_NAME="Ubuntu 22.04 LTS" NAME="Ubuntu" VERSION_ID="22.04" VERSION="22.04 LTS (Jammy Jellyfish)" VERSION_CODENAME=jammy ID=ubuntu ID_LIKE=debian HOME_URL="https://www.ubuntu.com/"; SUPPORT_URL="https://help.ubuntu.com/"; BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"; PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"; UBUNTU_CODENAME=jammy nmcli -v: nmcli tool, version 1.36.6 Looking at the changelog of 1.38.0: * Fix bug setting priority for IP addresses. * Static IPv6 addresses from "ipv6.addresses" are now preferred over addresses from DHCPv6, which are preferred over addresses from autoconf. This affects IPv6 source address selection, if the rules from RFC 6724, section 5 don't give a exhaustive match. https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/blob/nm-1-38/NEWS So it looks like Ubuntu just introduced that bug by upgrading to 1.36.6. Please either backport the fix from 1.38.0 or revert to 1.36.4, which was working fine. More background here: https://bugs.launchpad.net/ubuntu/+source/network- manager/+bug/1974428/comments/11 ** Description changed: My network has both DHCPv6 and SLAAC for IPv6. From both a privacy perspective and readability reasons, DHCPv6 should *always* be preferred over SLAAC addresses when available. And according to RFC 6724 the smaller /128 scope of the DHCPv6 address should be chosen over the larger /64 scope of the SLAAC address. NetworkManager has always been able to adhere to that by simply setting - ip6.privacy=0 for the connection (in nm-connection-editor called "Prefer - temporary address"). Then it would use the DHCPv6 address as the source - for all outgoing traffic. + ip6.privacy=0 for the connection (in nm-connection-editor *not* + selecting "Prefer temporary address" for IPv6 privacy extensions). Then + it would use the DHCPv6 address as the source for all outgoing traffic. So if you would - for instance - run `curl ifconfig.co`, the DHCPv6 address would be used to connect to the outside world and be echoed back. Since the update to 1.36.6, this is no longer the case. NetworkManager now routes outgoing traffic through the SLAAC
[Touch-packages] [Bug 1977619] Re: NetworkManager 1.36.6 orders IPv6 addresses incorrectly
** Description changed: My network has both DHCPv6 and SLAAC for IPv6. From both a privacy perspective and readability reasons, DHCPv6 should *always* be preferred over SLAAC addresses when available. NetworkManager has always been able to adhere to that by simply setting ip6.privacy=0 for the connection. Then it would not generate temporary addresses and use the DHCPv6 address as the source for outgoing traffic. So if you would - for instance - run `curl ifconfig.co`, the DHCPv6 address would be used to connect to the outside world and be echoed back. Since the update to 1.36.6, this is no longer the case. NetworkManager now routes outgoing traffic through the SLAAC address, even if ip6.privacy=0 is set for the connection. Setting net.ipv6.conf.all.use_tempaddr=0 and net.ipv6.conf..use_tempaddr=0 with sysctl also no longer has any effect. Removing the SLAAC addresses with `ip addr del` or disabling SLAAC RA's altogether is the only way to stop NetworkManager from preferring SLAAC over DHCPv6 now. Looking at the changelog of NetworkManager 1.36.6, things regarding IP address order and temporary addresses have been changed in that release: https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/blob/nm-1-36/NEWS When running `ip -6 a`, the list now sorts SLAAC addresses above DHCPv6 addresses. With NetworkManager 1.36.4 this was not the case. (The Linux kernel uses the address highest in the list as preferred.) This can break many real-life use cases. For instance, my router gives out static leases to my machines. Those addresses are whitelisted in all kinds of firewalls to allow me to access servers for my work. Now that the "wrong" address is being preferred for outgoing traffic (a SLAAC address that I have no influence on), I am being locked out of the servers in question unless I forcefully remove the addresses or disable SLAAC on my router, so my outgoing traffic is being routed through the DHCPv6 address again. So this update introduces a very breaking change in IPv6 source address selection to an LTS release, while LTS releases should be stable. I should note that the bug is not present in NetworkManager 1.38.0 on Debian sid. That just prefers DHCPv6 addresses when available, like it should. /etc/os-release: PRETTY_NAME="Ubuntu 22.04 LTS" NAME="Ubuntu" VERSION_ID="22.04" VERSION="22.04 LTS (Jammy Jellyfish)" VERSION_CODENAME=jammy ID=ubuntu ID_LIKE=debian HOME_URL="https://www.ubuntu.com/"; SUPPORT_URL="https://help.ubuntu.com/"; BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"; PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"; UBUNTU_CODENAME=jammy nmcli -v: nmcli tool, version 1.36.6 + + Looking at the changelog of 1.38.0: + + * Fix bug setting priority for IP addresses. + * Static IPv6 addresses from "ipv6.addresses" are now preferred over addresses from DHCPv6, which are preferred over addresses from autoconf. This affects IPv6 source address selection, if the rules from RFC 6724, section 5 don't give a exhaustive match. + + https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/blob/nm-1-38/NEWS + + So it looks like Ubuntu just introduced that bug by upgrading to 1.36.6. + Please either backport the fix from 1.38.0 or revert to 1.36.4, which + was working fine. ** Description changed: My network has both DHCPv6 and SLAAC for IPv6. From both a privacy perspective and readability reasons, DHCPv6 should *always* be preferred over SLAAC addresses when available. NetworkManager has always been able to adhere to that by simply setting ip6.privacy=0 for the connection. Then it would not generate temporary addresses and use the DHCPv6 address as the source for outgoing traffic. So if you would - for instance - run `curl ifconfig.co`, the DHCPv6 address would be used to connect to the outside world and be echoed back. Since the update to 1.36.6, this is no longer the case. NetworkManager now routes outgoing traffic through the SLAAC address, even if ip6.privacy=0 is set for the connection. Setting net.ipv6.conf.all.use_tempaddr=0 and net.ipv6.conf..use_tempaddr=0 with sysctl also no longer has any effect. Removing the SLAAC addresses with `ip addr del` or disabling SLAAC RA's altogether is the only way to stop NetworkManager from preferring SLAAC over DHCPv6 now. Looking at the changelog of NetworkManager 1.36.6, things regarding IP address order and temporary addresses have been changed in that release: https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/blob/nm-1-36/NEWS When running `ip -6 a`, the list now sorts SLAAC addresses above DHCPv6 addresses. With NetworkManager 1.36.4 this was not the case. (The Linux kernel uses the address highest in the list as preferred.) This can break many real-life use cases. For i
[Touch-packages] [Bug 1977619] Re: NetworkManager 1.36.6 orders IPv6 addresses incorrectly
** Tags added: regression-update -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1977619 Title: NetworkManager 1.36.6 orders IPv6 addresses incorrectly Status in network-manager package in Ubuntu: Confirmed Bug description: My network has both DHCPv6 and SLAAC for IPv6. From both a privacy perspective and readability reasons, DHCPv6 should *always* be preferred over SLAAC addresses when available. NetworkManager has always been able to adhere to that by simply setting ip6.privacy=0 for the connection. Then it would not generate temporary addresses and use the DHCPv6 address as the source for outgoing traffic. So if you would - for instance - run `curl ifconfig.co`, the DHCPv6 address would be used to connect to the outside world and be echoed back. Since the update to 1.36.6, this is no longer the case. NetworkManager now routes outgoing traffic through the SLAAC address, even if ip6.privacy=0 is set for the connection. Setting net.ipv6.conf.all.use_tempaddr=0 and net.ipv6.conf..use_tempaddr=0 with sysctl also no longer has any effect. Removing the SLAAC addresses with `ip addr del` or disabling SLAAC RA's altogether is the only way to stop NetworkManager from preferring SLAAC over DHCPv6 now. Looking at the changelog of NetworkManager 1.36.6, things regarding IP address order and temporary addresses have been changed in that release: https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/blob/nm-1-36/NEWS When running `ip -6 a`, the list now sorts SLAAC addresses above DHCPv6 addresses. With NetworkManager 1.36.4 this was not the case. (The Linux kernel uses the address highest in the list as preferred.) This can break many real-life use cases. For instance, my router gives out static leases to my machines. Those addresses are whitelisted in all kinds of firewalls to allow me to access servers for my work. Now that the "wrong" address is being preferred for outgoing traffic (a SLAAC address that I have no influence on), I am being locked out of the servers in question unless I forcefully remove the addresses or disable SLAAC on my router, so my outgoing traffic is being routed through the DHCPv6 address again. So this update introduces a very breaking change in IPv6 source address selection to an LTS release, while LTS releases should be stable. I should note that the bug is not present in NetworkManager 1.38.0 on Debian sid. That just prefers DHCPv6 addresses when available, like it should. /etc/os-release: PRETTY_NAME="Ubuntu 22.04 LTS" NAME="Ubuntu" VERSION_ID="22.04" VERSION="22.04 LTS (Jammy Jellyfish)" VERSION_CODENAME=jammy ID=ubuntu ID_LIKE=debian HOME_URL="https://www.ubuntu.com/"; SUPPORT_URL="https://help.ubuntu.com/"; BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"; PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"; UBUNTU_CODENAME=jammy nmcli -v: nmcli tool, version 1.36.6 Looking at the changelog of 1.38.0: * Fix bug setting priority for IP addresses. * Static IPv6 addresses from "ipv6.addresses" are now preferred over addresses from DHCPv6, which are preferred over addresses from autoconf. This affects IPv6 source address selection, if the rules from RFC 6724, section 5 don't give a exhaustive match. https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/blob/nm-1-38/NEWS So it looks like Ubuntu just introduced that bug by upgrading to 1.36.6. Please either backport the fix from 1.38.0 or revert to 1.36.4, which was working fine. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1977619/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1977619] Re: NetworkManager 1.36.6 orders IPv6 addresses incorrectly
** Description changed: My network has both DHCPv6 and SLAAC for IPv6. From both a privacy perspective and readability reasons, DHCPv6 should *always* be preferred over SLAAC addresses when available. NetworkManager has always been able to adhere to that by simply setting - ip6.privacy=0 for the connection. + ip6.privacy=0 for the connection. Then it would not generate temporary + addresses and use the DHCPv6 address as the source for outgoing traffic. So if you would - for instance - run `curl ifconfig.co`, the DHCPv6 - address would be used to connect to the outside world. + address would be used to connect to the outside world and be echoed + back. Since the update to 1.36.6, this is no longer the case. NetworkManager now routes outgoing traffic through the SLAAC address, even if ip6.privacy=0 is set for the connection. Setting net.ipv6.conf.all.use_tempaddr=0 and net.ipv6.conf..use_tempaddr=0 with sysctl also no longer has any effect. Removing the SLAAC addresses with `ip addr del` or disabling SLAAC RA's altogether is the only way to stop NetworkManager from preferring SLAAC over DHCPv6 now. Looking at the changelog of NetworkManager 1.36.6, things regarding IP address order and temporary addresses have been changed in that release: https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/blob/nm-1-36/NEWS When running `ip -6 a`, the list now sorts SLAAC addresses above DHCPv6 addresses. With NetworkManager 1.36.4 this was not the case. (The Linux kernel uses the address highest in the list as preferred.) This can break many real-life use cases. For instance, my router gives out static leases to my machines. Those addresses are whitelisted in all kinds of firewalls to allow me to access servers for my work. Now that the "wrong" address is being preferred for outgoing traffic (a SLAAC address that I have no influence on), I am being locked out of the servers in question unless I forcefully remove the addresses or disable SLAAC on my router, so my outgoing traffic is being routed through the DHCPv6 address again. So this update introduces a very breaking change in IPv6 source address selection to an LTS release, while LTS releases should be stable. I should note that the bug is not present in NetworkManager 1.38.0 on Debian sid. That just prefers DHCPv6 addresses when available, like it should. /etc/os-release: PRETTY_NAME="Ubuntu 22.04 LTS" NAME="Ubuntu" VERSION_ID="22.04" VERSION="22.04 LTS (Jammy Jellyfish)" VERSION_CODENAME=jammy ID=ubuntu ID_LIKE=debian HOME_URL="https://www.ubuntu.com/"; SUPPORT_URL="https://help.ubuntu.com/"; BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"; PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"; UBUNTU_CODENAME=jammy nmcli -v: nmcli tool, version 1.36.6 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1977619 Title: NetworkManager 1.36.6 orders IPv6 addresses incorrectly Status in network-manager package in Ubuntu: Confirmed Bug description: My network has both DHCPv6 and SLAAC for IPv6. From both a privacy perspective and readability reasons, DHCPv6 should *always* be preferred over SLAAC addresses when available. NetworkManager has always been able to adhere to that by simply setting ip6.privacy=0 for the connection. Then it would not generate temporary addresses and use the DHCPv6 address as the source for outgoing traffic. So if you would - for instance - run `curl ifconfig.co`, the DHCPv6 address would be used to connect to the outside world and be echoed back. Since the update to 1.36.6, this is no longer the case. NetworkManager now routes outgoing traffic through the SLAAC address, even if ip6.privacy=0 is set for the connection. Setting net.ipv6.conf.all.use_tempaddr=0 and net.ipv6.conf..use_tempaddr=0 with sysctl also no longer has any effect. Removing the SLAAC addresses with `ip addr del` or disabling SLAAC RA's altogether is the only way to stop NetworkManager from preferring SLAAC over DHCPv6 now. Looking at the changelog of NetworkManager 1.36.6, things regarding IP address order and temporary addresses have been changed in that release: https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/blob/nm-1-36/NEWS When running `ip -6 a`, the list now sorts SLAAC addresses above DHCPv6 addresses. With NetworkManager 1.36.4 this was not the case. (The Linux kernel uses the address highest in the list as preferred.) This can break many real-life use cases. For instance, my router gives out static leases to my machines. Those addresses are whitelisted in all kinds of firewalls to allow me to access servers for my work. Now that the "wrong" address is being preferred for out
[Touch-packages] [Bug 1974428] Re: Update to the current 1.36 stable version
@seb128 I have created a new bug report with links to the upstream commits. The core of the issue is that IPv6 addresses are now being added in the wrong order, so the kernel prefers SLAAC addresses over DHCPv6 addresses, which should be the other way around. As this is a breaking change in source-based IPv6 routing in an LTS release, I think the impact is severe. In my opinion, this update should never have reached stable, especially because this bug is known upstream and fixed in a later version. I'm already quite stressed how this will turn out at work after the weekend. We use source-based ACL's on all of our firewalls, giving static DHCPv6 leases to our client devices. Now all of a sudden those addresses are no longer being used for outgoing traffic, but instead the non-controllable SLAAC-addresses are. This will lock everyone out of all servers. The only way to get the proper addresses to be preferred again seems to be to disable SLAAC on the router, because any local setting in NetworkManager no longer works. I can disable SLAAC without issues at home, because everything is 100% Ubuntu and Debian there. But in environments with other OS'es that don't support DHCPv6 (like Android), disabling SLAAC will break IPv6 on all such devices. Moreover, not everybody controls their own routers, so this really isn't much of a solution. Other options would be to downgrade and apt-mark hold network-manager on all Ubuntu 22.04 devices, or to completely change server firewall infrastructure by whitelisting prefixes. As you can see, none of these options sound appealing. So regarding the regression potential: it has severely regressed IPv6 handling, and definitely *not* fixed things. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1974428 Title: Update to the current 1.36 stable version Status in network-manager package in Ubuntu: Fix Released Status in network-manager source package in Jammy: Fix Released Bug description: * Impact It's a stable update from upstream, the changes are listed in the NEWS https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/blob/nm-1-36/NEWS * Test Case Since it's an update with several fixes the testing should focus on a specific point but rather by validating that the testplan is green, https://wiki.ubuntu.com/NetworkManager/DistroTesting * Regression potential There are fixes around IPv6 handling, VPN connections and the hotspot feature, verify that those configurations are still working as expected. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1974428/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1977619] Re: NetworkManager 1.36.6 orders IPv6 addresses incorrectly
** Description changed: My network has both DHCPv6 and SLAAC for IPv6. From both a privacy perspective and readability reasons, DHCPv6 should *always* be preferred over SLAAC addresses when available. NetworkManager has always been able to adhere to that by simply setting ip6.privacy=0 for the connection. So if you would - for instance - run `curl ifconfig.co`, the DHCPv6 address would be used to connect to the outside world. Since the update to 1.36.6, this is no longer the case. NetworkManager now routes outgoing traffic through the SLAAC address, even if ip6.privacy=0 is set for the connection. Setting net.ipv6.conf.all.use_tempaddr=0 and net.ipv6.conf..use_tempaddr=0 with sysctl also no longer has any effect. Removing the SLAAC addresses with `ip addr del` or disabling SLAAC RA's altogether is the only way to stop NetworkManager from preferring SLAAC over DHCPv6 now. Looking at the changelog of NetworkManager 1.36.6, things regarding IP address order and temporary addresses have been changed in that release: https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/blob/nm-1-36/NEWS When running `ip -6 a`, the list now sorts SLAAC addresses above DHCPv6 addresses. With NetworkManager 1.36.4 this was not the case. (The Linux kernel uses the address highest in the list as preferred.) This can break many real-life use cases. For instance, my router gives out static leases to my machines. Those addresses are whitelisted in all kinds of firewalls to allow me to access servers for my work. Now that the "wrong" address is being preferred for outgoing traffic (a SLAAC address that I have no influence on), I am being locked out of the servers in question unless I forcefully remove the addresses or disable SLAAC on my router, so my outgoing traffic is being routed through the DHCPv6 address again. - So this update introduces a very breaking change to an LTS release, - while LTS releases should be stable. + So this update introduces a very breaking change in IPv6 source address + selection to an LTS release, while LTS releases should be stable. I should note that the bug is not present in NetworkManager 1.38.0 on Debian sid. That just prefers DHCPv6 addresses when available, like it should. /etc/os-release: PRETTY_NAME="Ubuntu 22.04 LTS" NAME="Ubuntu" VERSION_ID="22.04" VERSION="22.04 LTS (Jammy Jellyfish)" VERSION_CODENAME=jammy ID=ubuntu ID_LIKE=debian HOME_URL="https://www.ubuntu.com/"; SUPPORT_URL="https://help.ubuntu.com/"; BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"; PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"; UBUNTU_CODENAME=jammy nmcli -v: nmcli tool, version 1.36.6 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1977619 Title: NetworkManager 1.36.6 orders IPv6 addresses incorrectly Status in network-manager package in Ubuntu: New Bug description: My network has both DHCPv6 and SLAAC for IPv6. From both a privacy perspective and readability reasons, DHCPv6 should *always* be preferred over SLAAC addresses when available. NetworkManager has always been able to adhere to that by simply setting ip6.privacy=0 for the connection. So if you would - for instance - run `curl ifconfig.co`, the DHCPv6 address would be used to connect to the outside world. Since the update to 1.36.6, this is no longer the case. NetworkManager now routes outgoing traffic through the SLAAC address, even if ip6.privacy=0 is set for the connection. Setting net.ipv6.conf.all.use_tempaddr=0 and net.ipv6.conf..use_tempaddr=0 with sysctl also no longer has any effect. Removing the SLAAC addresses with `ip addr del` or disabling SLAAC RA's altogether is the only way to stop NetworkManager from preferring SLAAC over DHCPv6 now. Looking at the changelog of NetworkManager 1.36.6, things regarding IP address order and temporary addresses have been changed in that release: https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/blob/nm-1-36/NEWS When running `ip -6 a`, the list now sorts SLAAC addresses above DHCPv6 addresses. With NetworkManager 1.36.4 this was not the case. (The Linux kernel uses the address highest in the list as preferred.) This can break many real-life use cases. For instance, my router gives out static leases to my machines. Those addresses are whitelisted in all kinds of firewalls to allow me to access servers for my work. Now that the "wrong" address is being preferred for outgoing traffic (a SLAAC address that I have no influence on), I am being locked out of the servers in question unless I forcefully remove the addresses or disable SLAAC on my router, so my outgoing traffic is being routed through the DHCPv6 address ag
[Touch-packages] [Bug 1977619] Re: NetworkManager 1.36.6 orders IPv6 addresses incorrectly
** Description changed: My network has both DHCPv6 and SLAAC for IPv6. From both a privacy perspective and readability reasons, DHCPv6 should *always* be preferred over SLAAC addresses when available. NetworkManager has always been able to adhere to that by simply setting ip6.privacy=0 for the connection. So if you would - for instance - run `curl ifconfig.co`, the DHCPv6 address would be used to connect to the outside world. Since the update to 1.36.6, this is no longer the case. NetworkManager now routes outgoing traffic through the SLAAC address, even if ip6.privacy=0 is set for the connection. Setting net.ipv6.conf.all.use_tempaddr=0 and net.ipv6.conf..use_tempaddr=0 with sysctl also no longer has any effect. Removing the SLAAC addresses with `ip addr del` or disabling SLAAC RA's altogether is the only way to stop NetworkManager from preferring SLAAC over DHCPv6 now. Looking at the changelog of NetworkManager 1.36.6, things regarding IP address order and temporary addresses have been changed in that release: https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/blob/nm-1-36/NEWS When running `ip -6 a`, the list now sorts SLAAC addresses above DHCPv6 addresses. With NetworkManager 1.36.4 this was not the case. (The Linux kernel uses the address highest in the list as preferred.) This can break many real-life use cases. For instance, my router gives out static leases to my machines. Those addresses are whitelisted in all kinds of firewalls to allow me to access servers for my work. Now that the "wrong" address is being preferred for outgoing traffic (a SLAAC address that I have no influence on), I am being locked out of the servers in question unless I forcefully remove the addresses or disable SLAAC on my router, so my outgoing traffic is being routed through the DHCPv6 address again. + So this update introduces a very breaking change to an LTS release, + while LTS releases should be stable. + I should note that the bug is not present in NetworkManager 1.38.0 on Debian sid. That just prefers DHCPv6 addresses when available, like it should. /etc/os-release: PRETTY_NAME="Ubuntu 22.04 LTS" NAME="Ubuntu" VERSION_ID="22.04" VERSION="22.04 LTS (Jammy Jellyfish)" VERSION_CODENAME=jammy ID=ubuntu ID_LIKE=debian HOME_URL="https://www.ubuntu.com/"; SUPPORT_URL="https://help.ubuntu.com/"; BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"; PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"; UBUNTU_CODENAME=jammy nmcli -v: nmcli tool, version 1.36.6 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1977619 Title: NetworkManager 1.36.6 orders IPv6 addresses incorrectly Status in network-manager package in Ubuntu: New Bug description: My network has both DHCPv6 and SLAAC for IPv6. From both a privacy perspective and readability reasons, DHCPv6 should *always* be preferred over SLAAC addresses when available. NetworkManager has always been able to adhere to that by simply setting ip6.privacy=0 for the connection. So if you would - for instance - run `curl ifconfig.co`, the DHCPv6 address would be used to connect to the outside world. Since the update to 1.36.6, this is no longer the case. NetworkManager now routes outgoing traffic through the SLAAC address, even if ip6.privacy=0 is set for the connection. Setting net.ipv6.conf.all.use_tempaddr=0 and net.ipv6.conf..use_tempaddr=0 with sysctl also no longer has any effect. Removing the SLAAC addresses with `ip addr del` or disabling SLAAC RA's altogether is the only way to stop NetworkManager from preferring SLAAC over DHCPv6 now. Looking at the changelog of NetworkManager 1.36.6, things regarding IP address order and temporary addresses have been changed in that release: https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/blob/nm-1-36/NEWS When running `ip -6 a`, the list now sorts SLAAC addresses above DHCPv6 addresses. With NetworkManager 1.36.4 this was not the case. (The Linux kernel uses the address highest in the list as preferred.) This can break many real-life use cases. For instance, my router gives out static leases to my machines. Those addresses are whitelisted in all kinds of firewalls to allow me to access servers for my work. Now that the "wrong" address is being preferred for outgoing traffic (a SLAAC address that I have no influence on), I am being locked out of the servers in question unless I forcefully remove the addresses or disable SLAAC on my router, so my outgoing traffic is being routed through the DHCPv6 address again. So this update introduces a very breaking change to an LTS release, while LTS releases should be stable. I should note that the b
[Touch-packages] [Bug 1977619] Re: NetworkManager 1.36.6 orders IPv6 addresses incorrectly
** Description changed: My network has both DHCPv6 and SLAAC for IPv6. From both a privacy perspective and readability reasons, DHCPv6 should *always* be preferred over SLAAC addresses when available. NetworkManager has always been able to adhere to that by simply setting ip6.privacy=0 for the connection. So if you would - for instance - run `curl ifconfig.co`, the DHCPv6 address would be used to connect to the outside world. Since the update to 1.36.6, this is no longer the case. NetworkManager now routes outgoing traffic through the SLAAC address, even if ip6.privacy=0 is set for the connection. Setting - net.ipv6.conf.all.use_tempaddr = 0 and - net.ipv6.conf..use_tempaddr = 0 with sysctl also no longer - has any effect. + net.ipv6.conf.all.use_tempaddr=0 and + net.ipv6.conf..use_tempaddr=0 with sysctl also no longer has + any effect. - Removing the SLAAC addresses with `ip addr del` or disabling RA's + Removing the SLAAC addresses with `ip addr del` or disabling SLAAC RA's altogether is the only way to stop NetworkManager from preferring SLAAC over DHCPv6 now. Looking at the changelog of NetworkManager 1.36.6, things regarding IP address order and temporary addresses have been changed in that release: https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/blob/nm-1-36/NEWS When running `ip -6 a`, the list now sorts SLAAC addresses above DHCPv6 addresses. With NetworkManager 1.36.4 this was not the case. (The Linux kernel uses the address highest in the list as preferred.) This can break many real-life use cases. For instance, my router gives out static leases to my machines. Those addresses are whitelisted in all kinds of firewalls to allow me to access servers for my work. Now that the "wrong" address is being preferred for outgoing traffic (a SLAAC address that I have no influence on), I am being locked out of the servers in question unless I forcefully remove the addresses or disable SLAAC on my router, so my outgoing traffic is being routed through the DHCPv6 address again. I should note that the bug is not present in NetworkManager 1.38.0 on Debian sid. That just prefers DHCPv6 addresses when available, like it should. /etc/os-release: PRETTY_NAME="Ubuntu 22.04 LTS" NAME="Ubuntu" VERSION_ID="22.04" VERSION="22.04 LTS (Jammy Jellyfish)" VERSION_CODENAME=jammy ID=ubuntu ID_LIKE=debian HOME_URL="https://www.ubuntu.com/"; SUPPORT_URL="https://help.ubuntu.com/"; BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"; PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"; UBUNTU_CODENAME=jammy nmcli -v: nmcli tool, version 1.36.6 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1977619 Title: NetworkManager 1.36.6 orders IPv6 addresses incorrectly Status in network-manager package in Ubuntu: New Bug description: My network has both DHCPv6 and SLAAC for IPv6. From both a privacy perspective and readability reasons, DHCPv6 should *always* be preferred over SLAAC addresses when available. NetworkManager has always been able to adhere to that by simply setting ip6.privacy=0 for the connection. So if you would - for instance - run `curl ifconfig.co`, the DHCPv6 address would be used to connect to the outside world. Since the update to 1.36.6, this is no longer the case. NetworkManager now routes outgoing traffic through the SLAAC address, even if ip6.privacy=0 is set for the connection. Setting net.ipv6.conf.all.use_tempaddr=0 and net.ipv6.conf..use_tempaddr=0 with sysctl also no longer has any effect. Removing the SLAAC addresses with `ip addr del` or disabling SLAAC RA's altogether is the only way to stop NetworkManager from preferring SLAAC over DHCPv6 now. Looking at the changelog of NetworkManager 1.36.6, things regarding IP address order and temporary addresses have been changed in that release: https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/blob/nm-1-36/NEWS When running `ip -6 a`, the list now sorts SLAAC addresses above DHCPv6 addresses. With NetworkManager 1.36.4 this was not the case. (The Linux kernel uses the address highest in the list as preferred.) This can break many real-life use cases. For instance, my router gives out static leases to my machines. Those addresses are whitelisted in all kinds of firewalls to allow me to access servers for my work. Now that the "wrong" address is being preferred for outgoing traffic (a SLAAC address that I have no influence on), I am being locked out of the servers in question unless I forcefully remove the addresses or disable SLAAC on my router, so my outgoing traffic is being routed through the DHCPv6 address again. I should note that the bug is not present in NetworkManage
[Touch-packages] [Bug 1977619] Re: DHCPv6 addresses are no longer preferred over SLAAC addresses
** Tags added: jammy ** Description changed: My network has both DHCPv6 and SLAAC for IPv6. From both a privacy perspective and readability reasons, DHCPv6 should *always* be preferred over SLAAC addresses when available. NetworkManager has always been able to adhere to that by simply setting ip6.privacy=0 for the connection. So if you would - for instance - run `curl ifconfig.co`, the DHCPv6 address would be used to connect to the outside world. Since the update to 1.36.6, this is no longer the case. NetworkManager now routes outgoing traffic through the SLAAC address, even if ip6.privacy=0 is set for the connection. Setting net.ipv6.conf.all.use_tempaddr = 0 and net.ipv6.conf..use_tempaddr = 0 with sysctl also no longer has any effect. Removing the SLAAC addresses with `ip addr del` or disabling RA's altogether is the only way to stop NetworkManager from preferring SLAAC over DHCPv6 now. Looking at the changelog of NetworkManager 1.36.6, things regarding IP address order and temporary addresses have been changed in that release: https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/blob/nm-1-36/NEWS When running `ip -6 a`, the list now sorts SLAAC addresses above DHCPv6 - addresses. With NetworkManager 1.36.4 this was not the case. - - Unfortunately, this introduced this bug, which is really breaking a lot - of my use cases. + addresses. With NetworkManager 1.36.4 this was not the case. (The Linux + kernel uses the top address as preferred.) I should note that the bug is not present in NetworkManager 1.38.0 on Debian sid. That just prefers DHCPv6 addresses when available, like it should. ** Description changed: My network has both DHCPv6 and SLAAC for IPv6. From both a privacy perspective and readability reasons, DHCPv6 should *always* be preferred over SLAAC addresses when available. NetworkManager has always been able to adhere to that by simply setting ip6.privacy=0 for the connection. So if you would - for instance - run `curl ifconfig.co`, the DHCPv6 address would be used to connect to the outside world. Since the update to 1.36.6, this is no longer the case. NetworkManager now routes outgoing traffic through the SLAAC address, even if ip6.privacy=0 is set for the connection. Setting net.ipv6.conf.all.use_tempaddr = 0 and net.ipv6.conf..use_tempaddr = 0 with sysctl also no longer has any effect. Removing the SLAAC addresses with `ip addr del` or disabling RA's altogether is the only way to stop NetworkManager from preferring SLAAC over DHCPv6 now. Looking at the changelog of NetworkManager 1.36.6, things regarding IP address order and temporary addresses have been changed in that release: https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/blob/nm-1-36/NEWS When running `ip -6 a`, the list now sorts SLAAC addresses above DHCPv6 addresses. With NetworkManager 1.36.4 this was not the case. (The Linux - kernel uses the top address as preferred.) + kernel uses the address highest in the list as preferred.) I should note that the bug is not present in NetworkManager 1.38.0 on Debian sid. That just prefers DHCPv6 addresses when available, like it should. ** Description changed: My network has both DHCPv6 and SLAAC for IPv6. From both a privacy perspective and readability reasons, DHCPv6 should *always* be preferred over SLAAC addresses when available. NetworkManager has always been able to adhere to that by simply setting ip6.privacy=0 for the connection. So if you would - for instance - run `curl ifconfig.co`, the DHCPv6 address would be used to connect to the outside world. Since the update to 1.36.6, this is no longer the case. NetworkManager now routes outgoing traffic through the SLAAC address, even if ip6.privacy=0 is set for the connection. Setting net.ipv6.conf.all.use_tempaddr = 0 and net.ipv6.conf..use_tempaddr = 0 with sysctl also no longer has any effect. Removing the SLAAC addresses with `ip addr del` or disabling RA's altogether is the only way to stop NetworkManager from preferring SLAAC over DHCPv6 now. Looking at the changelog of NetworkManager 1.36.6, things regarding IP address order and temporary addresses have been changed in that release: https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/blob/nm-1-36/NEWS When running `ip -6 a`, the list now sorts SLAAC addresses above DHCPv6 addresses. With NetworkManager 1.36.4 this was not the case. (The Linux kernel uses the address highest in the list as preferred.) I should note that the bug is not present in NetworkManager 1.38.0 on Debian sid. That just prefers DHCPv6 addresses when available, like it should. + + /etc/os-release: + + PRETTY_NAME="Ubuntu 22.04 LTS" + NAME="Ubuntu" + VERSION_ID="22.04" + VERSION="22.04 LTS (Jammy Jellyfish)" + VERSION_CODENAME=jammy + ID=ubuntu + ID_LIKE=debian +
[Touch-packages] [Bug 1977619] Re: DHCPv6 addresses are no longer preferred over SLAAC addresses
I guess these commits are relevant: https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/commit/c631aa48f034ade2b5cb97ccc4462d56d80174e7 https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/commit/257221d1986b56cbb2e329fcc74a2daca145b7aa Bottom line: addresses are now being added in the wrong order, which is known and fixed upstream for 1.38.x, but never fixed for 1.36.x. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1977619 Title: DHCPv6 addresses are no longer preferred over SLAAC addresses Status in network-manager package in Ubuntu: New Bug description: My network has both DHCPv6 and SLAAC for IPv6. From both a privacy perspective and readability reasons, DHCPv6 should *always* be preferred over SLAAC addresses when available. NetworkManager has always been able to adhere to that by simply setting ip6.privacy=0 for the connection. So if you would - for instance - run `curl ifconfig.co`, the DHCPv6 address would be used to connect to the outside world. Since the update to 1.36.6, this is no longer the case. NetworkManager now routes outgoing traffic through the SLAAC address, even if ip6.privacy=0 is set for the connection. Setting net.ipv6.conf.all.use_tempaddr = 0 and net.ipv6.conf..use_tempaddr = 0 with sysctl also no longer has any effect. Removing the SLAAC addresses with `ip addr del` or disabling RA's altogether is the only way to stop NetworkManager from preferring SLAAC over DHCPv6 now. Looking at the changelog of NetworkManager 1.36.6, things regarding IP address order and temporary addresses have been changed in that release: https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/blob/nm-1-36/NEWS When running `ip -6 a`, the list now sorts SLAAC addresses above DHCPv6 addresses. With NetworkManager 1.36.4 this was not the case. (The Linux kernel uses the address highest in the list as preferred.) I should note that the bug is not present in NetworkManager 1.38.0 on Debian sid. That just prefers DHCPv6 addresses when available, like it should. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1977619/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1977619] Re: DHCPv6 addresses are no longer preferred over SLAAC addresses
Comparing the output of `ip -6 a`, you can see that the dynamic addresses are no longer at the top of the list, where they should be. Before (network-manager 1.36.4): 2: eno0: mtu 1500 state UP qlen 1000 inet6 2a10:3781:::bd0/128 scope global dynamic noprefixroute valid_lft 43193sec preferred_lft 43194sec inet6 fd10:3781:::bd0/128 scope global dynamic noprefixroute valid_lft 43193sec preferred_lft 43194sec inet6 fd10:3781::0:9875:4dec:b9f9:e768/64 scope global noprefixroute valid_lft forever preferred_lft forever inet6 2a10:3781::0:f802:2428:9af1:dcb3/64 scope global noprefixroute valid_lft forever preferred_lft forever inet6 fe80::36e2:ec4c:fddb:3c89/64 scope link noprefixroute valid_lft forever preferred_lft forever After (network-manager 1.36.6): 2: eno0: mtu 1500 state UP qlen 1000 inet6 fd10:3781::0:9875:4dec:b9f9:e768/64 scope global noprefixroute valid_lft forever preferred_lft forever inet6 2a10:3781::0:f802:2428:9af1:dcb3/64 scope global noprefixroute valid_lft forever preferred_lft forever inet6 2a10:3781:::bd0/128 scope global dynamic noprefixroute valid_lft 43194sec preferred_lft 43194sec inet6 fd10:3781:::bd0/128 scope global dynamic noprefixroute valid_lft 43194sec preferred_lft 43194sec inet6 fe80::36e2:ec4c:fddb:3c89/64 scope link noprefixroute valid_lft forever preferred_lft forever On another machine with Debian sid and network-manager 1.38.0, it looks like the way it should be again (dynamic addresses at the top of the list, preferred to autoconfigured / temporary addresses): 2: wlan0: mtu 1500 state UP qlen 1000 inet6 fd10:3781:::5bf/128 scope global dynamic noprefixroute valid_lft 43193sec preferred_lft 43193sec inet6 2a10:3781:::5bf/128 scope global dynamic noprefixroute valid_lft 43193sec preferred_lft 43193sec inet6 2a10:3781::0:42cd:4f1b:89b8:77fd/64 scope global noprefixroute valid_lft forever preferred_lft forever inet6 fd10:3781::0:8a59:df52:9ea1:e7c8/64 scope global noprefixroute valid_lft forever preferred_lft forever inet6 fe80::a738:71dc:f10e:924e/64 scope link noprefixroute valid_lft forever preferred_lft forever So this bug was not present in NetworkManager 1.36.4, introduced in 1.36.6, and then fixed in 1.38.0. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1977619 Title: DHCPv6 addresses are no longer preferred over SLAAC addresses Status in network-manager package in Ubuntu: New Bug description: My network has both DHCPv6 and SLAAC for IPv6. From both a privacy perspective and readability reasons, DHCPv6 should *always* be preferred over SLAAC addresses when available. NetworkManager has always been able to adhere to that by simply setting ip6.privacy=0 for the connection. So if you would - for instance - run `curl ifconfig.co`, the DHCPv6 address would be used to connect to the outside world. Since the update to 1.36.6, this is no longer the case. NetworkManager now routes outgoing traffic through the SLAAC address, even if ip6.privacy=0 is set for the connection. Setting net.ipv6.conf.all.use_tempaddr = 0 and net.ipv6.conf..use_tempaddr = 0 with sysctl also no longer has any effect. Removing the SLAAC addresses with `ip addr del` or disabling RA's altogether is the only way to stop NetworkManager from preferring SLAAC over DHCPv6 now. Looking at the changelog of NetworkManager 1.36.6, things regarding IP address order and temporary addresses have been changed in that release: https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/blob/nm-1-36/NEWS When running `ip -6 a`, the list now sorts SLAAC addresses above DHCPv6 addresses. With NetworkManager 1.36.4 this was not the case. Unfortunately, this introduced this bug, which is really breaking a lot of my use cases. I should note that the bug is not present in NetworkManager 1.38.0 on Debian sid. That just prefers DHCPv6 addresses when available, like it should. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1977619/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1977619] Re: DHCPv6 addresses are no longer preferred over SLAAC addresses
** Description changed: My network has both DHCPv6 and SLAAC for IPv6. From both a privacy perspective and readability reasons, DHCPv6 should *always* be preferred over SLAAC addresses when available. NetworkManager has always been able to adhere to that by simply setting ip6.privacy=0 for the connection. So if you would - for instance - run `curl ifconfig.co`, the DHCPv6 address would be used to connect to the outside world. Since the update to 1.36.6, this is no longer the case. NetworkManager now routes outgoing traffic through the SLAAC address, even if ip6.privacy=0 is set for the connection. Setting net.ipv6.conf.all.use_tempaddr = 0 and net.ipv6.conf..use_tempaddr = 0 with sysctl also no longer has any effect. Removing the SLAAC addresses with `ip addr del` or disabling RA's - altogether is the only way to stop NetworkManager from prefering SLAAC + altogether is the only way to stop NetworkManager from preferring SLAAC over DHCPv6 now. Looking at the changelog of NetworkManager 1.36.6, things regarding IP address order and temporary addresses have been changed in that release: https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/blob/nm-1-36/NEWS When running `ip -6 a`, the list now sorts SLAAC addresses above DHCPv6 addresses. With NetworkManager 1.36.4 this was not the case. Unfortunately, this introduced this bug, which is really breaking a lot of my use cases. I should note that the bug is not present in NetworkManager 1.38.0 on Debian sid. That just prefers DHCPv6 addresses when available, like it should. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1977619 Title: DHCPv6 addresses are no longer preferred over SLAAC addresses Status in network-manager package in Ubuntu: New Bug description: My network has both DHCPv6 and SLAAC for IPv6. From both a privacy perspective and readability reasons, DHCPv6 should *always* be preferred over SLAAC addresses when available. NetworkManager has always been able to adhere to that by simply setting ip6.privacy=0 for the connection. So if you would - for instance - run `curl ifconfig.co`, the DHCPv6 address would be used to connect to the outside world. Since the update to 1.36.6, this is no longer the case. NetworkManager now routes outgoing traffic through the SLAAC address, even if ip6.privacy=0 is set for the connection. Setting net.ipv6.conf.all.use_tempaddr = 0 and net.ipv6.conf..use_tempaddr = 0 with sysctl also no longer has any effect. Removing the SLAAC addresses with `ip addr del` or disabling RA's altogether is the only way to stop NetworkManager from preferring SLAAC over DHCPv6 now. Looking at the changelog of NetworkManager 1.36.6, things regarding IP address order and temporary addresses have been changed in that release: https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/blob/nm-1-36/NEWS When running `ip -6 a`, the list now sorts SLAAC addresses above DHCPv6 addresses. With NetworkManager 1.36.4 this was not the case. Unfortunately, this introduced this bug, which is really breaking a lot of my use cases. I should note that the bug is not present in NetworkManager 1.38.0 on Debian sid. That just prefers DHCPv6 addresses when available, like it should. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1977619/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1977619] Re: DHCPv6 addresses are no longer preferred over SLAAC addresses
Looking at the changelog of 1.38.0: * Fix bug setting priority for IP addresses. https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/blob/nm-1-38/NEWS So it looks like Ubuntu just introduced that bug by upgrading to 1.36.6. Please either backport it from 1.38.0 or revert to 1.36.4. ** Description changed: My network has both DHCPv6 and SLAAC for IPv6. From both a privacy perspective and readability reasons, DHCPv6 should *always* be preferred over SLAAC addresses when available. NetworkManager has always been able to adhere to that by simply setting ip6.privacy=0 for the connection. So if you would - for instance - run `curl ifconfig.co`, the DHCPv6 address would be used to connect to the outside world. Since the update to 1.36.6, this is no longer the case. NetworkManager now routes outgoing traffic through the SLAAC address, even if ip6.privacy=0 is set for the connection. Setting net.ipv6.conf.all.use_tempaddr = 0 and net.ipv6.conf..use_tempaddr = 0 with sysctl also no longer has any effect. - Physically removing the SLAAC addresses or disabling RA's altogether is - the only way to stop NetworkManager from prefering SLAAC over DHCPv6 - now. + Removing the SLAAC addresses with `ip addr del` or disabling RA's + altogether is the only way to stop NetworkManager from prefering SLAAC + over DHCPv6 now. Looking at the changelog of NetworkManager 1.36.6, things regarding IP address order and temporary addresses have been changed in that release: https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/blob/nm-1-36/NEWS When running `ip -6 a`, the list now sorts SLAAC addresses above DHCPv6 addresses. With NetworkManager 1.36.4 this was not the case. Unfortunately, this introduced this bug, which is really breaking a lot of my use cases. I should note that the bug is not present in NetworkManager 1.38.0 on Debian sid. That just prefers DHCPv6 addresses when available, like it should. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1977619 Title: DHCPv6 addresses are no longer preferred over SLAAC addresses Status in network-manager package in Ubuntu: New Bug description: My network has both DHCPv6 and SLAAC for IPv6. From both a privacy perspective and readability reasons, DHCPv6 should *always* be preferred over SLAAC addresses when available. NetworkManager has always been able to adhere to that by simply setting ip6.privacy=0 for the connection. So if you would - for instance - run `curl ifconfig.co`, the DHCPv6 address would be used to connect to the outside world. Since the update to 1.36.6, this is no longer the case. NetworkManager now routes outgoing traffic through the SLAAC address, even if ip6.privacy=0 is set for the connection. Setting net.ipv6.conf.all.use_tempaddr = 0 and net.ipv6.conf..use_tempaddr = 0 with sysctl also no longer has any effect. Removing the SLAAC addresses with `ip addr del` or disabling RA's altogether is the only way to stop NetworkManager from preferring SLAAC over DHCPv6 now. Looking at the changelog of NetworkManager 1.36.6, things regarding IP address order and temporary addresses have been changed in that release: https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/blob/nm-1-36/NEWS When running `ip -6 a`, the list now sorts SLAAC addresses above DHCPv6 addresses. With NetworkManager 1.36.4 this was not the case. Unfortunately, this introduced this bug, which is really breaking a lot of my use cases. I should note that the bug is not present in NetworkManager 1.38.0 on Debian sid. That just prefers DHCPv6 addresses when available, like it should. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1977619/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1974428] Re: Update to the current 1.36 stable version
https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1977619 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1974428 Title: Update to the current 1.36 stable version Status in network-manager package in Ubuntu: Fix Released Status in network-manager source package in Jammy: Fix Released Bug description: * Impact It's a stable update from upstream, the changes are listed in the NEWS https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/blob/nm-1-36/NEWS * Test Case Since it's an update with several fixes the testing should focus on a specific point but rather by validating that the testplan is green, https://wiki.ubuntu.com/NetworkManager/DistroTesting * Regression potential There are fixes around IPv6 handling, VPN connections and the hotspot feature, verify that those configurations are still working as expected. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1974428/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1977619] Re: DHCPv6 addresses are no longer preferred over SLAAC addresses
** Description changed: My network has both DHCPv6 and SLAAC for IPv6. From both a privacy perspective and readability reasons, DHCPv6 should *always* be preferred over SLAAC addresses when available. NetworkManager has always been able to adhere to that by simply setting ip6.privacy=0 for the connection. So if you would - for instance - run `curl ifconfig.co`, the DHCPv6 address would be used to connect to the outside world. Since the update to 1.36.6, this is no longer the case. NetworkManager now routes outgoing traffic through the SLAAC address, even if ip6.privacy=0 is set for the connection. Setting net.ipv6.conf.all.use_tempaddr = 0 and net.ipv6.conf..use_tempaddr = 0 with sysctl also no longer has any effect. Physically removing the SLAAC addresses or disabling RA's altogether is the only way to stop NetworkManager from prefering SLAAC over DHCPv6 now. Looking at the changelog of NetworkManager 1.36.6, things regarding IP address order and temporary addresses have been changed in that release: https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/blob/nm-1-36/NEWS + When running `ip -6 a`, the list now sorts SLAAC addresses above DHCPv6 + addresses. With NetworkManager 1.36.4 this was not the case. + Unfortunately, this introduced this bug, which is really breaking a lot of my use cases. I should note that the bug is not present in NetworkManager 1.38.0 on Debian sid. That just prefers DHCPv6 addresses when available, like it should. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1977619 Title: DHCPv6 addresses are no longer preferred over SLAAC addresses Status in network-manager package in Ubuntu: New Bug description: My network has both DHCPv6 and SLAAC for IPv6. From both a privacy perspective and readability reasons, DHCPv6 should *always* be preferred over SLAAC addresses when available. NetworkManager has always been able to adhere to that by simply setting ip6.privacy=0 for the connection. So if you would - for instance - run `curl ifconfig.co`, the DHCPv6 address would be used to connect to the outside world. Since the update to 1.36.6, this is no longer the case. NetworkManager now routes outgoing traffic through the SLAAC address, even if ip6.privacy=0 is set for the connection. Setting net.ipv6.conf.all.use_tempaddr = 0 and net.ipv6.conf..use_tempaddr = 0 with sysctl also no longer has any effect. Removing the SLAAC addresses with `ip addr del` or disabling RA's altogether is the only way to stop NetworkManager from prefering SLAAC over DHCPv6 now. Looking at the changelog of NetworkManager 1.36.6, things regarding IP address order and temporary addresses have been changed in that release: https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/blob/nm-1-36/NEWS When running `ip -6 a`, the list now sorts SLAAC addresses above DHCPv6 addresses. With NetworkManager 1.36.4 this was not the case. Unfortunately, this introduced this bug, which is really breaking a lot of my use cases. I should note that the bug is not present in NetworkManager 1.38.0 on Debian sid. That just prefers DHCPv6 addresses when available, like it should. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1977619/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1977619] [NEW] DHCPv6 addresses are no longer preferred over SLAAC addresses
Public bug reported: My network has both DHCPv6 and SLAAC for IPv6. From both a privacy perspective and readability reasons, DHCPv6 should *always* be preferred over SLAAC addresses when available. NetworkManager has always been able to adhere to that by simply setting ip6.privacy=0 for the connection. So if you would - for instance - run `curl ifconfig.co`, the DHCPv6 address would be used to connect to the outside world. Since the update to 1.36.6, this is no longer the case. NetworkManager now routes outgoing traffic through the SLAAC address, even if ip6.privacy=0 is set for the connection. Setting net.ipv6.conf.all.use_tempaddr = 0 and net.ipv6.conf..use_tempaddr = 0 with sysctl also no longer has any effect. Physically removing the SLAAC addresses or disabling RA's altogether is the only way to stop NetworkManager from prefering SLAAC over DHCPv6 now. Looking at the changelog of NetworkManager 1.36.6, things regarding IP address order and temporary addresses have been changed in that release: https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/blob/nm-1-36/NEWS Unfortunately, this introduced this bug, which is really breaking a lot of my use cases. I should note that the bug is not present in NetworkManager 1.38.0 on Debian sid. That just prefers DHCPv6 addresses when available, like it should. ** Affects: network-manager (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1977619 Title: DHCPv6 addresses are no longer preferred over SLAAC addresses Status in network-manager package in Ubuntu: New Bug description: My network has both DHCPv6 and SLAAC for IPv6. From both a privacy perspective and readability reasons, DHCPv6 should *always* be preferred over SLAAC addresses when available. NetworkManager has always been able to adhere to that by simply setting ip6.privacy=0 for the connection. So if you would - for instance - run `curl ifconfig.co`, the DHCPv6 address would be used to connect to the outside world. Since the update to 1.36.6, this is no longer the case. NetworkManager now routes outgoing traffic through the SLAAC address, even if ip6.privacy=0 is set for the connection. Setting net.ipv6.conf.all.use_tempaddr = 0 and net.ipv6.conf..use_tempaddr = 0 with sysctl also no longer has any effect. Physically removing the SLAAC addresses or disabling RA's altogether is the only way to stop NetworkManager from prefering SLAAC over DHCPv6 now. Looking at the changelog of NetworkManager 1.36.6, things regarding IP address order and temporary addresses have been changed in that release: https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/blob/nm-1-36/NEWS Unfortunately, this introduced this bug, which is really breaking a lot of my use cases. I should note that the bug is not present in NetworkManager 1.38.0 on Debian sid. That just prefers DHCPv6 addresses when available, like it should. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1977619/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1974428] Re: Update to the current 1.36 stable version
All of a sudden SLAAC addresses are preferred over DHCPv6 addresses, which should not be happening. Setting ip6.privacy=0 no longer helps, nor does setting net.ipv6.conf.all.use_tempaddr = 0 with sysctl. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1974428 Title: Update to the current 1.36 stable version Status in network-manager package in Ubuntu: Fix Released Status in network-manager source package in Jammy: Fix Released Bug description: * Impact It's a stable update from upstream, the changes are listed in the NEWS https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/blob/nm-1-36/NEWS * Test Case Since it's an update with several fixes the testing should focus on a specific point but rather by validating that the testplan is green, https://wiki.ubuntu.com/NetworkManager/DistroTesting * Regression potential There are fixes around IPv6 handling, VPN connections and the hotspot feature, verify that those configurations are still working as expected. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1974428/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1447654] Re: installing policykit-1 hangs under systemd
I did a couple of wily netinstalls today, and I'm still having this problem. I first have to run sudo apt-get install policykit-1, and only then I can run my postinstall scripts normally. Otherwise, I'm left with the notorious timeouts. Can't policykit-1 be installed as part of the mini.iso? Then the reboot into the installed system will probably avoid the issue. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to policykit-1 in Ubuntu. https://bugs.launchpad.net/bugs/1447654 Title: installing policykit-1 hangs under systemd Status in policykit-1 package in Ubuntu: Confirmed Status in policykit-1 source package in Vivid: Confirmed Bug description: I've installed 15.04 using the current amd64 netboot.tar.gz (MD5 = 6566065bf73a9c81feeddf5520dda122). It installs fine, but I'm getting errors installing packages (such as lubuntu-core). Last few lines from apt-get: Processing triggers for systemd (219-7ubuntu3) ... Error getting authority: Error initializing authority: Error calling StartServiceByName for org.freedesktop.PolicyKit1: Timeout was reached (g-io-error-quark, 24) Failed to execute operation: Connection timed out dpkg: error processing package systemd (--unpack): subprocess installed post-installation script returned error exit status 1 Processing triggers for libglib2.0-0:amd64 (2.44.0-1ubuntu3) ... Processing triggers for shared-mime-info (1.3-1) ... Processing triggers for mime-support (3.58ubuntu1) ... Processing triggers for udev (219-7ubuntu3) ... Processing triggers for dbus (1.8.12-1ubuntu5) ... Errors were encountered while processing: systemd E: Sub-process /usr/bin/dpkg returned an error code (1) I've done a second install using the server iso and lubuntu-core installs fine on that. The only thing different was my install media. SRU INFORMATION === Test case: - Boot a minimal VM and purge "apport policykit-1", or do the above netboot installation. - sudo apt-get install policykit-1 apport - The above hangs on the systemd triggers and eventually fails in vivid final. It should succeed fine with this update. Regression potential: Very low: polkitd does not keep state, so one can restart it fine. The postinst shell modification is simple and obvious. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/policykit-1/+bug/1447654/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1447654] Re: installing policykit-1 hangs under systemd
All I have to do is a mini.iso 15.04 netinstall, install my default packages, and I can reproduce this bug on any machine I've tested. The only workaround for me is: Immediately after a netinstall: --- sudo apt-get purge policykit-1 sudo apt-get update sudo apt-get upgrade sudo systemctl reboot --- sudo apt-get install policykit-1 sudo systemctl reboot --- Install the rest of the packages I want. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to policykit-1 in Ubuntu. https://bugs.launchpad.net/bugs/1447654 Title: installing policykit-1 hangs under systemd Status in policykit-1 package in Ubuntu: Confirmed Status in policykit-1 source package in Vivid: Fix Released Bug description: I've installed 15.04 using the current amd64 netboot.tar.gz (MD5 = 6566065bf73a9c81feeddf5520dda122). It installs fine, but I'm getting errors installing packages (such as lubuntu-core). Last few lines from apt-get: Processing triggers for systemd (219-7ubuntu3) ... Error getting authority: Error initializing authority: Error calling StartServiceByName for org.freedesktop.PolicyKit1: Timeout was reached (g-io-error-quark, 24) Failed to execute operation: Connection timed out dpkg: error processing package systemd (--unpack): subprocess installed post-installation script returned error exit status 1 Processing triggers for libglib2.0-0:amd64 (2.44.0-1ubuntu3) ... Processing triggers for shared-mime-info (1.3-1) ... Processing triggers for mime-support (3.58ubuntu1) ... Processing triggers for udev (219-7ubuntu3) ... Processing triggers for dbus (1.8.12-1ubuntu5) ... Errors were encountered while processing: systemd E: Sub-process /usr/bin/dpkg returned an error code (1) I've done a second install using the server iso and lubuntu-core installs fine on that. The only thing different was my install media. SRU INFORMATION === Test case: - Boot a minimal VM and purge "apport policykit-1", or do the above netboot installation. - sudo apt-get install policykit-1 apport - The above hangs on the systemd triggers and eventually fails in vivid final. It should succeed fine with this update. Regression potential: Very low: polkitd does not keep state, so one can restart it fine. The postinst shell modification is simple and obvious. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/policykit-1/+bug/1447654/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp