On Tue, Aug 30, 2022 at 11:35 PM <[email protected]> wrote:
> From: Luca Boccassi <[email protected]>
>
> It is useful for applications to be able to query DHCP options
> without renewing IP address. Instead of a full DHCP handshake,
> using -I will cause a single DHCPINFORM packet to be sent, and
> the server response (including DHCP options received) to be
> printed and terminate. No configuration will be changed.
>
> This is useful for clients that want to query additional information
> from a server, that might not be normally processed, like custom
> server options. Also useful for checking specific options via -O.
>
> As per RFC 2131, allow targeting the already-known DHCP server via
> unicast instead of broadcast, via new -e option.
>
> Tested by running isc-dhcp-server with the following configuration:
>
> option domain-name "example.org";
> option domain-name-servers 1.1.1.1, 8.8.8.8;
> subnet 192.168.11.0 netmask 255.255.255.0 {
> range 192.168.11.1 192.168.11.100;
> authoritative;
> option default-url "default.url";
> }
>
> $ busybox udhcpc -I -i host0 -O 114 -r 192.168.11.1
> udhcpc: started, v1.36.0.git
> udhcpc: broadcasting inform for 192.168.11.1, server 0.0.0.0
> udhcpc: lease of 0.0.0.0 obtained from 0.0.0.0, lease time 3600 (default)
> udhcpc: option: opt53=0x05
> udhcpc: option: serverid=192.168.11.101
> udhcpc: option: subnet=255.255.255.0
> udhcpc: option: dns=1.1.1.1 8.8.8.8
> udhcpc: option: domain=example.org
> udhcpc: option: opt114=0x64656661756c742e75726c
>
> $ busybox udhcpc -e 192.168.11.101 -I -i host0 -O 114 -r 192.168.11.1
> udhcpc: started, v1.36.0.git
> udhcpc: unicasting inform for 192.168.11.1, server 192.168.11.101
> udhcpc: lease of 0.0.0.0 obtained from 192.168.11.101, lease time 3600
> (default)
> udhcpc: option: opt53=0x05
> udhcpc: option: serverid=192.168.11.101
> udhcpc: option: subnet=255.255.255.0
> udhcpc: option: dns=1.1.1.1 8.8.8.8
> udhcpc: option: domain=example.org
> udhcpc: option: opt114=0x64656661756c742e75726c
The use case is unclear. For the above examples,
how is this supposed to be used outside of manual debug runs
to see what server responds with?
E.g. if used from a script or another tool:
* how -r IP_ADDR value is to be determined?
* are results meant to be parsed by looking at stderr??
udhcpc6 needed this functionality more urgently
because IPv6 address autoconfiguration without DHCP is common,
yet DHCP *is* useful/needed in many environments to retrieve
other data, such as NTP server address and whatnot -
this means people need to run DHCP, but don't need to get the address.
udhcpc6 now has a -l option for this, and (as far as I understand it)
the effect is that udhcpc6 runs as normal (i.e. usually as a daemon,
it runs a script when it gets replies, etc), it just sends
an INFORMATION_REQUEST instead of discover / select:
case INIT_SELECTING:
- send_d6_discover(xid, requested_ipv6);
+ if (opt & OPT_l)
+ send_d6_info_request(xid);
+ else
+ send_d6_discover(xid,
requested_ipv6);
case RENEWING:
- send_d6_renew(xid, &srv6_buf,
requested_ipv6);
+ if (opt & OPT_l)
+ send_d6_info_request(xid);
+ else
+ send_d6_renew(xid,
&srv6_buf, requested_ipv6);
case REBINDING:
<similar>
This means that the handling of replies is (I assume) easier, it is done
in the script, by looking at environment variables.
Should we do it this/similar way for DHCPv4 too?
If not, why not, and what is the way which works for your use case?
For example:
""We assume we have eth4 IP address (and routing and such) configured,
for example static configuration.
We run "udhcpc -I -i eth4 -O 114" to get option 114
...periodically?
...once, in some post-address-configuration script?
...how do you learn IP address of the DHCP server?
""
_______________________________________________
busybox mailing list
[email protected]
https://lists.busybox.net/mailman/listinfo/busybox
