CUPS does not print to LPD printer

[Cybodog]

Binary package hint: cupsys

not just a ubuntu issue. Same issue seen in Debian Sid and now Debian stable. The result of a receint security update? Ubuntu 7.10 can print to lpd printer: lpd://192.168.200.150/lpt1 Same address/syntax used for years.

Upgraded to Hardy, Samsung ML-1430 printer comes to life, data light blinks, nothing comes out. Printer stops making noice, data light continues to blink. No print ever comes out. Printer and print server (Hawkings Tech. print server, NIC-->LPT port) have to be re-set to allow other clients to print.

Win boxes print just fine. Ubuntu 7.10 if re-installed prints just fine.

Debian Stable and Sid used to print, no more as of my last Debian test (yesterday). Upstream change made?

This looks as if the spool is very very very slow and the printer times out. I don't know how to troubleshoot any more then this. I am willing and able to do anything you suggest to pin this down.

no errors in cups log (uploaded)

Description: Ubuntu hardy (development branch)
Release: 8.04
cupsys:
  Installed: 1.3.7-1ubuntu2
  Candidate: 1.3.7-1ubuntu2
  Version table:
 *** 1.3.7-1ubuntu2 0

[Till Kamppeter (till-kamppeter)]

Can you run "ls -l /usr/lib/cups/backend/lpd"? It most have the following results:

till@till-laptop:~$ ls -l /usr/lib/cups/backend/lpd
-rwx------ 2 root root 19220 2008-04-21 21:18 /usr/lib/cups/backend/lpd
till@till-laptop:~$

Important is that only the owner is allowed to execute it and that the owner is root. Then CUPS knows that the backend must be run as root (otherwise it runs the backends as the special user "lp"). The lpd backend has to be run as root, as otherwise it cannot communicate through the reserved LPD port 515.

Make also sure that there is no firewall blocking port 515 on your system.

[Cybodog (damon-damtek)]

Till Kamppeter wrote:
> Can you run "ls -l /usr/lib/cups/backend/lpd"? It most have the
> following results:
>
> till@till-laptop:~$ ls -l /usr/lib/cups/backend/lpd
> -rwx------ 2 root root 19220 2008-04-21 21:18 /usr/lib/cups/backend/lpd
> till@till-laptop:~$
>
> Important is that only the owner is allowed to execute it and that the
> owner is root. Then CUPS knows that the backend must be run as root
> (otherwise it runs the backends as the special user "lp"). The lpd
> backend has to be run as root, as otherwise it cannot communicate
> through the reserved LPD port 515.
>
> Make also sure that there is no firewall blocking port 515 on your
> system.
>
>
Till,

damon@dam-main:~$ ls -l /usr/lib/cups/backend/lpd
-rwx------ 2 root root 20432 2008-04-23 05:14 /usr/lib/cups/backend/lpd

Just so you know. I am 90% certain this is a kernel bug. I see this in
ubuntu >2.6.22 amd64 and I see it in debian >2.6.22 amd64. I filed a
bug report with the kernel devs of debian:

Bug#478062: Info received (Bug#478062: (Kernel >2.6.22.3-amd64 will
not print to cups network printer))

If you have access to that, you can read what I have done. No solution
as of yet. I compiled source from 2.6.22 up to 2.6.24-1 and all kernels
work until you get to 2.6.24 (all amd64). Same system used for all
tests, same packages, just different kernels booted.

HTH!

--
Damon L. Chesser
<email address hidden>
http://www.linkedin.com/in/dchesser

[EricDHH (ericdhh)]

Hello

some further informations from my system.

root@ingerimm:~# ls -l /usr/lib/cups/backend/lpd
-rwx------ 2 root root 20432 2008-04-21 22:22 /usr/lib/cups/backend/lpd

And you're right the printing works in really slow motion, the epson d88 get a line every 30 minutes. Maybe a page can be possible when waiting some days for the result. The 7.10 on my laptop prints well so i can transfer the documents to it for printing.

ByeBye
Eric

[EricDHH (ericdhh)]

Finally tested with socket (raw) and ipp backend, both run in the same situation. It seems th bug affects all kind of network printing solutions from cups. Transfers a few bytes in hours to the printers, no special errors seen.

This line appears after testpage in syslog, messages and kern.log.

Apr 29 15:25:17 ingerimm kernel: [ 5709.623969] audit(1209475517.229:13): type=1502 operation="inode_permission" requested_mask="::rw" denied_mask="::rw" name="/dev/tty" pid=13719 profile="/usr/sbin/cupsd" namespace="default"

I think the importance of this bug must be higher, cause all typos of network printing are affected.

Bye
Eric

[EricDHH (ericdhh)]

Hello

