dhcpcd-discuss

On Wed, May 4, 2016 at 10:03 AM, Roy Marples <roy@xxxxxxxxxxxx> wrote:

> On 04/05/2016 14:25, Shahid Mahmood wrote:
> > Hi
> > We have a scenario where we request a custom option, and if the DHCP
> > server understands the option it returns an offer filled with the value
> > (the "better" offer). If not, we accept whatever server sends us (the
> > 'simple' offer).
> >
> > But in some cases, there are two servers. One sends the "better" offer
> > slightly later (say 1 sec) than the simple offer. We end up using the
> > 'simple' offer.
> >
> > Is it possible to pick the "better" offer even if it comes after a short
> > period (1 sec) later than the 'simple' one?
>
> Well, there are many aspects of "better".
> Generally DHCP servers on the same network segment should be configured
> the same, just with different pools.
>
> > Thoughts:
> > a) "require" the custom option with -Q. If no offer is received within
> > certain time, retry without -Q Side effect: delay for networks without
> > custom option.
> > b) Somehow fireup two parallel instances, one with -Q. Then deal with
> > the lease. (not even sure if this is possible)
> > c) Patch dhcpcd (would like to avoid this)
>
> d) "preferred" option list, similar to -Q, but adds weight to a message.
> This option would cause dhcpcd to stall for reboot timeout seconds until
> DHCP DISCOVER is replied to with all preferred options.
> Upon timeout the received replies would be sorted by preferred option
> availability (not option value) and dhcpcd will then bind to this server.
> Once bound it stays bound and will not prefer a "beter" server until the
> lease is dropped (expired, carrier, release for example).
>
> This probably won't be trivial to do in the very near future.
>
> Roy
>

So we can't do it today? Is that right? What about option a? Any issues
other than the delay?
(I deduce option b is out as anticipated)

Thanks!
-shahid