Link to home
Start Free TrialLog in
Avatar of catzodellamarina
catzodellamarina

asked on

Printing - Any known issues with printservers and IP addressing?

I'm not a UNIX admin but I suffer at the hands of one.  I'm a LAN Admin with a MS domain.  I have IP printers, Ricoh and HP's  with Jetdirects or Ricoh NICs.  Printing is done from the NT Server spooler for MS Office apps, and the HP-UX server for Unix printing.  Both print to the same IP address, but they have different NOS printer names.
Here's my problem:

When I poweroff, disconnect a print server from a printer, replace it with a different print server (same IP address & name), MS Printing resumes like nothing ever happened.  UPUX print queue fills up but printing stops. Several powerdowns, restarts, and going back to the original printserver doesn't kickstart UNIX printing.  My UNIX admin doesn't know why it happens and offers no solutions except I shouldn't mess with changing things.  I'm battling an issue I don't have rights or the training to solve (the Unix server) and an admin with a bad attitude.  In addition he blames the Ricoh printers - even though I've proven it happens to HP printers as well.  I'd like to:
1. FIX THE ISSUE!!!
2. Know why Unix printing is so sensitive and unforgiving to printserver changes.
3. Upgrade printservers & printers without having to call my UNIX admin for attitude?  Is there a timeout on Unix spoolers?  A safe waiting period?  Should I shut down the printer & printserver for 5 min, 1 hr, 2 hrs?  before adding a new printserver?
Avatar of Pete Long
Pete Long
Flag of United Kingdom of Great Britain and Northern Ireland image

>>My UNIX admin doesn't know why it happens and offers no solutions except I shouldn't mess with changing things

bah - Unix admins!

LOL Impress your HPUX administrator by asking if he has jetadmin installed on the HPUX box (Yes Im serious) jetdirect runs on HPUX (there both HP products after all) most printing problems from HPUX are software specific though? are you printing from an application? is there an entry in the HOST file on the unix box this would explain your problem (tell the *nix boy) its in the etc/hosts directory ask him to vi it for added smugness :)

Pete
Avatar of catzodellamarina
catzodellamarina

ASKER

He won't be impressed.. only irritated.  I will ask him about Jetdirect on his HPUX box.  I know he's aware of the host file because he sends it to printers as a test page.  The one I got today says:
B.11.11_LRhosts $Revision 1.9.214.1
# (followed by a bunch of #text lines)
Printer IP addresses, hostnames, aliases

There is no entry for my printer and many, many others.  Perhaps he keeps them listed somewhere else?

Our application we print Unix from is called MFGPRO.
>>Perhaps he keeps them listed somewhere else?

Well if he does youll like to think hed know where they are? ask him if you can see the print spooler info, or as a long shot see if they are boing loaded from usr/local/bin

Pete
Meddle not in the affairs of sysadmins, for they are unsubtle and have acccess to your mail ;-)

If Unix detects a printer fault  _while_printing_, it will generally disable the print queue and will not automatically reenable it. But it will keep accepting requests, so the queue builds up.  The printer status & queue should be obvious from running `lpstat -t`; And doing `enable printer_name` should resume printing.  Those commands DON'T need root privileges ;-)

You mentioned powerdowns, but I assume that's of the printserver, not the Unix box!  (Rebooting the Unix box would stop & start the spooler, which would renable all the printers, but even stopping/starting the spooler is unnecessary in this case)
:) Meddle not in the affairs of sysadmins :)

Ahh the BOFH school of system support ;)
Some other thoughts:  If I recall correctly, Jetadmin keeps its own database of queue names/ IP addresses so it doesn't use /etc/hosts, which would explain the missing addresses.  I always add printers to /etc/hosts, for easy reference as Jetadmin is a pain to use (tho' it's essential for adding networked printers and has a good range of printer drivers).

The delay in getting the queue going again could also conceivably be related to arp tables (IP <-> MAC address tables) not being updated, so the Unix box can't resolve the target device correctly- but as a LAN admin you'd know more about that sort of stuff than I do!

This is great info guys.

So to summarize - Unix Admin can have list of printers in either:
a. host file <IP Address>  <hostname>  <alias>
b. JetAdmin on the Unix box

By the looks of the host file, he must be using JetAdmin.


When I make print server changes, we do experience UNIX queues continuing to add print jobs, but not printing them out.  When the Unix admin disables/enables the queue, it generally spits a copy of the last job out, then sits idle for XX amount of time.  The whole time we can't print, he's messing with UNIX commands, I'm turning off/on printer, printserver, unplugging powersupplies, and praying. lol

After a period of time, the new printserver will work again, and printing resumes.  This is beginning to smell like a MAC address issue.  The new printserver with same IP address is ready to fly, but UNIX needs to translate MAC but it's slow.  This explains the delay in getting a LAN printer to work again.  Can we submit the MAC address to UNIX box manually in JetAdmin and speed up the process?
Also - very important - - have any of you experienced incompatibility with UNIX LAN printing and printservers other than HP?  Reason I ask is the Unix Admin swears on a holy stack of bibles that if I use ANY other printer or printserver other than HP, it causes problems.
`grep PERIPH= /etc/lp/interface/*`   to see JetAdmins "host list"

