Endless repeated jobs with LinkSys PSUS4

[michaelrsweet]

Version: 1.1.22rc1
CUPS.org User: twaugh.redhat

When submitting IPP jobs, the job is endlessly repeated if a corrupt IPP response is received on completion. This is the case with at least one LinkSys PSUS4 device which claims to speak IPP/1.0.

In this case, ippRead will set lastError to IPP_SERVICE_UNAVAILABLE, and the ipp backend catches it here:

if (ipp_status > IPP_OK_CONFLICT)
{
  job_id = 0;

  if (ipp_status == IPP_SERVICE_UNAVAILABLE ||
      ipp_status == IPP_PRINTER_BUSY)
  {
    fputs("INFO: Printer is busy; retrying print job...\n", stderr);
    sleep(10);
  }
  else
    fprintf(stderr, "ERROR: Print file was not accepted (%s)!\n",
            ippErrorString(ipp_status));
}

It retries the job (it doesn't cause an 'ERROR') even though it is bound to fail again.

I would suggest removing 'ipp_status == IPP_SERVICE_UNAVAILABLE ||' to prevent this, or else setting a different error code in ippRead in this situation.

Original bug report:

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=135502

[michaelrsweet]

CUPS.org User: mike

The current linksys print servers are known to be buggy (we recently added an option to force IPP/1.0 since they will crash if sent a 1.1 request!) so I'm not sure there is much point to fixing things for this particular print server.

It doesn't appear that the user has tried changing the device URI to:

ipp://172.31.16.3/printers/queue1?version=1.0

I don't think this will fix the actual problem, but that is the current workaround until Linksys fixes their buggy implementation...

Not handling IPP_SERVICE_UNAVAILABLE will cause problems with some printers since that status is returned for an off-line or busy printer in some cases.

Changing cupsDoFileRequest() to set the status to IPP_ERROR might be appropriate, however I will need to investigate the API implications.

[michaelrsweet]

CUPS.org User: twaugh.redhat

How about the above patch? The idea is that if we see IPP_SERVICE_UNAVAILABLE and got NULL from cupsDoFileRequest, we have hit an error that can't be resolved.

[michaelrsweet]

CUPS.org User: mike

That's a possible solution, but I'd prefer to use a dedicated error constant (e.g. IPP_ERROR) if we can. Will let you know...

[michaelrsweet]

CUPS.org User: mike

Please see the attached (simple) patch which should resolve the issue for all possible cases.

[michaelrsweet]

CUPS.org User: mike

Fixed in CVS - the anonymous CVS repository will be updated at midnight EST.

[michaelrsweet]

"cups-ippfail.patch":

--- cups-1.1.22rc1/backend/ipp.c 2004-10-14 08:41:52.536559206 +0100
+++ cups-1.1.22rc1/backend/ipp.c 2004-10-14 10:30:03.997762811 +0100
@@ -806,7 +806,7 @@
{
job_id = 0;

•  if (ipp_status == IPP_SERVICE_UNAVAILABLE ||
  

•  if ((response && ipp_status == IPP_SERVICE_UNAVAILABLE) ||
  

  ipp_status == IPP_PRINTER_BUSY)
  {
  fputs("INFO: Printer is busy; retrying print job...\n", stderr);
  @@ -836,7 +836,7 @@
  fprintf(stderr, "PAGE: 1 %d\n", copies_sup ? atoi(argv[4]) : 1);
  copies --;
  }
• else if (ipp_status != IPP_SERVICE_UNAVAILABLE &&
• else if (!(response && ipp_status == IPP_SERVICE_UNAVAILABLE) &&
  ipp_status != IPP_PRINTER_BUSY)
  break;

[michaelrsweet]

"str953.patch":

Index: util.c

RCS file: /development/cvs/cups/cups/util.c,v
retrieving revision 1.121
diff -u -r1.121 util.c
--- util.c 19 Aug 2004 12:46:17 -0000 1.121
+++ util.c 27 Oct 2004 14:07:44 -0000
@@ -1237,8 +1237,8 @@
last_error = IPP_NOT_FOUND;
break;
case HTTP_ERROR :

•      DEBUG_puts("Mapping HTTP error to IPP_SERVICE_UNAVAILABLE");
  

•      last_error = IPP_SERVICE_UNAVAILABLE;
  

•      DEBUG_puts("Mapping HTTP error to IPP_ERROR");
  

•      last_error = IPP_ERROR;
  

  break;
  case HTTP_UNAUTHORIZED :
  last_error = IPP_NOT_AUTHORIZED;