Hello all. The link below is for a partial capture from a customer installation. The printer, 172.40.22.250, is not printing the data sent in frame 12. It correctly prints data in frames 4 and 20. The data in frame 12 has been verified as valid printer code. I'm no TCP expert but I suspect the RST's have something to do with the skipped print job. The host / sender is an AS400 computer. This happens consistently. Any insight GREATLY appreciated. https://www.dropbox.com/s/o20v7t33kggooie/ANC%20Printer%20Capture%203-18.pcapng?dl=0 asked 20 Mar '15, 06:42  shoal |
4 Answers:
The printer is 10.40.22.250. Packet 12 is in tcp stream 1. You can see the printer sending a RST after the TCP handshake, so it will not print packet 12. What devices are between the host and the printer? answered 20 Mar '15, 07:20  Roland |
My guess is that the printer refuses the new connection with more print data because it's too busy. Packet 12 comes after a Reset packet, which terminates the session. And since it's coming from the printer it's pretty clear it is not going to do anything afterwards. Maybe its because the second of three print jobs (all with their own TCP sessions) is initiated before the first is complete, while the third is on its own again. You might want to check if the printer has some kind of utilization statistics or an error log that you can inspect. Otherwise your sending software needs to send the print jobs sequenially I guess. answered 20 Mar '15, 07:37  Jasper ♦♦ |
The client is also sending data after initiating the termination of the TCP stream. Client = 172.16.2.10, initiates the connection Server = 10.40.22.250, the printer in this case There are 3 TCP streams. The following are the TCP source ports. 35910 48485 57660 The destination TCP port is always 9100 = printer page description language In your case, TCP stream 48485 is being Reset by the printer and that is why the 2nd label is not printing. However, if we filter on the first TCP stream (Wireshark filter is tcp.port==35910) we see the following: packet #5 = client sends FIN packet #9 = server acknowledges FIN and send ACK When the client sends the FIN packet, the client can still receive data from the server but will no longer accept data from its local application to be sent to the server. But packet #18 shows the client trying to send data using the same port number. This is strange? Maybe there is a filter not showing all the packets? answered 20 Mar '15, 08:15  Amato_C |
As others have mentioned: Frame #12 does not get printed because the printer RESET the connection. However the question is: Why did the printer RESET the connection? I believe, because the printer does not allow multiple connections to port 9100 at the same time. The SYN of TCP stream #1 arrives at the printer while TCP Stream #0 was still active (FIN of client sent). Sounds stupid, but I have seen that in other cases. Why the printer did not RESET the SYN itself? Good question. I guess the support hotline of the vendor should be able to answer that question. Regards answered 20 Mar '15, 11:45  Kurt Knochner ♦ That's pretty much what I meant with the first connection not being complete ;-) (20 Mar '15, 12:22) Jasper ♦♦ |
No, it doesn't send data. Packet #18 is empty, it's just the ACK to the FIN from the other side, plus a (useless and a little uncommon) PSH flag.
Oops, you are correct Jasper. I was looking at the packet numbering and not the TCP payload size. Sorry for the confusion.
no worries ;-)