Network Printer Problem - HPUX

[Craig Sutton_2]

I moved the HP server from one office to another and am having problems with the printers.
The printers are on different networks:

previous location network IP's:
x.x.20.9 - printer

current location network IP's:
x.x.10.15 - server

The only thing that changed was the IP of the server. After re-ip'ing things and getting them running, the printer in the old office - known in SAM as a network printer - only seems to print some simple text files. Otherwise, the print job sits in the scheduler saying, "printing". I am able to ping the remote/network printer and telnet to port 23&9100 on the printer - so it's not a firewall issue.

I just deleted the printer using JetDirect admin when I went to add network printer within SAM. Then I re-added it... but now it won't even print the simple text file to it.

Any assistance provided would be great.

Thank you,

Craig

[Craig Sutton_2]

A little more added info:

From lpstat:
prx1-4892 root priority 0 Jun 28 15:53 on prx1 tmp.txt 15 bytes


And from netstat:

tcp 0 3204 server1.ourdomain.com.51132 prx1.9100 ESTABLISHED


This shows the connection is there to the printer from the server... *sigh*

Thank you,

Craig

[Bill Hassell · Accepted solution]

You said that you only changed the IP address. This is not correct when you move any computer (or network printer) to another network. You must setup 3 separate values for all network devices when they are part of a larger network. The required values are:

IP address
subnet mask
router

The new network has a different router and in order for packets to flow in both directions, the router must be correct as well as the subnet mask. Be sure to look at the status of the printer's LAN card. Use the selftest or printer configuration page. Errors might be "dup arp address" or something else. Also use hpnpadmin to report all the statistics in the printer's LAN card:

/opt/hpnpl/bin/hpnpadmin -v 12.34.56.78

where 12.34.56.78 is the IP address.

[Craig Sutton_2]

here's the output from hpnpadmin:

192.168.20.9 is a network printer

Printer State : ready to print


server1 is allowed access to 192.168.20.9

Fail (1)

Card IP Address : prx1 (192.168.20.9)
Network Mask : 255.255.255.0
Default Gateway : ??? (192.168.20.1)
Idle Timeout : 90 seconds

Uptime : 8:01:23
Connections Accepted: 106
Connections Denied : 0 (not on access list)
Connections Aborted : 77
Last Host : server1.mydomain.com (192.168.10.15)
Last Host TCP Port: -14397
Reason : idle timeout
Time Since Abort : 3:36:12
Connections Killed : 0
Bytes Received : 0 (current connection)
Bytes Sent : 0 (current connection)
Total Bytes Received: 595760 (since power-on or reconfig)
Total Bytes Sent : 16130 (since power-on or reconfig)

Control Panel : POWERSAVE ON
Line State : Online

TCP Statistics

649 segments received
0 segments received in error
48 segments received in order
78 segments received out of order
45 zero window probes
0 segments discarded
293 segments sent

UDP Statistics

2109 datagrams received and delivered
674 discarded due to no application at the destination port
0 discarded due to other reasons
1074 datagrams sent

IP Statistics

3980 datagrams received
0 discarded due to IP header errors
0 discarded due to address error
0 discarded due to an unknown or unsupported protocol
2055 datagrams transmission requests
0 discarded due to lack of resources
0 discarded due to no route to destination
0 valid routing entries discarded

ICMP Statistics

12 messages received
0 messages received with ICMP-specific errors
0 destination unreachable
2 time exceeded
0 source quench
0 redirect
10 echo
10 messages sent
0 destination unreachable
0 time exceeded
10 echo reply

SNMP Statistics

1073 packets received
1071 GetRequests
1 GetNexts
0 SetRequests
0 bad community names
0 operation not allowed by the SNMP community named
1067 packets sent
0 traps

[Craig Sutton_2]

Oh yeah, I forgot to mention, the only IPs that were changed were on the server (it moved to new location on new network). This included the default router info and the netmask.

Craig

[Bill Hassell]

Sorry, I thought the printers had moved. Start by printing various files using the hpnpf command as in:

alias hpnpf=/opt/hpnpl/bin/hpnpf
hpnpf -x 12.34.56.78 -s /var/tmp/hpnp.log

If is ASCII, put -N in front of the filename:

hpnpf -x 12.34.56.78 -s /var/tmp/hpnp.log -N

Then look at the hpnp.log file to see if any network problems are being reported.

[Geoff Wild]

As a test - why not delete one of the printers giving you trouble - then re-add it - and see what happens....

Rgds...Geoff

[Craig Sutton_2]

I tried deleting and then re-adding the printer... but jobs still hang in the queue.

Interesting though when I used the hpnpf prog. The outcome is as follows:

server1# more hpnp.log

Jun 28 22:28:43%%[ status: Job: ; User: ]%%
Jun 28 22:28:43%%[ status: making connection to 192.168.20.9; source: ethernet ]%%
Jun 28 22:28:43%%[ status: connected to 192.168.20.9; source: ethernet ]%%
Jun 28 22:28:43%%[ status: transmitting data ]%%
Jun 28 22:28:43%%[ status: finish sending print data ]%%

This tells me that using the IP directly works... but that when I use the printer name (which is ip'd correctly in the hosts file)it hangs. But deleting and re-adding network printer using jetdirect admin tool from sam doesn't seem to affect whether it works (I do test the printer after creating it using the admin tool).

[Bill Hassell]

Try removing and adding the printer using addqueue and the IP address of the printer:

/opt/hpnpl/bin/removequeue -q local_prn_name
/opt/hpnpl/bin/addqueue -h 192.168.20.9 -q myprinter

Then try printing with:

lp -dmyprinter -odebugm /var/tmp/debug.log /etc/issue

There will be a file in /var/tmp/debug.log that should give a lot of details. If it works OK, use the same option with a bigger job. This assumes that the printer is an HP printer with an internal JetDirect LAN card.

[Craig Sutton_2]

Odd. When I attempt to run the lp command with the debug, it won't print anything to the file. Below is what occurred:

server1# lp -d prx1 -odebugm /var/tmp/debug.log /etc/issue
lp: can't access file "/var/tmp/debug.log"
lp: can't open file /var/tmp/debug.log

So I touched the file and then attempted it again, and the following is what occurred:

server1# lp -d prx1 -odebugm /var/tmp/debug.log /etc/issue
lp: file "/var/tmp/debug.log" is empty
request id is prx1-4930 (1 file)

The file was there and I had chowned it to lp with perms set to 666...


It did, however, print the file. But when I send a 1k file to it, it sits in the queue and says it's printing... but nothing is happening.

[Bill Hassell]

Whoops, the debugm option is like all the lp options...no space allowed after the keyword. The command should be:

lp -d prx1 -odebugm/var/tmp/debug.log /etc/issue

Notice: no space after debugm. or you can just use the -odebugm with nothing and the log file will be: /tmp/prx1 as in:

lp -d prx1 -odebugm /etc/issue

With the space, the lp command saw the option -odebugm and created /tmp/prx1 automatically (it's probably still there). Then lp saw /var/tmp/debug.log and figured that's a file to print (hence the error messages about not finding it).

[Craig Sutton_2]

It works every time with everything I print when I use the -odebugm option, but it hangs every time I leave that option out. The following is from the debug.log file:

^[%-12345X@PJL USTATUS PAGE = OFF
@PJL COMMENT **** Job (prx1-4951) Profile ****
@PJL COMMENT Copies : 1
@PJL COMMENT Banner page: Front
@PJL JOB
@PJL SET COPIES = 1
@PJL ENTER LANGUAGE=PCL
^[&k2G^[&l0O^[)8U^[)s1p60v1s0b16901T^N
root^[)s14v0S

User: (No User Info in /etc/passwd)

Request: prx1-4951 from server1
Options: debugm/var/tmp/debug.log


Tue Jun 29 14:24:33 PDT 2004
^O^[&l0E^[&a120v0H^[*c4h1680v0P^[&a120v0H^[*c5616h4v0P^[&a1800v0H^[*c5616h4v0P^[&a120v5616H^[*c4h1680v0P^[&l0e
8C^[&a120v0H^[*c5616h1680v10g2P^[&a5676v36L********** Option Summary **********
(See "man net_ljx000" for details)

^[&k2Sauto (default), postscript, pcl, hpgl2, hpgl2_p, raw, relay
manual, tray1, tray2, tray3, bin1, bin2, mtype
legal, letter, exec, ledger/11x17 A3, A4, A5, A6, B5-ISO
com10, C5, DL, monarc PostCardS, PostCard/PostCardD
B4-JIS, B5-JIS, B6-JIS topaz, yb, nb, job, nojob
dpi#, fuser simplex, duplex, hduplex
2up, 2+,4up(pcl-hpux only), portrait, landscape, quality
srbb#, srb#, sre#, tondensity, econo# (#=on/off)
For PS : wmnum#, wmstr, ascii, ps1, ps2
For PCL : text, ln66, stye#, italic, condensed, condensedi
c, 10, 12, lpi# height#, weight#, medium, bold, ebold, type#
^[&a5518v2505H^[*c4h1800v0P^[*c2880h4v0P^[&a7315v2505H^[*c2880h4v0P^[&a5518v5385H^[*c4h1800v0P^[E^[%-12345X@PJL US
TATUS PAGE=ON
@PJL JOB NAME = "User: root; Job: prx1-4951" START = 1
@PJL COMMENT Start Page : 1
@PJL COMMENT End Page : Last Page
@PJL SET COPIES = 1
@PJL COMMENT File: /etc/issue
@PJL COMMENT ** LANGUAGE: PCL
@PJL COMMENT ** 1-up Text printing (adding one CR for each LF)
@PJL ENTER LANGUAGE=PCL
^[&s1C^[&k2GGenericSysName [HP Release B.11.11] (see /etc/issue)
^[E^[%-12345X@PJL
@PJL RESET
@PJL EOJ NAME = "User: root; Job: prx1-4951"
@PJL RESET
@PJL EOJ
@PJL COMMENT End of Job
^[%-12345X

The following is what I type in to get it to work and what doesn't work:

lp -dprx1 -odebugm/var/tmp/debug.log

The above works... the following doesn't:

lp -dprx1

Craig

[Bill Hassell]

Looks OK. The debugm output is useful in debugging printer scripts. To watch the actual network activity, use the -ohpnpflog option as in:

lp -dprx1 -ohpnpflog /etc/issue

The network trace will be in /tmp/hpnpflog. For short jobs, the file is short but can get very long with a few pages of printout.

[Craig Sutton_2]

I tried the -ohpnpflog option but that one doesn't work when I run lp. It hangs and I have to cancel the print job. We will recompile many programs with the -odebugm/dev/null option on the lp line. That should get us through month end tomorrow... but I still don't know why lp without the debug option is hanging.

[Bill Hassell]

Was the /tmp/hpnpflog file empty when it hangs? You may have to resort to getting a copy of Ethereal (for HP-UX or for a PC) and tracing all the communication to/from the printer's IP address. Why the debugm option works is quite a mystery but it is passed to hpnpf just like the hpnpflog. hpnpf does all the network tasks. In looking over the previous posts, I didn't see where you had tried hnpnf directly using only the IP address of the printer:

/opt/hpnpl/bin/hpnpf -x 12.34.56.78 -N /etc/issue

and then to trace the network activity:

/opt/hpnpl/bin/hpnpf -x 12.34.56.78 -N -l /tmp/hpnpflog /etc/issue

Another thing to check: nslookup printer-hostname and also nslookup 12.34.56.78 to see that your printer's name and IP are both resolvable. The default nsswitch.conf file always uses DNS which may not be desirable if there are difficulties in getting DNS changes propagated into your network. I prefer this line in /etc/nsswitch.conf:

hosts: files [NOTFOUND=continue UNAVAIL=continue] dns [NOTFOUND=retur
n UNAVAIL=continue TRYAGAIN=return]

What this does is to always check /etc/hosts first, then DNS. /etc/hosts is kept short with only important IP addresses and ones that can be a problem (ie, network printers). Then once DNS is working (you can use nslookup printer-hostname dns-servername to check), you can delete the entry from /etc/hosts. Using files first improves system and network performance in many cases.

[Craig Sutton_2]

Okay, some setbacks have occurred. I thought the -odebugm option was printing since it didn't hang in the queue, but I was wrong. It wasn't printing anything but just created the logfile I specified. So that has to be backed out of the programs.


I checked nslookup to make sure the correct IP was being returned, it is. I have the nsswitch.conf file set with FILES then DNS.

I also ran hpnpf to the ip and the output from the logfile is as follows:

08:20:41 hpnpf[22502]
OpenLog: logging started (/tmp/hpnpflog)
08:20:41 hpnpf[22502] Process: entered
08:20:41 hpnpf[22502] OpenSocket: entered
08:20:41 hpnpf[22502] OpenSocket: using 16K send buffer
08:20:41 hpnpf[22502] MakeConnection: 192.168.20.9, port 9100
08:20:41 hpnpf[22502] DoNonBlocking: non-blocking on
08:20:41 hpnpf[22502] Connection has been set up
08:20:41 hpnpf[22502] connected
08:20:41 hpnpf[22502] Process: sending file /etc/issue
08:20:41 hpnpf[22502] SendFile: entered
08:20:41 hpnpf[22502] SendFile: 53 bytes read from host
08:20:41 hpnpf[22502] SendFile: 0 bytes read from host
08:20:41 hpnpf[22502] SendFile: 53 bytes written to socket
08:20:41 hpnpf[22502] SendFile: end, return succ
08:20:41 hpnpf[22502] DoNonBlocking: non-blocking off
08:20:42 hpnpf[22502] Process: read EOF on socket
08:20:42 hpnpf[22502] StopLog: logging stopped


Now this did print. I called the office and had someone check. Interesting.

[Bill Hassell]

Go ahead and try larger files but make sure the path for the hpnpflog file has lots of free megs. The one line /etc/issue generated more than a dozen lines of output so a large file may need several megs. You're really interested in the last 10-20 lines of the log where it hangs.

[Bill Hassell]

PS. If you don't get any additional hangs with the -l logging, you can always use -l /dev/null so the logfile is not created.

[Craig Sutton_2]

Here is the output from the logfile:

OpenLog: logging started (/tmp/hpnpflog)
09:41:04 hpnpf[26073] Process: entered
09:41:04 hpnpf[26073] OpenSocket: entered
09:41:04 hpnpf[26073] OpenSocket: using 16K send buffer
09:41:04 hpnpf[26073] MakeConnection: 192.168.20.9, port 9100
09:41:04 hpnpf[26073] DoNonBlocking: non-blocking on
09:41:04 hpnpf[26073] Connection has been set up
09:41:04 hpnpf[26073] connected
09:41:04 hpnpf[26073] Process: sending file /opt/hpnpl/tmp/pdx1
09:41:04 hpnpf[26073] SendFile: entered
09:41:04 hpnpf[26073] SendFile: 2093 bytes read from host
09:41:04 hpnpf[26073] SendFile: 2093 bytes written to socket
09:41:04 hpnpf[26073] SendFile: 1838 bytes read from host
09:41:04 hpnpf[26073] SendFile: 1838 bytes written to socket
09:41:04 hpnpf[26073] SendFile: 0 bytes read from host
09:41:04 hpnpf[26073] SendFile: end, return succ
09:41:04 hpnpf[26073] DoNonBlocking: non-blocking off
09:42:34 hpnpf[26073] Process: Connection reset by peer


It apparently never received an EOF as it did in the previous small file which was sent. When I ran the print request (hpnpf -options file) it sat there till the connection was dropped. This is probably happening with the spooler too. Also, nothing printed out when I ran the larger print job.

The following is from the end from the smaller print job - which did print out:

08:43:12 hpnpf[23534] SendFile: end, return succ
08:43:12 hpnpf[23534] DoNonBlocking: non-blocking off
08:43:13 hpnpf[23534] Process: read EOF on socket
08:43:13 hpnpf[23534] StopLog: logging stopped

[Craig Sutton_2]

One other thing to note:

The following is from a -odebugm/logfile:

^[E^[%-12345X@PJL
@PJL RESET
@PJL EOJ NAME = "User: root; Job: pdx1-5014"
@PJL RESET
@PJL EOJ
@PJL COMMENT End of Job
^[%-12345X

Now I'll print the output from a failed print attempt from someone else earlier:

@PJL RESET
@PJL EOJ NAME = "User: sbyers; Job: pdx1-5009"
@PJL RESET
@PJL EOJ
@PJL COMMENT End of Job
^[%-12345X


I caught that file in the /opt/hpnpl/tmp/ directory.
I don't know if this helps... but I did notice a difference between what the debug option is creating and what the lp is creating.

[Craig Sutton_2]

Ignore my last comment on here, I used the diagnostic menu from JetDirect and the output file was correct. When I sent it to the printer it hung at the -I'm assuming- last step in the analysis process. Here's what came up:

Diagnostic Message:
------------------
All printing components have been verified functional. The next
step is to send the intermediate output to printer via hpnpf with
debug logging on. The log (/opt/hpnpl/tmp/hpnpflog) records
the activities between hpnpf and JetDirect. Delete the log when
you don't need it anymore.


Do you want to send this job to it (y/n/q, default-n)? y
hpnpf: Connection reset by peer
Failed to send the file to output

comments?

[Craig Sutton_2]

Could the modelscript for this printer be the problem?

[Craig Sutton_2]

Oops... I didn't mean to close this out. I just wanted to give the points to people who responded.

[Bill Hassell]

This is the key:

09:42:34 hpnpf[26073] Process: Connection reset by peer

The connection is being refused. This is likely due to a router or firewall between your box and the printer. Start with a traceroute to the printer's IP and see what is between you and the printer. You'll need to get your network team involved, especially if there are evolving security policies being developed. The final step is to use Ethereal (and on the PC, winpcap) to trace a failed connection. Note that hpnpf does all the work. The lp spooler simply schedules the job and starts the printer scripts running. By using hpnpf directly, you can eliminate a lot of code.

[Craig Sutton_2]

Is there a difference between the jetdirect firmware and the printer firmware? Or are they one and the same? If there is a difference, how do I update the printer firmware?