i think damon is right, some kernel bogus cause most of the problem. Owners with jetdirect will run in trouble too:-(

8.04 bootet with 2.6.22-14 (from gutsy)
lpd broken
jetdirect working
ipp working

8.04 bootet with 2.6.24-14 (original)
lpd broken
jetdirect broken
ipp broken

ByeBye
Eric

[Keith (zumrs)]

Hi,

Same problem here. I have a Hawking HPS3P with an HP Laserjet 4L attached. Worked great for 3 years, first on Suse, Ubuntu 7.04, then 7.10, using lpd://192.168.0.100/lpt2. Upgraded to 8.04 from 7.10, (Through Update Mgr) on this machine and now lpd is broken. The Ready and Data lights light up on the printer, but the printer does nothing. If I push the panel button a page will print, but only a thin garbled line. From then on, about every 5 to 10 min. the data light comes back on and nothing happens until I press the printer panel button, and then another thin garbled line prints. This goes on forever.

I ran the 8.04 live disk and had the same problem. I ran the 7.10 live disk and could print to it no problem. I fired up a spare with 7.10 on it and can print to it no problem. I finally connected the printer directly to the parallel port on this 8.04 machine and can print just fine.

Would sure like to get this fixed! I share that printer with 5 machines, and like the fact that no other server computer has to be on in order to print to the 4L. I am still a noob when it comes to error log files and such, mostly because I haven't had any problems with Ubuntu! So if you would like some output file or another, please give me detailed instructions. I did run the "ls -l /usr/lib/cups/backend/lpd" and it had the correct results.

Thanks!

[EricDHH (ericdhh)]

Hello Keith

just a possible solution is to run 2.6.22 from ubuntu 7.10 further, but there are some problems with closed drivers like nvidia. Then 8.04 will print like all other distros before. This printing bug is really a mess cause all alternatives lpd, ipp and socket:9100 are totally broken at same time.

I suggest to not install or upgrade to 8.04 if there are any kind of network printing required! Searching the web shows article from gentoo to mandrake of this ugly bug. The importance should be high cause all network printing are broken. I found no hints in the logs to get more information, the data seems to be blocked or mangled silently.

Bye
Eric

[Till Kamppeter (till-kamppeter)]

Moved to kernel, as it is definitely a problem of the kernel. Confirmed due to duplicates.

[Keith (zumrs)]

Hi Eric

Thanks for the idea. I have already moved the printer to this machine, and am sharing it from here. That will work OK for now until there is a fix. This machines up-time is way longer than the others, so that will work for now. Not quite the central location as before, but hey, I don't think it will kill anyone to walk a few steps further to retrieve their copy! Besides a couple have regular inkjets they use, and are shared as well. No worries.

Thanks

Keith

[Steve Langasek (vorlon)]

Till, it is exceedingly unlikely that this is a kernel bug; no one is reporting this class of breakage with other applications. I myself am using IPP without incident on 8.04. Is there some hard evidence, such as a network trace, that supports this assertion that there's a kernel problem?

[Till Kamppeter (till-kamppeter)]

Steve, my assumption that this is a kernel bug is that the problem gets solved by downdating the kernel to an older version.

[Steve Langasek (vorlon)]

This appears to be the same as Debian bug #478062, which mentions a workaround in the form of disabling the TCP F-RTO congestion algorithm via sysctl.

Yes, this may be a kernel bug; or it may be a CUPS bug, or a bug in whatever print server is being written to. More information is still needed here to ensure the problem is fixed appropriately.

[DaveM (davem)]

From: "Ilpo_Järvinen" <email address hidden>
Date: Thu, 8 May 2008 01:26:59 +0300 (EEST)

> [PATCH] [TCP] FRTO: SACK variant is errorneously used with NewReno

I applied this with a minor coding style fixup.

From: "Ilpo_Järvinen" <email address hidden>
Date: Thu, 8 May 2008 01:26:59 +0300 (EEST)

> +static int tcp_is_sackfrto(const struct tcp_sock *tp) {
> + return (sysctl_tcp_frto == 0x2) && !tcp_is_reno(tp);
> +}
> +

Should be:

static int tcp_is_sackfrto(const struct tcp_sock *tp)
{
 return (sysctl_tcp_frto == 0x2) && !tcp_is_reno(tp);
}

I will also queue this up to -stable, thanks so much for
this bug fix!

[Steve Langasek (vorlon)]

the kernel developers have taken responsibility for this as a kernel bug, marking as invalid for cupsys.

[arbulus (arbulus)]

I don't know if it's related, but I've had massive problems printing across my network to an Ubuntu machine running as a print server. I had used it for a year or so running Edgy, then Feisty, then upgraded to Gutsy, and printing basically stopped. I could print from the server itself, but my machines across the network were not able to access the printers. I upgraded to Hardy thinking that there may be a fix, but it was no different. So I went back to Gutsy (no change) and when back to Feisty (still no change). Network printing would work just fine at first until I rebooted the server, and it would all stop.

Here's a link to my thread in the ubuntu forums discussing the issue. It's complete with CUPS error logs.

http://ubuntuforums.org/showthread.php?t=781958

[EricDHH (ericdhh)]

Hello

arbulus <email address hidden> wrote:

Have you tried the workaraound that we found for my described problem?

# /etc/sysctl.conf - Configuration file for setting system variables
# See sysctl.conf (5) for information.
#
# Get printing over lan
net.ipv4.tcp_frto = 0

Are older images like feisty backported to the not working frto? Hardy
comes with 2, older kernels worked with 0.

In my case all network printing are totally slowed down, till this
little frto setting switch everything back to old behaviour.

Bye Eric
--

[Jerzy Luszawski (dr-agon)]

I had the same problem since installation of Hardy - could not print to remote printer, while connecting it locally was OK. I use kernel 2.6.24-16-generic on AMD64. The workaround described above by Eric Wick solved the problem for me. Thanks a lot!

[Mack (ldm1979)]

I am having the same problems with a Hawking HPS1U print server with my Samsung ML-1430. My 7.10 machines print without problem but my two 8.04 computers fail to print (although they printed perfectly before upgrade). I see Mr. Wick's work around however I am unable understand how to apply this (due to my own ignorance). I am just an end user with a problem not a developer. When attempting to edit sysctl.conf I am told I do not have permission. Can you step down your workaround for an end user. I am sorry if this is an inappropriate question for this forum but I am desperate.

Thank You

[Jerzy Luszawski (dr-agon)]

Mack:
You have to get the root privileges to edit /etc/sysctl.conf. To learn about acting as root see for example:
   https://help.ubuntu.com/8.04/administrative/C/
   https://help.ubuntu.com/community/RootSudo

I suppose you use graphical interface, so open a terminal and at the command prompt enter

   sudo gedit /etc/sysctl.conf

Insert the new line as Eric proposed:

   net.ipv4.tcp_frto = 0

save the file and close the editor. To make the system recognize the change enter the command

   sudo /sbin/sysctl -p /etc/sysctl.conf

or reboot your machine.
Good luck

PS. Consider making your e-mail available in your profile, to avoid posting information just for you to the entire forum.

[Mack (ldm1979)]

Thank You to Eric Wick and Dr_agon for your gracious help. Mr. Wick's workaround worked like a charm.

[grungy_me (grungyme)]

Same problem here. Unable to print my HP LaserJet 1100, which is connected to a Zonet ZPS3603 wired print server with static IP address. Initially after updating to the 2.6.24-19-generic kernel, I was able to print. As of this morning I could not print. Tried the workaround posted above by Eric Wick. And now I can print again.

[adonet (jeroen-adolfse)]

Same problem here, I could print one page with the 2.6.24-19 kernel. After that it didn't work anymore. The workaround doen't work for me.

Jeroen

[Andy Coulson (andy17mb)]

Ditto,

I can print one page following a reboot. My printers are configured as IPP. I have also tried the patch and it has made no difference. All the details of my configuration, outputs from printingbuginfo etc have been posted to bug no. 237759 if that helps

Andy

[jgordon510 (jeffreygordonchachacha)]

Had the same problem using LDP with a hawking print server. Used Eric Wick's workaround and printing works flawlessly.

[adonet (jeroen-adolfse)]

Why doesn't this workaround work for my printer. I use socket://192.168.2.10:9100 with a HP Laserjet 4000 on a Sitecom printerserver. this works allright wit older kernels as it does when booting from windows. The system keeps asking if the printer is connected or not and nothing is printed Allthoug the printes tells me on its display that it is receiving some data.

Jeroen

[mnott (spam-mnsoft)]

Same here on 8.04 with some random printserver. Caused all sorts of headaches and made it work on 9100 w/ this setting.

[Andy Coulson (andy17mb)]

I think I have solved my problem - on my system the printserver printing issue appears to be down to permissions on config files stored on /home.

I have /home on a separate partition from my system and when I upgraded i simply reformatted the system partition and reinstalled. When you do this you create a new user, which might be the same username and password as you used on the old install, but as far as the system is concerned is different. Consequently your new login can not access the .XXXXXX configuration files on /home.

Thanks to nelz at linuxformat.co.uk for spotting this. The solution is to run in the terminal:
    sudo chown -R username: ~username

Where username is the username you login with after a restart. You should reboot after doing this.

I can now print multiple docs to both printers on my Edimax printserver, provided I go into the print queue and cancel the document when it has come off the printer. So I am Now back to where I was with Gutsy

Hope this helps

Andy

[adonet (jeroen-adolfse)]

Hi Andy

thanks for your message. But again, I'm afraid I did the same as you did. Made an installation with a new system partition, but with the same /home partition and the same username. I did sudo chown -R jeroen: ~jeroen It gave an error message saying that it couldn't find a certain directory that doesn't excist.
I reboot.
But trying to print still gives the same error messages,

Jeroen

[adonet (jeroen-adolfse)]

Hi Andy

I rebooted in Gutsy and Gutsy couldn't print anymore. I repeated your command in gutsy. No error message this time. I rebooted and now I can print in Gutsy again. And I can print in Hardy too now. I but only after the third time I rebooted. I still don't understand what happens, but I can print again.
Thanks

Jeroen

[phil (wrigsster-deactivatedaccount)]

Not sure if this is a help or not BUT... I have a Samsung ML-2010 Mono Laser which I print to through a Netcomm NP3680 USB 2.0 Multifunction Server and it works beautifully. The strange part is though that it won't work if I utilise the driver supplied on the CD by Samsung (ML-2010spl2.ppd) but it works perfectly if I use the systems recommended driver (Samsung ML-2010, 1.1.0)

I set my printers (I use the Samsung Laser plus an Epson CX9300F MFC) up as jetdirect with the settings as follows:

10.1.1.2:9100 for my Samsung which is on Socket One of Server, and;
10.1.1.2:9101 for my Epson

I have set them up similarly in openSUSE and PCLinuxOS and don't usually have many issues at all.

I am currently using Ubuntu 8.04 (Hardy) and used same setup when I was running 7.10 (Gutsy).

Regards... Phil

[Leann Ogasawara (leannogasawara)]

Hi everyone,

I'm just adding the two upstream git commit id's for the kernel team to reference that seem to have resolved the debian bug - http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=478062 . Also, it appears these patches are already in the Intrepid kernel. If anyone would like the test the latest Alpha for the upcoming Intrepid Ibex 8.10 release you can find more information here - http://www.ubuntu.com/testing . Thanks.

commit 62ab22278308a40bcb7f4079e9719ab8b7fe11b5
Author: Ilpo Järvinen <email address hidden>
Date: Thu May 8 01:09:11 2008 -0700

    tcp FRTO: SACK variant is errorneously used with NewReno

commit a1c1f281b84a751fdb5ff919da3b09df7297619f
Author: Ilpo Järvinen <email address hidden>
Date: Tue May 13 02:53:26 2008 -0700

    tcp FRTO: Fix fallback to conventional recovery

[Stefan Bader (smb)]

For Hardy there is currently a test kernel (smb3) building in my PPA at
https://launchpad.net/~stefan-bader-canonical/+archive
(since that is based on the latest kernel in -proposed this might require to enable -proposed in the installation sources as well)

If you could try this and provide feedback that would be great.

[Brian Burch (brian-pingtoo)]

Stefan Bader wrote:
> For Hardy there is currently a test kernel (smb3) building in my PPA at
> https://launchpad.net/~stefan-bader-canonical/+archive
> (since that is based on the latest kernel in -proposed this might require to enable -proposed in the installation sources as well)
>
> If you could try this and provide feedback that would be great.
>

Hi, Stefan.

I have downloaded the Intrepid alpha 4 iso and was intending to install
it on a test partition this weekend, but an alternate kernel for Hardy
would be much simpler for me.

I went to your url, but wasn't sure what to do next. If I put your
personal package archive onto my apt sources.list, am I going to see all
143 packages available for update? I could test the new kernel quite
quickly, but I don't have a "spare" Hardy system to wreck, so I'll need
to install it as an alternate kernel on a production system.

Please reply soon... I won't do anything until you advise me.

Regards,

Brian

[Stefan Bader (smb)]

Hi Brian,

no you should not see more than two, all the other binary packages mentionen on that page are just udeb packages (which I personally have never used, they are just automatically created). You will just see a new kernel (and maybe the kerneloops package).
There is an alternate way if you feel more comfortable with that. You can follow the link below and download the kernel image directly. One thing, as you said you use a production system. You need to enable the hardy-proposed option in the sources so you get the matching linux-ubuntu-modules (and maybe linux-restricted-modules and linux-backports-modules, depending on your setup) because this is a kernel with a different ABI version -21 (instead of the current -19).

http://ppa.launchpad.net/stefan-bader-canonical/ubuntu/pool/main/l/linux/

[Brian Burch (brian-pingtoo)]

Stefan Bader wrote:
> no you should not see more than two, all the other binary packages mentionen on that page are just udeb packages (which I personally have never used, they are just automatically created). You will just see a new kernel (and maybe the kerneloops package).

 > One thing, as you said you use a production system. You need to
enable the hardy-proposed option in the sources so you get the matching
linux-ubuntu-modules (and maybe linux-restricted-modules and
linux-backports-modules, depending on your setup) because this is a
kernel with a different ABI version -21 (instead of the current -19).

I added your ppa to my sources.list, and also added hardy-proposed to
collect any pre-requisites.

I can see your package kernel-image-2.6.24-21-generic-di (version
2.6.24.21.40smb) is available for upgrade, but am surprised at several
things...

1. It has NO dependencies.

2. The description says "This package contains the Linux kernel image
for the Debian installer boot images. It does _not_ provide a usable
kernel for your full Debian system"

3. package linux-image-generic shows a latest version of 2.6.24.21.23
(hardy-proposed) - not your one.

I am nervous about marking all available upgrades, because I am will
pick up a 23 changes that are not yet released for production use.

Which packages should I install to prepare my system to use your
kernel-image?

Can I just install your image package, or will I need to run initramfs
manually?

> There is an alternate way if you feel more comfortable with that. You can follow the link below and download the kernel image directly.
> http://ppa.launchpad.net/stefan-bader-canonical/ubuntu/pool/main/l/linux/

I went there, but it has a load of stuff available... nothing there
seemed to answer my questions above. I would prefer to use the tools I
am familiar with - synaptic or update-manager.

Sorry to ask for so much help and advice, but you are taking me into new
territory. I'm an expert with network protocols, not linux kernels or
debian package management. If you had to wait for me to research all
this "new" stuff, you'd wait for ever before I could run a simple trace
and confirm the tcp/ip protocol fix!

Once I have your kernel booted, I only need about 10 minutes to do my
stuff. But then I need to restore my system to its production state and
get back to (paid) work. I'll continue using the net.ipv4.tcp_frto
bypass until an official fix becomes available.

Regards,

Brian

[Stefan Bader (smb)]

I wonder how you get to those -di versions. Unfortunately I can only say what I can see here (with update-manager) and my system also had -proposed active before. So maybe try two steps:

1. Remove manually the line to the PPA and select "check" in update-manager to reread the packages.
2. Now, since you have proposed enabled you should get offered a lot of packages.
3. Only select those with the linux- prefix (leave out the linux-libc-dev)

You should only see something like linux-image-2.6.24-21-generic, nothing with -di or the likes. You need at least a matching linux-ubuntu-modules and possibly a linux-restricted-modules and linux-backports-modules (depending on you installation). Since this is a new ABI version this installs a new kernel in parallel to your current one. So you can still select the old -19 kernel from the boot menu.

If that has finished and you can do this without rebooting,

4. Add "deb http://ppa.launchpad.net/stefan-bader-canonical/ubuntu hardy main" to the installation sources again.
5. Press "check" in update-manager and it should only show you (beside of the other packages) a linux-image, the linux-libc-dev and possible linux-headers. You only need the linux-image.

If done, you can remove the PPA line and also uncheck the proposed checkbox so you won't get offered the other packages over and over again.

[Brian Burch (brian-pingtoo)]

Leann Ogasawara wrote:
> I'm just adding the two upstream git commit id's for the kernel team to
> reference that seem to have resolved the debian bug -
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=478062 . Also, it
> appears these patches are already in the Intrepid kernel. If anyone
> would like the test the latest Alpha for the upcoming Intrepid Ibex 8.10
> release you can find more information here -
> http://www.ubuntu.com/testing . Thanks.
>
> commit 62ab22278308a40bcb7f4079e9719ab8b7fe11b5
> Author: Ilpo Järvinen <email address hidden>
> Date: Thu May 8 01:09:11 2008 -0700
>
> tcp FRTO: SACK variant is errorneously used with NewReno
>
> commit a1c1f281b84a751fdb5ff919da3b09df7297619f
> Author: Ilpo Järvinen <email address hidden>
> Date: Tue May 13 02:53:26 2008 -0700
>
> tcp FRTO: Fix fallback to conventional recovery
>
>
> ** Changed in: linux (Ubuntu Hardy)
> Status: Confirmed => Triaged

You will all be pleased to know that I had a lot of problems installing
the Intrepid alpha 4 (e.g. bug 260001), but I finally succeeded.

My Intrepid system has successfully printed several large files, so I am
satisfied that my specific problem has been fixed.

However, until I have taken and analysed several wireshark traces, I
will not be able to confirm the bug is completely fixed. I intend to do
that work soon, using the patched Hardy kernel that Stefan has prepared.

[Brian Burch (brian-pingtoo)]

Stefan Bader wrote:
> I wonder how you get to those -di versions. Unfortunately I can only say
> what I can see here (with update-manager) and my system also had
> -proposed active before. So maybe try two steps:
<snip/>

Thanks very much for the instructions, Stefan. I followed them carefully
and THINK I've installed your new kernel. dmesg shows this line..

Linux version 2.6.24-21-generic (buildd@iridium) (gcc version 4.2.3
(Ubuntu 4.2.3-2ubuntu7)) #1 SMP Tue Aug 19 22:34:58 UTC 2008 (Ubuntu
2.6.24-21.40smb3-generic)

