[ipxe-devel] wdsnbp.com loop in iPXE

[Andreas Hammarskjöld]

I think this is the fact that gPXE managed the proxy response differently. You can edit the code to work with the proxy (WDS) instead of the DHCP info.

You could do a one-line hack to pxeprefix.S to retrieve packet type 3 (instead of 2); this _may_ end up giving you the proxydhcp information instead.

It's a bit dubious since PXE conceptually has three DHCPACK-like packets: the "proper" DHCP ACK (with the IP address), the optional ProxyDHCPACK, and the optional boot server reply

That will work for BIOS but not implemented for EFI yet.

//Andreas

From: ipxe-devel-bounces at lists.ipxe.org [mailto:ipxe-devel-bounces at lists.ipxe.org] On Behalf Of wd_liu at sohu.com
Sent: den 9 juli 2015 10:14
To: ipxe-devel
Subject: [ipxe-devel] wdsnbp.com loop in iPXE


Dear，



  I have to write a mail for help to this maillist, because i have failed to register on site http://forum.ipxe.org/.





  Firstly I copy the "Chainloading Windows Deployment Services" text on http://ipxe.org/appnote/chainload_wds to below.



The WDS boot process

Once wdsnbp.com starts, it initiates a session with the WDS server that was specified in the DHCP next-server parameter. The session protocol uses a combination of DHCP requests and responses and TFTP to provide the client with the appropriate boot loader (such as bootmgr.exe or bootmgfw.efi) and boot configuration data (BCD).

The wdsnbp.com program performs client architecture detection and reports it back to the server via the WDS session. This session protocol uses DHCP as an RPC service endpoint, and the data passed back and forth (such as architecture information) is encoded in DHCP option 250. Together with option 252 (used by WDS to indicate BCD file name) and the DHCP file field (pointing the client to the next network boot program), the DHCP+TFTP negotiation completes the WDS session.

Example boot process

  1.  Client: iPXE requests TFTP /boot/x86/wdsnbp.com from ip.of.wds.server.

  1.  Client: wdsnbp.com uses a direct DHCP request to ip.of.wds.server, with no option 250 nor 252 defined.

  1.  Server: DHCP response:

     *   filename: boot\x86\wdsnbp.com

     *   option 250: 0b0101100400000001ff

     *   option 252: \Tmp\x86{<GUID>}.bcd

  1.  Client: wdsnbp.com uses a direct DHCP request to ip.of.wds.server:

     *   option 250: 0d0208000e010001020006ff

  1.  Server: DHCP response:

     *   filename: boot\x86\wdsnbp.com

     *   option 250: 0b0101100400000001ff

     *   option 252: \Tmp\x86x64{GUID}.bcd

  1.  Client: wdsnbp.com requests TFTP /boot\x86\wdsnbp.com from ip.of.wds.server. Note the use of slashes.

  1.  Client: wdsnbp.com uses a direct DHCP request to ip.of.wds.server:

     *   option 250: 0c01010d0208000e010001020006ff

  1.  Server: DHCP response:

     *   filename: boot\x64\pxeboot.n12.

     *   option 250: 0b0101100400000001ff

     *   option 252: \Tmp\x86x64{GUID}.bcd

  1.  Client: wdsnbp.com requests TFTP /boot\x64\pxeboot.n12.

  1.  Client: pxeboot requests TFTP /boot\x64\bootmgr.exe.

  1.  Client: pxeboot requests TFTP \Tmp\x86x64{GUID}.bcd.

  1.  Client: bootmgr.exe executes and reads the BCD.



My situation is a DHCP on a server2012 and a WDS on another server2012r2, and I'm booting a WinPE on a client computer.



The question is when I boot using gPXE(gpxe-1.0.1-gpxe.pxe), it works well, exactly the same boot process copied above from step 1 to 12.



But when I boot using iPXE(undionly.kpxe, latest version), it stucks in a loop, repeats loading wdsnbp.com again and again.



I had a look in wireshark and found that the problem is at the boot process step 7, copied above.



When in gPXE, wdsnbp.com sends a DHCP request with option 250 0c01010d0208000e010001020006ff, and then the process goes to next process step 8.



But when in iPXE, wdsnbp.com sends a DHCP request with no option 250 nor 252 defined, just the same like at process step 2, so the process goes step 2 to step 7 repeatly.



What should I do with this problem?



Thanks for your consiseration.

Looking forward to your answer.




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ipxe.org/pipermail/ipxe-devel/attachments/20150710/9156e4f6/attachment.htm>