udhcpc: Wrong lease time is passed to the --script (PATCH)

Markus Gothe nietzsche at lysator.liu.se
Thu Jul 16 08:27:06 UTC 2020


Seems legitimate, I agree that if you want to keep things in sync it is problematic when it gives the script the wrong information.

//Markus

Sent from my BlackBerry - the most secure mobile device


	  Original Message  	


From: karel.dolezal at ui.com
Sent: July 16, 2020 10:12
To: nietzsche at lysator.liu.se
Cc: busybox at busybox.net
Subject: Re: udhcpc: Wrong lease time is passed to the --script (PATCH)


Hi Markus,

Thanks for looking at my suggestion. I'd like to explain my point of
view better:

It would be fairly easy to mimick the said "minimum lease time" check
in the script. However, that introduces a problem of duplicated code
which is hard to maintain. Whenever busybox updated this minimum, the
script could break for some users. For example, a recent change moved
this min value from 16s to 122s.

https://www.mail-archive.com/busybox@busybox.net/msg25448.html

In my view, the unexpected/mismatched behavior is already there, as
the udhcpc "says A and does B". It would be just fine if both udhcpc
and the script used the original lease time provided by the server
(30s). However, udhcpc does not. (probably because it honors the
rfc2131 rule for minimum interval of 60s before attempting renewal)

In systems where the --script option is used, udhcpc is not making
system changes itself, it's only a "middleman", and so it becomes
problematic if it "lies" about what it's doing (it postpones address
renewal (T1) to 61s, instead of using 15s). It currently requires
special considerations from the user.


> else it will introduce an unexpected behavior.

In case you are not convinced, can you please elaborate on that
statement? What are the use cases for the current solution? Why would
the user/script be interested in a value which is not respected by
udhcpc?



Thanks for your time.

Regards
Karel


More information about the busybox mailing list