• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 548
  • Last Modified:

Intermittent Print issue across LAN

HP Printer Issue.

We are currently experiencing an issue with HP printers that after a couple of months trying to rectify the problem we seem no closer to a solution.   An overview of the issue is:

When a print job is sent to the printer, the print server shows the job as printing but the printer does not respond to the job at all.  This effectively blocks the printer to all other tasks.  To clear the printer you need to log onto the printer server with administrative privilege, delete the task, restart the print spooler, and delete the task again.  This fault started small, with one printer semmingly affected and has now grown to include all HP printers.  The fault only happens for about 5% of print jobs (yes, this is a guess) and is not consistent for machine combinations. (i.e. not a particular computer to a particular printer.)

Hardware:  Printer Server:  W2K3 SP1 with HP Jet Admin
HP Printers:         HP Laserjet 5Si        x1
                        HP LaserJet 4/4M       x1
                        HP Laserjet 4 Plus      x3
                        HP Laserjet 2100      x2      
                        HP Laserjet 4100      x1
                        HP Laserjet 4050      x5
                        HP Laserjet 5000      x1
                        Xerox Workcentre Pro 320/315      x2
                        Fuji Xerox Document Centre 250      x1

      Only the HP printers are affected.

Testing done:
      Moved machines to another Print Server.  Results are the same.  Machines continue to ignore print requests.
      Configured network so that ALL switches on a connection between a test printer and the print server were replaced.  No change.  (i.e.  bypassed all of the switches between the printer and the print server.)
      We have swapped printer locations.
      We have been monitoring the network with wireshark installed on the Print Server.  The results are in-conclusive and a little disturbing.  The failures are seen in one of two ways.  We have only been monitoring traffic from the Printer Servers to the printers.  All of our printers are in an exclusive sub-net of our network, so easy to see this happen.
      In all failures the server fails to handshake with the printer concerned.  We have seen the server send sync packets to the printer without reply and the print server fail to call the printer at all.  
      Currently waiting result of moving all HP Printers off "HP Standard TCP/IP Port" to a "Standard TCP/IP Port" No results of this move as yet, simply because it is too soon to tell.

Craig Rayner
Crossroads International
1 Solution
on what level are these packets send?
It's a good option to configure snmp for this communication.

What type of network-devices is used for the printers?
Internet Jetdirect cards, external Jetdirect boxes ?
With the last mentioned, it's often best to reset the box quickly, and then restart the job. In most cases the print comes out of the printer and there is no need to reset the spooler.
c_a_raynerAuthor Commented:
Hmm.  Not sure about your comment.

We are capturing the packets between the server and the printers.  These are TCP and are usually NOT SNMP.  The monitoring software (HP Webjet) uses SNMP to monitor the printers, but the print jobs are standard TCP.

All of our printers are connected via JetDirect cards.  All cards, except J2552A are updated to the latest firmware.  The J2552A melts components if you try and update the firmware, so after losing three we no longer bother to update this model JetDirect card.  

The basic issue that you may have missed is that I should not have to reset the printers at the moment about 12 times a day.
I expressed myself a little wrong with the snmp, sorry about that.
But I understand you use it to monitor it. What is the intervall ?

Is the snmp also activated in the TCP printer-port settings on your print-server ?

And can you still access the web-component of the printer when it is piling up the queue ?

What PCL-langauge are you using for these printers ?

Get your problem seen by more experts

Be seen. Boost your question’s priority for more expert views and faster solutions

c_a_raynerAuthor Commented:
We have not adjusted the standard settings for SNMP on any of our printers.  We do not usually rely on passive snmp, but use active snmp to poll the printer and return the condition of same.

We are only using the standard PCL drivers for the machines.  No Postscript, and no PCL6.   Exception  THe 5000 uses PCL6 drivers and the 4/4M uses PS.

Yes, we can normally ping the printer, and gain access to the web GUI when the printer is blocked at the server.

Is the snmp also activated in the TCP printer-port settings on your print-server ?   Sorry, I am not understanding this question.  The Printer server and the WebJet admin program are on the same machine.  We do use another machine to test Network availability.  This is a Centos box running NAGIOS.  Only key printers are targeted to monitor in this manner as the result is more to do with network integrity, rather than the printer actually working report.  

We have had a failure in a switch at the centre (close to the server) of our network.  Since rebuilding this network, the printers have not (yet) required intervension.  We live in hope.

Thanks for your attention.
WadskiIT DirectorCommented:
It looks to me like it was a symptom of the problem with your Switch and since it's been replaced I'll bet it is now sorted!  

My reasoning for this is that the packet is getting lost between the server and the printer subnet and since it is temperamental when it happens it is not a setup fault (they work okay 95% of the time).

My suggestion would have been to move a printer onto a different switch on the same subnet to see it the problem occurred then later (as it would have carried on it seems) change the IP address onto the same subnet and test it then.

(please do not consider this an answer - more of an observation)

c_a_raynerAuthor Commented:
     Sorry guys.  Should have got back to you.  The solution was indeed a network issue, but not the one that Wadski supplied, as that had already been done without success.  One switch in our network was intermittently failing, and in doing so was broadcasting to the point of a DOS on the network.  It appeared that the slow 10M HP printers were the first victims of this issue, and as the switch fault was intermittent, and not necessarily in the printer IP address range, was not detected on our focused view of printer network traffic.  
     Thankfully, the switch in question failed completely, absolutely killing the entire internal network.   Made it reasonable easy to spot and the printers have been fine since the switch  was binned.
   The switch in question was not the one mentioned above, but an outlying network port.  
   Thanks for you help, but we did appear to solve this one ourselves.
No comment has been added to this question in more than 21 days, so it is now classified as abandoned.

I will leave the following recommendation for this question in the Cleanup topic area:
    PAQ with points refunded

Any objections should be posted here in the next 4 days. After that time, the question will be closed.

EE Cleanup Volunteer
PAQed with points refunded (250)

EE Admin
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Free Tool: SSL Checker

Scans your site and returns information about your SSL implementation and certificate. Helpful for debugging and validating your SSL configuration.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now