`arp -a` will show you the current arp cache on the HP-UX system, and should prove or disprove (our) theory that the arp table is not getting updated.  `arp -d hostname` can be used to flush an old entry, so HP-UX will broadcast a request for a new MAC address to match the IP addy.  But an arp mapping should only be cached for 5 minutes before it is flushed & rediscovered automatically.

What does your network look like? Is it possible that there's a switch/router between the Unix box and the printers that has its own arp cache and is slow to update it? Routers can act as arp servers, so HP-UX would continue to be fooled. Is HP-UX only using the hosts file, or does it use NIS or DNS, which whould be slower to update?

And while I'm clutching at straws, is it possible that arp refers to /etc/hosts and so if there's no entry in /etc/hosts it will struggle to update the arp cache?  You could add try adding a printer using an entry in the hosts file & then swap the print server to see if that makes a difference.

I've used Intel & some other print servers on mixed Windows/Unix/Novell networks without problems, though working out the config initially is often painful - e.g. having to send Unix print jobs to port 9100 so the print server recognises it's a Unix job and sends the appropriate control characters, or even hack the print driver to manually send an end-of-job character.  
ASKER CERTIFIED SOLUTION
Avatar of tfewster
tfewster
Flag of United Kingdom of Great Britain and Northern Ireland image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
You mentioned replacing the print servers and configuring with same ip address as one removed.  It is possible that your HPUX machine still has the old arp table entry.  Do an "arp -a" command and make note of the MAC(hardware adress) of the printserver that is not working.  Then compare that with the MAC adress that is printed on the outsied of the jetdirect.  The numbers should match.  If they don't, your HPUX machine is trying to send the print jobs to a piece of hardware that is no longer there.  Check your man pages on how to remove the offending arp table entry, then make sure the printer is enabled.  Send a new print request and it will probably work.

Good luck

catzodellamarina, thank you for the points, but could you summarise what the problem was and what solved it?   I suggested  a few approaches to try, but I'm curious as to what the real issue was...

Thanks again,
Tim
The HPUX ARP table & MAC address seem slow to repond to printserver hardware changes.  Stopping and starting the spooler and queue doesn't speed up the process.  It seems whenever we change a printserver, we need to give UNIX time to learn the MAC address.  The other solution is to have the UNIX admin manually update the ARP table.  That is his call.

I've presented the info to my manager.  She accepted it too and I left her the job of telling her employee of the fix.  I can't say I've tested it since the UNIX admin will only give me the finger if I make suggestions to him.  He does not play well with others.
>>He does not play well with others.

Really? - set the port on the switch to auto negotiate his drop speed, Im sure he'll be getting friendly again soon ;)

Pete
UPDATE - I was told by my Herr HPUX Fuherer:
"HP-UX does not use an ARP table.  You have received erroneous information."

Is this true, or is he got a god complex and refuses to be upstaged by you guys?
catzodellamarina, I'm torn between saying "Trust your sysadmin, he understands the Higher Truth"  and "LART him, he asked for it".  I have the same problem with our network "gurus" - I have to prove to them that the problem is THEIRS before they'll lift a finger. A common issue is that overnight backups die with comms errors: I ask them to reset the port on the hub (approx 2 minutes work)  - They respond by saying "We see no evidence of a problem - Check your NIC & reboot the server" (Which would take at least 40 minutes).

The TCP/IP model depends on ARP to resolve IP addresses to MAC addresses. HP-UX caches those mappings in a "table" (`man arp`).   We may be looking in the wrong area for the problem, but it doesn't hurt to eliminate ARP as the culprit.

I'd suggest you ask management to "force" you to collaborate on the tests we've discussed , e.g. arp -a/arp -d after swapping a print server; If I'm wrong, I'll only have wasted a few minutes of your time. (If I'm right, I reserve the right to gloat over your Guru ;-)






I've spoken to my dept manager and she is pleased to know I'm discovering solutions and answers to this issue.  In the meantime, we are awaiting a moment to attempt a fix and present facts without threatening the Unix admin's insecurity.  Implementing a tactful fix is necesary due to the sensitive issue of this employee.

On another note:
I'm finding out if you have a temper, prone to irrational thinking, an over-inflated ego, and lack social skills - you're job is protected and nobody wants to bother you.   You get treated like the behavior disorder kids in school.  Like the teacher used to say, "Leave him alone.. he's being quiet."   This Unix admin won't ever have to fix or assist with this issue since it may disrupt him emotionally.  What a crock.
>>I'm finding out if you have a temper, prone to irrational thinking, an over-inflated ego, and lack social skills - you're job is protected and nobody wants to bother you

This will only hold for a while :) sooner or later it dont matter how good you are if your attitude troward others is bad you will go https://www.experts-exchange.com/M_113854.html proves my point :)