I removed my over-ride for net.ipv4.tcp_frto and after booting your
kernel, it had acquired the default value of 2.

Sadly, my job did not print - it appeared to hang for ever and certainly
was still going after 10 minutes. I then cancelled the job, changed frto
to zero, power-cycled the printer, resubmitted the job and it printed
successfully within a few seconds.

So who made a mistake? The alpha 4 Intrepid kernel prints OK, but this
Hardy system does not.

Did I do the install wrong, or did you send me a kernel that did not
have the complete fix?

I've captured sniffer traces of the successful and hung TCP sessions.
Your kernel seems to be behaving slightly differently to the current
production Hardy version.

Under 2.6.24-19, the printer is completely hung because the protocol is
so garbled - the retransmissions and duplicate acks eventually get
"stuck" so the session never makes any progress beyond a certain point.

However, under your modified 2.6.24-21, it looks to me (provisionally)
as if data is still managing to be transferred even though the protocol
is seriously broken. When I cancelled the job it had managed to transfer
and acknowledge 1500 bytes in the previous 4 minutes. Perhaps if I had
waited a couple of hours, the job might have completed!?

I await your thoughts with interest.

Brian

[Stefan Bader (smb)]

Brian,

this is bad new, sorry. The problem here is, that as much as you are unfamiliar with kernels and packaging, I am not very much into the depths of protocols. But maybe we can help each other out here.
I am quite confident that I got the patches that were mentioned as fixes to this got into the PPA kernel. The changelog you see when expanding the entry of the kernel on the PPA page get generated automatically as I prepare the kernels. Beside of other fixes there are three that are concerned with F-RTO. One I added because one of the other two depended on it and the description sounded like an isolated fix as well.
Since you can print with the Intrepid kernel, there will be not much sense in opening an bugzilla bug. The usual answer is, use the latest kernel. Unfortunately, if I only compare roughly how many changes there where on the very same file between Hardy and Intrepid this is 46 and over 600 in the ipv4 directories (ok, this include netfilter). So it sounds like a search for the needle in the haystack.
The question is, is there any hint you can read from your logs about what might be going wrong (missing packets or too many or whatever) which might get mapped to a certain description in the kernel changelogs?

