| 2021-10-14 05:39:11 |
Khaled El Mously |
bug |
|
|
added bug |
| 2021-10-14 05:39:23 |
Khaled El Mously |
nominated for series |
|
Ubuntu Bionic |
|
| 2021-10-14 05:39:23 |
Khaled El Mously |
bug task added |
|
klibc (Ubuntu Bionic) |
|
| 2021-10-14 05:53:59 |
Khaled El Mously |
description |
In some cases, ipconfig can take longer than the user-specified timeouts, causing unexpected delays.
in main.c, in function loop(), the process can go into process_timeout_event() (or process_receive_event() ) and if it encounters an error situation, will set an attempt to "try again later" at time equal now + 10 seconds by setting
s->expire = now + 10;
This can happen at any time during the main event loop, which can end up extending the user-specified timeout if "now + 10" is greater than "start_time + user-specified-timeout".
I believe a patch like the following is needed to avoid this problem:
--- a/usr/kinit/ipconfig/main.c
+++ b/usr/kinit/ipconfig/main.c
@@ -437,6 +437,13 @@ static int loop(void)
if (timeout > s->expire - now.tv_sec)
timeout = s->expire - now.tv_sec;
+
+ /* Compensate for already-lost time */
+ gettimeofday(&now, NULL);
+ if (now.tv_sec + timeout > start + loop_timeout) {
+ timeout = loop_timeout - (now.tv_sec - start);
+ printf("Lowered timeout to match user request = (%d s) \n", timeout);
+ }
} |
In some cases, ipconfig can take longer than the user-specified timeouts, causing unexpected delays.
in main.c, in function loop(), the process can go into process_timeout_event() (or process_receive_event() ) and if it encounters an error situation, will set an attempt to "try again later" at time equal now + 10 seconds by setting
s->expire = now + 10;
This can happen at any time during the main event loop, which can end up extending the user-specified timeout if "now + 10" is greater than "start_time + user-specified-timeout".
I believe a patch like the following is needed to avoid this problem:
--- a/usr/kinit/ipconfig/main.c
+++ b/usr/kinit/ipconfig/main.c
@@ -437,6 +437,13 @@ static int loop(void)
if (timeout > s->expire - now.tv_sec)
timeout = s->expire - now.tv_sec;
+
+ /* Compensate for already-lost time */
+ gettimeofday(&now, NULL);
+ if (now.tv_sec + timeout > start + loop_timeout) {
+ timeout = loop_timeout - (now.tv_sec - start);
+ printf("Lowered timeout to match user request = (%d s) \n", timeout);
+ }
}
I believe the current behaviour is buggy. This is confirmed when the following line is executed:
if (loop_timeout >= 0 &&
now.tv_sec - start >= loop_timeout) {
printf("IP-Config: no response after %d "
"secs - giving up\n", loop_timeout);
rc = -1;
goto bail;
}
'loop_timeout' is the user-specified time-out. With a value of 2, in case of error, this line prints:
IP-Config: no response after 2 secs - giving up
So it thinks that it waited 2 seconds - however, in reality it had actually waited for 10 seconds.
The suggested code-change ensures that the timeout that is actually used never exceeds the user-specified timeout. |
|
| 2021-10-14 06:17:39 |
Khaled El Mously |
attachment added |
|
Suggested patch that fixes the problem https://bugs.launchpad.net/ubuntu/+source/klibc/+bug/1947099/+attachment/5532730/+files/honour-user-requested-timeouts-in-all-cases.patch |
|
| 2021-10-14 07:33:02 |
Sebastien Bacher |
bug |
|
|
added subscriber Ubuntu Sponsors Team |
| 2021-10-14 20:57:41 |
Fabio Augusto Miranda Martins |
bug |
|
|
added subscriber Fabio Augusto Miranda Martins |
| 2021-10-15 04:35:07 |
Mathew Hodson |
klibc (Ubuntu): importance |
Undecided |
Medium |
|
| 2021-10-15 04:35:10 |
Mathew Hodson |
klibc (Ubuntu Bionic): importance |
Undecided |
Medium |
|
| 2021-10-28 14:54:40 |
Eric Desrochers |
bug |
|
|
added subscriber Eric Desrochers |
| 2021-10-28 15:15:30 |
Eric Desrochers |
tags |
|
sts |
|
| 2021-10-28 17:23:26 |
Eric Desrochers |
description |
In some cases, ipconfig can take longer than the user-specified timeouts, causing unexpected delays.
in main.c, in function loop(), the process can go into process_timeout_event() (or process_receive_event() ) and if it encounters an error situation, will set an attempt to "try again later" at time equal now + 10 seconds by setting
s->expire = now + 10;
This can happen at any time during the main event loop, which can end up extending the user-specified timeout if "now + 10" is greater than "start_time + user-specified-timeout".
I believe a patch like the following is needed to avoid this problem:
--- a/usr/kinit/ipconfig/main.c
+++ b/usr/kinit/ipconfig/main.c
@@ -437,6 +437,13 @@ static int loop(void)
if (timeout > s->expire - now.tv_sec)
timeout = s->expire - now.tv_sec;
+
+ /* Compensate for already-lost time */
+ gettimeofday(&now, NULL);
+ if (now.tv_sec + timeout > start + loop_timeout) {
+ timeout = loop_timeout - (now.tv_sec - start);
+ printf("Lowered timeout to match user request = (%d s) \n", timeout);
+ }
}
I believe the current behaviour is buggy. This is confirmed when the following line is executed:
if (loop_timeout >= 0 &&
now.tv_sec - start >= loop_timeout) {
printf("IP-Config: no response after %d "
"secs - giving up\n", loop_timeout);
rc = -1;
goto bail;
}
'loop_timeout' is the user-specified time-out. With a value of 2, in case of error, this line prints:
IP-Config: no response after 2 secs - giving up
So it thinks that it waited 2 seconds - however, in reality it had actually waited for 10 seconds.
The suggested code-change ensures that the timeout that is actually used never exceeds the user-specified timeout. |
** SRU TEMPLATE DRAFT **
[Impact]
[Test Plan]
[Where problems could occur]
[Other Info]
[Original Description]
In some cases, ipconfig can take longer than the user-specified timeouts, causing unexpected delays.
in main.c, in function loop(), the process can go into process_timeout_event() (or process_receive_event() ) and if it encounters an error situation, will set an attempt to "try again later" at time equal now + 10 seconds by setting
s->expire = now + 10;
This can happen at any time during the main event loop, which can end up extending the user-specified timeout if "now + 10" is greater than "start_time + user-specified-timeout".
I believe a patch like the following is needed to avoid this problem:
--- a/usr/kinit/ipconfig/main.c
+++ b/usr/kinit/ipconfig/main.c
@@ -437,6 +437,13 @@ static int loop(void)
if (timeout > s->expire - now.tv_sec)
timeout = s->expire - now.tv_sec;
+
+ /* Compensate for already-lost time */
+ gettimeofday(&now, NULL);
+ if (now.tv_sec + timeout > start + loop_timeout) {
+ timeout = loop_timeout - (now.tv_sec - start);
+ printf("Lowered timeout to match user request = (%d s) \n", timeout);
+ }
}
I believe the current behaviour is buggy. This is confirmed when the following line is executed:
if (loop_timeout >= 0 &&
now.tv_sec - start >= loop_timeout) {
printf("IP-Config: no response after %d "
"secs - giving up\n", loop_timeout);
rc = -1;
goto bail;
}
'loop_timeout' is the user-specified time-out. With a value of 2, in case of error, this line prints:
IP-Config: no response after 2 secs - giving up
So it thinks that it waited 2 seconds - however, in reality it had actually waited for 10 seconds.
The suggested code-change ensures that the timeout that is actually used never exceeds the user-specified timeout. |
|
| 2021-10-28 19:11:04 |
Eric Desrochers |
bug |
|
|
added subscriber STS Sponsors |
| 2021-11-03 14:05:19 |
Heitor Alves de Siqueira |
bug |
|
|
added subscriber Heitor Alves de Siqueira |
| 2021-11-18 09:51:35 |
Khaled El Mously |
description |
** SRU TEMPLATE DRAFT **
[Impact]
[Test Plan]
[Where problems could occur]
[Other Info]
[Original Description]
In some cases, ipconfig can take longer than the user-specified timeouts, causing unexpected delays.
in main.c, in function loop(), the process can go into process_timeout_event() (or process_receive_event() ) and if it encounters an error situation, will set an attempt to "try again later" at time equal now + 10 seconds by setting
s->expire = now + 10;
This can happen at any time during the main event loop, which can end up extending the user-specified timeout if "now + 10" is greater than "start_time + user-specified-timeout".
I believe a patch like the following is needed to avoid this problem:
--- a/usr/kinit/ipconfig/main.c
+++ b/usr/kinit/ipconfig/main.c
@@ -437,6 +437,13 @@ static int loop(void)
if (timeout > s->expire - now.tv_sec)
timeout = s->expire - now.tv_sec;
+
+ /* Compensate for already-lost time */
+ gettimeofday(&now, NULL);
+ if (now.tv_sec + timeout > start + loop_timeout) {
+ timeout = loop_timeout - (now.tv_sec - start);
+ printf("Lowered timeout to match user request = (%d s) \n", timeout);
+ }
}
I believe the current behaviour is buggy. This is confirmed when the following line is executed:
if (loop_timeout >= 0 &&
now.tv_sec - start >= loop_timeout) {
printf("IP-Config: no response after %d "
"secs - giving up\n", loop_timeout);
rc = -1;
goto bail;
}
'loop_timeout' is the user-specified time-out. With a value of 2, in case of error, this line prints:
IP-Config: no response after 2 secs - giving up
So it thinks that it waited 2 seconds - however, in reality it had actually waited for 10 seconds.
The suggested code-change ensures that the timeout that is actually used never exceeds the user-specified timeout. |
** SRU TEMPLATE DRAFT **
[Impact]
In some cases, ipconfig can take a longer time than the user-specified timeouts, causing unexpected delays.
[Test Plan]
Any situation where ipconfig encounters an error sending the DHCP packet, it will automatically set a delay of 10 seconds, which could be longer than the user-specified timeout. It can be reproduced by creating a dummy interface and attempting to run ipconfig on it with a timeout value of less than 10:
# ip link add eth1 type dummy
# date; /usr/lib/klibc/bin/ipconfig -t 2 eth1; date
Thu Nov 18 04:46:13 EST 2021
IP-Config: eth1 hardware address ae:e0:f5:9d:7e:00 mtu 1500 DHCP RARP
IP-Config: no response after 2 secs - giving up
Thu Nov 18 04:46:23 EST 2021
^ Notice above, ipconfig thinks that it waited 2 seconds, but the timestamps show an actual delay of 10 seconds.
[Where problems could occur]
Please see reproduction steps above. We are seeing this in production too (see comment #2).
[Other Info]
A patch to fix the issue is being proposed here. It is a safe fix - it only checks before going into sleep that the timeout never exceeds the user-requested value.
[Original Description]
In some cases, ipconfig can take longer than the user-specified timeouts, causing unexpected delays.
in main.c, in function loop(), the process can go into process_timeout_event() (or process_receive_event() ) and if it encounters an error situation, will set an attempt to "try again later" at time equal now + 10 seconds by setting
s->expire = now + 10;
This can happen at any time during the main event loop, which can end up extending the user-specified timeout if "now + 10" is greater than "start_time + user-specified-timeout".
I believe a patch like the following is needed to avoid this problem:
--- a/usr/kinit/ipconfig/main.c
+++ b/usr/kinit/ipconfig/main.c
@@ -437,6 +437,13 @@ static int loop(void)
if (timeout > s->expire - now.tv_sec)
timeout = s->expire - now.tv_sec;
+
+ /* Compensate for already-lost time */
+ gettimeofday(&now, NULL);
+ if (now.tv_sec + timeout > start + loop_timeout) {
+ timeout = loop_timeout - (now.tv_sec - start);
+ printf("Lowered timeout to match user request = (%d s) \n", timeout);
+ }
}
I believe the current behaviour is buggy. This is confirmed when the following line is executed:
if (loop_timeout >= 0 &&
now.tv_sec - start >= loop_timeout) {
printf("IP-Config: no response after %d "
"secs - giving up\n", loop_timeout);
rc = -1;
goto bail;
}
'loop_timeout' is the user-specified time-out. With a value of 2, in case of error, this line prints:
IP-Config: no response after 2 secs - giving up
So it thinks that it waited 2 seconds - however, in reality it had actually waited for 10 seconds.
The suggested code-change ensures that the timeout that is actually used never exceeds the user-specified timeout. |
|
| 2021-11-18 09:51:45 |
Khaled El Mously |
description |
** SRU TEMPLATE DRAFT **
[Impact]
In some cases, ipconfig can take a longer time than the user-specified timeouts, causing unexpected delays.
[Test Plan]
Any situation where ipconfig encounters an error sending the DHCP packet, it will automatically set a delay of 10 seconds, which could be longer than the user-specified timeout. It can be reproduced by creating a dummy interface and attempting to run ipconfig on it with a timeout value of less than 10:
# ip link add eth1 type dummy
# date; /usr/lib/klibc/bin/ipconfig -t 2 eth1; date
Thu Nov 18 04:46:13 EST 2021
IP-Config: eth1 hardware address ae:e0:f5:9d:7e:00 mtu 1500 DHCP RARP
IP-Config: no response after 2 secs - giving up
Thu Nov 18 04:46:23 EST 2021
^ Notice above, ipconfig thinks that it waited 2 seconds, but the timestamps show an actual delay of 10 seconds.
[Where problems could occur]
Please see reproduction steps above. We are seeing this in production too (see comment #2).
[Other Info]
A patch to fix the issue is being proposed here. It is a safe fix - it only checks before going into sleep that the timeout never exceeds the user-requested value.
[Original Description]
In some cases, ipconfig can take longer than the user-specified timeouts, causing unexpected delays.
in main.c, in function loop(), the process can go into process_timeout_event() (or process_receive_event() ) and if it encounters an error situation, will set an attempt to "try again later" at time equal now + 10 seconds by setting
s->expire = now + 10;
This can happen at any time during the main event loop, which can end up extending the user-specified timeout if "now + 10" is greater than "start_time + user-specified-timeout".
I believe a patch like the following is needed to avoid this problem:
--- a/usr/kinit/ipconfig/main.c
+++ b/usr/kinit/ipconfig/main.c
@@ -437,6 +437,13 @@ static int loop(void)
if (timeout > s->expire - now.tv_sec)
timeout = s->expire - now.tv_sec;
+
+ /* Compensate for already-lost time */
+ gettimeofday(&now, NULL);
+ if (now.tv_sec + timeout > start + loop_timeout) {
+ timeout = loop_timeout - (now.tv_sec - start);
+ printf("Lowered timeout to match user request = (%d s) \n", timeout);
+ }
}
I believe the current behaviour is buggy. This is confirmed when the following line is executed:
if (loop_timeout >= 0 &&
now.tv_sec - start >= loop_timeout) {
printf("IP-Config: no response after %d "
"secs - giving up\n", loop_timeout);
rc = -1;
goto bail;
}
'loop_timeout' is the user-specified time-out. With a value of 2, in case of error, this line prints:
IP-Config: no response after 2 secs - giving up
So it thinks that it waited 2 seconds - however, in reality it had actually waited for 10 seconds.
The suggested code-change ensures that the timeout that is actually used never exceeds the user-specified timeout. |
[Impact]
In some cases, ipconfig can take a longer time than the user-specified timeouts, causing unexpected delays.
[Test Plan]
Any situation where ipconfig encounters an error sending the DHCP packet, it will automatically set a delay of 10 seconds, which could be longer than the user-specified timeout. It can be reproduced by creating a dummy interface and attempting to run ipconfig on it with a timeout value of less than 10:
# ip link add eth1 type dummy
# date; /usr/lib/klibc/bin/ipconfig -t 2 eth1; date
Thu Nov 18 04:46:13 EST 2021
IP-Config: eth1 hardware address ae:e0:f5:9d:7e:00 mtu 1500 DHCP RARP
IP-Config: no response after 2 secs - giving up
Thu Nov 18 04:46:23 EST 2021
^ Notice above, ipconfig thinks that it waited 2 seconds, but the timestamps show an actual delay of 10 seconds.
[Where problems could occur]
Please see reproduction steps above. We are seeing this in production too (see comment #2).
[Other Info]
A patch to fix the issue is being proposed here. It is a safe fix - it only checks before going into sleep that the timeout never exceeds the user-requested value.
[Original Description]
In some cases, ipconfig can take longer than the user-specified timeouts, causing unexpected delays.
in main.c, in function loop(), the process can go into process_timeout_event() (or process_receive_event() ) and if it encounters an error situation, will set an attempt to "try again later" at time equal now + 10 seconds by setting
s->expire = now + 10;
This can happen at any time during the main event loop, which can end up extending the user-specified timeout if "now + 10" is greater than "start_time + user-specified-timeout".
I believe a patch like the following is needed to avoid this problem:
--- a/usr/kinit/ipconfig/main.c
+++ b/usr/kinit/ipconfig/main.c
@@ -437,6 +437,13 @@ static int loop(void)
if (timeout > s->expire - now.tv_sec)
timeout = s->expire - now.tv_sec;
+
+ /* Compensate for already-lost time */
+ gettimeofday(&now, NULL);
+ if (now.tv_sec + timeout > start + loop_timeout) {
+ timeout = loop_timeout - (now.tv_sec - start);
+ printf("Lowered timeout to match user request = (%d s) \n", timeout);
+ }
}
I believe the current behaviour is buggy. This is confirmed when the following line is executed:
if (loop_timeout >= 0 &&
now.tv_sec - start >= loop_timeout) {
printf("IP-Config: no response after %d "
"secs - giving up\n", loop_timeout);
rc = -1;
goto bail;
}
'loop_timeout' is the user-specified time-out. With a value of 2, in case of error, this line prints:
IP-Config: no response after 2 secs - giving up
So it thinks that it waited 2 seconds - however, in reality it had actually waited for 10 seconds.
The suggested code-change ensures that the timeout that is actually used never exceeds the user-specified timeout. |
|
| 2021-11-18 14:34:17 |
Eric Desrochers |
klibc (Ubuntu Bionic): assignee |
|
Khaled El Mously (kmously) |
|
| 2021-11-18 14:34:21 |
Eric Desrochers |
klibc (Ubuntu Bionic): status |
New |
In Progress |
|
| 2021-11-19 18:34:13 |
Brian Murray |
removed subscriber Ubuntu Sponsors Team |
|
|
|
| 2022-03-02 12:32:32 |
Robie Basak |
klibc (Ubuntu Bionic): status |
In Progress |
Incomplete |
|
| 2022-03-17 16:20:35 |
Dariusz Gadomski |
bug |
|
|
added subscriber Dariusz Gadomski |
| 2022-03-21 21:54:31 |
Khaled El Mously |
description |
[Impact]
In some cases, ipconfig can take a longer time than the user-specified timeouts, causing unexpected delays.
[Test Plan]
Any situation where ipconfig encounters an error sending the DHCP packet, it will automatically set a delay of 10 seconds, which could be longer than the user-specified timeout. It can be reproduced by creating a dummy interface and attempting to run ipconfig on it with a timeout value of less than 10:
# ip link add eth1 type dummy
# date; /usr/lib/klibc/bin/ipconfig -t 2 eth1; date
Thu Nov 18 04:46:13 EST 2021
IP-Config: eth1 hardware address ae:e0:f5:9d:7e:00 mtu 1500 DHCP RARP
IP-Config: no response after 2 secs - giving up
Thu Nov 18 04:46:23 EST 2021
^ Notice above, ipconfig thinks that it waited 2 seconds, but the timestamps show an actual delay of 10 seconds.
[Where problems could occur]
Please see reproduction steps above. We are seeing this in production too (see comment #2).
[Other Info]
A patch to fix the issue is being proposed here. It is a safe fix - it only checks before going into sleep that the timeout never exceeds the user-requested value.
[Original Description]
In some cases, ipconfig can take longer than the user-specified timeouts, causing unexpected delays.
in main.c, in function loop(), the process can go into process_timeout_event() (or process_receive_event() ) and if it encounters an error situation, will set an attempt to "try again later" at time equal now + 10 seconds by setting
s->expire = now + 10;
This can happen at any time during the main event loop, which can end up extending the user-specified timeout if "now + 10" is greater than "start_time + user-specified-timeout".
I believe a patch like the following is needed to avoid this problem:
--- a/usr/kinit/ipconfig/main.c
+++ b/usr/kinit/ipconfig/main.c
@@ -437,6 +437,13 @@ static int loop(void)
if (timeout > s->expire - now.tv_sec)
timeout = s->expire - now.tv_sec;
+
+ /* Compensate for already-lost time */
+ gettimeofday(&now, NULL);
+ if (now.tv_sec + timeout > start + loop_timeout) {
+ timeout = loop_timeout - (now.tv_sec - start);
+ printf("Lowered timeout to match user request = (%d s) \n", timeout);
+ }
}
I believe the current behaviour is buggy. This is confirmed when the following line is executed:
if (loop_timeout >= 0 &&
now.tv_sec - start >= loop_timeout) {
printf("IP-Config: no response after %d "
"secs - giving up\n", loop_timeout);
rc = -1;
goto bail;
}
'loop_timeout' is the user-specified time-out. With a value of 2, in case of error, this line prints:
IP-Config: no response after 2 secs - giving up
So it thinks that it waited 2 seconds - however, in reality it had actually waited for 10 seconds.
The suggested code-change ensures that the timeout that is actually used never exceeds the user-specified timeout. |
[Impact]
In some cases, ipconfig can take a longer time than the user-specified timeouts, causing unexpected delays.
[Test Plan]
Any situation where ipconfig encounters an error sending the DHCP packet, it will automatically set a delay of 10 seconds, which could be longer than the user-specified timeout. It can be reproduced by creating a dummy interface and attempting to run ipconfig on it with a timeout value of less than 10:
# ip link add eth1 type dummy
# date; /usr/lib/klibc/bin/ipconfig -t 2 eth1; date
Thu Nov 18 04:46:13 EST 2021
IP-Config: eth1 hardware address ae:e0:f5:9d:7e:00 mtu 1500 DHCP RARP
IP-Config: no response after 2 secs - giving up
Thu Nov 18 04:46:23 EST 2021
^ Notice above, ipconfig thinks that it waited 2 seconds, but the timestamps show an actual delay of 10 seconds.
[Where problems could occur]
Please see reproduction steps above. We are seeing this in production too (see comment #2).
[Other Info]
A patch to fix the issue is being proposed here. It is a safe fix - it only checks before going into sleep that the timeout never exceeds the user-requested value.
[Original Description]
In some cases, ipconfig can take longer than the user-specified timeouts, causing unexpected delays.
in main.c, in function loop(), the process can go into process_timeout_event() (or process_receive_event() ) and if it encounters an error situation, will set an attempt to "try again later" at time equal now + 10 seconds by setting
s->expire = now + 10;
This can happen at any time during the main event loop, which can end up extending the user-specified timeout if "now + 10" is greater than "start_time + user-specified-timeout".
I believe a patch like the following is needed to avoid this problem:
--- a/usr/kinit/ipconfig/main.c
+++ b/usr/kinit/ipconfig/main.c
@@ -437,6 +437,13 @@ static int loop(void)
if (timeout > s->expire - now.tv_sec)
timeout = s->expire - now.tv_sec;
+
+ /* Compensate for already-lost time */
+ gettimeofday(&now, NULL);
+ if (now.tv_sec + timeout > start + loop_timeout) {
+ timeout = loop_timeout - (now.tv_sec - start);
+ printf("Lowered timeout to match user request = (%d s) \n", timeout);
+ }
}
I believe the current behaviour is buggy. This is confirmed when the following line is executed:
if (loop_timeout >= 0 &&
now.tv_sec - start >= loop_timeout) {
printf("IP-Config: no response after %d "
"secs - giving up\n", loop_timeout);
rc = -1;
goto bail;
}
'loop_timeout' is the user-specified time-out. With a value of 2, in case of error, this line prints:
IP-Config: no response after 2 secs - giving up
So it thinks that it waited 2 seconds - however, in reality it had actually waited for 10 seconds.
The suggested code-change ensures that the timeout that is actually used never exceeds the user-specified timeout.
[ Regression potential ]
This change ensures that user-specified timeouts are never exceeded, which is a problem that appears to happen only in case of interface errors.
It may be that someone is relying on current behaviour where they receive DHCP offers after their specified timeout (but within the 10-second error timeout). However, 1) that is buggy behaviour and should be exposed. Such a user would need to update their specified timeout to make it long enough to receive the DHCP offer (setting the timeout to 10 would keep the existing behaviour). 2) I think it is unlikely that such a scenario exists at all. The 10-second timeout problem happens when there are problems with the interface that prevent it from even sending out the DHCP request. I think it is very unlikely (or even, impossible) that DHCP offers would be received on a dead interface.
Based on the above points, I consider the regression potential to be very low for this change. I do not expect anyone who is currently using ipconfig successfully to notice this change.
I believe the only difference introduced by this is the reduction of delays caused by dead or problematic network interfaces. Those error delays are shortened such that they never exceeed user-specified timeouts. |
|
| 2022-04-25 14:52:57 |
Mauricio Faria de Oliveira |
tags |
sts |
sts sts-sponsor-mfo |
|
| 2022-05-10 21:51:35 |
Mauricio Faria de Oliveira |
klibc (Ubuntu Bionic): status |
Incomplete |
Confirmed |
|
| 2022-05-11 13:46:13 |
Robie Basak |
description |
[Impact]
In some cases, ipconfig can take a longer time than the user-specified timeouts, causing unexpected delays.
[Test Plan]
Any situation where ipconfig encounters an error sending the DHCP packet, it will automatically set a delay of 10 seconds, which could be longer than the user-specified timeout. It can be reproduced by creating a dummy interface and attempting to run ipconfig on it with a timeout value of less than 10:
# ip link add eth1 type dummy
# date; /usr/lib/klibc/bin/ipconfig -t 2 eth1; date
Thu Nov 18 04:46:13 EST 2021
IP-Config: eth1 hardware address ae:e0:f5:9d:7e:00 mtu 1500 DHCP RARP
IP-Config: no response after 2 secs - giving up
Thu Nov 18 04:46:23 EST 2021
^ Notice above, ipconfig thinks that it waited 2 seconds, but the timestamps show an actual delay of 10 seconds.
[Where problems could occur]
Please see reproduction steps above. We are seeing this in production too (see comment #2).
[Other Info]
A patch to fix the issue is being proposed here. It is a safe fix - it only checks before going into sleep that the timeout never exceeds the user-requested value.
[Original Description]
In some cases, ipconfig can take longer than the user-specified timeouts, causing unexpected delays.
in main.c, in function loop(), the process can go into process_timeout_event() (or process_receive_event() ) and if it encounters an error situation, will set an attempt to "try again later" at time equal now + 10 seconds by setting
s->expire = now + 10;
This can happen at any time during the main event loop, which can end up extending the user-specified timeout if "now + 10" is greater than "start_time + user-specified-timeout".
I believe a patch like the following is needed to avoid this problem:
--- a/usr/kinit/ipconfig/main.c
+++ b/usr/kinit/ipconfig/main.c
@@ -437,6 +437,13 @@ static int loop(void)
if (timeout > s->expire - now.tv_sec)
timeout = s->expire - now.tv_sec;
+
+ /* Compensate for already-lost time */
+ gettimeofday(&now, NULL);
+ if (now.tv_sec + timeout > start + loop_timeout) {
+ timeout = loop_timeout - (now.tv_sec - start);
+ printf("Lowered timeout to match user request = (%d s) \n", timeout);
+ }
}
I believe the current behaviour is buggy. This is confirmed when the following line is executed:
if (loop_timeout >= 0 &&
now.tv_sec - start >= loop_timeout) {
printf("IP-Config: no response after %d "
"secs - giving up\n", loop_timeout);
rc = -1;
goto bail;
}
'loop_timeout' is the user-specified time-out. With a value of 2, in case of error, this line prints:
IP-Config: no response after 2 secs - giving up
So it thinks that it waited 2 seconds - however, in reality it had actually waited for 10 seconds.
The suggested code-change ensures that the timeout that is actually used never exceeds the user-specified timeout.
[ Regression potential ]
This change ensures that user-specified timeouts are never exceeded, which is a problem that appears to happen only in case of interface errors.
It may be that someone is relying on current behaviour where they receive DHCP offers after their specified timeout (but within the 10-second error timeout). However, 1) that is buggy behaviour and should be exposed. Such a user would need to update their specified timeout to make it long enough to receive the DHCP offer (setting the timeout to 10 would keep the existing behaviour). 2) I think it is unlikely that such a scenario exists at all. The 10-second timeout problem happens when there are problems with the interface that prevent it from even sending out the DHCP request. I think it is very unlikely (or even, impossible) that DHCP offers would be received on a dead interface.
Based on the above points, I consider the regression potential to be very low for this change. I do not expect anyone who is currently using ipconfig successfully to notice this change.
I believe the only difference introduced by this is the reduction of delays caused by dead or problematic network interfaces. Those error delays are shortened such that they never exceeed user-specified timeouts. |
[Impact]
In some cases, ipconfig can take a longer time than the user-specified timeouts, causing unexpected delays.
[Test Plan]
[racb: pending agreement with the SRU team; please see comment 37]
Any situation where ipconfig encounters an error sending the DHCP packet, it will automatically set a delay of 10 seconds, which could be longer than the user-specified timeout. It can be reproduced by creating a dummy interface and attempting to run ipconfig on it with a timeout value of less than 10:
# ip link add eth1 type dummy
# date; /usr/lib/klibc/bin/ipconfig -t 2 eth1; date
Thu Nov 18 04:46:13 EST 2021
IP-Config: eth1 hardware address ae:e0:f5:9d:7e:00 mtu 1500 DHCP RARP
IP-Config: no response after 2 secs - giving up
Thu Nov 18 04:46:23 EST 2021
^ Notice above, ipconfig thinks that it waited 2 seconds, but the timestamps show an actual delay of 10 seconds.
[Where problems could occur]
Please see reproduction steps above. We are seeing this in production too (see comment #2).
[Other Info]
A patch to fix the issue is being proposed here. It is a safe fix - it only checks before going into sleep that the timeout never exceeds the user-requested value.
[Original Description]
In some cases, ipconfig can take longer than the user-specified timeouts, causing unexpected delays.
in main.c, in function loop(), the process can go into process_timeout_event() (or process_receive_event() ) and if it encounters an error situation, will set an attempt to "try again later" at time equal now + 10 seconds by setting
s->expire = now + 10;
This can happen at any time during the main event loop, which can end up extending the user-specified timeout if "now + 10" is greater than "start_time + user-specified-timeout".
I believe a patch like the following is needed to avoid this problem:
--- a/usr/kinit/ipconfig/main.c
+++ b/usr/kinit/ipconfig/main.c
@@ -437,6 +437,13 @@ static int loop(void)
if (timeout > s->expire - now.tv_sec)
timeout = s->expire - now.tv_sec;
+
+ /* Compensate for already-lost time */
+ gettimeofday(&now, NULL);
+ if (now.tv_sec + timeout > start + loop_timeout) {
+ timeout = loop_timeout - (now.tv_sec - start);
+ printf("Lowered timeout to match user request = (%d s) \n", timeout);
+ }
}
I believe the current behaviour is buggy. This is confirmed when the following line is executed:
if (loop_timeout >= 0 &&
now.tv_sec - start >= loop_timeout) {
printf("IP-Config: no response after %d "
"secs - giving up\n", loop_timeout);
rc = -1;
goto bail;
}
'loop_timeout' is the user-specified time-out. With a value of 2, in case of error, this line prints:
IP-Config: no response after 2 secs - giving up
So it thinks that it waited 2 seconds - however, in reality it had actually waited for 10 seconds.
The suggested code-change ensures that the timeout that is actually used never exceeds the user-specified timeout.
[ Regression potential ]
This change ensures that user-specified timeouts are never exceeded, which is a problem that appears to happen only in case of interface errors.
It may be that someone is relying on current behaviour where they receive DHCP offers after their specified timeout (but within the 10-second error timeout). However, 1) that is buggy behaviour and should be exposed. Such a user would need to update their specified timeout to make it long enough to receive the DHCP offer (setting the timeout to 10 would keep the existing behaviour). 2) I think it is unlikely that such a scenario exists at all. The 10-second timeout problem happens when there are problems with the interface that prevent it from even sending out the DHCP request. I think it is very unlikely (or even, impossible) that DHCP offers would be received on a dead interface.
Based on the above points, I consider the regression potential to be very low for this change. I do not expect anyone who is currently using ipconfig successfully to notice this change.
I believe the only difference introduced by this is the reduction of delays caused by dead or problematic network interfaces. Those error delays are shortened such that they never exceeed user-specified timeouts. |
|
| 2022-05-11 13:46:33 |
Robie Basak |
klibc (Ubuntu): status |
New |
Won't Fix |
|
| 2022-05-11 13:46:41 |
Robie Basak |
klibc (Ubuntu Bionic): status |
Confirmed |
Fix Committed |
|
| 2022-05-11 13:46:43 |
Robie Basak |
bug |
|
|
added subscriber Robie Basak |
| 2022-05-11 13:46:43 |
Robie Basak |
bug |
|
|
added subscriber Ubuntu Stable Release Updates Team |
| 2022-05-11 13:46:44 |
Robie Basak |
bug |
|
|
added subscriber SRU Verification |
| 2022-05-11 13:46:48 |
Robie Basak |
tags |
sts sts-sponsor-mfo |
sts sts-sponsor-mfo verification-needed verification-needed-bionic |
|
| 2022-05-12 13:57:49 |
Fabio Augusto Miranda Martins |
description |
[Impact]
In some cases, ipconfig can take a longer time than the user-specified timeouts, causing unexpected delays.
[Test Plan]
[racb: pending agreement with the SRU team; please see comment 37]
Any situation where ipconfig encounters an error sending the DHCP packet, it will automatically set a delay of 10 seconds, which could be longer than the user-specified timeout. It can be reproduced by creating a dummy interface and attempting to run ipconfig on it with a timeout value of less than 10:
# ip link add eth1 type dummy
# date; /usr/lib/klibc/bin/ipconfig -t 2 eth1; date
Thu Nov 18 04:46:13 EST 2021
IP-Config: eth1 hardware address ae:e0:f5:9d:7e:00 mtu 1500 DHCP RARP
IP-Config: no response after 2 secs - giving up
Thu Nov 18 04:46:23 EST 2021
^ Notice above, ipconfig thinks that it waited 2 seconds, but the timestamps show an actual delay of 10 seconds.
[Where problems could occur]
Please see reproduction steps above. We are seeing this in production too (see comment #2).
[Other Info]
A patch to fix the issue is being proposed here. It is a safe fix - it only checks before going into sleep that the timeout never exceeds the user-requested value.
[Original Description]
In some cases, ipconfig can take longer than the user-specified timeouts, causing unexpected delays.
in main.c, in function loop(), the process can go into process_timeout_event() (or process_receive_event() ) and if it encounters an error situation, will set an attempt to "try again later" at time equal now + 10 seconds by setting
s->expire = now + 10;
This can happen at any time during the main event loop, which can end up extending the user-specified timeout if "now + 10" is greater than "start_time + user-specified-timeout".
I believe a patch like the following is needed to avoid this problem:
--- a/usr/kinit/ipconfig/main.c
+++ b/usr/kinit/ipconfig/main.c
@@ -437,6 +437,13 @@ static int loop(void)
if (timeout > s->expire - now.tv_sec)
timeout = s->expire - now.tv_sec;
+
+ /* Compensate for already-lost time */
+ gettimeofday(&now, NULL);
+ if (now.tv_sec + timeout > start + loop_timeout) {
+ timeout = loop_timeout - (now.tv_sec - start);
+ printf("Lowered timeout to match user request = (%d s) \n", timeout);
+ }
}
I believe the current behaviour is buggy. This is confirmed when the following line is executed:
if (loop_timeout >= 0 &&
now.tv_sec - start >= loop_timeout) {
printf("IP-Config: no response after %d "
"secs - giving up\n", loop_timeout);
rc = -1;
goto bail;
}
'loop_timeout' is the user-specified time-out. With a value of 2, in case of error, this line prints:
IP-Config: no response after 2 secs - giving up
So it thinks that it waited 2 seconds - however, in reality it had actually waited for 10 seconds.
The suggested code-change ensures that the timeout that is actually used never exceeds the user-specified timeout.
[ Regression potential ]
This change ensures that user-specified timeouts are never exceeded, which is a problem that appears to happen only in case of interface errors.
It may be that someone is relying on current behaviour where they receive DHCP offers after their specified timeout (but within the 10-second error timeout). However, 1) that is buggy behaviour and should be exposed. Such a user would need to update their specified timeout to make it long enough to receive the DHCP offer (setting the timeout to 10 would keep the existing behaviour). 2) I think it is unlikely that such a scenario exists at all. The 10-second timeout problem happens when there are problems with the interface that prevent it from even sending out the DHCP request. I think it is very unlikely (or even, impossible) that DHCP offers would be received on a dead interface.
Based on the above points, I consider the regression potential to be very low for this change. I do not expect anyone who is currently using ipconfig successfully to notice this change.
I believe the only difference introduced by this is the reduction of delays caused by dead or problematic network interfaces. Those error delays are shortened such that they never exceeed user-specified timeouts. |
[Impact]
In some cases, ipconfig can take a longer time than the user-specified timeouts, causing unexpected delays.
[Test Plan]
- Check that the ipconfig utility is able to obtain an IP through dhcp:
# ip l set dev ens9 down
# date; /usr/lib/klibc/bin/ipconfig ens9; date
- Check if it respects the timeout (i.e. 2 seconds in the example below):
# ip l set dev ens9 down
# date; /usr/lib/klibc/bin/ipconfig -t 2 ens9; date
- The original issue is that timeout is being ignored when not receiving any reply from a DHCP Server, so for this test you have to stop your DHCP Server (i.e. dnsmasq) and then test the timeouts:
# ip l set dev ens9 down
# date; /usr/lib/klibc/bin/ipconfig -t 2 ens9; date
# ip l set dev ens9 down
# date; /usr/lib/klibc/bin/ipconfig -t 5 ens9; date
Make sure it times out respectivelly in 2 and 5 seconds.
[racb: pending agreement with the SRU team; please see comment 37]
Any situation where ipconfig encounters an error sending the DHCP packet, it will automatically set a delay of 10 seconds, which could be longer than the user-specified timeout. It can be reproduced by creating a dummy interface and attempting to run ipconfig on it with a timeout value of less than 10:
# ip link add eth1 type dummy
# date; /usr/lib/klibc/bin/ipconfig -t 2 eth1; date
Thu Nov 18 04:46:13 EST 2021
IP-Config: eth1 hardware address ae:e0:f5:9d:7e:00 mtu 1500 DHCP RARP
IP-Config: no response after 2 secs - giving up
Thu Nov 18 04:46:23 EST 2021
^ Notice above, ipconfig thinks that it waited 2 seconds, but the timestamps show an actual delay of 10 seconds.
[Where problems could occur]
Please see reproduction steps above. We are seeing this in production too (see comment #2).
[Other Info]
A patch to fix the issue is being proposed here. It is a safe fix - it only checks before going into sleep that the timeout never exceeds the user-requested value.
[Original Description]
In some cases, ipconfig can take longer than the user-specified timeouts, causing unexpected delays.
in main.c, in function loop(), the process can go into process_timeout_event() (or process_receive_event() ) and if it encounters an error situation, will set an attempt to "try again later" at time equal now + 10 seconds by setting
s->expire = now + 10;
This can happen at any time during the main event loop, which can end up extending the user-specified timeout if "now + 10" is greater than "start_time + user-specified-timeout".
I believe a patch like the following is needed to avoid this problem:
--- a/usr/kinit/ipconfig/main.c
+++ b/usr/kinit/ipconfig/main.c
@@ -437,6 +437,13 @@ static int loop(void)
if (timeout > s->expire - now.tv_sec)
timeout = s->expire - now.tv_sec;
+
+ /* Compensate for already-lost time */
+ gettimeofday(&now, NULL);
+ if (now.tv_sec + timeout > start + loop_timeout) {
+ timeout = loop_timeout - (now.tv_sec - start);
+ printf("Lowered timeout to match user request = (%d s) \n", timeout);
+ }
}
I believe the current behaviour is buggy. This is confirmed when the following line is executed:
if (loop_timeout >= 0 &&
now.tv_sec - start >= loop_timeout) {
printf("IP-Config: no response after %d "
"secs - giving up\n", loop_timeout);
rc = -1;
goto bail;
}
'loop_timeout' is the user-specified time-out. With a value of 2, in case of error, this line prints:
IP-Config: no response after 2 secs - giving up
So it thinks that it waited 2 seconds - however, in reality it had actually waited for 10 seconds.
The suggested code-change ensures that the timeout that is actually used never exceeds the user-specified timeout.
[ Regression potential ]
This change ensures that user-specified timeouts are never exceeded, which is a problem that appears to happen only in case of interface errors.
It may be that someone is relying on current behaviour where they receive DHCP offers after their specified timeout (but within the 10-second error timeout). However, 1) that is buggy behaviour and should be exposed. Such a user would need to update their specified timeout to make it long enough to receive the DHCP offer (setting the timeout to 10 would keep the existing behaviour). 2) I think it is unlikely that such a scenario exists at all. The 10-second timeout problem happens when there are problems with the interface that prevent it from even sending out the DHCP request. I think it is very unlikely (or even, impossible) that DHCP offers would be received on a dead interface.
Based on the above points, I consider the regression potential to be very low for this change. I do not expect anyone who is currently using ipconfig successfully to notice this change.
I believe the only difference introduced by this is the reduction of delays caused by dead or problematic network interfaces. Those error delays are shortened such that they never exceeed user-specified timeouts. |
|
| 2022-06-09 14:36:59 |
Mauricio Faria de Oliveira |
tags |
sts sts-sponsor-mfo verification-needed verification-needed-bionic |
sts sts-sponsor-mfo verification-done verification-done-bionic |
|
| 2022-06-09 14:38:41 |
Launchpad Janitor |
klibc (Ubuntu Bionic): status |
Fix Committed |
Fix Released |
|
| 2022-06-09 14:38:44 |
Łukasz Zemczak |
removed subscriber Ubuntu Stable Release Updates Team |
|
|
|
