[Thinlinc-technical] TL v4.5 : failure printing from Ubuntu-agent (was: Windows-client)

Rob De Langhe rob.de.langhe at twistfare.be
Mon Nov 23 21:41:32 CET 2015

  and the saga continues ...

On Ubuntu 14.04LTS, the package "cups" contains CUPS software 1.7.2

This CUPS software version is documented to contain a 'patch' which
effectively breaks the job-content filtering.

Nowhere it is explicitly documented if a more recent version of CUPS would
no longer contain that 'patch', so I tried the following :

1) Contacted CUPS authors for more information : radio-silence ... :-(
2) found latest CUPS software version to be v2.1.0
3) found that only in "cups" package of Ubuntu 15.10, this v2.1.0 is
4) upgraded master and agent servers to Ubuntu 15.10, now they run "cups"
package with this latest CUPS software version:

# dpkg -l cups
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name           Version      Architecture Description
ii  cups           2.1.0-4ubunt amd64        Common UNIX
Printing System(tm) -

5) had TL setup with the local print queue (thinlocal) only
6) checked that printing works fine from my Ubuntu 14.04LTS client to a
local printer : OK
7) tried printing a single one-page from a session on the agent; as far as
the agent is concerned all goes smoothly : nothing in
/var/log/cups/error_log, and a succesfull print log in
/var/log/cups/access_log :

localhost - - [23/Nov/2015:21:18:27 +0100] "POST /printers/thinlocal
HTTP/1.1" 200 21526 Print-Job successful-ok

8) on the client the job is accepted from the agent

# tail /var/log/cups/access_log
localhost - - [23/Nov/2015:21:18:27 +0100] "POST /printers/MFCJ6510DW
HTTP/1.1" 200 317 Create-Job successful-ok
localhost - - [23/Nov/2015:21:18:27 +0100] "POST /printers/MFCJ6510DW
HTTP/1.1" 200 21541 Send-Document successful-ok

but nothing gets printed and the job remains queued in /var/spool/cups :
# ls -ltr
-rw-r----- 1 root lp 21278 nov 23 21:18 d00013-001
-rw------- 1 root lp   794 nov 23 21:18 c00013
# file d00013-001
d00013-001: PDF document, version 1.5

In the beginning of the file, I see

  # head -7 d00013-001
3 0 obj
<< /Length 4 0 R
   /Filter /FlateDecode
(and then a bunch of binary data)

9) I remembered the 'workaround' suggested in the Redhat forum for this
incorrect print-job filtering issue, namely setting the printer queue as
'raw' :
(agent)# lpadmin -p thinlocal -m raw

After a restart of the "cups" service, this changed
"/etc/cups/printers.conf" from

<Printer thinlocal>
MakeModel Generic postscript printer
Type 4180


<Printer thinlocal>
Type 4

10) then tried the printing again, but still not joy and exactly the same
behaviour (job queued on client), printer status on client is happily idle
as if nothing decent is queued for printing:
# lpstat -t
scheduler is running
system default destination: MFCJ6510DW
device for MFCJ6510DW: ipp://
MFCJ6510DW accepting requests since ma 23 nov 2015 21:18:38 CET
printer MFCJ6510DW is idle.  enabled since ma 23 nov 2015 21:18:38 CET

The queued file from this print-attempt seems to contain now some
indication of a 'application/vnd.cups-raw' job :
# od -c /var/spool/cups/c00014
0001260   d   o   c   u   m   e   n   t   -   f  
o   r   m   a   t  \0
0001300 030   a   p   p   l   i   c   a   t   i   o  
n   /   v   n   d
0001320   .   c   u   p   s   -   r   a   w   A  \0
031   j   o   b   -
0001340   p   r   i   n   t   e   r   -   s   t  
a   t   e   -   m   e
0001360   s   s   a   g   e  \0  \0   D  \0 031   j  
o   b   -   p   r
0001400   i   n   t   e   r   -   s   t   a   t  
e   -   r   e   a   s
0001420   o   n   s  \0 004   n   o   n   e 003

=> anyone with a clue about how printing is $!**# possible with TL ?

with kind regards,

Citeren Pierre Ossman <ossman at cendio.se>:

> On Sat, 07 Nov 2015 16:20:56 +0100
> Rob De Langhe <rob.de.langhe at twistfare.be> wrote:
>> The bug description refers to another bug filed at Redhat, bug
>> "https://bugzilla.redhat.com/show_bug.cgi?id=1010580"
>> In this bug, it is not so clear to me whether there is finally some
>> patch, the only 'workaround' I see more or less described as
>> succesfull, is setting the printer driver on the client side (I
>> assume that, in the context of ThinLinc, that is the agent because
>> there the print job is initiated) to "raw" so that the client side is
>> not doing any job-content filtering.
> There's a lot of technical details on that bug so it's not terribly
> easy to follow. The story is basically this:
> - A user could print to his printer locally but not remotely.
> - The bug turned out to be that CUPS is sending the right data, but
>   putting an incorrect type label on it. This is only noticeable when
>   using an advanced protocol like IPP in combination with having the
>   printer driver early in the chain. This is a fairly uncommon setup.
> - Red Hat "fixed" the bug by forcing everything leaving CUPS to be
>   tagged as raw data. This is the correct type in most cases when
>   sending to a printer. It is not the correct type for advanced queues
>   like thinlocal.
> - The "fix" got removed once we pointed out that this was an incorrect
>   way of handling things.
> - Users are now experiencing the original bug again, which can be
>   worked around by configuring one of the queues as raw.
> That's why the workaround does nothing for you. It solves a different
> bug.
> The reason thinlocal doesn't work is because the "fix" is broken. To
> get thinlocal working you have to remove that "fix". Red Hat has
> already done so, but Ubuntu are still using it.
>> -> puzzled as to whom to contact to get this resolved ... As least I
>> wanted to share my findings (or lack of...) with anyone here who's
>> investigating the same issues on Ubuntu.
> It's only Canonical that can fix this properly. They are the ones
> compiling the CUPS package for you.
> Rgds
> --
> Pierre Ossman           Software Development
> Cendio AB                https://cendio.com
> Teknikringen 8                https://twitter.com/ThinLinc
> 583 30 Linköping        https://facebook.com/ThinLinc
> Phone: +46-13-214600        https://plus.google.com/+CendioThinLinc
> A: Because it messes up the order in which people normally read text.Q:
> Why is top-posting such a bad thing?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cendio.se/pipermail/thinlinc-technical/attachments/20151123/f5b35d05/attachment-0003.html>

More information about the Thinlinc-technical mailing list