Network Printers - Stopping.

Tue Jul 5 05:51:39 PDT 2005

> Anonymous wrote:
> >
> > > John Winward wrote:
> > > >
> > > > > John Winward wrote:
> > > > > >
> > > > > > Hello
> > > > > >
> > > > > > I am am having a strange problem with CUPS and network printers.
> > > > > >
> > > > > > I am running Red Hat Enterprise 3.0 ES, up-to-date KERNEL and up-to-date CUPS rpm.
> > > > > >
> > > > > > My database is D3/PICK and network printers are supported via the LPD process. I am aware LPD has now gone from Enterprise, but CUPS has CUPS-LPD for backward compatability. All the printers are set-up as RAW devices, no specific drivers required. Most of the time the printers work ok, but every now and then, random network printers will appear to stop printing, sometimes up to 30 minutes at a time. You can look at the GNOME PRINT MANAGER and it will show the jobs.
> > > > > >
> > > > > > Anywhere between 5 and 30 minutes and the printer will continue printing jobs. It is not the printer because we have 40 network printers all assigned and random printers will go into this state.
> > > > > >
> > > > > > To add to this environment, only those printers that are on REMOTE locations are the ones that appear to stall. We have 6 shops all connected via VPN / FRAME RELAY. The connections between these sites don't appear to drop because each SHOP has 6 PC's connecting via TELNET and these never drop.
> > > > > >
> > > > > > I am wondering whether CUPS is failing to connect to printers on a random basis, so when jobs are getting sent, it holds onto them. Only when it believes it can communicate with a printer does it send them again.
> > > > > >
> > > > > > Any ideas or help would be appreciated.
> > > > > >
> > > > > > ==========================
> > > > > > Further Notes
> > > > > > ==========================
> > > > > >
> > > > > > On a day to day basis all 45 network printers will print instantaneously as soon as a JOB has been sent. Then, on the ODD occasion a JOB will be sent, but the printer will not output it. The DATA lights are not on, so the JOB is still residing on the Red Hat Enterprise server and not simply stuck in the Printer / Print Server itself.
> > > > > >
> > > > > > The job will eventually come out, with all other jobs that may have accumulated behind it. This delay could be 5 minutes, it could be 30 minutes. totally random. When the printer seems to become active all jobs print as if there was nothing wrong in the first place. This is usually what happens, but it can also get stuck on loads of jobs and print them out very slowly.
> > > > > >
> > > > > > The printers NEVER go into "STOPPED" mode, just that CUPS seems to stop printing. Today (30th June 2005), one of the network printers seem to have stopped. It had 14 jobs queued. I went through http://localhot:631, stopped the printer, then started and the NEXT print job came out, but the remaining 13 were still sitting there. Every time I stopped / started the printer another job would come out. In ALL cases, CUPS never complained the printer was having a problem.
> > > > > >
> > > > > > I put the CUPS system into DEBUG mode this morning, and the ONLY error I can see in there (when one of the printers appeared to have hesitated) is the following.
> > > > > >
> > > > > > [Job 16405] Remote Host did not respond with a command status byte after 300 seconds!!
> > > > > >
> > > > > > Can someone explain what this means, and how I overcome it.
> > > > > >
> > > > > > Thanks
> > > > > >
> > > > > > John
> > > > >
> > > > > Are you using reserved source ports for your LPD driven printers? If yes, the lpd backend uses only
> > > > > port numbers 721 .. 732, that means at most 12 jobs may be processed in parallel. If your printers
> > > > > support printing from unresoerved ports, try that.
> > > > >
> > > > > Helge
> > > > >
> > > > > --
> > > > > Helge Blischke
> > > > > Softwareentwicklung
> > > > > SRZ Berlin | Firmengruppe besscom
> > > > > http://www.srz.de
> > > >
> > > > Hello Helge
> > > >
> > > > Sorry, do not understand your questions?
> > > >
> > > > All the printers either have Network Ports in them, or are on Print Servers. I have not configured anything different on the Linux server, just a BASE install with applied updates.
> > > >
> > > > I have not changed any "defaults" withn Linux / CUPS if that is what you are asking?
> > > >
> > > > John
> > >
> > > To settle the issue step by step, a simple question first:
> > > What does the command
> > >       lpstat -v printername
> > > (where printername is to be replaced by the name(s) of your printer(s)) reply?
> > >
> > ======================
> > ======================
> >
> > Hello Helge
> >
> > CONTRACT05 seems to have stopped printing for 20 minutes, these are the results
> >
> > [root at d3server root]£ lpstat -v CONTRACT05
> > device for CONTRACT05: lpd://192.168.5.40/lpt1
> > [root at d3server root]£
> >
> > [root at d3server root]£ ping 192.168.5.40
> > PING 192.168.5.40 (192.168.5.40) 56(84) bytes of data.
> > 64 bytes from 192.168.5.40: icmp_seq=0 ttl=253 time=27.6 ms
> > 64 bytes from 192.168.5.40: icmp_seq=1 ttl=253 time=26.5 ms
> > 64 bytes from 192.168.5.40: icmp_seq=2 ttl=253 time=26.7 ms
> >
> > [root at d3server root]£ lpstat -a CONTRACT05
> > CONTRACT05 accepting requests since Jan 01 00:00
> > [root at d3server root]£
> >
> > On the CUPS WEB Printer Page (ie http://localhost:631), CONTRACT 05 says "connect from port 515..."
> >
> > All the other printers say "Data Sent Successfully"
> >
> > Then again, CONTRACT05 has woken up again and printed its job. At some point today, it will be a different PRINTER that goes into this mode.
> >
> > John
> >
>
> Ah, yes. The more recent versions of the lpd backend by default try to use a source port number between
> 1023 (upper limit) does to 1 (lower limit) by default when connecting to a printer. This range includes,
> surely, port number 515, which is the official destinationm port number for all LPD implementations I know of.
> Thus, I suspect your print server(s)/printer(s) get confused whenever the source port equals the destination
> port and stay idle until the connectionn is cancelled due to inactivity.
>
> Try to modify the device-URI of your pritner(s) to e.g.
> 	lpd://192.168.5.40/lpt1?reserve=on
> or
> 	lpd://192.168.5.40/lpt1?reserve=off
> The first variant (on may be substuted by yes, true,or rfc1179) restricts the source port numbers to
> 721 to 731 (according to RFC 1179), the latter permits any port number as sorce port.
>
> Even if you don't understand this in full depth, try it out and let us know what happens.
>
> Helge
>
>
> --
> Helge Blischke
> Softwareentwicklung
> SRZ Berlin | Firmengruppe besscom
> http://www.srz.de

============================
============================
Helge

Something has just sprung to mind, and might be a FACTOR in the problem we are seeing.

The DATABASE we run is D3/PICK. Without you having to understand what this is, users TELNET into this database on PC's with Telnet software. We have settings which allows them to have a PORT NUMBER attached also.

Therefore  TELNET 192.168.0.1 16011
           TELNET 192.168.0.1 16030

and so forth. This means we can attach specifc D3/PICK lines to PC's, so that we know "who is who".

The D3 database is setup so as PORT NUMBERS 16001 - 16200 are for the D3 database TELNET users only.

Strangely enough, some users have mentioned that on the ODD occasion when the PRINTER does not output the required report, it appears as if their REQUEST ends up coming out on someboys TELNET session.

If that was the CASE, it could mean that if CUPS is generating a JOB and gave it PORT 16011 or something, that would end up on a Users TELNET screen.

Can you "block" PORT ranges for LPD?

I am going to try the RESERVE=YES, for strict RFC1179 compliance, but that means only 11 ports available. If I have 40 network printers with plenty of JOBS being produced, does that give me sufficent ports to support the environment.

John