Re: [EXTERNAL] Re: [edk2-devel] NetworkPkg: Unexpected DHCP RELEASE after PXE server reply on IPv6

["Bret Barkelew" <bret.barkelew@microsoft.com>]

[-- Attachment #1.1: Type: text/plain, Size: 10342 bytes --]

Maciej and Vincent,

We’ve captured data that demonstrates that EDK2 is handling IPv4 differently than IPv6. I’ve opened a bug to track this work:
3471 – Unexpected DHCP RELEASE after PXE server reply on IPv6; IPv4 handled differently (tianocore.org)<https://bugzilla.tianocore.org/show_bug.cgi?id=3471>

The captures were large, so I’ve shared them with OneDrive links.
The IPv4 capture shows that the UEFI is _not_ responding with a special UDP request.

Thoughts?

- Bret

From: LathaKannan Arumugam<mailto:larumugam@microsoft.com>
Sent: Tuesday, June 29, 2021 11:54 AM
To: Zimmer, Vincent<mailto:vincent.zimmer@intel.com>; devel@edk2.groups.io<mailto:devel@edk2.groups.io>; Bret Barkelew<mailto:Bret.Barkelew@microsoft.com>; maciej.rabeda@linux.intel.com<mailto:maciej.rabeda@linux.intel.com>
Subject: RE: [EXTERNAL] Re: [edk2-devel] NetworkPkg: Unexpected DHCP RELEASE after PXE server reply on IPv6

Thanks Vincent and Maciej for the your inputs. We made some more analysis and want your inputs for the same.

Test:1


  1.  DHCPv6 server replied with IANA,  Option 16(Vendor class with String as PxeClient), Option 59(Boot File URL with TFTP address), and Option 60 (BootFileParam)

Analysis: It is observed UEFI is trying to send boot server request based on the address mentioned in the boot file URL which is unicast. And this is done as part of SARR and as station IP is not assigned, the route lookup failed and packet dropped. If I use any link-local address in boot file URL , then request goes out. But in our case, PXE client and server are not on same link. So should the order be changed here. Finish SARR, assign Station IP and then do Boot server request.

Test:2
DHCPv6 server replied with IANA , Option 59(Boot File URL with TFTP address), and Option 60 (BootFileParam). I did not include Option 16(Pxe vendor string)
Analysis: It is observed that UEFI expects boot file length in 512 byte resolution and the did parsing was not in line with rfc5970 (ietf.org)<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc5970%23section-3.2&data=04%7C01%7CBret.Barkelew%40microsoft.com%7C2810d8102cea4be5741208d93b2f4e7e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637605896636463718%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=z6b5uIqrd7xDaa6EtAoiggvG1UgufNQrOuRBH4oK0gY%3D&reserved=0>.  Can you tell us what is the expectation here? Please find the attached file for how option 60 is added by server.

Test:3

DHCPv6 server replied with IANA , Option 59(Boot File URL with TFTP address). I did not include Option 16(Pxe vendor string) and Option 60(BootFileParam)
As the reply does not carry PxeVendor string and boot file param, It is observed that UEFI finished SARR and station IPv6 was configured. It also went ahead and downloaded bootx64.efi file which was mentioned in option 59.
We also observed that UEFI loaded bootMgr and but eventually failed  with following error on screen.  We want UEFI to boot it in this method. Can you share us what needs to be done to move forward in this direction?

[cid:image003.png@01D76DBE.63C70480]



From: Zimmer, Vincent <vincent.zimmer@intel.com>
Sent: Tuesday, June 29, 2021 10:34 AM
To: devel@edk2.groups.io; Bret Barkelew <Bret.Barkelew@microsoft.com>; maciej.rabeda@linux.intel.com; LathaKannan Arumugam <larumugam@microsoft.com>
Subject: RE: [EXTERNAL] Re: [edk2-devel] NetworkPkg: Unexpected DHCP RELEASE after PXE server reply on IPv6

FYI
For IPv6, the TFTP-based network boot process (i.e., pxe) is called Netboot6 & detailed in “24.3.1 Netboot6”/” 24.3.1.2 IPv6-based PXE boot", and for IPV4 PXE we also curate changes/clarifications in “E.4.20 PXE 2.1 specification wire protocol clarifications”, all of which are found in https://uefi.org/sites/default/files/resources/UEFI_Spec_2_9_2021_03_18.pdf<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fuefi.org%2Fsites%2Fdefault%2Ffiles%2Fresources%2FUEFI_Spec_2_9_2021_03_18.pdf&data=04%7C01%7CBret.Barkelew%40microsoft.com%7C2810d8102cea4be5741208d93b2f4e7e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637605896636473672%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=iVMicYpEcGSV1wNXEL9zDV2%2F5ZeK5jFgFabbCwuk%2FUU%3D&reserved=0> since http://www.pix.net/software/pxeboot/archive/pxespec.pdf<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.pix.net%2Fsoftware%2Fpxeboot%2Farchive%2Fpxespec.pdf&data=04%7C01%7CBret.Barkelew%40microsoft.com%7C2810d8102cea4be5741208d93b2f4e7e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637605896636473672%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=%2FXkhfh7PmOXMn4Tu2uG6Dk2GMYaaFwlhlhnSB8oYonA%3D&reserved=0> is frozen/unmaintained at this point.

Vincent


From: devel@edk2.groups.io<mailto:devel@edk2.groups.io> <devel@edk2.groups.io<mailto:devel@edk2.groups.io>> On Behalf Of Bret Barkelew via groups.io
Sent: Tuesday, June 29, 2021 9:54 AM
To: devel@edk2.groups.io<mailto:devel@edk2.groups.io>; maciej.rabeda@linux.intel.com<mailto:maciej.rabeda@linux.intel.com>; LathaKannan Arumugam <larumugam@microsoft.com<mailto:larumugam@microsoft.com>>
Subject: Re: [EXTERNAL] Re: [edk2-devel] NetworkPkg: Unexpected DHCP RELEASE after PXE server reply on IPv6

Thanks, Maciej! We’ll investigate!

- Bret

From: Rabeda, Maciej <maciej.rabeda@linux.intel.com<mailto:maciej.rabeda@linux.intel.com>>
Sent: Tuesday, June 29, 2021 9:39:59 AM
To: devel@edk2.groups.io<mailto:devel@edk2.groups.io> <devel@edk2.groups.io<mailto:devel@edk2.groups.io>>; LathaKannan Arumugam <larumugam@microsoft.com<mailto:larumugam@microsoft.com>>; Bret Barkelew <Bret.Barkelew@microsoft.com<mailto:Bret.Barkelew@microsoft.com>>
Subject: Re: [EXTERNAL] Re: [edk2-devel] NetworkPkg: Unexpected DHCP RELEASE after PXE server reply on IPv6

Additionally, for claim that IPv4 does not do that, please provide Wireshark trace, if available.
On 29-Jun-21 18:36, Maciej Rabeda wrote:
Hi guys,

Finally got some time to look into it.

Long story short, this smells like infrastructure problem.
SARR passes over 546/547 port pair. That is between UEFI PXE client and DHCP server (even if it is the same machine).
The next packet is essentially a Boot Server choice step. UEFI PXE client sends a unicast discovery packet towards Boot server (same machine, same address) coded as DHCP Request.
The release packet is a direct reaction to 3 second timeout (see time diff between packet 9 and 11).

See section 2.2.1 in PXE spec: http://www.pix.net/software/pxeboot/archive/pxespec.pdf<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.pix.net%2Fsoftware%2Fpxeboot%2Farchive%2Fpxespec.pdf&data=04%7C01%7CBret.Barkelew%40microsoft.com%7C2810d8102cea4be5741208d93b2f4e7e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637605896636483629%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=9mwsE3chGgjMSgKQE0dklTdNuhZvdmNdIyxzi%2F7wZ%2Fs%3D&reserved=0>

Please verify that your WDS service is running correctly, since clearly there is no reaction to that packet from Boot server.

[cid:image001.png@01D76CDA.A49138D0]
On 28-Jun-21 22:05, LathaKannan Arumugam via groups.io wrote:
Can you please help us on this issues?
Get Outlook for Android<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Faka.ms%2FAAb9ysg&data=04%7C01%7CBret.Barkelew%40microsoft.com%7C2810d8102cea4be5741208d93b2f4e7e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637605896636483629%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=sy2x%2FAcNazfbhrDsCVX4780KkKf8qdjNG6yKD7W2BxM%3D&reserved=0>

From: devel@edk2.groups.io<mailto:devel@edk2.groups.io> <devel@edk2.groups.io><mailto:devel@edk2.groups.io> on behalf of LathaKannan Arumugam via groups.io <larumugam=microsoft.com@groups.io><mailto:larumugam=microsoft.com@groups.io>
Sent: Friday, June 25, 2021 1:11:42 PM
To: Bret Barkelew <Bret.Barkelew@microsoft.com><mailto:Bret.Barkelew@microsoft.com>; Rabeda, Maciej <maciej.rabeda@linux.intel.com><mailto:maciej.rabeda@linux.intel.com>; devel@edk2.groups.io<mailto:devel@edk2.groups.io> <devel@edk2.groups.io><mailto:devel@edk2.groups.io>
Subject: Re: [EXTERNAL] Re: [edk2-devel] NetworkPkg: Unexpected DHCP RELEASE after PXE server reply on IPv6


Any inputs?

We kind of blocked on this for a week.  Kindly look into packet capture and suggest a path forward.





From: LathaKannan Arumugam
Sent: Friday, June 25, 2021 9:23 AM
To: Bret Barkelew <Bret.Barkelew@microsoft.com><mailto:Bret.Barkelew@microsoft.com>; Rabeda, Maciej <maciej.rabeda@linux.intel.com><mailto:maciej.rabeda@linux.intel.com>; devel@edk2.groups.io<mailto:devel@edk2.groups.io>
Subject: RE: [EXTERNAL] Re: [edk2-devel] NetworkPkg: Unexpected DHCP RELEASE after PXE server reply on IPv6



Attached packet captured from server.



From: Bret Barkelew <Bret.Barkelew@microsoft.com<mailto:Bret.Barkelew@microsoft.com>>
Sent: Friday, June 25, 2021 9:19 AM
To: Rabeda, Maciej <maciej.rabeda@linux.intel.com<mailto:maciej.rabeda@linux.intel.com>>; devel@edk2.groups.io<mailto:devel@edk2.groups.io>; LathaKannan Arumugam <larumugam@microsoft.com<mailto:larumugam@microsoft.com>>
Subject: Re: [EXTERNAL] Re: [edk2-devel] NetworkPkg: Unexpected DHCP RELEASE after PXE server reply on IPv6



+ @LathaKannan Arumugam<mailto:larumugam@microsoft.com>



- Bret


From: Rabeda, Maciej <maciej.rabeda@linux.intel.com<mailto:maciej.rabeda@linux.intel.com>>
Sent: Friday, June 25, 2021 7:40:16 AM
To: devel@edk2.groups.io<mailto:devel@edk2.groups.io> <devel@edk2.groups.io<mailto:devel@edk2.groups.io>>; Bret Barkelew <Bret.Barkelew@microsoft.com<mailto:Bret.Barkelew@microsoft.com>>; Bret Barkelew <Bret.Barkelew@microsoft.com<mailto:Bret.Barkelew@microsoft.com>>
Subject: [EXTERNAL] Re: [edk2-devel] NetworkPkg: Unexpected DHCP RELEASE after PXE server reply on IPv6



Looking at it. Any chance to get Wireshark trace for this scenario?

On 25-Jun-21 09:25, brbarkel via groups.io wrote:

Just poking this to see if anyone has any ideas. Thanks!







[-- Attachment #1.2: Type: text/html, Size: 21019 bytes --]

[-- Attachment #2: image001.png --]
[-- Type: image/png, Size: 69408 bytes --]

[-- Attachment #3: D69B36B6AC6841BB8FDB55D570561B53.png --]
[-- Type: image/png, Size: 286320 bytes --]

[-- Attachment #4: 2DE378E8AEA048A2B6C74BF16B651720.png --]
[-- Type: image/png, Size: 141 bytes --]

[-- Attachment #5: DA1BAD5431864482A26DD838DE240250.png --]
[-- Type: image/png, Size: 137 bytes --]

[-- Attachment #6: 453836353A2041E6BAF497633F089500.png --]
[-- Type: image/png, Size: 140 bytes --]