This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

How can I add the “BOOT File name” protocol element to my “DHCP Discover” message?

Hi.

I got a PLUS-license for KEIL uV5 and a KEIL MCBSTM32C evaluation board (for STM32F107).

I want to send my "DHCP Discover" message containing a (random/dummy) "BOOT File name" protocol element.
But the information on www.keil.com/.../group__using__ethernet__interfaces__conf.html
don't seems sufficient (my DHCP-client wont add this "BOOT File name" protocol element).

How can I add the "BOOT File name" protocol element to my "DHCP Discover" message?

best regards
Terje Bøhler

Parents
  • In rfc2131 page 9, the 'file' field is defined as "Boot file name, null terminated string; "generic" name or null in DHCPDISCOVER, fully qualified directory-path name in DHCPOFFER." In other words, it is NOT mandatory to specify a "generic" name to this 'file' field. That means if your DHCP server really follows the rfc2131, it should accept 'NULL' for this 'file' field in DHCP DISCOVER. The more important thing is the option 67 'Bootfile name' in DHCPOFFER from your DHCP server back.

    If you enable the option ETH0_DHCP_BOOTFILE in Net_Config_EHT_0.h, you can see the difference via e.g. Wireshark log, where in DHCPOFFER from DHCP server there will be an additional "Parameter Request List Item: (67) Bootfile name" comparing with the case of ETH0_DHCP_BOOTFILE disabled. That's why in Net_Config_EHT_0.h it is written "If enabled, the Bootfile Name (option 67) is also requested from DHCP server." for ETH0_DHCP_BOOTFILE.

    Thus, the point is not whether or how to specify a boot file name in DHCP DISCOVER. The point is your DHCP server should accept the 'file' field with NULL in DHCPDISCOVER and encode its Bootfile name in DHCPOFFER back to the DHCP client.

Reply
  • In rfc2131 page 9, the 'file' field is defined as "Boot file name, null terminated string; "generic" name or null in DHCPDISCOVER, fully qualified directory-path name in DHCPOFFER." In other words, it is NOT mandatory to specify a "generic" name to this 'file' field. That means if your DHCP server really follows the rfc2131, it should accept 'NULL' for this 'file' field in DHCP DISCOVER. The more important thing is the option 67 'Bootfile name' in DHCPOFFER from your DHCP server back.

    If you enable the option ETH0_DHCP_BOOTFILE in Net_Config_EHT_0.h, you can see the difference via e.g. Wireshark log, where in DHCPOFFER from DHCP server there will be an additional "Parameter Request List Item: (67) Bootfile name" comparing with the case of ETH0_DHCP_BOOTFILE disabled. That's why in Net_Config_EHT_0.h it is written "If enabled, the Bootfile Name (option 67) is also requested from DHCP server." for ETH0_DHCP_BOOTFILE.

    Thus, the point is not whether or how to specify a boot file name in DHCP DISCOVER. The point is your DHCP server should accept the 'file' field with NULL in DHCPDISCOVER and encode its Bootfile name in DHCPOFFER back to the DHCP client.

Children