[NTLUG:Discuss] printing using CUPS

[Leroy Tennison]

Charles Cashion wrote:

> I have an AMD computer running Fedora Core 3.
> It is connected via ethernet to a router.
> The router connects to a print server.
> The print server address is 192.168.1.254 and it responds to ping.
> The print server connects by parallel port to the Canon i550 inkjet.
> The router also connects to a cable modem supported by comcast.
>
> The router/print server/Canon i550 are all working.
>
> I have cups-1.1.22
>
> If you were sitting in front of my computer, and it did not print,
> what would you want to see? What would you want to examine?
>
> Thanks,
> Charles Cashion
>
> _______________________________________________
> https://ntlug.org/mailman/listinfo/discuss
>
Go into the print queue itself (System Settings->Printing) and see if 
there are any messages in the Description area (I'm having trouble with 
FC3 using settings which work fine on RH9).  One issue you may be facing 
is if the printer itself needs to "talk back" to the host.  Idon't know 
if CUPS can handle this (not trying to cast doubt, just don't know).  If 
nothing is in the queue then "windowize" your apps so that you can see 
the queue and application simultaneously.  Try to print watching to see 
if it appears that anything is making it to the queue.  If it is then 
what I would want to see is an Etherreal trace.  There are some 
guidelines for setting this up if you have never done one:  Get the 
application set up to print first (all you have to do is click 'print'), 
start Etherreal and start a capture, immediatly change to the 
application and print, assoon as things are "quiet" (no obvious 
activity) stop the capture.  The goal is to get only 100-200 packets in 
the trace (in most cases the less the better).  In the trace you are 
looking for high-level things: messages going to the print server's IP 
address, any replies coming back, retries to the print server 
(particularly with no response).  This may give you some idea of where 
the problem is located.  Avoid getting into intra-packet analysis if at 
all possible - you could be hours or days disecting them.