Comment 4 for bug 2007167

Revision history for this message
James Denton (james-denton) wrote :

Hi Lucas,

I believe I have tracked this down to the lack of a "null terminated string" for option 66 and 67 presented by OVN. I reverted to a single DHCP agent and disabled OVN DHCP by setting [ovn]disable_ovn_dhcp_for_baremetal_ports = True.

At [1] you will see the full DHCP cycle with OVN DHCP, and at [2] the full DHCP cycle with DHCP Agent (dnsmasq). With OVN DHCP, option 66 and 67 are presented like so:

TFTP (66), length 14: "192.168.208.22"
BF (67), length 8: "ipxe.efi"

In this environment, 192.168.208.22 is the TFTP server IP and is on the same subnet as the PXE network (not routed). However, the PXE client attempts to use 192.168.208.1 as the TFTP server (tftp://192.168.208.1/ipxe.efi), possibly as a fallback.

Using dnsmasq-based DHCP agent, option 66 and 67 are presented like so:

TFTP (66), length 15: "192.168.208.22^@"
BF (67), length 9: "ipxe.efi^@"

Notice the null-termination happening there. With DHCP agent in place, my PXE client successfully loaded tftp://192.168.208.22/ipxe.efi and proceeded with iPXE boot and provisioning.

If it's useful, the system I'm testing with is an HP Proliant DL360 Gen9 PXE booting from the integrated HPE Ethernet 1Gb 4-port 331i Adapter. I believe this is a Broadcom BCM5719-based card. HP firmware 20.18.31. There may be a more recent firmware, but not sure if it handles normal strings or not.

[1] https://paste.opendev.org/show/bQ9ivwpx9rsBOS82bNVS/
[2] https://paste.opendev.org/show/bTqV5nT04949dfQvn3LD/