1

I am working on an embedded Linux which uses BusyBox and udhcpc (part of BusyBox) as its DHCP client.

If I configure the DHCP server to deliver an FTP server in the DHCP option 66 everything is fine (i.e. the tftp variable in the /etc/udhcpc.script contains the configured value) as long as the option contains a hostname (a valid DNS name, probably?!). If the option contains an IP address, the variable tftp contains the value "bad".

What are the reason and the point of this behavior?

I cannot find any information in the udhcpc documentation about this behavior (https://udhcp.busybox.net/README.udhcpc, https://udhcp.busybox.net/) nor do I get any useful search results on Google.

RFC2132 does not contain any restrictions that disallow IP addresses in this option (to my understanding).

Is there any way to get the IP address from option 66 in udhcpc?

1

UPDATE: options 150 (or 66) are often not needed to use a separate TFTP server, the original siaddr field should be enough if configurable on the DHCP server, see at the end.

RFC 5859 tells this:

Abstract

This memo documents existing usage for the "TFTP Server Address"
option. The option number currently in use is 150.

[...]

There are two commonly accepted methods to discover this server via DHCP; the "sname" field in the DHCP header [RFC2131] and the "TFTP Server Name" option (66) [RFC2132]. Both of these sources of information, however, contain the TFTP server's hostname. That hostname must then be translated to an IP address. The usual method to accomplish this would be DNS [RFC1034].

[...]

  1. TFTP Server Address Option Definition

The TFTP Server Address option is a DHCP option [RFC2132]. The option contains one or more IPv4 addresses that the client MAY use. The current use of this option is for downloading configuration from a VoIP server via TFTP; however, the option may be used for purposes other than contacting a VoIP configuration server.

The format of the option is:

Code   Len   IPv4 Configuration Server Address(es)
+-----+-----+-----+-----+-----+-----+
| 150 |  n  |     IPv4 address      | ...
+-----+-----+-----+-----+-----+-----+

              Figure 1

The option minimum length (n) is 4.

[...]

So I can only tell the answer to your question is: no, you can't use option 66 at all for this, you should support DHCP option 150 or the siaddr field which is the "next-server" configuration pointing to the TFTP server, but this RFC mentions some limited DHCP servers will only return themselves in this field.


UPDATE (to clarify the solution might be simpler than thought):

If providing the correct siaddr (ie different from the DHCP server itself) is supported by the DHCP server (eg: ISC dhcp, or busybox's own udhcpd), then it's of course already supported by the udhcpcd client:

The paramaters for enviromental variables are as follows:

$HOME     - The set $HOME env or "/"

[...]

siaddr        - The bootp next server option

[...]

siaddr is what I've been using so far to boot x86 systems over DHCP with a separate TFTP server, for example straight to a Debian network installation. I didn't know about nor need options 66 or 150.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.