This is a static archive of our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

TCP ZeroWindow when printing

0

We've been having on/off issues all day with some of our Ricoh copiers and multiple PCs. Documents will take anywhere from 1-5 minutes to begin printing. I mirrored the switchport of one of the printers to the second NIC on my PC and ran a capture while sending a test page, and it looks like we're filling the TCP Window which is causing the delays, in the linked image .144 is my client PC and .235 is the printer. No recent changes were made to the network or any printer or GP settings, when I view all the captured traffic without filters there doesn't seem to be a ton of broadcast/multicast traffic bouncing around and slowing things down. I can post the capture file if someone wants to take a look at it.

One thing that I found strange is that it looks like the initial "TCP Window Full" packet is being sent by the client PC and not the printer, which I would take as pointing to an issue with the PCs and not the printers. Am I correct on that?

Any help is greatly appreciated, this one is a little out of my realm of expertise. Thanks!

asked 30 Dec '13, 11:35

motoxrdr21's gravatar image

motoxrdr21
16114
accept rate: 0%


One Answer:

2

"Window Full" is NOT sent by the client. It is a diagnostic message created by Wireshark while examining the communication. See my explanation at the bottom of this question: http://ask.wireshark.org/questions/27556/relation-between-window-full-zero-window-and-push

The screenshot you provided looks quite typical - a printer receiving a print job often advertises a zero window at the start of the job to slow down the client, because it needs to spin up its mechanical parts first. In your case the "Zero Window/Zero Window Probe" phase is way too long though - it should accept more packets a after a couple of seconds at most, not close to 3 minutes later like in your case. Looks like your printer has a big big problem with it's performance. I'd probably call a service technician to find out what the problem is.

answered 30 Dec '13, 12:00

Jasper's gravatar image

Jasper ♦♦
23.8k551284
accept rate: 18%

Thanks for the quick response Jasper it gets a little bit more interesting now though, since I knew the our copier vendor would immediately point to the network as being the issue I pulled a spare switch out and hooked up the copier and a client to it. I was able to print 10 test pages from the client in that configuration with no issue.

So I went back to looking at what other traffic was hitting the copier, did a 10 minute capture without any print jobs and according to Wireshark the average was just shy of 8 Packets/Sec primarily consisting of ARP and SSDP packets. It's a fairly new (within 3 years) Ricoh so I wouldn't imagine that amount of noise would be anything for it to complain about.

It does work fine for 10-15 min when we reset the printer.

Any ideas? Thanks again!

(30 Dec '13, 13:05) motoxrdr21
1

The printer is advertizing a window size of 23 bytes!!, which is kind of, well ... bad, as those 23 bytes are consumed with the first 'data packet' from the client (Frame #4), hence the Wireshark message TCP Window Full ;-))

There is nothing to blame to the network. It's the printer doing that and that's the reason for the delay, as it is not updating its window size for nearliy 3 minutes. I don't see how Ricoh is going to successfully blame the network for the problem.

However: my experience with all kinds of support engineers is, that they don't know anything about the network level and thus they don't understand what is going on in your capture file. So, it will take a long, long time to convince them to escalate the case, so an experienced engineer (or a firmware developer) can check the capture file.

It does work fine for 10-15 min when we reset the printer.

well, isn't that a sign for a bogus printer firmware in itself?

What happens if you wait 20 min after you hooked up the printer to the new switch? Does it still work? If yes: What happens if you print more that 10 test pages, etc....

Sounds like something 'breaks' within the printer (might be the network interface) after some time.

(30 Dec '13, 14:58) Kurt Knochner ♦

The 23 bytes Window size is another part of the printer having to spin up first I guess. And agreed, the network is not the problem. Zero Window messaging means that the buffers on the printer ran out for whatever reason. It's a printer problem. If the vendor blames it on the network tell them they need to learn how TCP works.

From what you describe I assume that the printer has some kind of slow ressource leak. Maybe they implemented the TCP stack in a bad way so that it eats up memory ressources but does not free them again.

(30 Dec '13, 15:25) Jasper ♦♦

The 23 bytes Window size is another part of the printer having to spin up first I guess.

that would be strange, as the NIC (or the OS in the driver) should have some buffer space available for print jobs, even if the hardware needs to 'warm up'. But that's just my interpretation of what would be reasonable ;-))

Maybe they implemented the TCP stack in a bad way so that it eats up memory ressources but does not free them again.

The weird thing is, that the OP said: 'It does work fine for 10-15 min when we reset the printer'. Sounds like a bug in the firmware or something (some hardware parts) breaks horribly after a short period.

(30 Dec '13, 15:29) Kurt Knochner ♦
1

I've just checked some LPR capture files, but was unable to find one with a similar 'spin up' time behavior.

Then I found this:

http://rfg-esource.ricoh-usa.com/oracle/groups/public/documents/communication/rfg042515.pdf

On page 5, you can see the same behavior: Window size 23, announced by the printer. So, this seems to be Ricoh specific. But then, the whole communication is totally different than in the case described here !??!

This is clearly something for the Ricoh support. As they describe how to use Wireshark, they should be able to read the capture files themselves :-))

(30 Dec '13, 15:46) Kurt Knochner ♦
1

Agreed.

@motoxrdr21: Hand over the case to them. Point their engineers to this thread if necessary.

(30 Dec '13, 15:54) Jasper ♦♦

Did a cold reboot before I left yesterday as a last ditch, read about a similar issue with old HP JetDirects, not sure why I didn't think to do it earlier, but anyway heard no complaints from people last night, and it seems to be working normally this morning. I can't have techs here taking the printer down for maintenance this week since it's our primary in Accounting and they need to use it a lot this week to close the year, so I'm going to hand it off to support next week (not that they'll do anything if it's still working then of course). Thanks again for everyone's help, I really appreciate it!

(31 Dec '13, 03:50) motoxrdr21
showing 5 of 7 show 2 more comments