Re: Dhcpleased feature request.

On Tue, Aug 29, 2023 at 08:53:14AM -0000, Stuart Henderson wrote:
> On 2023-08-28, Christopher Sean Hilton <chris@vindaloo.com> wrote:
> > I'd be fine with
> > dhcpleased if I can set an option to ask the dhcp server for a
> > specific lease time. I know that the server need not honor my request
> > but the dhcp server that I'm using will honor a reasonable duration,
> > say a fraction of a day. The default lease length is 30 minutes.
>
> I do think this is a useful thing to be able to add to the request and
> probably is something that dhcpleased should have.
>
> > I'm reading through the dhclient code now to see how it implements the
> > lease time option. If I'm capable, I'll send in a patch.
>
> You probably won't find dhclient code to be particularly helpful in
> implementing this. In dhclient the set of all requested options is built up in
> one place, then written to the packet separately, and it's all dine in
> one process so it's just stored in memory. In dhcpleased the values
> for a fixed set of config options are passed through a message-passing
> framework between several processes and the request packet is built,
> using the options values if they were set but otherwise ignoring them.
>
> It's easiest to first hardcode the actual requested lease time and get
> the packet sending to work (a few lines of code in one function) before
> looking at making it configurable (not difficult, but requires changes
> in various pieces of code in different files).
>
> You would need to add to the request in dhcpleased/frontend.c's
> build_packet() function. See how the various options are appended to the
> buffer dhcp_packet by incrementing the pointer p and writing/copying to
> it. See how existing config options like hostname and client id are
> added (first byte is the option number using the relevant DHO_DHCP_xxx
> #define, followed by the number of bytes used to encode that option
> value, followed by the value).
>
> In this case it's DHO_DHCP_LEASE_TIME (numerically that's 51), and it's
> always 4 bytes and written as an unsigned integer (number of seconds).
> (https://datatracker.ietf.org/doc/html/rfc2132#section-9.2)
>
> Note the value must be in network byte order; htonl will be needed to
> convert from host byte order.
>
> To make it configurable in dhcpleased a bunch of 'plumbing' is needed,
> follow how an existing option like hostname is passed through from the
> config parser to the engine to where the request packets are actually
> built via messages sent through the imsg api. Nothing really tricky
> but it's a bit of a pipeline of different pieces that need connecting
> and it's probably more encouraging to see your efforts show up in the
> transmitted packet before starting on that.
>
> You might find the graphical wireshark utility to be helpful in the
> initial stage of changing build-packet() as you can click on the decoded
> DHCP options in the request and see how they translate to bytes in the
> packet. Or tcpdump, but the concise output format used by the dhcp
> decoder isn't very obvious at first.
>
>

Stuart, Thanks for the tips. That will save me a bucket of time. I
have a couple of hours on the train this afternoon. I'll look into
things then.

Thanks again

--
Chris

__o "All I was trying to do was get home from work."
_`\<,_ -Rosa Parks
___(*)/_(*)____.___o____..___..o...________ooO..._____________________
Christopher Sean Hilton [chris/at/vindaloo/dot/com]