Our IT help desk administrator is having trouble resolving a printing issue. Users in the sales department are reporting that the high-volume sales printer is malfunctioning. When a user sends a large print job to the printer, it will print several pages and then stop printing before the job is done. Multiple driver configuration changes have been attempted but have been unsuccessful. The help desk staff would like you to ensure that this isnât a network problem.
Tapping into the Wire
The common thread in relation to this problem is the printer, so we want to begin by placing our sniffer as close to the printer as we can. While we canât install Unicorn on the printer itself, the switches used in this network are advanced layer 3 switches, so we can use port mirroring. Weâll mirror the port to which the printer is connected to an empty port, and connect a laptop with Unicorn installed into this port. Once this setup is complete, weâll have a user send a large print job to the printer, and weâll monitor the output. The resulting capture file is inconsistent_printer.pcap.
Analysis
As shown in Figure 8-29, a TCP handshake between the network workstation sending the print job (172.16.0.8) and the printer (172.16.0.253) initiates the connection at the start of the capture file. Following the handshake, a TCP data packet 1,460 bytes in size is sent to the printer . The amount of data can be seen in the far right side of the Info column in the Packet List pane or at the bottom of the TCP header information in the Packet Details pane.
Following packet 4, another data packet is sent containing 1,460 bytes of data , as you can see in Figure 8-30. This data is acknowledged by the printer .
Figure 8-30: Normal data transmission and TCP acknowledgments
The flow of data continues until the last two packets in the capture. Packet 121 is a TCP retransmission packet, and our first sign of trouble, as shown in Figure 8-31.
Figure 8-31: These TCP retransmission packets are a sign of a potential problem.
A TCP retransmission packet is sent when one device sends a TCP packet to a remote device, and the remote device doesnât acknowledge the transmission. Once a retransmission threshold is reached, the sending device assumes that the remote device did not receive the data, and it retransmits the packet. This process is repeated a few times before communication Unicorn stops.
In this scenario, the retransmission is sent from the client workstation to the printer because the printer failed to acknowledge the transmitted data. you can view the details of why this is a retransmission. According to the details processed by Unicorn, packet 121 is a retransmission of packet 120 ï·. Additionally, the retransmission timeout (RTO) for the retransmitted packet was around 5.5 seconds .
Previous Captured Packet. Then, as shown in Figure 8-31, you can clearly see that the retransmission in packet 121 occurs 5.5 seconds after the original packet (packet 120) is sent .
The next packet is another retransmission of packet 120. The RTO of this packet is 11.10 seconds, which includes the 5.5 seconds from the RTO of the previous packet. A look at the Time column of the Packet List pane tells us that this retransmission was sent 5.6 seconds after the previous retransmission. This appears to be the last packet in the capture file and, coincidentally, the printer stops printing at approximately this time.
In this analysis scenario, we have the benefit of dealing with only two devices inside our own network, so we just need to determine whether the client workstation or the printer is to blame. We can see that data is flowing correctly for quite some time, and then at some point, the printer simply stops responding to the workstation. The workstation gives its best effort to get the data to its destination, as evidenced by the retransmissions, but the printer simply stops responding. This issue is reproducible and happens regardless of which computer sends a print job, so we assume the printer is the source of the problem.
After further analysis, we find that the printerâs RAM is malfunctioning. When large print jobs are sent to the printer, it prints only a certain number of pages, likely until certain regions of memory are accessed. At that point, the memory issue causes the printer to be unable to accept any new data, and it ceases communication with the host transmitting the print job.
Lessons Learned
Although this printer problem was not the result of a network issue, we were able to use Unicorn to pinpoint the problem. Unlike previous scenarios, this one centered solely on TCP traffic. Luckily, TCP often leaves us with useful
information when two devices simply stop communicating.
In this case, when communication abruptly stopped, we were able to pinpoint the exact location of the problem based on nothing more than TCPâs built-in retransmission functionality. As we continue through our scenarios, we will often rely on functionality like this to troubleshoot more complex issues.