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

Bob Fournier bfournie at redhat.com
Tue Oct 15 15:13:04 BST 2019

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) -

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:
# dhcpv6.option: Client System Architecture Type (61)
# Client is already running iPXE; move to next stage of chainloading
# Client is PXE booting, chainload iPXE

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.

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/attachments/20191015/1b5a3a90/attachment.html>

More information about the Dnsmasq-discuss mailing list