none
WDS and TFTP Windows 2008 R2 RRS feed

  • Question

  • My WDS MDT PXE boot process was working fine until I installed the latest versions a couple of days ago of Windows 10 Deployment Kit and ADK WinPE for Windows 10. I've seen a possible fix (see below)

    1.Open WDS

    2.Right-click your server in the left pane and open properties.

    3.Open tab “TFTP” and change the maximum block size to eg 1024.

    4.Restart your WDS server.

    The trouble is there is no TFTP tab in the properties of my WDS? Any ideas?




    • Edited by petefarrell Tuesday, June 18, 2019 10:31 AM
    Tuesday, June 18, 2019 8:12 AM

All replies

  • Hi,

    As the issue occur after update action, so would you provide the version previous and existing?

    Also we could try to use previous version to check if the issue disappear or not.

    Bests, 


    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.


    • Edited by Joy-Qiao Thursday, June 20, 2019 1:34 AM
    Thursday, June 20, 2019 1:33 AM
  • Hi,

    Any update?

    Bests,


    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Friday, June 21, 2019 9:18 AM
  • As far as I can tell, the biggest current problem with the latest WDS for PXE booting process can't be fixed by any TFTP tab properties.

    If you run Wireshark on your WDS server (Microsoft Message Analyzer may also work, I have not tried), you should see something like this around the time PXE fails:

    Server -> Client TFTP Data Packet Block #805

    Client -> Server TFTP Acknowledgement Block #805

    Server -> Client TFTP Data Packet Block #806

    Client -> Server TFTP Acknowledgement Block #806

    Server -> Client TFTP Data Packet Block #807

    Client -> Server TFTP Acknowledgement Block #806

    Server -> Client Error Code 5 (Illegal operation error)

    What is taking place above is block 807 was lost in the network.  WIth FTP or HTTP which are over TCP, the TCP stack takes care of the retransmission of the packet.  With TFTP which is over UDP, the TFTP server is responsible for retransmitting re-requested blocks.  This is explain in the RFC 783 and RFC 1350 specifications for TFTP and the client is complying with the standard exactly.

    However, included in Microsoft security fix for CVE-2019-0603 seems to be a violation of RFC 1350 were the TFTP server no longer permits retransmission of lost TFTP data packets.  This violation should have been easy to catch with any TFTP compliance / regression test suite but maybe Microsoft does not have one of those?  It also should have minimized the impact of CVE-2019-0603 if the TFTP server ran as a .NET application and as an unprivileged user.

    This situation seems to put the user in an uncomfortable position of choosing either a server that is vulnerable to CVE-2019-0603 or a TFTP server which violates RFC 1350 thus possibly not working as reliably.  I found a way to avoid using the Microsoft WDS TFTP server completely for PXE boot using the open source iPXE/wimboot projects but I think explaining how to do that probably is not what this forum is for.

    If anyone from Microsoft is listening, please dump the source code to the following on github:

    WDS TFTP, pxeboot.com, pxeboot.n12, bootmgr.exe, sdimgr.exe and bcdedit.exe

    I might be wrong, but I personally don't see how keep any of these closed source provides any competitive advantage.  In my opinion, the lack of community involvement in helping improve these may actually be a competitive disadvantage in the long run.

    All we want to be able to do is reliably install the Microsoft product we are paying for.  Dictating changes such as TFTP retransmission is just something that will now be marked an illegal operation just doesn't fit well with us doing that!

    Wednesday, July 3, 2019 4:32 AM