1. Edk2 | Discuss
  2. Topics

BUG: System UUID not being read correctly

brogrammerjohn@...
 

Hey there folks. I'd like to make a formal bugreport on Bugzilla, but as I'm new to this project, I can't have an account yet. So, I'm writing here.

What I am attempting to do: boot a system via PXE-IPv6 with static DHCP configuration based on DUID-UUID (https://datatracker.ietf.org/doc/html/rfc6355).

What the issue is: The UUID isn't being used correctly when sending a DHCP solicitation message.

Steps to reproduce:

- Set up GNS3
- Get two basic Linux VMs up and running.
- Capture traffic between them
- Set one VM's UUID to a pre-defined value
- Set it to boot through PXE IPv6
- Watch it send out a completely random (but constant) DUID and not the one you've set.

My investigation:

So I'm trying to setup static DHCP for the purposes of employing Fully Automated Install (https://fai-project.org/fai-guide.pdf) over IPv6. The DHCP server would be isc-dhcp-server. And while nothing prohibits me from identifying hosts as usual - via MAC addresses, it doesn't work. Only DUID. There are four kinds of DUIDs - Enterprise number-based DUID, Link-Local address based, LLA+Timestamp based, and UUID-based. Now booting up OVMF-powered VM (via QEMU) and capturing the traffic with Wireshark I determine the method employed by OVMF is UUID-based. So I set my UUID to a specific value by two separate methods - the one recommended by GNS3 (https://docs.gns3.com/docs/emulators/qemu-system-uuid/) and via SMBIOS entry (https://wiki.qemu.org/images/d/d7/DSP0134_2.6.1.pdf 3.3.2.1 System — UUID), and the changes are not being reflected in Wireshark traffic capture, the DHCP solicit message specifically. The UUID is always set to "8c69d3135e29984189e1e1d1c2dcf7dd", why this one specifically - I've looked through the source code for OVMF and I have no idea. And the issue isn't with QEMU or GNS3 - when Linux gets booted off disk as usual, the "dmidecode -s system-uuid" command yields the correct result. Moreover - after entering the UEFI shell and entering the "SmbiosView" command - there it is, in the correct record. It's there, the UEFI shell finds it, the Linux kernel sees it. But it doesn't get included into the DHCP solicitation message.

The relevant part of the source code is here - (https://github.com/tianocore/edk2/blob/7c0ad2c33810ead45b7919f8f8d0e282dae52e71/NetworkPkg/Dhcp6Dxe/Dhcp6Utility.c#L59). The DUID type is UUID (number four) specifically, so it definitely is this part of the source code that is in some way buggy. I am using Arch Linux, OVMF package is - "edk2-ovmf-202205-1", the most recent version. QEMU 7.0.

What do I want?

- Figure out where the DUID of "8c69d3135e29984189e1e1d1c2dcf7dd" comes from

- Get an example of properly setting the UUID for it to get reflected in DHCPv6 solicitation message during PXE

- If the software really is exhibiting undocumented behavior - for it to be fixed.
Andrew Fish
 

I’d try dumping the SMBIOS tables to make sure your UUID is there. NetLibGetSystemGuid() is grading the UUID from the SMBIOS Type 1 record.


FYI PcdDhcp6UidType is a build config knob. Looks like it defaults to Dhcp6DuidTypeUuid

/Volumes/Case/edk2(master)>git grep Dhcp6DuidTypeUuid -- \*.h
MdePkg/Include/IndustryStandard/Dhcp.h:163: Dhcp6DuidTypeUuid = 4

///
/// Enumeration of Duid type recorded by IANA, refers to section-24.5 of rfc-3315.
///
typedef enum {
Dhcp6DuidTypeLlt = 1,
Dhcp6DuidTypeEn = 2,
Dhcp6DuidTypeLl = 3,
Dhcp6DuidTypeUuid = 4
} DHCP6_DUID_TYPE;

/Volumes/Case/edk2(master)>git grep PcdDhcp6UidType -- \*.dec \*.dec
NetworkPkg/NetworkPkg.dec:137: gEfiNetworkPkgTokenSpaceGuid.PcdDhcp6UidType|4|UINT8|0x10000001


Thanks,

Andrew Fish

On Jul 14, 2022, at 3:19 PM, John Brogrammer via groups.io <brogrammerjohn@...> wrote:

Hey there folks. I'd like to make a formal bugreport on Bugzilla, but as I'm new to this project, I can't have an account yet. So, I'm writing here.

What I am attempting to do: boot a system via PXE-IPv6 with static DHCP configuration based on DUID-UUID (https://datatracker.ietf.org/doc/html/rfc6355).

What the issue is: The UUID isn't being used correctly when sending a DHCP solicitation message.

Steps to reproduce:

- Set up GNS3
- Get two basic Linux VMs up and running.
- Capture traffic between them
- Set one VM's UUID to a pre-defined value
- Set it to boot through PXE IPv6
- Watch it send out a completely random (but constant) DUID and not the one you've set.

My investigation:

So I'm trying to setup static DHCP for the purposes of employing Fully Automated Install (https://fai-project.org/fai-guide.pdf) over IPv6. The DHCP server would be isc-dhcp-server. And while nothing prohibits me from identifying hosts as usual - via MAC addresses, it doesn't work. Only DUID. There are four kinds of DUIDs - Enterprise number-based DUID, Link-Local address based, LLA+Timestamp based, and UUID-based. Now booting up OVMF-powered VM (via QEMU) and capturing the traffic with Wireshark I determine the method employed by OVMF is UUID-based. So I set my UUID to a specific value by two separate methods - the one recommended by GNS3 (https://docs.gns3.com/docs/emulators/qemu-system-uuid/) and via SMBIOS entry (https://wiki.qemu.org/images/d/d7/DSP0134_2.6.1.pdf 3.3.2.1 System — UUID), and the changes are not being reflected in Wireshark traffic capture, the DHCP solicit message specifically. The UUID is always set to "8c69d3135e29984189e1e1d1c2dcf7dd", why this one specifically - I've looked through the source code for OVMF and I have no idea. And the issue isn't with QEMU or GNS3 - when Linux gets booted off disk as usual, the "dmidecode -s system-uuid" command yields the correct result. Moreover - after entering the UEFI shell and entering the "SmbiosView" command - there it is, in the correct record. It's there, the UEFI shell finds it, the Linux kernel sees it. But it doesn't get included into the DHCP solicitation message.

The relevant part of the source code is here - (https://github.com/tianocore/edk2/blob/7c0ad2c33810ead45b7919f8f8d0e282dae52e71/NetworkPkg/Dhcp6Dxe/Dhcp6Utility.c#L59). The DUID type is UUID (number four) specifically, so it definitely is this part of the source code that is in some way buggy. I am using Arch Linux, OVMF package is - "edk2-ovmf-202205-1", the most recent version. QEMU 7.0.

What do I want?

- Figure out where the DUID of "8c69d3135e29984189e1e1d1c2dcf7dd" comes from

- Get an example of properly setting the UUID for it to get reflected in DHCPv6 solicitation message during PXE

- If the software really is exhibiting undocumented behavior - for it to be fixed.
John Brogrammer <brogrammerjohn@...>
 

I’d try dumping the SMBIOS tables to make sure your UUID is there.
Doesn't entering UEFI Shell and entering the "SmbiosView" count as dumping the SMBIOS tables? I already did it and said about it in the initial message. Could you try and set DUID for a VM to replicate the bug I've found?

OpenPGP_0x5432281948A156A4.asc

OpenPGP_0x5432281948A156A4.asc
OpenPGP_signature

OpenPGP_signature

1 - 3 of 3