← Back to team overview

desktop-packages team mailing list archive

  1. desktop-packages team
  2. Mailing list archive
  3. Message #161349

[Bug 1544571] Re: Unable to get PPD file for ...: Moved Permanently

  Thread Previous • Date Previous • • Thread Next 
** Changed in: cups (Ubuntu)
     Assignee: (unassigned) => Till Kamppeter (till-kamppeter)

** Changed in: cups (Ubuntu)
   Importance: Undecided => High

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to cups in Ubuntu.
https://bugs.launchpad.net/bugs/1544571

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

Status in cups package in Ubuntu:
  New

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.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/cups/+bug/1544571/+subscriptions

References

  Thread Previous • Date Previous • • Thread Next