[LOW] STR #4185: ipp backend wait endless under certain circumstances

DO NOT REPLY TO THIS MESSAGE.  INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.

[STR New]

Scenario:

CUPS (central office) --- VPN --- CUPS (embedded system) --- printer


The CUPS server in the central office compress the print job and send it
through the VPN to an embedded system (OpenWRT + CUPS). The embedded
system decompress the job and send it to the printer.

Protocol: IPP
Central Office: CUPS 1.5.4 (from source width modified ipp backend)
Embedded System: CUPS 1.4.4 (from OpenWRT repo)

The ipp backend was modified because of:
https://www.cups.org/str.php?L4181
But I do not use the patch in our production system. I only modified
following variables "version=11" and "create_job" should alway stay "0".
The backend will always use "Print-Job" instead of "Create-Job" and
"Send-Document" (at least for a single file).


The problem:
One of our VPN gateways does not work as it should, so the connections
become dropped and lose packets. After some seconds (0-180), the
connection is established again.

The ipp backend sends the job to the other CUPS server, then it waits for
the job to complete. I assume that we lose one or more packets in the job
creation phase. So the CUPS server on the embedded system waits for more
packets and does not start the job. The ipp backend waits for job
completion and hangs forever.

Some facts I could get:
1. ipp backend waits for job completion (gdb helped me)
2. job exists on the other CUPS server with job state = IPP_JOB_PENDING
3. job on the other CUPS server is only displayed with "lpstat -W all"

I didn't write a patch because I don't know the right way, how to solve
this (except replacing the "faulty" VPN gateway).
In the meanwhile I use "waitjob=false" as workaround (maybe this is the
solution).


regards,
Bernd

Link: http://www.cups.org/str.php?L4185
Version: 1.5.4