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

Printer intermittently “drops” off network

0

Hi all. Been having a problem with a copier that has scanning/printing capabilities for a month or so now. The machine will randomly drop from the network, you can still ping it but print jobs will fail and you are unable to access it's web interface. The copier service people have replaced the NIC and main control board and the problem is still present. We've gone through the motions of disabling any unused protocols on the machine in case it was creating too much traffic for the device, switched the IP address and completely uninstalled and reinstalled the drivers on our print server. I captured a log of my workstation trying to send a print job and this is what wireshark gave me when the job failed. I created a filter for my workstation(192.168.1.10) and the printer(192.168.1.11) on port 9100 since I would assume all the print data is going through that port. I'm still new to wireshark so if anyone could help me out and explain why all these lines are in Black/Red/Dark Grey compared to the light blue lines when the machine works normally I would greatly appreciate it, thanks.

10683   700.434934000   192.168.1.11    192.168.1.10    TCP 62  [TCP ACKed unseen segment] hp-pdl-datastr > 56487 [SYN, ACK] Seq=0 Ack=1020557286 Win=16384 Len=0 MSS=1460 WS=1
10684   700.434986000   192.168.1.10    192.168.1.11    TCP 54  56487 > hp-pdl-datastr [RST] Seq=1020557286 Win=0 Len=0
10705   703.428448000   192.168.1.11    192.168.1.10    TCP 62  [TCP ACKed unseen segment] hp-pdl-datastr > 56487 [SYN, ACK] Seq=0 Ack=1020557286 Win=16384 Len=0 MSS=1460 WS=1
10706   703.428554000   192.168.1.10    192.168.1.11    TCP 54  56487 > hp-pdl-datastr [RST] Seq=1020557286 Win=0 Len=0
10707   703.437296000   192.168.1.10    192.168.1.11    TCP 66  56487 > hp-pdl-datastr [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=256 SACK_PERM=1
10708   703.437747000   192.168.1.11    192.168.1.10    TCP 62  hp-pdl-datastr > 56487 [SYN, ACK] Seq=0 Ack=1020557286 Win=16384 Len=0 MSS=1460 WS=1
10709   703.437816000   192.168.1.10    192.168.1.11    TCP 54  56487 > hp-pdl-datastr [RST] Seq=1020557286 Win=0 Len=0

This keeps going on over and over until I do a hard reboot on the machine, it prints the stuff out on the print queue and sure enough a few minutes later no more printing. I know this isnt a forum for other people to fix my problems but time is of the essence on this one so any help is nice!

asked 09 Jun '14, 15:00

osty's gravatar image

osty
11112
accept rate: 0%

Would you be able to upload the packet capture and post the URL here (https://appliance.cloudshark.org/upload/ )?

One comment is that those "RST" flags are being sent from your workstation to terminate the TCP session after it tries to initiate a session (at the end there, you see SYN from your workstation to establish a session, SYN ACK in response from the printer, and RST to terminate sent by the workstation).

WIthout seeing the full trace it's hard to say what reds/blacks you're talking about, but there are a few common/normal causes that aren't actual problems, though those RST flags do look like they could be related to your problem since those are session disconnects when you're just trying to establish a TCP connection.

Also, you say you assume that 9100 is the correct port. To be safe, can you please do that trace without any port-level filtering between your workstation and the printer?

(09 Jun '14, 17:54) Quadratic

One Answer:

0

It's time consuming and annoying to do packet analysis based on text exports and screen shots (not in your case), so please post the capture file somewhere, like: google drive, dropbox, cloudshark.org. Thank you!

Now, for the problem: By looking at the text output, we can see, that the SYN-ACK arrives with the wrong sequence number, and thus the client sends a RESET.

Explanation:

SYN frame uses SEQ=0, which is an indication, that relative sequences numbers is activated for the TCP protocol (default setting), so Wireshark will remember the real sequence number (whatever it might be) and count from there. Thus the SYN is shown with SEQ=0.

SYN-ACK frame shows Ack=1020557286. This is wrong it should be ACK=1 (remember the relative sequence numbers), so the TCP stack of the server ACKs 1020557286 bytes, while it should have ACKed only one byte (the SYN flag).

RESET: The client send a RESET, because the SYN-ACK is totally wrong.

So, everything O.K. on the client side. There seems to be a bug in the firmware of the printer. As you say, that the problem occurs for a month or so, I guess it was caused by a firmware upgrade (or downgrade), that took place ~ one month ago.

10707   703.437296000   192.168.1.10    192.168.1.11    TCP 66  56487 > hp-pdl-datastr [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=256 SACK_PERM=1
10708   703.437747000   192.168.1.11    192.168.1.10    TCP 62  hp-pdl-datastr > 56487 [SYN, ACK] Seq=0 Ack=1020557286 Win=16384 Len=0 MSS=1460 WS=1
10709   703.437816000   192.168.1.10    192.168.1.11    TCP 54  56487 > hp-pdl-datastr [RST] Seq=1020557286 Win=0 Len=0

Regards
Kurt

answered 12 Jun '14, 05:38

Kurt%20Knochner's gravatar image

Kurt Knochner ♦
24.8k1039237
accept rate: 15%

edited 12 Jun '14, 06:14

Yes totally agree with Kurt but one more interesting thing to notice is that within span of 3 second client has opened atleast 3 session with same source port and printer is acking with same ack no everytime.

(14 Jun '14, 04:07) kishan pandey

Yes, interesting that the client does not increase the source port after the reset.

BTW: It's not necessarily the same ACK number, it's probably just the same ACK delta (remember the relative SEQ number display in Wireshark). So, until @osty posts the capture file, we cannot know which SEQ number the client was using for the new connection attempts.

(15 Jun '14, 03:01) Kurt Knochner ♦