[Dnsmasq-discuss] DHCPv6 PXE booting - client PXE-E99 error

Geert Stappers stappers at stappers.nl
Tue Oct 15 17:15:32 BST 2019

On Tue, Oct 15, 2019 at 10:13:04AM -0400, Bob Fournier wrote:
> Hi. I could use some dnsmasq configuration advice to get around a UEFI
> client issue when IPv6 PXE booting that results in the client terminating
> the process with a PXE-E99 error.  I've seen this with multiple vendors
> implementations (not all) and a similar issue is described here (albeit for
> IPv4) - https://www.ibm.com/support/pages/pxe-uefi-mode-fails-when-dhcp-server-not-also-tftp-server-ibm-bladecenter-and-system-x
> .
> I'm using dnsmasq 2.79 and the xinetd TFTP server.  The interface has both
> a local IPv6 unicast address and the link-local address.  The local address
> is needed for site local routing for spine/leaf.
> br-ctlplane: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default qlen 1000
>     link/ether 48:df:37:19:90:00 brd ff:ff:ff:ff:ff:ff
>     inet6 fe32:dead:beef::1/64 scope global
>        valid_lft forever preferred_lft forever
>     inet6 fe80::4adf:37ff:fe19:9000/64 scope link
>        valid_lft forever preferred_lft forever
> Here is the dnsmasq config:
> port=0
> interface=br-ctlplane
> listen-address=fe32:dead:beef::1
> dhcp-range=set:ctlplane-subnet,fe32:dead:beef::100,fe32:dead:beef::120,64,10m
> dhcp-sequential-ip
> # dhcpv6.option: Client System Architecture Type (61)
> dhcp-match=set:efi6,option6:61,0007
> dhcp-match=set:efi6,option6:61,0009
> dhcp-match=set:efi6,option6:61,0011
> dhcp-userclass=set:ipxe6,iPXE
> # Client is already running iPXE; move to next stage of chainloading
> dhcp-option=tag:ipxe6,option6:bootfile-url,http://[fe32:dead:beef::1]:8088/inspector.ipxe
> # Client is PXE booting, chainload iPXE
> dhcp-option=tag:efi6,tag:!ipxe6,option6:bootfile-url,tftp://[fe32:dead:beef::1]/ipxe.efi
> The issue is that dnmasq responds to the client Solicit pkt with an
> Advertise using the link-local address as source.  The client does a RRQ to
> the TFTP site local address (fe32:dead:beef) defined in bootfile-url and
> then terminates the process  with a DHCP6 release and logs a PXE-E99 error
> when it receives a TFTP Option Acknowledgement with fe32:dead:beef:X as
> source.  I've obviously tried changing the bootfile-url to use the
> link-local address but the TFTP server still responds with fe32:dead:beef:X
> as source.
> So although this appears to be a client UEFI issue, for a workaround the
> question is - is there a way to coerce dnsmasq to use the fe32:dead:beef::1
> source IP in the DHPv6 Advertise/Reply packets?  I've tried to set the
> listen-address as above to force this but that didn't help.
> Thanks very much for any help.
> Bob
> BTW, here is the tcpdump of the problematic sequence:
> IP6 fe80::a236:9fff:fef4:8094.dhcpv6-client > ff02::1:2.dhcpv6-server: dhcp6 solicit
> P6 fe80::4adf:37ff:fe19:9000.dhcpv6-server >
> fe80::a236:9fff:fef4:8094.dhcpv6-client: dhcp6 advertise
> 09:09:05.515476 IP6 fe80::a236:9fff:fef4:8094.dhcpv6-client > ff02::1:2.dhcpv6-server: dhcp6 request
> 09:09:05.516978 IP6 fe80::4adf:37ff:fe19:9000.dhcpv6-server > fe80::a236:9fff:fef4:8094.dhcpv6-client: dhcp6 reply
> 09:09:05.542660 IP6 fe32:dead:beef::100 > ff02::1:ff00:1: ICMP6, neighbor solicitation, who has fe32:dead:beef::1, length 32
> 09:09:05.542709 IP6 fe32:dead:beef::1 > fe32:dead:beef::100: ICMP6, neighbor advertisement, tgt is fe32:dead:beef::1, length 32
> 09:09:05.542822 IP6 fe32:dead:beef::100.metasage > fe32:dead:beef::1.tftp: 38 RRQ "ipxe.efi" octet tsize 0 blksize 1228
> 09:09:05.545642 IP6 fe32:dead:beef::1.55618 > fe32:dead:beef::100.metasage: UDP, length 28
> 09:09:05.578967 IP6 fe80::a236:9fff:fef4:8094.dhcpv6-client > ff02::1:2.dhcpv6-server: dhcp6 release
> 09:09:05.579576 IP6 fe80::4adf:37ff:fe19:9000.dhcpv6-server > fe80::a236:9fff:fef4:8094.dhcpv6-client: dhcp6 reply

Interesting problem.  Root cause probably isn't in Dnsmasq.
Solution might be Dnsmasq or another TFTP server.

And please contact your procurement department, tell them about this trouble.

Geert Stappers
Leven en laten leven

More information about the Dnsmasq-discuss mailing list