Bug#822263: cups printing from 2 recently patched systems stops with incomplete spooling; printer works fine with Windows

[Dave Martin <ja@yeahblah.com>]

Bingo!  I did steps 1-5, and now printing is working fine.  *Thank you!*

Is this really a Debian or kernel bug (or regression)?  if so, what 
steps should be taken to report it?

...and are there ramifications to setting frto=0?



On 04/27/2016 01:23 AM, Brian Potkin wrote:
> tags 822263 - moreinfo
> thanks
>
>
>
> On Tue 26 Apr 2016 at 10:39:31 -0700, Dave Martin wrote:
>
> > I'm not sure if this will help at all, but I re-tested cups printing on my
> > netbook (wheezy, cups 1.5.2) to again make sure the print server and printer
> > are working properly.  (and just to clarify, this netbook is a 3rd machine,
> > not to be confused with the other 2 machines which both suffer the
> > referenced printing problems).  I printed 2 cups test pages, a simple text
> [...Snip...]
>
> It does help. Taken with the information in your previous mail and the lack of
> any obvious misbehaviour shown in the cups error logs, it could be we are
> looking at something similar to Ubuntu bug #213081 and Debian bug #478062.
>
>    https://bugs.launchpad.net/ubuntu/+source/linux/+bug/213081
>
> and
>
>    https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=478062
>
> The advice offered there is:
>
>    1. Power-off the printer to totally clear the corrupt job.
>    2. Clear the printer spool queue ('cancel -a -x').
>    3. Power-on the printer
>    4. Do '/sbin/sysctl -n net.ipv4.tcp_frto' and confirm the current
>       value is 2.
>    5. 'sysctl -w net.ipv4.tcp_frto=0' (as root).
>
> If it works
>
>    net.ipv4.tcp_frto=0
>
> is put in /etc/sysctl.conf so that the change survives rebooting.
>
> Regards,
>
> Brian.