Unable to get PPD file for ...: Moved Permanently

Bug #1544571 reported by Christian Scheunert
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
cups (Ubuntu)
New
High
Till Kamppeter

Bug Description

1) lsb_release -rd
Description: Ubuntu 14.04.3 LTS
Release: 14.04

2) apt-cache policy cups-client
cups-client:
  Installed: 1.7.2-0ubuntu1.7
  Candidate: 1.7.2-0ubuntu1.7
  Version table:
 *** 1.7.2-0ubuntu1.7 0
        500 http://de.archive.ubuntu.com/ubuntu/ trusty-updates/main amd64 Packages
        500 http://security.ubuntu.com/ubuntu/ trusty-security/main amd64 Packages
        100 /var/lib/dpkg/status
     1.7.2-0ubuntu1 0
        500 http://de.archive.ubuntu.com/ubuntu/ trusty/main amd64 Packages

My problem:

*What I expected to happen:
In our environment we have a cups print server delivering different print queues, e.g. elbe_transparency. For all queues I get the same faulty result running lpoptions, e.g. for

lpoptions -l -d elbe_transparency

I get

lpoptions: Unable to get PPD file for elbe_transparency: Moved Permanently.

And also GUI apps like Evince have problems due to this bug.

* What I did so far:

(a) I used wireshark to capture the ipp protocol and found that lpoptions tries to retrieve the PPD
for the printer elbe with device-uri "ipp://elbe.tnt.ifn.et.tu-dresden.de:631" from that device URI
instead of the cups server with printer-uri-supported "ipp://192.168.3.5:631/printers/elbe_transparency".
This makes sense when the device URI is actually another CUPS server, but not when, as in our case, it is a
network-attached printer that "talks" IPP natively. It will not have the PPD at the CUPS-specific URL.

(b) I used "strace -s1000 lpoptions -p elbe_transparency -l 2>lpoptions.txt" to get
...
sendto(9, "GET /.ppd HTTP/1.1\r\nHost: elbe.tnt.ifn.et.tu-dresden.de:631\r\nUser-Agent: CUPS/1.7.2 (Linux 3.16.0-60-generic; x86_64) IPP/2.0\r\n\r\n", 129, 0, NULL, 0) = 129
poll([{fd=9, events=POLLIN}], 1, 60000) = 1 ([{fd=9, revents=POLLIN}])
recvfrom(9, "HTTP/1.1 301 Moved Permanently\r\nServer: Virata-EmWeb/R6_2_1\r\nLocation: https://elbe.tnt.ifn.et.tu-dresden.de/.ppd\r\nContent-Type: text/html\r\nContent-Length: 110\r\n\r\n<HEAD><TITLE>Moved</TITLE></HEAD><BODY><A HREF=\"https://elbe.tnt.ifn.et.tu-dresden.de/.ppd\">Moved</A></BODY>\r\n", 2048, 0, NULL, NULL) = 273
...
which shows the same problem as described above.

* Where does the problem come from
The actual problem can be found in cups/util.c (1.7.2) within function cups_get_printer_uri() starting at line 1623. At line 1719 one finds

if (device_uri &&
         (!strncmp(device_uri, "ipp://", 6) ||
         !strncmp(device_uri, "ipps://", 7) ||
         ((strstr(device_uri, "._ipp.") != NULL ||
           strstr(device_uri, "._ipps.") != NULL) &&
          !strcmp(device_uri + strlen(device_uri) - 5, "/cups")))){...}
else if ((attr = ippFindAttribute(response, "member-uris", IPP_TAG_URI)) != NULL) {...}
else if ((attr = ippFindAttribute(response, "printer-uri-supported", IPP_TAG_URI)) != NULL){...}

The problem is that always the statement of the first if block is executed as our printer has device-uri "ipp://elbe.tnt.ifn.et.tu-dresden.de:631. However, it should execute the third block with printer-uri-supported. This problem was discussed several times before, e.g.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=729713.

In later versions of cups this was fixed by

    if (device_uri &&
        (((!strncmp(device_uri, "ipp://", 6) || !strncmp(device_uri, "ipps://", 7)) &&
   (strstr(device_uri, "/printers/") != NULL || strstr(device_uri, "/classes/") != NULL)) ||
         ((strstr(device_uri, "._ipp.") != NULL || strstr(device_uri, "._ipps.") != NULL) &&
          !strcmp(device_uri + strlen(device_uri) - 5, "/cups"))))

to ensure the device URI is actually another CUPS server. Please, could you fix this asap. We have many Ubuntu machines in our environment and this bug is really annoying. Many thanks for your help in advance.

Changed in cups (Ubuntu):
assignee: nobody → Till Kamppeter (till-kamppeter)
importance: Undecided → High
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.