We have clients that, on startup, map an smb share on a FreeNAS server. We've noticed that after a power loss, they sometimes have an issue connecting to the smb share.
After a bit of debugging and packet capture, it appears the problem is that the client is choosing a previously-used ephemeral port that, due to the power failure, was not properly closed. When the SYN is sent to the start the SMB connection, the server responds with an ACK with a very high Ack number, instead of a SYN-ACK as expected.
It appears the server sees the SYN from the previously used, never-closed ephemeral port, and tries to continue the old conversation. This back and forth will continue for a while (over a minute), and the errors/delays are problematic.
Who bears the responsibility for dealing with this situation? The client or the server? Any specs or details would be very helpful. Who, if anyone, is misbehaving in this situation?
Update: The behavior that @fendall describes is what Windows proper does. However, the currently released version of WinPE, v10.0.18362.1, does not behave appropriately. Instead, it will try new ephemeral ports, with each subsequent port getting more attempts, until it finally gives up. The winPE version that ships with the Win10 1903 installer works fine. On the released WinPE, if you've recently had connections on the fairly deterministic handful of ephemeral ports it tries, you're just out of luck - no tcp connections can be made until the server decides to forget about them.
The answer to your question, from my interpretation, is that the client is responsible.
In response to the server's ACK, the client should detect that "this segment does not acknowledge anything it sent and, being unsynchronized, sends a reset (RST) because it has detected a half-open connection." Reference: RFC 793 Pg 34