After doing a capture from the source to the destination address. I keep seeing an TCP {Ack} being sent and an a{PSH}, but no {ACK}. After a minute or so I get the {TCP ZEROWINDOW PROBE}, which is causing the backup server to hang since theres no data actually being sent correctly. Not sure what would cause the {TCP ZEROWINDOW PROBE}. I have read up on it and I believe it has something to do with the destination IP Address Buffer being filled up to quickly. This question is marked "community wiki". asked 30 Apr '12, 12:00  pshaw085 |
One Answer:
Correct. TCP window probe means that the receiver has reduced his receive buffer (a.k.a. window) to zero, basically telling the sender to stop sending - usually for performance reasons. If the receiver does not recover and send an so called "Window Update" with a buffer size greater than zero (meaning, the sender is allowed to continue) the sender will become "impatient" at some point and "check" if the receiver is able to receive more data. That "check" is the Zero Window Probe you observed. If you run into packets diagnosed as Zero Window Probe you can tell that your receiving node is not able to process incoming data fast enough. That is the typical performance problem that everybody blames the network for, while it is in fact a software/hardware problem on the receiving node. answered 30 Apr '12, 13:20  Jasper ♦♦ showing 5 of 7 show 2 more comments |
what would cause it to happen on multiple printers (different brands) on the same network?
I have seen printers use zero window signaling to slow down/stop transmission from print servers/workstations while they're busy waking up and spinning up their internal mechanical parts. When ready, the zero window is pulled up to signal that the sender may continue. It's like a "wait a second, need to get running first... okay, send".
Our HP printers use zero window signaling during the "ink drying" phase when we use double-sided printing. It's weird since they have plenty of RAM, but they don't want to buffer the jobs. They'd rather tell our hosts to stop sending while those little squirrels inside the printer blow on the paper to dry the ink... <grin>
Could you please post a sample capture of such a session? That would be a good sample for an excercise ;-)
I am having the same problem, I am having some zebra printers that I am not sure if it can handle the volume we are sending to them. I keep seeing the tcp-zerowindow-probe message.
This is at packet 39343, 39359, 39383, 39411 Any idea as to what is causing this?
The packet capture can be found here: packet capture download
Yes. Your printer seems to be overwhelmed with incoming packets, which means it is too slow to process (print) them right on time to continue without a pause. Also see my answer in your own question.
Is there a chance that this could be causing the shutdown of the web server on the printer also? When we do a port scan on the printer and the web interface times out?