TCP protocol bug in currently released Windows PE ADK addon

%3CLINGO-SUB%20id%3D%22lingo-sub-837507%22%20slang%3D%22en-US%22%3ETCP%20protocol%20bug%20in%20currently%20released%20Windows%20PE%20ADK%20addon%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-837507%22%20slang%3D%22en-US%22%3E%3CP%3EWe%20were%20hitting%20intermittent%20issues%20with%20mapping%20network%20drives%20during%20our%20MDT%20deployment%20sequence%20with%20the%20latest%20MDT%20and%20ADK%2FPE.%20After%20capturing%20packets%20and%20getting%20reliable%20steps%20to%20reproduce%2C%20we%20now%20know%20it%20is%20a%20bug%20in%20the%20currently%20released%20Windows%20PE%2C%20version%2010.0.18362.1%20.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EThe%20bug%20is%20in%20how%20the%20PE%20on%20the%20client%20handles%20a%20response%20from%20the%20server%20when%20the%20client%20uses%20an%20ephemeral%20port%20that%20was%20recently%20used%20and%20is%20half-open%20(server-side).%20An%20MDT%20task%20sequence%20can%20contain%20many%20reboots%2C%20leading%20to%20use%20of%20many%20ephemeral%20ports%20and%20leaving%20connections%20open%20only%20on%20the%20server%20side%2C%20so%20if%20you%20enter%20the%20PE%20soon%20after%20a%20previous%20sequence%2C%20this%20is%20likely%20to%20happen.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EThe%20server%20will%20respond%20to%20the%20client's%20initial%20SYN%20packet%20with%20a%20SYN-free%20ACK.%20The%20client%20is%20supposed%20to%20see%20this%20response%20and%20issue%20a%20RST.%20Windows%2010%201803%2C%201903%2C%20and%20the%20associated%20PE%20environments%20on%20their%20install%20media%20do%20precisely%20that.%20But%20PE%2010.0.18362.1%20instead%20tries%20a%20few%20different%20ephemeral%20ports%20with%20increasing%20persistence%20and%20eventually%20gives%20up.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EThis%20bug%20is%20easy%20to%20reproduce.%20Set%20up%20a%20share%20on%20a%20server%2C%20and%20create%20a%20PE%20iso%20and%20a%20VM%20that%20boots%20from%20it.%20At%20the%20VM's%20command%20prompt%2C%20run%3CBR%20%2F%3E%3CBR%20%2F%3Enet%20use%20***your%20share%2Fcredentials***%3CBR%20%2F%3Ewpeutil%20reboot%3CBR%20%2F%3E%3CBR%20%2F%3ERepeat%20this%205%20times.%20By%20the%205th%20time%2C%20the%20net%20use%20will%20incur%20a%20noticeable%20delay.%20You%20can%20continue%20repeating%20until%20it%20fails.%20If%20you%20run%20packet%20capture%20software%20on%20the%20server%20side%2C%20you%20can%20see%20the%20client's%20incorrect%20behavior.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EIs%20there%20any%20workaround%20for%20this%3F%20How%20can%20I%20make%20sure%20this%20bug%20is%20received%20by%20the%20appropriate%20team%20and%20addressed%20in%20a%20timely%20manner%3F%3CBR%20%2F%3E%3CBR%20%2F%3E%3CA%20href%3D%22https%3A%2F%2Fstackoverflow.com%2Fquestions%2F57778683%2Fwho-bears-the-responsibility-for-dealing-with-client-ephemeral-port-reuse-after%22%20target%3D%22_self%22%20rel%3D%22nofollow%20noopener%20noreferrer%22%3EStack%20overflow%20discussion%20that%20evolved%20as%20issue%20was%20investigated%3C%2FA%3E%3C%2FP%3E%3C%2FLINGO-BODY%3E
Frequent Visitor

We were hitting intermittent issues with mapping network drives during our MDT deployment sequence with the latest MDT and ADK/PE. After capturing packets and getting reliable steps to reproduce, we now know it is a bug in the currently released Windows PE, version 10.0.18362.1 .

 

The bug is in how the PE on the client handles a response from the server when the client uses an ephemeral port that was recently used and is half-open (server-side). An MDT task sequence can contain many reboots, leading to use of many ephemeral ports and leaving connections open only on the server side, so if you enter the PE soon after a previous sequence, this is likely to happen.

 

The server will respond to the client's initial SYN packet with a SYN-free ACK. The client is supposed to see this response and issue a RST. Windows 10 1803, 1903, and the associated PE environments on their install media do precisely that. But PE 10.0.18362.1 instead tries a few different ephemeral ports with increasing persistence and eventually gives up.

 

This bug is easy to reproduce. Set up a share on a server, and create a PE iso and a VM that boots from it. At the VM's command prompt, run

net use ***your share/credentials***
wpeutil reboot

Repeat this 5 times. By the 5th time, the net use will incur a noticeable delay. You can continue repeating until it fails. If you run packet capture software on the server side, you can see the client's incorrect behavior.

 

Is there any workaround for this? How can I make sure this bug is received by the appropriate team and addressed in a timely manner?

Stack overflow discussion that evolved as issue was investigated

0 Replies
We support Ukraine and condemn war. Push Russian government to act against war. Be brave, vocal and show your support to Ukraine. Follow the latest news HERE