PXE configuration for dhcpv6 is wrong

Bug #1718209 reported by Witold Krecicki
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
MAAS
Fix Released
High
Andres Rodriguez
2.2
Fix Released
High
Unassigned

Bug Description

DHCP config generator in provisioning server generates config for v6 as:
if client-arch-type = 00:00 {
  filename = "...";
} elsif client-arch-type = 00:07 {
  filename = "...";
} else {
  filename = "final";
}

This is wrong (although it parses correctly it'd always end up with the 'final' filename, confirmed with isc-dhcp team), the correct way to define this kind of switch would be:

if exists dhcp6.client-arch-type and option dhcp6.client-arch-type = 00:00 {
...
} elsif exists dhcp6.client-arch-type and option dhcp6.client-arch-type = 00:07 {
...
}...

Related branches

Revision history for this message
Andres Rodriguez (andreserl) wrote :

Can you provide any references to bugs or similar where this is being shown ? We have enabled and tested the MAAS configuration against ipv6 clients and was proven to work correctly. The work was done, and the configuration reviewed by one of the maintainers of isc-dhcp at the time.

Changed in maas:
status: New → Incomplete
milestone: none → 2.3.0
Revision history for this message
Andres Rodriguez (andreserl) wrote :

Also, please attach your dhcpd.conf so we can see what configuration is being written for you!

Changed in maas:
importance: Undecided → Critical
importance: Critical → High
Revision history for this message
Andres Rodriguez (andreserl) wrote :

Witold,

One clarification. The client architecture code is only used to differentiate with different architectures, as such, we would need logs that show the issue:

1. /var/lib/maas/dhcpd.conf
2. Console log showing how machines from different architectures PXE boot (in the different MAAS stages, e.g. enlistment vs commissioning).
3. /var/log/maas/rackd.log showing the same as 2 above.

Thanks!

Revision history for this message
Andres Rodriguez (andreserl) wrote :

Also, please provide the version of isc-dhcp you have been using (e.g. whether this is xenial or a newer one).

Revision history for this message
Witold Krecicki (wpk) wrote :

isc-dhcp from Xenial - 4.3.3-5ubuntu12.7

The relevant part of config, as generated by maas, looks like this (I've changed filenames to make things clearly visible):

shared-network vlan-5002 {
    subnet6 XXXXXXXXXXXXX::/64 {
           # Bootloaders
           if client-arch-type = 00:01 {
               option dhcp6.bootfile-url "tftp://[XXXXXXXXXXXXX:fa00::1]//00:01";
           } elsif client-arch-type = 00:00 {
               option dhcp6.bootfile-url "tftp://[XXXXXXXXXXXXX:fa00::1]//00:00";
           } elsif client-arch-type = 00:07 {
               option dhcp6.bootfile-url "tftp://[XXXXXXXXXXXXX:fa00::1]//00:07";
           } else {
               option dhcp6.bootfile-url "tftp://[XXXXXXXXXXXXX:fa00::1]//default";
           }
    (...)
}

When trying to boot virsh qemu with fresh iPXE that is sending 00:00 as OPT61 client-arch-type (verified with wireshark, unfortunately tcpdump does not understand DHCPv6 very well) dhcpd returns (...)/default as bootfile to iPXE (as seen on screen1.png)

With modified dhcpd.conf:
           if exists dhcp6.client-arch-type and option dhcp6.client-arch-type = 00:01 {
               option dhcp6.bootfile-url "tftp://[XXXXXXXXXXXXX:fa00::1]//00:01";
           } elsif exists dhcp6.client-arch-type and option dhcp6.client-arch-type = 00:00 {
               option dhcp6.bootfile-url "tftp://[XXXXXXXXXXXXX:fa00::1]//00:00";
           } elsif exists dhcp6.client-arch-type and option dhcp6.client-arch-type = 00:07 {
               option dhcp6.bootfile-url "tftp://[XXXXXXXXXXXXX:fa00::1]//00:07";
           } else {
               option dhcp6.bootfile-url "tftp://[XXXXXXXXXXXXX:fa00::1]//default";
           }
iPXE receives proper '00:00' filename (as seen on screen2.png)

It works without this fix only because of the sane defaults (pxelinux.0 for IPv4 and uefi_amd64 for IPv6), but the client-arch-type was always ignored - in this case when I tried to boot with regular BIOS on IPv6 it tried to load uefi_amd64 which regular bios does not understand (pxelinux.0 won't work either but that's another bug)

Revision history for this message
Witold Krecicki (wpk) wrote :
Changed in maas:
assignee: nobody → Andres Rodriguez (andreserl)
Changed in maas:
status: Incomplete → In Progress
Changed in maas:
status: In Progress → Fix Committed
Changed in maas:
milestone: 2.3.0 → 2.3.0beta1
Changed in maas:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.