Diagnosing Printer Rebooting Continuously

Shooting fish in a barrel the professional way

I got a call about a Samsung SCX-6x55 Series multi-function copier / scanner / printer / fax / PDF / collator / coffee maker that was rebooting itself every few minutes. The factory authorized and trained technician "fixed" the problem by unplugging it from the network and left them with a $200 bill for the site visit.

They called me because their Samsung copier / scanner / printer was now reduced to being just a plain old photocopier and was giving errors when they tried to print to it.

Think about that for a second, then say it with me: "Well Duhhhh.... if it isn't plugged into the network anymore nobody can print to it, it can't scan and send anything, etc."

How the first tech fixed the problem is like going to the doctor and saying "It hurts when I lift my arms up" and him telling you "Don't lift your arms up! Keep them down! Here is a bill for $200, have a nice day."

If you touch equipment that connects to a network, you have to be able to look at the network data. If you can't, you are neutered when it comes diagnosing many problems that are all too common. It isn't hard! I've said it in many articles and walked many people through adding this tool to their tool belt - this will be another attempt to get more people sniffing networks.

Quote
Click Here for Press Release

The Diagnostic Process

First step was easy - look at the printer from the network with Ping - it wasn't there. With one visual look I can see the Samsung printer isn't plugged into the network. Plug it in and in a few seconds it starts printing a print job ... then a red light comes on, I get a fault error message "System fault : uRlsBlkNo, file lmTNT_Main.c, line 759, Task Xetd"

Samsung printer error message

I've written a LOT of C programming code in my years writing software - this is some internal software defect which sounds like the system is trying to free up a block of memory or block of data from the hard disk and some failure occurred. It could be a block was already released and trying to be released again, or a defect on the hard drive causing an error, or something else... tough to say exactly without seeing the line of code in the file lmTNT_Main.c at line 759.

The defect is there because the programmer that wrote this section of code isn't handling that particular error condition properly and recovering from it - instead letting the code crash the printer. Given this is an older printer and accoring to the tech already has the latest firmware it isn't likely to be fixed anytime soon. I actually got into an argument with him as he was blaming the print job which I agreed was tripping on this software bug over and over again but the root of the problem is indeed a software defect.

Nothing you print to a printer should EVER cause it to reboot. Nothing you do on any computer should EVER cause it to just spontaneously reboot itself.

Given the root of the problem can't / won't be fixed, how do you know which computer is sending the print job to delete it?

That is where the network sniffer comes in! I've described tee-ing into the network data in multiple articles multiple times so we will skip that and jump right into the network data trace.

The printer of interest is at 192.168.19.240 and we need to find out which computer is sending data to that printer and crashing it. Start a sniff in promiscuous mode, plug the printer into the network, let it crash, stop the sniffer and get ready to identify the culprit with just a few seconds of analysis.

Here is the capture - call it up on another screen larger (it is a thumbnail) and I'll walk you through line by line.

Up top in the green bar to the left of the red arrow - I enter a filter to show me just the data to or from the crashing Samsung printer:

ip.addr == 192.168.19.240

Now the rest of the sniff only shows that data.

Bracked to the right of the red O you can see I had a continuous ping window to the printer. This was so I had a definitive indication when the printer was no longer listening on the network. Not required, but was an earlier diagnostic step before I started the sniff. My system is pinging from 192.168.19.74 to 192.168.19.240 and echos are coming back like they are supposed to.

Bracketed to the right of the red X is the Syn / Syn-Ack / Ack of the 3 way handshake that happens at the start of every TCP socket connection. The system trying to talk to the printer is at 192.168.19.106.

That first connection happens at 10:50:37
The printer goes off-line at 10:50:40, 3 seconds later. That is at the bottom of the trace which I didn't show, don't need to show, and doesn't matter as we already know which system is causing the printer to reboot.

Once the printer comes back on-line, the computer sees the printer is back available and that it has a print job that didn't finish but errored out, so the computer restarts sending the exact same document to the printer ... which crashes again. Lather, rinse, repeat.

Knowing which computer is sending this bad data you go to it, open up the print jobs and delete either the one causing the problem or if there are a bunch delete all of them:

Deleting printer queue items

And the results?

Sniff started at 10:50 AM. I took the picture above and deleted the print jobs at 10:57 AM. The person's office was locked and he wasn't there otherwise it would have been quicker.

What should be your the take-away from this? If your computer person can't sniff a network and interpret it they'll spend a whole lot of time and a whole lot of your money chasing down problems that should be no-brainer fixes.