Robert Harris wrote:
> (E-Mail Removed) wrote:
> > we have a problem connecting our client machines to DLink and older
> > Kingston print servers, and it seems that CUPS and the print server
> > don't like talking LPD to each other. The printers are a mixture of
> > laser and epson compatible dot matrix printers.
> >
> > Can anyone recommend a print server that will definetly work with
> > fedora, and support IPP or socket printing with parrallel port
> > connectors?
> >
> > We keep trying to get an answer from HP but they just ignore us. We
> > need to sort this out as we are repeatedly having to reset print
> > servers remotely.
> >
> > Any useful answer appreciated.
> >
> > thankyou.
> >
> > kevin
> >
> CUPS doesn't normally have a problem using lpd protocol. Are you sure
> that your print server has an IP route back to your CUPS server (i.e.
> gateway defined if necessary)?
>
> Otherwise set debug mode in your /etc/cups/cupsd.conf ("LogLevel debug")
> and read the logs.
>
> Robert
the problem for the kingston servers is that the cups-lpd backend exits
with a non zero code after printing *N* requests, taking cups down. The
recommended action from the groups Iv'e trawled seems to be not to use
lpd. The Dlink on the other hand seems to think after a while it is
still printing, when it clearly isn't and cups can't send anymore spool
until it clears. Both of these scenarios require a intervention to fix.
the print server and the linux boxes are both on the same cat c lan,
frequently they are the only machines except the router and windoze
clients. Generally the router is defined as the gateway, because we
need remote service access via vpn / telnet
The nature of the printing may contribute to the cause where 50 - 100
small print jobs are loaded into the spool queue rapidly by the
application.
kevin.