[Brian Burch (brian-pingtoo)]

Stefan Bader wrote:
> this is bad new, sorry. The problem here is, that as much as you are unfamiliar with kernels and packaging,

Don't worry, I think it is quite good news - although (of course) it
could have been better!

You seem to be convinced that I am running your new kernel, so at least
I understand how to get one made by you into my system without breaking it.

> I am not very much into the depths of protocols. But maybe we can help each other out here.

I am certainly prepared to help as much as possible. This bug is
inconvenient for me, but I have a work-round. It is a nasty bug that
crept in with the Gutsy kernel, but luckily I skipped releases and went
straight from dapper and feisty to Hardy.

I suspect there are a lot of people out there who are already suffering
with hung network printers, or will be when they upgrade to the Hardy
release. Because it is LTS, someone HAS to fix it soon.

> I am quite confident that I got the patches that were mentioned as fixes to this got into the PPA kernel.
> The changelog you see when expanding the entry of the kernel on the PPA page get generated automatically
> as I prepare the kernels.

Thanks for the tip... I found the changelog installed by your package
and can see you used three fixes all labelled "LP: #213081". I'm
convinced (at last) that I have installed your kernel properly. (It is
easy to think you've done something right when you haven't.)

> Beside of other fixes there are three that are concerned with F-RTO. One I added because one of the other two
> depended on it and the description sounded like an isolated fix as well.
> Since you can print with the Intrepid kernel, there will be not much sense in opening an bugzilla bug.

