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