<div dir="ltr"><div class="gmail_default" style="font-family:arial,sans-serif;font-size:small">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) - <a href="https://www.ibm.com/support/pages/pxe-uefi-mode-fails-when-dhcp-server-not-also-tftp-server-ibm-bladecenter-and-system-x">https://www.ibm.com/support/pages/pxe-uefi-mode-fails-when-dhcp-server-not-also-tftp-server-ibm-bladecenter-and-system-x</a>.<br><br>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><br>br-ctlplane: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default qlen 1000<br>    link/ether 48:df:37:19:90:00 brd ff:ff:ff:ff:ff:ff<br>    inet6 fe32:dead:beef::1/64 scope global <br>       valid_lft forever preferred_lft forever<br>    inet6 fe80::4adf:37ff:fe19:9000/64 scope link <br>       valid_lft forever preferred_lft forever<br><br>Here is the dnsmasq config:<br>port=0<br>interface=br-ctlplane<br>listen-address=fe32:dead:beef::1<br>dhcp-range=set:ctlplane-subnet,fe32:dead:beef::100,fe32:dead:beef::120,64,10m<br>dhcp-sequential-ip<br># dhcpv6.option: Client System Architecture Type (61)<br>dhcp-match=set:efi6,option6:61,0007<br>dhcp-match=set:efi6,option6:61,0009<br>dhcp-match=set:efi6,option6:61,0011<br>dhcp-userclass=set:ipxe6,iPXE<br># Client is already running iPXE; move to next stage of chainloading<br>dhcp-option=tag:ipxe6,option6:bootfile-url,http://[fe32:dead:beef::1]:8088/inspector.ipxe<br># Client is PXE booting, chainload iPXE<br>dhcp-option=tag:efi6,tag:!ipxe6,option6:bootfile-url,tftp://[fe32:dead:beef::1]/ipxe.efi<br><br>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.  <br><br>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.<br><br>Thanks very much for any help.<br>Bob<br><br>BTW, here is the tcpdump of the problematic sequence:<br>IP6 fe80::a236:9fff:fef4:8094.dhcpv6-client > ff02::1:2.dhcpv6-server: dhcp6 solicit<br>P6 fe80::4adf:37ff:fe19:9000.dhcpv6-server > fe80::a236:9fff:fef4:8094.dhcpv6-client: dhcp6 advertise<br>09:09:05.515476 IP6 fe80::a236:9fff:fef4:8094.dhcpv6-client > ff02::1:2.dhcpv6-server: dhcp6 request<br>09:09:05.516978 IP6 fe80::4adf:37ff:fe19:9000.dhcpv6-server > fe80::a236:9fff:fef4:8094.dhcpv6-client: dhcp6 reply<br>09:09:05.542660 IP6 fe32:dead:beef::100 > ff02::1:ff00:1: ICMP6, neighbor solicitation, who has fe32:dead:beef::1, length 32<br>09:09:05.542709 IP6 fe32:dead:beef::1 > fe32:dead:beef::100: ICMP6, neighbor advertisement, tgt is fe32:dead:beef::1, length 32<br>09:09:05.542822 IP6 fe32:dead:beef::100.metasage > fe32:dead:beef::1.tftp:  38 RRQ "ipxe.efi" octet tsize 0 blksize 1228<br>09:09:05.545642 IP6 fe32:dead:beef::1.55618 > fe32:dead:beef::100.metasage: UDP, length 28<br>09:09:05.578967 IP6 fe80::a236:9fff:fef4:8094.dhcpv6-client > ff02::1:2.dhcpv6-server: dhcp6 release<br>09:09:05.579576 IP6 fe80::4adf:37ff:fe19:9000.dhcpv6-server > fe80::a236:9fff:fef4:8094.dhcpv6-client: dhcp6 reply<br></div></div>