Processing of TCP packets sent by the SYSTEM process using windows-redirector.exe

[sbromt]

When accessing the NAS through Windows Explorer, the TCP handshake packets from the System process (PID=4) are held at the if block on line 188 of the main2.rs. However, when a socket event occurs, processing is skipped at the if block on line 232 of the main2.rs, preventing Windows Explorer from establishing a TCP connection.

Wouldn't it be better to reinject the connections held in connections back into the network before skipping them, even if the process is the System process?

[sbromt]

I submitted a pull request, but it seems there has been no response so far. What should I do next?

[mhils]

@sbromt: thanks - you're all good. We're a bit short on reviewers on Windows, but I'll try to get to your patch in the next week or so.

[sbromt]

@mhils Has there been any progress regarding this matter?

[boli1024]

Thank you for this work. While testing v0.12.9 on Windows with this PR, I observed another related failure mode: an outbound network packet could be received without any subsequent SocketConnect event. The packet remained in the Unknown connection cache and the application timed out.

The PID 4 / multicast cleanup does not cover this case because no socket event arrives at all. We tested a fallback that, for the first unknown outbound packet, queries the Windows TCP/UDP connection table, resolves the owning PID, and then applies the process selector. If the table has no matching entry, the existing pending-packet path is retained.