Print from hppi but not lp -d

[Michael Steele_2]

Hi again All:

Got an HP2400 that passes hppi diag.s just fine then hangs from 'lp' on the command line. Pings OK, connects from hppi OK, (see log below), the job passes through the queue when I observe it in hppi but then, it hangs from the command line.

# lpd -d (name) (file) <== hangs in queue

14:19:25 hpnpf[26033]
OpenLog: logging started (/home/michaels/UW19.log)
14:19:25 hpnpf[26033] Process: entered
14:19:25 hpnpf[26033] OpenSocket: entered
14:19:25 hpnpf[26033] OpenSocket: using 16K send buffer
14:19:25 hpnpf[26033] MakeConnection: 192.168.56.12, port 9100
14:19:25 hpnpf[26033] DoNonBlocking: non-blocking on
14:19:25 hpnpf[26033] Connection has been set up
14:19:25 hpnpf[26033] connected
14:19:25 hpnpf[26033] Process: sending file /home/michaels/test_print
14:19:25 hpnpf[26033] SendFile: entered
14:19:25 hpnpf[26033] SendFile: 74 bytes read from host
14:19:25 hpnpf[26033] SendFile: 0 bytes read from host
14:19:25 hpnpf[26033] SendFile: 74 bytes written to socket
14:19:25 hpnpf[26033] SendFile: end, return succ
14:19:25 hpnpf[26033] DoNonBlocking: non-blocking off
14:19:25 hpnpf[26033] Process: read EOF on socket
14:19:25 hpnpf[26033] StopLog: logging stopped


Comments?

[Geoff Wild]

I have seen something similar, only resolution I found was to delete the queue and re-add it.

Rgds...Geoff

[A. Clay Stephenson · Accepted solution]

Let's first try to isolate lp from the picture and use hpnpf directly.

1) Do an lpstat -pqueuename and cancel any outstanding jobs.
2) disable queuename # just to be safe
3) Now do ps and look for any hpnpf's to that device. If found, kill 'em.
4) ls -l | hpnpf -x 192.168.56.12 -p 9100 -n
# assuming port 9100 is your boy

Check for your directory listing output at the printer. If this works then the problem is within lp; if not, you have a communications problem.

5) enable queuename # when ready

[Michael Steele_2]

Just hangs there Clay. LP or COMM?

[A. Clay Stephenson]

If hpnpf is hanging then the problem lies in the network, the JetDirect card on the printer, or perhaps the printer itself. Kill the hpnpf process and power-cycle the printer. Think happy thoughts while the printer is coming ready and pet it a little. Check your printer's IP Address, Subnet Mask, and Gateway. Then repeat the above hpnpf test.

It is also (barely) possible that your hpnpf binary is corrupt but I assume that you have other Network printers which are working; if so, it ain't a corrupt executable file.

[Geoff Wild]

If you just want to test network, you can use the hpnpadmin command:

# hpnpadmin -i W052
Printer Description:
--------------------
MFG :Hewlett-Packard;
CMD :PJL,MLC,BIDI-ECP,PCLXL,PCL,PDF,PJL,XHTML,MIME,POSTSCRIPT;
1284.4DL :4d,4e,1;
MDL :hp LaserJet 4345 mfp;
CLS :PRINTER;
DES :Hewlett-Packard LaserJet 4345 mfp;

Printer ID : 400


Or -v for even more info...

Rgds...Geoff

[Michael Steele_2]

Well, as goofy as it is logical all those network tests with port 9100 turned out to be normal. Previous hpnpf -x ip -p 9100 and telnet ip 9100 failures still failing, even though I am now printing. And the final outcome turns into replacing the latest hp2420 model script in hppi (which seems to have some bugs) with the default generic model script. So rebuilding the queuename with the generic default script worked.

I thought this was weird.