© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
73416ba
(Get the code!)
Hello @Łukasz Zemczak
I understand your concern about breaking existing behaviour.
I would like to clarify 2 things:
1) The change introduced here only ensures that user-requested timeouts are never exceeded. That means that if something is currently accepting DHCP offers after the specified timeout has expired, then that is buggy behaviour. It would make sense that such behaviour would change after this change. If such a user exists, they would need to change their timeout values so as to be long enough to receive the DHCP offer that they want. I think it makes sense that such buggy behaviour would get exposed with this fix.
2) That said, I consider it very unlikely for that scenario to even exist. The main reason is that the bug (going over the specified timeout) happens in the case where there is a problem bringing up the interface, so the ipconfig logic simply says "try again in 10 seconds" in that case, even if that 10 seconds is longer than the entire specified timeout. Since this happens when there are interface problems, it can be safely assumed that no DHCP offers will be received anyway on that problematic interface (in fact, no DHCP request was even sent out). These 10 seconds are just dead time, basically.
So I would consider it unlikely that anyone who is successfully using ipconfig today would even notice a change. This patch should only affect those 10-seconds delays caused by problematic interfaces not normal functioning interfaces, (and even then, it would only affect them if the user-specified timeout is less than 10 seconds).
I am not sure what you mean by how it differs from focal+. The last time I checked, the timeout-bug was affecting ipconfig in both focal and bionic (and upstream HEAD). However, we are only interested in Bionic since Focal does not even use ipconfig it uses dhclient instead.
I will add a regression-
I will try to expand the regression-