Help understanding a RST, ACK sent after ACK of ZeroWIndow

asked 2021-09-28 19:13:03 +0000

Gcaviston
1 ●1 ●1 ●1

I have been looking at this for a couple weeks now and for the life of me cannot truly figure out what is going on.

We have large print jobs, that are setting to a printer. At times, the printer will sit paused, as it waits for the printer Labels to be changed. Some of these long pauses cause a Windows 2019 Print server to Reset the connection, but I cannot figure out why. You can see from the screen shot, the printer will go into a zero window hold, 35 mins of waiting in this example. When the printer comes back, it updates the window, and the server then ACK, and sends traffic. It than sends a RST, ACK to the printer which marks the job as printed, kills the session, without it truly finishing the job, and starts the next print job.

There is no Firewall between them, nor is it enabled on the print server.

Is there anything in a timeout of over 30 mins of zero window probes, that could cause the server to drop the connection?

Image of Wireshark https://drive.google.com/file/d/19xNz...

edit retag flag offensive close merge delete

add a comment

answered 2021-09-29 11:17:46 +0000

SYN-bit

18528 ●9 ●343 ●255 https://SYN-b.it

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.

edit flag offensive delete link

Comments

Thanks Sys-Bit

Its pretty much what I thought also that something in the application stack is resetting the session. The only items on the 2019 Print server is SAPSprint as the labels are printed from SAP. So SAPSprint does a LPR to RAW conversion. We had these same issues, when we used the LPD Service from MS.

I could not upload the capture, seeing its Print traffic. All of the data is in the packets as ZPL for the zebra printers, so you can read it plain text.

I have seen the RST that happen as soon as 370s, but not happen at 3 hours, so its not a hard rule that they all are RST.

The only packets that would also be part of this stream I guess, would be SAP checking using LPR on jobs, and the printer reporting back the status of these jobs, but I do ...(more)

Gcaviston ( 2021-09-29 15:43:58 +0000 )edit

Wireshark can only tell us what happens on the cable.(or in the air). A logical troubleshooting step would be to get logs from both application ends if possible

Now I don't expect that from the printer But I sure would expect a log on the print server. Can you check that? Maybe even enable some sort of debug logging?

hugo.vanderkooij ( 2021-09-30 07:04:57 +0000 )edit

add a comment

Help understanding a RST, ACK sent after ACK of ZeroWIndow

1 Answer

Comments

Your Answer

Question Tools

Stats

Help understanding a RST, ACK sent after ACK of ZeroWIndow edit

1 Answer

Comments

Your Answer

Question Tools

Stats

Help understanding a RST, ACK sent after ACK of ZeroWIndow