On 2023-08-28, Christopher Sean Hilton <ch...@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.
