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
_______________________________________________
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

Reply via email to