Don't be too hasty. I need to go back to my intrepid system and run some
network traces. I wasn't happy with the speed of printing, even though
it "worked". I think I need to be certain that the fix developed by
Ilpo Järvinen is 100% correct before we put too much energy into Hardy.

> The usual answer is, use the latest kernel.

I can follow that argument for feisty and gutsy, but it doesn't sound
right for Hardy. I think the bug is too fundamental to let people
believe the release will be supported for the next 2 years when a lot of
devices with embedded low-tech tcp/ip stacks will never work.

> Unfortunately, if I only compare roughly how many changes there where on the
> very same file between Hardy and Intrepid this is 46 and over 600 in the ipv4
> directories (ok, this include netfilter). So it sounds like a search for the needle in the haystack.
> The question is, is there any hint you can read from your logs about what might be
> going wrong (missing packets or too many or whatever) which might get mapped to a certain description in the kernel changelogs?

Yes, I understand what is required. Leave it with me for now and I'll do
some traces on intrepid over the weekend. I will let you know what I've
found asap. Once I have a good grasp of the protocol issues, then it
will be time to start looking at the code. (After 15 years with C and
C++, I jumped ship to java as soon as it was released and never looked
back... occasionally...

[Brian Burch (brian-pingtoo)]

Brian Burch wrote:
> Yes, I understand what is required. Leave it with me for now and I'll do
> some traces on intrepid over the weekend. I will let you know what I've
> found asap. Once I have a good grasp of the protocol issues, then it
> will be time to start looking at the code. (After 15 years with C and
> C++, I jumped ship to java as soon as it was released and never looked
> back... occasionally that experience comes in useful).

I ran a trace of a 220K print file using the Intrepid alpha 4 kernel,
2.6.26-5.17-generic. It took a long time - cups said it was 220K, but
actually transmitted twice that much. It also transmitted datagrams with
only 512 bytes, but I feel these are cups issues, not kernel tcp/ip.

The tcp session appears to be satisfactory. There were some timeouts,
retransmissions, duplicate acks, window closures, etc. All these
"normally abnormal events" were handled in a reasonable manner.

I conclude that the intrepid kernel with Ilpo's fix is correct:- when
sending significant data to remote devices that have primitive tcp/ip
stacks.

I will research the fixes in intrepid to see which ones we should
back-port, but this might take me some time...

Regards,

Brian

[Leann Ogasawara (leannogasawara)]

The Ubuntu Kernel Team is planning to move to the 2.6.27 kernel for the upcoming Intrepid Ibex 8.10 release. As a result, the kernel team would appreciate it if you could please test this newer 2.6.27 Ubuntu kernel. There are one of two ways you should be able to test:

1) If you are comfortable installing packages on your own, the linux-image-2.6.27-* package is currently available for you to install and test.

--or--

2) The upcoming Alpha5 for Intrepid Ibex 8.10 will contain this newer 2.6.27 Ubuntu kernel. Alpha5 is set to be released Thursday Sept 4. Please watch http://www.ubuntu.com/testing for Alpha5 to be announced. You should then be able to test via a LiveCD.

Please let us know immediately if this newer 2.6.27 kernel resolves the bug reported here or if the issue remains. More importantly, please open a new bug report for each new bug/regression introduced by the 2.6.27 kernel and tag the bug report with 'linux-2.6.27'. Also, please specifically note if the issue does or does not appear in the 2.6.26 kernel. Thanks again, we really appreicate your help and feedback.

[Patrick Schueller (pschuel)]

I have tested it here by installing kernel 2.6.27-1-generic on Hardy (downloaded from http://kernel.ubuntu.com/pub/next/2.6.27-rc3/hardy/), then removed the workaround patch (net.ipv4.tcp_frto = 0) from sysctl.conf and rebooted with the new kernel. It seems that the bug is gone with this kernel since IP printing now works normally without the patch.

Thanks for fixing it :-)

Patrick

[Brian Burch (brian-pingtoo)]

Leann Ogasawara wrote:
> The Ubuntu Kernel Team is planning to move to the 2.6.27 kernel for the
> upcoming Intrepid Ibex 8.10 release. As a result, the kernel team would
> appreciate it if you could please test this newer 2.6.27 Ubuntu kernel.
> There are one of two ways you should be able to test:

I booted the intrepid system and update manager offered me an upgrade
that included the new kernel.

dmesg shows :- Linux version 2.6.27-1-generic (build@palmer) / Ubuntu
2.6.27.1

net.ipv4.tcp_frto is 2 (full logic enabled)

My test print job was successful.
I analysed a sniffer trace and the protocol is acceptable.

As far as I am concerned, the TCP fix in the latest kernel is correct.

Thanks for your help, Leann.

Brian

[Leann Ogasawara (leannogasawara)]

Thanks for testing and the feedback. I'm glad to hear this appears to be resolved at least with the 2.6.27 kernel. I'm tentatively marking this "Fix Released" against Intrepid. Obviously, if you see any regressions prior to Intrepid's final release, please change the status from "Fix Released" back to "New".

Now regarding the backports for Hardy. Brian, will you still be willing to help and test? Possibly run a git-bisect to narrow down the specific patches we'd need to backport? I can try to give you some pointers to docs to help with this. Let us know. Thanks.

[Brian Burch (brian-pingtoo)]

Leann Ogasawara wrote:
> Now regarding the backports for Hardy. Brian, will you still be willing
> to help and test? Possibly run a git-bisect to narrow down the specific
> patches we'd need to backport? I can try to give you some pointers to
> docs to help with this. Let us know. Thanks.

I was surprised to hear from you again, Leann, because I assumed your
main concern was Intrepid. I've done some work on Hardy over the
weekend, but was losing heart because I didn't have the right experience
to make rapid progress. I intended to contact Stefan Bader this morning
to ask for his help, but let me make this a general request instead.

