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"
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
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:
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.
Copyright (C) 2018 DAS Computer Consultants, LTD. All rights