>> The exact conditions for reproducing this bug on mixed IPv4/IPv6 networks 
>> are not known
>Looking at the upstream commit description, isn't it just that a DHCPv6 lease 
>expires and the >server NAKs a request for the same IP again? Or is that not 
>sufficient to trigger the problem.
Yes, when having a look at the previously collected logs, that seems to be the 
case (journalctl -u NetworkManager.service).

Some of our computers get this problem more often that other. Some
persons claim that they have never seen the problem. That is the part
that is unclear.

>In any case, I appreciate there might be difficulty in testing the fix, but 
>what's the actual >criteria you propose to use to decide when the bug is to be 
>marked verification-done-bionic?

In the best of worlds I would like to simulated environment where dhcp-
packages could be controlled, but that is not feasible.

I have been running this patch on two computers since 2022-04-13 and haven't 
seen the problem since. One laptop (restarted every day) and one desktop that 
is always on.
The desktop has been running for 29 days continuously according to syslog, 
without me having to manually remove dhcp lease files and restart network 

Ideas for getting confidence of this change:
We could ask more users who have experienced this error to install this change 
and confirm if they experience lost ipv6 addresses after installing patched 

Another idea is to shutdown computer in single user mode (without network), 
edit the dhcp6 lease file in a way so that dhcp-server will respond with NACK 
when booting up in multi-user mode. 
What to change in the lease file I do not know.

You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.

  network-manager fails to renew ipv6 address

To manage notifications about this bug go to:

ubuntu-bugs mailing list

Reply via email to