I use CVS and SVN a lot in my development projects, but I don't really
want to clutter my (paid) work with temporary kernel projects. What I
need most is a diff between all the tcp/ip files that go into the
kernel, using the latest Hardy kernel and the earliest alpha 4 Intrepid
kernel. Using the changes list (or the repository history) for the
intrepid kernel, I can start by reviewing Ilpo's fixes.

Perhaps you can suggest a quicker approach? Once I can lay the C source
out side-by-side, I expect to identify the relevant fixes. We then have
to map "the time tree" of all fixes to figure out the pre- and
co-requisites... we won't know if it is practical until we try. I am
reassured by the comment Ilpo made when he latched onto this bug - he
said he hadn't touched the code for a year or so.

If you want to take the rest of this investigation off the bugs list, we
can email directly or switch to a developers list. Let me know what you
think is most efficient.

Regards,

Brian

[Leann Ogasawara (leannogasawara)]

Hi Brian,

The best approach to isolating patches which resolved the issue for Intrepid would be to do a git bisect. This is obviously not something we expect you to know how to do so this is completely at your own discretion if you'd like to try. The following link describes how to perform a git bisect:

http://www.kernel.org/doc/local/git-quick.html#bisect

The only tricky issue is you're going to have to reverse the meanings of good and bad since you're trying to isolate a patch which fixed the issue, and not caused a regression. You can get the Intrepid git tree by doing:

git clone git://kernel.ubuntu.com/ubuntu/ubuntu-intrepid.git ubuntu-intrepid

In the process of performing the git bisect, you will also need to perform some kernel builds of your own. Again, not something we expect you to know how to do, but if you're willing to try that's great. Information regarding how to build the Ubuntu kernel can be found at https://help.ubuntu.com/community/Kernel/Compile .

I realize this can be quite a bit of information to digest and could be overwhelming. It's completely at your own comfort level if you'd like to give all this a try. We definitely already appreciate all the help you've given by testing. Thanks.

[Rainer Sabelka (sabelka)]

Just look at the the corresponding Debian bug. I think Ilpo Järvinen posted a fix there.

[adonet (jeroen-adolfse)]

Any chance that this patch will be included in any Hardy kernel update?

[Stefan Bader (smb)]

To clearify: I had a test kernel prepared for Brian which contained those fixes by Ilpo. However this did not solve his printing problem. So there is still the question which parts might be missing. Maybe there are several things getting together. So currently we either miss something or there are several issues.
You could try the test kernel in my PPA https://launchpad.net/~stefan-bader-canonical/+archive which contains the patches from Ilpo and tell me whether there is an improvement for you.

[Brian Burch (brian-pingtoo)]

Stefan Bader wrote:
> To clearify: I had a test kernel prepared for Brian which contained those fixes by Ilpo. However this did not solve his printing problem. So there is still the question which parts might be missing. Maybe there are several things getting together. So currently we either miss something or there are several issues.
> You could try the test kernel in my PPA https://launchpad.net/~stefan-bader-canonical/+archive which contains the patches from Ilpo and tell me whether there is an improvement for you.

Hi, Stefan. Thanks for your efforts. I meant to do some more work over
the weekend, but had to deal with an urgent problem instead. Luckily you
built a new kernel during my period of silence.

I installed your new linux-image (smb2), booted it and set
net.ipv4.tcp_frto=2. I am sorry to report that the print job hung, so
your new set of fixes are not sufficient to back-port the bug fix from
intrepid.

Unfortunately, the kernel booted in low-res graphics mode (only option)
and so I couldn't get wireshark to capture the tcp session (panels would
not resize or move to let me click the save button!). This means I
cannot say whether the low-level symptoms have changed... but I am sure
the printer hangs!

Regards,

Brian

[adonet (jeroen-adolfse)]

I installed Intrepid Alpha 4 and had the same resolution problem after acticvating the NVIDIA driver and couldn't get it back to work again even after some finetuning of that installation.
But network printing just works fine with intrepid.

For now I keep on using Hardy with the
net.ipv4.tcp_frto=0 solution in sysctl.conf but printing still isn't withhout problems.
Small documents come out of the printer, large documents very often don't. I print klarge documents one page at a time and thats working for me for the moment.

In 6 weeks Intrepid will be released....And then I 'll give that a try.

[Stefan Bader (smb)]

@Brian,

I have to apologize. There hasn't been any change in that kernel regarding this bug. That one added fixes for some other bug, while keeping the same patches as before for the cups problem. So this would have been rather a surprise if it changed anything for you.

[Brian Burch (brian-pingtoo)]

Leann Ogasawara wrote:
> The best approach to isolating patches which resolved the issue for
> Intrepid would be to do a git bisect. This is obviously not something
> we expect you to know how to do so this is completely at your own
> discretion if you'd like to try. The following link describes how to
> perform a git bisect:
>
> http://www.kernel.org/doc/local/git-quick.html#bisect

I've read the whole document, but do not understand it very well yet.

> The only tricky issue is you're going to have to reverse the meanings of
> good and bad since you're trying to isolate a patch which fixed the
> issue, and not caused a regression. You can get the Intrepid git tree
> by doing:
>
> git clone git://kernel.ubuntu.com/ubuntu/ubuntu-intrepid.git ubuntu-
> intrepid

Yes, I ran that command successfully. However, I am not sure how to run
the git bisect...

I now have a directory called "ubuntu-intrepid" with a lot of
subdirectories under it.

I can see that if I run "git bisect bad", this will establish the
current version of intrepid (aka master) as faulty (but in my case good).

I don't know what to use as the "good" version. Does my intrepid git
hold enough history to go back to the hardy kernel? I tried
"git bisect good release_2_6_24", but got the error message "bad rev
input" and wasn't very surprised.

I can see from the makefile that the current (intrepid) version is
2_6_27, but scratching around the directory hasn't shown me what to use
as the correct name for hardy - should I have also done a clone of
ubuntu-hardy-git into a different directory and then done a bisect
between these two? Even if yes, I still need to know what name to use
for the current Hardy kernel version.

Sorry to have to ask for help, but I need to get past the crud I don't
understand quickly so that I can devote my attention to the real problem!

Thanks in anticipation...

Brian

[Launchpad Janitor (janitor)]

Per a decision made by the Ubuntu Kernel Team, bugs will longer be assigned to the ubuntu-kernel-team in Launchpad as part of the bug triage process. The ubuntu-kernel-team is being unassigned from this bug report. Refer to https://wiki.ubuntu.com/KernelTeamBugPolicies for more information. Thanks.

