Bug#729713: libcups2: fails to fetch ppd of ipp:// device
On Sunday 05 January 2014 13:47:41 Till Kamppeter wrote:
> On 01/05/2014 01:36 PM, Wolfgang Walter wrote:
> > On Sunday 05 January 2014 13:12:31 Till Kamppeter wrote:
> >> On 01/05/2014 12:45 PM, Didier 'OdyX' Raboud wrote:
> >>> Control: tags -1 +moreinfo
> >>>
> >>> Hi Lionel and Wolfgang,
> >>> hi Till,
> >>>
> >>> thanks for your detailed bugreports and proposed patch.
> >>>
> >>> Le samedi, 16 novembre 2013, 05.34:09 Lionel Elie Mamane a écrit :
> >>>> Let FOO be a printer configured in CUPS with an
> >>>> ipp://foo.localdomain.tld/something device uri.
> >>>> Mine is a Konica Minolto C353.
> >>>>
> >>>> All cups clients fail to show printing options.
> >>>>
> >>>> "lpoptions -d FOO -l" says:
> >>>> lpoptions: Unable to get PPD file for FOO: Not Found
> >>>>
> >>>> A wireshark shows a request for http://device_ip:631/ipp.ppd,
> >>>> to which the printer replies by a 404.
> >>>>
> >>>> The attached patch disables that undesirable behaviour, which is new
> >>>> in 1.6 (did not happen in 1.5).
> >>>
> >>> Your proposed patch is functionally equivalent to disabling the get-ppd-
> >>> file-for-statically-configured-ipp-shared-queues.patch , which was
> >>> introduced in 1.6.1-1 as a backport from upstream's fix for
> >>> http://cups.org/str.php?L4178
> >>>
> >>> Till, as you wrote this patch, what do you think about this?
> >>>
> >>> Apparently, http://cups.org/str.php?L4159 was related to this problem
> >>> and got solved differently in 1.6.2, and now cups/util.c appears to be
> >>> redundant around this codeblock.
> >>>
> >>> Till, can we remove this patch on all versions > 1.6.2 ?
> >>
> >> Important is to check whether if you create a raw IPP queue pointing to
> >> a CUPS queue on a remote server that you get access to the options on
> >> the client (means that the client loads the PPD from the server). Please
> >> test this.
> >>
> >> You can test by creating an arbitrary print queue with PPD on one
> >> machine (the server) and sharing it. On another machine (the client) you
> >> either create a raw ipp: or ipps: queue pointing to the queue on the
> >> server or you run cups-browsed (which creates such a queue
> >> automatically). If you print out of a GUI app on the client using the
> >> ipp/ipps queue pointing to the CUPS server you should see the PPD
> >> options in the print dialog. You should also run "lpoptions -p <printer>
> >> -l" on the client and should see the options if <printer> is an ipp/ipps
> >> queue pointing to the server and no error message if <printer> is
> >> pointing to a native IPP printer.
> >>
> >> Till
> >
> > We do not have a cups-server running on the client. Our configuration is:
> >
> > client: only
> > /etc/cups/client.conf with
> > ServerName cups.localdomain.tld.
> >
> > On the print server cups.localdomain.tld. we have a lot of printers in
> > printers.conf like that
> >
> > <Printer Mehltau>
> > AuthInfoRequired none
> > Info Mehltau
> > Location Rosenstraße
> > MakeModel MyFavoritePostscripPrinterModel
> > DeviceURI ipp://mehltau.drucker.localdomain.tld/ipp
> > State Idle
> > StateTime 1387541234
> > Type 8425548
> > Filter application/vnd.cups-raw 0 -
> > Filter application/vnd.cups-command 0 commandtops
> > Filter application/vnd.cups-postscript 0 -
> > Accepting Yes
> > Shared Yes
> > JobSheets none none
> > QuotaPeriod 0
> > PageLimit 0
> > KLimit 0
> > OpPolicy default
> > ErrorPolicy abort-job
> > </Printer>
> >
> > We do not wan't to mehltau to be a raw-printer as the printer server
> > should
> > e.g. handle pdfs etc.
> >
> > This setting breaks with cups 1.6. as now the client contacts
> > cups.localdomain.tld but then tries to get the ppd from
> > mehltau.drucker.localdomain.tld instead from cups.localdomain.tld
> >
> > But mehltau.drucker.localdomain.tld is a ipp postscript printer (e.g. from
> > HP or any other vendor) and does not provide ppds (and in our case the
> > client is not even allowed to communicate with Mehltau directly).
> >
> > Regards,
>
> My patch did
>
> httpSeparateURI(HTTP_URI_CODING_ALL,
> device_uri,
> scheme, sizeof(scheme), username,sizeof(username),
> host, hostsize, port, resource, resourcesize);
>
> whereas the final fix does
>
> httpSeparateURI(HTTP_URI_CODING_ALL,
> _httpResolveURI(device_uri, uri, sizeof(uri),
> _HTTP_RESOLVE_DEFAULT, NULL,NULL),
> scheme, sizeof(scheme), username,sizeof(username),
> host, hostsize, port, resource, resourcesize);
>
> Can it be that the _httpResolveURI() causes some problem here?
>
> Till
No, this makes no difference. The problem is using device_uri. Having a
device-uri starting with ipp:// does not ensure that the printer is another
cups-server which you can ask for a ppd.
Regards,
--
Wolfgang Walter
Studentenwerk München
Anstalt des öffentlichen Rechts
Reply to: