HP JetDirect 170X problems
Duncan Seibert
JetDirect 170X use to work. It stopped working and gave garbage output,
often repeating pages. We upgraded to 5.0.6 and reinstalled all printers
using hpnpcfg. All LaserJet's with internal network I/Os work fine, the 2
external JetDirects with dot-matrix printers still don't work.
Report prints but lpstat -t shows the report on the printer even after it is
printed. Report gets reprinted until it is removed through scoadmin. We have
tried setting idle-timeout. Default is 90, we have tried 500, 800 and 15.
None work.
Any ideas?
Thanks,
Duncan
Andre Georgel
Duncan Seibert a écrit :
How are connected the dot Matrix printers ? serial or // ?
-----------------------------------------------------
Andre Georgel
Email : andre....@noos.fr
La perfection n'est pas lorsqu'il n'y a plus rien à
ajouter, mais lorsque qu'il n'y a plus rien à enlever.
(A. de Saint Exupery)
------------------------------------------------------
Jeff Liebermann
wrote:
Is this Jetdirect 170x exposed to the internet with a routeable IP
address? I have a few print servers like that. The Code Red and
similar worms just drive them nuts. The symptoms are similar to what
you're getting. If the day it stopped working coincides with the
emergence of Code Red, please hide your print servers behind a
firewall.
I'm not sure why lpstat -t still shows the print job. The report
writing program is responsible for closing the pipe to the print
spooler. Try printing something without your unspecified application
as in:
cat filename | lp -d print_spooler_name
and see if it has the same problem. If it works, then the problem is
in your unspecified application. It's probably leaving the print job
output open or not finishing the print job. You might be able to see
it open with:
ps -ef
which would show the application and the pipe to lp or lpr. The
reprint problem is really strange as it could be the internal settings
in the HP 170x deciding to restart if no data is received for xxx
number of seconds (I forgot the exact settings). Hard to tell from
here.
--
Jeff Liebermann 150 Felker St #D Santa Cruz CA 95060
(831)421-6491 pgr (831)426-1240 fax (831)336-2558 home
http://www.LearnByDestroying.com WB6SSY
je...@comix.santa-cruz.ca.us je...@cruzio.com
Duncan Seibert
Thanks for the response. The units are behind a firewall so I don't think
that a virus is the cause but, who knows!
I am not trying to print from an application. My test is: lp -d <spool-name>
/etc/motd or, for a longer file, lp -d <spool-name> <big-file>
Duncan
925-283-5549
"Jeff Liebermann" <je...@comix.santa-cruz.ca.us> wrote in message
news:v419rt018nhuk4mnm...@4ax.com...
Jeff Liebermann
wrote:
>Thanks for the response. The units are behind a firewall so I don't think
>that a virus is the cause but, who knows!
>
>I am not trying to print from an application. My test is: lp -d <spool-name>
>/etc/motd or, for a longer file, lp -d <spool-name> <big-file>
>
>Duncan
>925-283-5549
OK, so we have to assume that there's something different between the
HP170x print server and the other unspecified printers with built in
JetDirect print servers.
I'll assume that you're using the same method of printing with all
printers. OSR5 suports HPNP and LPR/LPD in scoadmin. Which are you
using? Are you using a mixture?
If it's LPR/LPD, is the jobs larger than 2MB? If so, add #MX0 to the
/etc/printcap entry to prevent the spooler from dying at exactly
2MBytes.
The 170x supports bi-directional parallel ports which drives some
older printers insane (HPIIp, HPIII), which only have unidirectional
ports. Dive into Windoze Jetadmin and set the port to unidirectional.
This may be the source of the "flow control" problem.
Is the Jetdirect HP170x an HP3258a or 3258b? I had some lockup
problems with the "a" version that magically disappeared when I
replaced it with a "b". (Sorry, I don't recall the details).
If you're looking for an alternative to HPNP and LPR/LPD, try netcat.
http://www.cruzio.com/~jeffl/sco/lp/
http://www.tkrh.demon.co.uk/netcat.html
Netcat prints directly to the IP socket and is much easier to
configure.
3.2v5.0.4 was not known for great printing. There were some updates
issued with fixes of LPR/LPD (oss469d ??). What's installed:
customquery listpatches | head -1
will supply a list. Check at:
http://www.sco.com/support/toolbox/patch.html#osr504
and see if there's anything missing.
Good luck.
Duncan Seibert
limited. We are using Centronix. All printers, HP 4000 series, 2100 series,
5 series, and jet directs to dot matrix use the same configuration. The
repeat problems start with files as small 10K.
I'm off on vacation for a few weeks but a colleague, bhillman, will be
following the thread.
Thanks for your help,
Duncan
"Jeff Liebermann" <je...@comix.santa-cruz.ca.us> wrote in message
news:l4sbrtc0nk7e0pdli...@4ax.com...
Jeff Liebermann
wrote:
>We are using HPNP with 1 3258a and 1 3258b. The options in JetAdmin are
>limited. We are using Centronix. All printers, HP 4000 series, 2100 series,
>5 series, and jet directs to dot matrix use the same configuration. The
>repeat problems start with files as small 10K.
Weird. I'm a bit confused with your description. As far as I can
tell, you have exactly two HP170x print servers, which appear to be
plugged into unspecified dot matrix printers. The other printers
(HP4000, HP2100, HP5_something) have built in JetDirect print servers,
and function properly. Is this correct? If not, could you please
un-muddle the system description?
Since the same HPNP print spooler is used for the other working
JetDirect print servers, I don't think the problem is in the OSR5
print spooler. Since the unspecified dot matrix printers seem to be
problematic, could it be that the point where the print spooler hangs
is exactly the size of the internal print buffer in the dot matrix
printer? A fast test would be to temporarily replace one of the dot
matrix printers with a parallel port laser printer and see if the
problem evaporates.
Also, please check or replace the parallel printer cable(s). I smell
some kind of communications problem between the printer and the print
server, and the cable might be part of the problem.
>I'm off on vacation for a few weeks but a colleague, bhillman, will be
>following the thread.