[Menno (m-tjoelker)]

My problem is probably the same:

- Large files are not printed ('small' files are) on network attached printer; CUPS reports broken pipe and puts job on 'held' status

Software versions:

- Ubuntu 8.10
- Cups 1.3.9-2ubuntu9.1

Printer:

- Xerox Phaser 6130

The attached Wireshark trace shows clearly what is going wrong. This is what happens:

- Cups opens a session to the printer on tcp/9100.
- Cups starts processing ... processing ... processing ...
- After 15 seconds, the printer ends the session due to timeout (FIN sent); this is orderly acknowledged by the computer.
- Meanwhile, Cups is still continuing to process the job.
- Finally, processing is ready.
- Now, Cups starts transmitting the print data - as if the session were still there. Naturally, this fails, with the reported result.
- After some time, Cups repeats the process, with (of course) the same result. (If it only would have saved the output of its efforts...)

(I've left out some other strange actions: trying to reach the printer on a completely different port (via udp), trying to access the printer via snmp.)

Cups should begin a session with the printer when it is ready to send the data, not as the first action before starting to process the data!

Bypasses:

- My printer (Xerox 6130) allows setting the session timeout up to 1000 seconds, i.e., about 18 minutes; this will mostly be sufficient to avoid the problem.
- Print to Postscript file and send this manually to the printer, without interference of Cups. Of course, this is not a solution for end users and only sensible if the problem doesn't occur too often.

- Menno

[Stefan Bader (smb)]

Thanks you for your report. However I think you should create a new one against
cups. The bug here was about some TCP/IP issues that could not be solved with
an increased timeout.

That said, Brian, how are you feeling about this? As the exact reason could not
be pinpointed and probably is more than could be argued to backport into a
released version and IIRC you had it solved with Intrepid, should we close this
one?

[Brian Burch (brian-pingtoo)]

Stefan Bader wrote:
> Thanks you for your report. However I think you should create a new one against
> cups. The bug here was about some TCP/IP issues that could not be solved with
> an increased timeout.
>
> That said, Brian, how are you feeling about this? As the exact reason could not
> be pinpointed and probably is more than could be argued to backport into a
> released version and IIRC you had it solved with Intrepid, should we close this
> one?

Hi, Stefan. I thought you had lost interest in this bug because I
haven't heard anything for several months. I still have all my notes,
but couldn't get further without help.

Here is the current situation as far as I see it...

1. The latest Intrepid kernel really does have the TCP/IP fix that
resolves my original problem.

2. The latest Hardy kernel is probably still broken - I have followed
your kernel fixes (especially TCP/IP) and haven't spotted anything that
looked relevant. However, I haven't run a test to confirm my beliefs
because....

3. The bypass I reported with the bug definitely works with the latest
Hardy kernel, so my Hardy systems (I still have a couple) run fine with
my printer.

4. Menno's problem does not sound like mine - if a print job was big
enough to stall, then it would never complete. Even a reboot would leave
the job queued and printing would hang again. Besides, he is using the
latest Intrepid kernel, where the bug is fixed (point 1 above).

I think Menno should open a new bug report - perhaps stating that it is
definitely NOT a duplicate of 213081.

I'm not sure what to do about 213081. It is fixed in Intrepid, but it
was reported against Hardy which is an LTS release with another year or
so of life. I think the circumvention is fine - do you have a bug status
something like "bypass available"?

I agree with Leann's original thought that we shouldn't waste a lot of
time back-porting the Intrepid fix. I was prepared to research the code
differences, but I couldn't get the tools to work and Leann didn't reply
to my questions. If you think it is important enough to help me get
started, then I'll give it another try.

Regards,

Brian

[Stefan Bader (smb)]

Brian Burch wrote:

> Hi, Stefan. I thought you had lost interest in this bug because I
> haven't heard anything for several months. I still have all my notes,
> but couldn't get further without help.

Not as much lost interest as buried under a pile of various other stuff. This
is quite unsatisfactory for the both of us but sadly the truth.

> Here is the current situation as far as I see it...
>
> 1. The latest Intrepid kernel really does have the TCP/IP fix that
> resolves my original problem.
>
> 2. The latest Hardy kernel is probably still broken - I have followed
> your kernel fixes (especially TCP/IP) and haven't spotted anything that
> looked relevant. However, I haven't run a test to confirm my beliefs
> because....
>

That is as I remember the situation. We have tried a few changes backported
from the upstream bug, but still had the issue. It has been quite a while but
if I remember it correctly it was not only one patch but accumulated into a
bigger series.

> 3. The bypass I reported with the bug definitely works with the latest
> Hardy kernel, so my Hardy systems (I still have a couple) run fine with
> my printer.

Which is at least something. It is not the best of solutions but at least
allows you and likely affected to work.

> 4. Menno's problem does not sound like mine - if a print job was big
> enough to stall, then it would never complete. Even a reboot would leave
> the job queued and printing would hang again. Besides, he is using the
> latest Intrepid kernel, where the bug is fixed (point 1 above).

My guess too. He actually pinpointed it quite well to a problem in cups by
saying that the connection is opened but the time it takes to process the job
results in a timeout.

> I think Menno should open a new bug report - perhaps stating that it is
> definitely NOT a duplicate of 213081.

And against cups as the package.

> I'm not sure what to do about 213081. It is fixed in Intrepid, but it
> was reported against Hardy which is an LTS release with another year or
> so of life. I think the circumvention is fine - do you have a bug status
> something like "bypass available"?

The problem is
a) Will we ever have the time to get to the bottom of the problem. It seems to
    be somewhere in the depths of the protocol stack.
b) Even if we found it, how simple is the fix? If it is hard to grasp the side
    effects it will be not applicable for SRU as it is not possible to tell
    whether it will break other things in that case. (Been there for another bug
    and still suffer from it)

> I agree with Leann's original thought that we shouldn't waste a lot of
> time back-porting the Intrepid fix. I was prepared to research the code
> differences, but I couldn't get the tools to work and Leann didn't reply
> to my questions. If you think it is important enough to help me get
> started, then I'll give it another try.

The tool for it would be git. You can get a log of changes or a diff for even
subdirectories. The big problem is that, while all updates should usually fix
something, it might only be part of the solution. So we probably talk about a
series of patches where you have to have a good protoco...

[derek tibbetts (derek-tibbettsfamily)]

You sent me an e-mail on Wed 22nd April and I wasn't sure how to reply
to it because I had no problem with the printer for ages. It suddenly
seemed to right itself.

This morning the problem arose again and whatever I did I could not get
it to work. However, at one point I had a box saying the printer might
not be connected so I removed the printer cable from both printer and
computer. There was a piece of fluff on the printer end which I blew
away and I blew heavily on the computer end as well. I reconnected and
everything seemed to work perfectly. My problem may not have been the
software.

