Revision history [back]

From analyzing the image (BTW, it is much easier to analyze network packets using a capture file, then we can use our favorite tool Wireshark ;-)):

• I see frames of less than 60 bytes being sent by the print server (10.150.100.222), so I assume the packet capture was made on the print server.
• After the printer opens up the TCP window, the print server sends a TCP segment of 16060, which seems to be the data it still has in its send buffer. As this is exactly 11*1460 (the MSS), I assume this is not the end of the data that the print server was going to send.
• There are ~7ms between the data and the RST, which I assume means TCP did not plan to kill the connection (then I would have expected the RST quicker after the data). So there might have been an issue communicating with the print server application

I don't think the print server application timed out and killed the connection, because when that happens, I would expect the TCP stack to send the TCP/RST straight away (so during the zero-window interval). But of course this all depends on the implementation of the TCP stack. So my best bet would be that something on the print server is in the way of the print server application and the TCP/IP stack and it is timing out.

What is the longest observed period of time that the zero-window condition can exist without the connection being reset? And what is the shortest observed period of time the zero-window condition existed that did trigger a RST? That would at least narrow down what the timeout period is. Next to find out is which component on the print server is having the timeout and whether it can be increased.

As the RST comes from the print server itself, you can of course rule out the network and the printer itself, the problem is in the print server.