[Bug 1947099] Re: ipconfig does not honour user-requested timeouts in some cases

[Khaled El Mously]

Hello @Eric.

> What make Bionic more susceptible to this particular problem ? Bionic
kernel version in use ? else ?

I believe klibc/ipconfig itself is susceptible to the problem in Bionic
and Focal and elsewhere. However, Focal (which uses klibc 2.0.7) uses
dhclient for networking initialization instead of ipconfig, therefore I
am not really concerned about fixing the ipconfig issue in Focal since
it is not causing any noticeable problems.

I have checked the HEAD of the klibc project and it appears that
ipconfig is still susceptible to the timeout problem. Sure I can propose
the patch upstream if you like - however, even if they accept it I
believe we will still need to apply it separately for Bionic because I
do not expect that Bionic will receive any major updates for klibc, so
it will not get any upstream fixes. It will remain on 2.0.4 as far as I
know. It is currently version 2.0.4-9ubuntu2 in Bionic which means we
are carrying (2?) Ubuntu-specific patches on top of 2.0.4. I believe
this fix can be added as well to produce 2.0.4-9ubuntu3.

I will attempt to upstream this fix to klibc, but I believe the change
to Bionic should happen in parallel/independently since the upstream
patch will not make its way back to Bionic (which is stuck at 2.0.4, as
mentioned above).

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to klibc in Ubuntu.
https://bugs.launchpad.net/bugs/1947099

Title:
  ipconfig does not honour user-requested timeouts in some cases

Status in klibc package in Ubuntu:
  New
Status in klibc source package in Bionic:
  New

Bug 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.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/klibc/+bug/1947099/+subscriptions