Regards,

Derek Tibbetts.

[derek tibbetts (derek-tibbettsfamily)]

You sent me an e-mail on Wed 22nd April and I wasn't sure how to reply
to it because I had no problem with the printer for ages. It suddenly
seemed to right itself.

This morning the problem arose again and whatever I did I could not get
it to work. However, at one point I had a box saying the printer might
not be connected so I removed the printer cable from both printer and
computer. There was a piece of fluff on the printer end which I blew
away and I blew heavily on the computer end as well. I reconnected and
everything seemed to work perfectly. My problem may not have been the
software.

Regards,

Derek Tibbetts.

On Wed, 2009-04-22 at 06:32 +0000, Stefan Bader wrote:
> Thanks you for your report. However I think you should create a new one against
> cups. The bug here was about some TCP/IP issues that could not be solved with
> an increased timeout.
>
> That said, Brian, how are you feeling about this? As the exact reason could not
> be pinpointed and probably is more than could be argued to backport into a
> released version and IIRC you had it solved with Intrepid, should we close this
> one?
>

[ethanay (ethan-y-us)]

this bug might exist in 9.10 w/latest updates?

i have several 9.10 computers trying to communicate to an HP 810C on the wireless network. The printer is attached to a NetGear WGPS606 print server via USB. All the computers and the print server are routed through a Netopia 2247WGX router. The wireless connection itself is solid.

However, when I try to print, it takes over a minute for the printer to become active (load a sheet of paper), and over 10 minutes for the spooling to reach even 10%. The printer starts and stops several times up to this point. I have yet to get a completed print job.

Previously, I was using another wireless print server (TRENDnet TEW-P1PG) that connected directly to the printer via parallel (vs USB) port. Ubuntu even detected the printer properly through the print server, requiring minimal setup on my part and the setup worked flawlessly.

Since switching to a USB-based print server connection, I have yet to successfully print a page. The printer works fine with a direct USB connection.

Something is getting lost in the translation...

[Wolf Halton (saphil)]

Getting the same symptoms on a Lucid distribution-upgrade. Worked in Karmic, fails in Lucid. Dell tower, HP LJ4000 network printer. Printing on my HP laptop just prints multiples, but I have fixed that issue before.
I am trying the fix mentioned above for cupsd.conf
net.ipv4.tcp_frto = 0
The fix works - the line was not in cupsd.conf

[ethanay (ethan-y-us)]

for the record, i can no longer add anything to this bug, as we have
moved from an HP810C w/print server to a Brother HL-2170W w/built-in
networking. The new printer has been working flawlessly (with the
Brother drivers).

The issue with the older printer was unresolved.

ethan

On Sun, May 2, 2010 at 7:40 AM, Wolf Halton <email address hidden> wrote:
> Getting the same symptoms on a Lucid distribution-upgrade.  Worked in Karmic, fails in Lucid.  Dell tower, HP LJ4000 network printer.  Printing on my HP laptop just prints multiples, but I have fixed that issue before.
> I am trying the fix mentioned above for cupsd.conf
> net.ipv4.tcp_frto = 0
> The fix works - the line was not in cupsd.conf
>
> --
> CUPS does not print to LPD printer
> https://bugs.launchpad.net/bugs/213081
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in “cupsys” package in Ubuntu: Invalid
> Status in “linux” package in Ubuntu: Fix Released
> Status in “cupsys” source package in Hardy: Invalid
> Status in “linux” source package in Hardy: In Progress
> Status in “linux” package in Debian: New
>
> Bug description:
> Binary package hint: cupsys
>
> not just a ubuntu issue.  Same issue seen in Debian Sid and now Debian stable.  The result of a receint security update?  Ubuntu 7.10 can print to lpd printer:  lpd://192.168.200.150/lpt1  Same address/syntax used for years.
>
> Upgraded to Hardy, Samsung ML-1430 printer comes to life, data light blinks, nothing comes out.  Printer stops making noice, data light continues to blink.  No print ever comes out.  Printer and print server (Hawkings Tech. print server, NIC-->LPT port) have to be re-set to allow other clients to print.
>
> Win boxes print just fine.  Ubuntu 7.10 if re-installed prints just fine.
>
> Debian Stable and Sid used to print, no more as of my last Debian test (yesterday).  Upstream change made?
>
> This looks as if the spool is very very very slow and the printer times out.  I don't know how to troubleshoot any more then this.  I am willing and able to do anything you suggest to pin this down.
>
> no errors in cups log (uploaded)
>
> Description:    Ubuntu hardy (development branch)
> Release:        8.04
> cupsys:
>  Installed: 1.3.7-1ubuntu2
>  Candidate: 1.3.7-1ubuntu2
>  Version table:
>  *** 1.3.7-1ubuntu2 0
>
> To unsubscribe from this bug, go to:
> https://bugs.launchpad.net/ubuntu/+source/cupsys/+bug/213081/+subscribe
>

[Brian Burch (brian-pingtoo)]

I worked on the original hardy bug, which was fixed in the kernel for jaunty. I have now been running the same printer under karmic for 6 months. I have just upgraded to lucid and the printer is still working fine. I have not needed to set "net.ipv4.tcp_frto = 0" on ANY kernel except hardy.

Based on my experiences, I think this particular bug should remain closed because the code has not regressed.

Anyone who needs to set tcp_frto as a bypass for slow printing problems on lucid is dealing with a new bug. Problem determination is required before we can decide the source of the bug, even if it turns out to be in the kernel tcp logic as before.

[Stefan Bader (smb)]

Given the fact that Lucid has now released and does not show the initially reported problem, I am closing the Hardy task. I know this is not really a solution that feels good, but honestly there is just not enough time for doing that and then its better to admit it.

[Brian Burch (brian-pingtoo)]

I agree with you Stefan, but don't see any reason for you to have regrets!

When this bug was "hot", it was because a new kernel had just been released for Hardy LTS. It broke a lot of stable printing systems and so we knew we would have to live with the bug for the next 18 months. Our bypass seemed to be acceptable to everyone who was affected by the bug, but several of us spent a lot of time trying to backport the kernel fix before giving up because it was too complex.

Lucid is the new LTS, so Hardy's days are numbered and (as I said before) there is a bypass.

Anyone who experiences the original symptoms:- slow or never-completing printing with an ancient tcp stack in the printer... needs to treat it as a new bug and do proper problem determination. That means wireshark traces to identify the broken protocol sequence. Once the low-level symptoms are identified unambiguously, we can reproduce it and try to get it fixed.