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

Connection reset (RST, ACK) causing print failure

0

Hi all!

I have an Epson 9600 wide format printer, we're experiencing issues where the print job fails, always at the end.

I've noticed that every time the job fails, the PC is sending standard ACK packets
Every time the job succeeds, the last two ACK packets have the PSH flag set too.

Output from a successful job: https://www.cloudshark.org/captures/47c1282d852d

Output from a failed job: https://www.cloudshark.org/captures/d54ab50636c1

I'm stumped, to be perfectly honest I'm shooting in the dark. Tried LPR vs RAW printing, tried different machines etc, still failing. Any help would be greatly appreciated!

edit: bit of extra info, printing from a mac works fine every time. o.O different TCP/IP versions/settings/something?

asked 28 Jul '14, 22:37

MikeAnthony's gravatar image

MikeAnthony
11114
accept rate: 0%

edited 31 Jul '14, 00:58

1

both traces have the same source 192.168.1.91, is it a intermittent issue?

I saw packets going through without issue initially until the source issued RST all of a sudden. Looks like we should understand when and why TCP would send out RST proactively. Weird...

(29 Jul '14, 01:10) SteveZhou

Yep, issue is intermittent. It seems I can completely power cycle the printer (power cord out, turn on to drain residual charge, power back in) and it will successfully print a job (barring issues with the PDF).
Subsequent jobs will then fail until I power cycle the printer again.

(29 Jul '14, 01:15) MikeAnthony

First I have a question. Are printing the same job or are they different?

(17 Apr '15, 04:01) Christian_R
1

Average RTT time in failed pcap is 2 ms,before sending RST 1.91 waits for almost 20 ms for an ack to come but it didnt receive.so in failure cases you can see that if this pattern is repeating,if yes than there could be some setting on device or system which is causing this.Other thing to find out is why 1.38 didnt sent an ack.

(17 Apr '15, 06:28) kishan pandey

One Answer:

0

A lot of important information is defined at the session start, which we can´t see here. So maybe we need it some day. The main difference between the traces as we can see is the termination of the session. In the successfull trace we can the a normal 4 way session closing (FIN-ACK)

In the failure trace we see an anormal session termination indicated by the RST-Bit. In the most cases I analyzed was the root cause a problem above Layer 4.

Maybe it is a driver problem at the 192.168.1.91 because this machine sends the RST apparently more or less unmotivated.

answered 17 Apr '15, 14:19

Christian_R's gravatar image

Christian_R
1.8k2625
accept rate: 16%