libcups.so.2::cupsCreateJob failed on remote CUPS server ( client-error-not-found for Get-Printer-Attributes )
Hi, I am working on printing services using CUPS as printing backend and run into a problem and may ask for suggestions.
pls note: issue reported at: https://github.com/apple/cups/issues/6100 as well.
Short: using libcups.so:2::cupsPrintFile to hand over print requests - this works fine on localhost.
Doing the same using identical remote CUPS server instead failed with client-error-not-found .
I am uncertain if i am doing something terribly wrong. From my point of view I would like to point out what went wrong and kindly ask for support.
host_ = any-non-local-ip port_ = 1631 # using CUPS server compiled with --with-ipp-port=1631 cancel_ = FALSE msec_to = 3000
All starts with cupsPrintFile
using http_t* httpConnect2(host_.data(),port_,NULL,AF_UNSPEC,HTTP_ENCRYPTION_IF_REQUESTED,TRUE,msec_to_,&cancel_); will come down to cupsCreateJob. cupsCreateJob will send three IPP requests to the remote CUPS server:
Response OK, as shared printer exists.
based on
destsecond request failed withReturning IPP client-error-not-found for Get-Printer-Attributes (lpd://printer-ip/LPT1)due do sending the request to the remote CUPS server but usingCUPS_DEST_FLAGS_DEVICEand using the device-uri instead of printer-uri.
Log:
[Client ] 2.0 Get-Printer-Attributes 24 cupsdProcessIPPRequest(0x5588b1f3d510[3]): operation_id=000b(Get-Printer-Attributes) cupsdProcessIPPRequest: operation-attributes-tag cupsdProcessIPPRequest: attributes-charset charset 'utf-8' cupsdProcessIPPRequest: attributes-natural-language naturalLanguage 'en-us' cupsdProcessIPPRequest: printer-uri uri 'lpd://printer-ip/LPT1' cupsdProcessIPPRequest: requesting-user-name nameWithoutLanguage 'root' cupsdProcessIPPRequest: requested-attributes 1setOf keyword 'job-template,media-col-database,printer-description' Get-Printer-Attributes lpd://printer-ip/LPT1 get_printer_attrs(0x5588b1f3d510[3], lpd://printer-ip/LPT1) Get-Printer-Attributes client-error-not-found: The printer or class does not exist. [Client ] Returning IPP client-error-not-found for Get-Printer-Attributes (lpd://printer-ip/LPT1) from...
In my case i would like to talk to the remote CUPS server. Especially due to line: https://github.com/OpenPrinting/cups/blob/d74a3d1c12a7672c9b738ea6164281e7088ed573/cups/dest-options.c#L719-L723
Question: Is there any change to force or configure to do the second IPP request right? Many thanks for any suggestions!
https://github.com/OpenPrinting/cups/blob/d74a3d1c12a7672c9b738ea6164281e7088ed573/cups/dest-options.c#L706-L728
up to here, only on locally used CUPS server as i guess
AF_LOCALwill take affect.
What version of CUPS are you using?
Currently running version 2.2.13 of apple/cups and relevant behaviour may be seen as of version 2.2.12
Corresponding changes of file dest-options.c can be traced back to https://github.com/apple/cups/issues/5587 and commit https://github.com/apple/cups/commit/9b48d16c1d5b4102bd8cbfdd053f7c9f5d3a8b5d
Refer to: apple/cups dest-options.c:622
and OpenPrinting/cups dest-options.c:719
Many thanks for any kind of advice!
Notes: aware of that the original intent may be violated: evaluation build of version 2.2.13 tested with success by comment out referred lines of file dest-options:622-626
Please re-test against CUPS 2.4.x to see if this is still an issue for OpenPrinting CUPS. Otherwise it is up to Apple to fix in their legacy version of CUPS.
Re-tested with OpenPrinting/cups#v2.4.2. Unfortunately, same erroneous result as described before.
Log:
D [20/Jan/2023] [Client 6] 2.0 Get-Printer-Attributes 2 d [20/Jan/2023] cupsdProcessIPPRequest(0x55eed927ade0[6]): operation_id=000b(Get-Printer-Attributes) d [20/Jan/2023] cupsdProcessIPPRequest: operation-attributes-tag d [20/Jan/2023] cupsdProcessIPPRequest: attributes-charset charset 'utf-8' d [20/Jan/2023] cupsdProcessIPPRequest: attributes-natural-language naturalLanguage 'en-us' d [20/Jan/2023] cupsdProcessIPPRequest: printer-uri uri 'lpd://printer-ip/LPT1' d [20/Jan/2023] cupsdProcessIPPRequest: requesting-user-name nameWithoutLanguage 'root' d [20/Jan/2023] cupsdProcessIPPRequest: requested-attributes 1setOf keyword 'job-template,media-col-database,printer-description' D [20/Jan/2023] Get-Printer-Attributes lpd://printer-ip/LPT1 d [20/Jan/2023] get_printer_attrs(0x55eed927ade0[6], lpd://printer-ip/LPT1) D [20/Jan/2023] Get-Printer-Attributes client-error-not-found: The printer or class does not exist. D [20/Jan/2023] [Client 6] Returning IPP client-error-not-found for Get-Printer-Attributes (lpd://printer-ip/LPT1) from... D [20/Jan/2023] [Client 6] Content-Length: 130 D [20/Jan/2023] [Client 6] cupsdSendHeader: code=200, type="application/ipp", auth_type=0
If I am interpreting this line correctly OpenPrinting/cups dest-options.c:719
else if ((strcmp(http->hostname, cg->server) && cg->server[0] != '/') || cg->ipp_port != httpAddrPort(http->hostaddr))
use
CUPS_DEST_FLAGS_DEVICEifhttp->hostnameis not equal tocg->serverandcg->serverlistener is not a /path/to/domain/socket or ifcg->ipp_portis not equal tohttp->hostaddr
Some thoughts:
What are the defaults or how are they defined: _cups_globals_t *cg = _cupsGlobals()
May i be able to set values by libcups:API to trigger intended behavior
What should i do, to handled requests/jobs always via CUPS-Scheduler
Many thanks for any kind of advice!
Hi @chri50 ,
what about setting a different CUPS server via cupsSetServer()? The all CUPS API functions should automatically work with remote CUPS instead of the local one (but beware of permissions - in case your user doesn't have some permissions on the server, you won't get a full access).
Either way you are trying to communicate with LPD printer via IPP protocol, which IMHO would not work unless you send the IPP request to printer's IPP port.
Hi @zdohnal ,
thank you very much for your suggestions, I'll take this into account and keep this thread updated.
Short Addition: My service never wants to communicate directly with a print device, instead the communication and any kind of protocol to any print device should be handled by a "central" CUPS service. This is fine if this "central" CUPS service is located on the same host as my service, but fails if this "central" CUPS service is located on any other host.
Near as I can tell, the code deciding whether to connect to the device or server isn't properly detecting things - clearly if that test fails then it should only connect to the device if it uses an IPP URI.
OK, so for 2.5 and later we really need to add a cups_dest_flags_t flags argument to this function since auto-detection isn't going to work well. WRT the current API, if the connected host and port matches the "device-uri" host and port, then use CUPS_DEST_FLAGS_DEVICE otherwise use CUPS_DEST_FLAGS_NONE.
[2.4.x 2d5deb744] Fix cupsCopyDestInfo device connection detection (Issue #586)
[master 32a8b5fb0] Fix cupsCopyDestInfo device connection detection (Issue #586)
[master 79eaf866f] Add cupsCopyDestInfo2 API (Issue #586)