Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CUPS should rely on SNMP and not IPP for device discovery #1728

Closed
michaelrsweet opened this issue May 26, 2006 · 11 comments
Closed

CUPS should rely on SNMP and not IPP for device discovery #1728

michaelrsweet opened this issue May 26, 2006 · 11 comments
Milestone

Comments

@michaelrsweet
Copy link
Collaborator

Version: 1.2.1
CUPS.org User: georgeliuyue

In the web GUI of CUPS 1.2.0, add printer will invoke /cups-1.2.0/backend/snmp.c to detect printers in the network.

Per my understanding, snmp.c will do the following:

  1. CUPS uses SNMP device type and device description OID to broadcast and detects printers
  2. CUPS tries to determine connection URI. It tries various URIs, in the order of IPP, socket 9100, then lpd
  3. If the device support IPP, it will then request printer-make-and-model IPP attribute from the printer.

As printer information has already been aquired using SNMP in the first step, and the support for SNMP is way better than IPP (some printers support IPP, but might not support all the IPP attributes), more printers will be supported if CUPS rely on SNMP sysDescr to match PPDs.

@michaelrsweet
Copy link
Collaborator Author

CUPS.org User: mike

Reassigning as RFE for -feature.

The problem with the device description that we get from SNMP is that it is a) less consistent than the IPP values, and b) doesn't handle multi-port print servers. In our testing, the IPP values were always more useful than the SNMP values.

As we continue to enhance the SNMP backend, we will be able to rely more on the SNMP data when it is available, reliable, and accurate, however there will likely always be a fallback to IPP (and other) device information when we can't find it via SNMP.

@michaelrsweet
Copy link
Collaborator Author

CUPS.org User: georgeliuyue

George Liu wrote:

Michael,

Thank you for the explanation and update for this feature.

As CUPS 1.2 has brought us this wonderful auto-printer-discovery
feature, Ricoh really wants to work with easysoft to bring the full
potential and the usefulness of this feature to the end user.

As Linux/CUPS is the first major OS that's pioneering the usage of IPP
attribute, I want to bring to your attention that Ricoh family
printers including Ricoh, Lanier, Gestetner, Savin, Infotec and NRG do
not support printer-make-and-model IPP attribute (although they
support IPP protocol ipp://ipaddress:631/printer and SNMP). Instead
printer-make-and-model will return a string like "Ricoh IPP Printer
V2.0", which is not useful in term of matching PPDs. I'm communicating
with our printer firmware development team to have it fixed in the
next printer releases. However, it's impossible to fix the problem on
printers already on the market.

CUPS has done a great job on backward compatibility in the past. As
one of the biggest manufacture PPD suppliers (Ricoh have published
more than 600 PPD files to linuxprinting.org), I really hope CUPS can
either use SNMP to match PPD as general case (in case SNMP not
supported, fall back to IPP) or make an exception (to check Ricoh,
Lanier, Gestetner, Infotec, NRG), that would make the
auto-printer-discovery feature work better.

I would like to hear your advice on this and appreciated your time on
looking into this issue.

I think we can just special-case this - if printer-make-and-model is bogus ("Ricoh IPP Printer" or other strings we add in the future) then we rely on the device description OID instead.

@michaelrsweet
Copy link
Collaborator Author

CUPS.org User: georgeliuyue

Michael,

I got the response from our firmware R&D team. The strings Ricoh family devices returns are:

"Ricoh IPP Printer v2.0" or
"Ricoh IPP Printer v1.0"

This covers Ricoh, Lanier, Gestetner, Savin, NRG and Infotec.

Snmp.c just need to add an additional condition check for these two strings.

Thanks and best regards
George Liu

@michaelrsweet
Copy link
Collaborator Author

CUPS.org User: mike

Fixed in Subversion repository.

Try the attached patch and let me know how it works for you...

@michaelrsweet
Copy link
Collaborator Author

CUPS.org User: georgeliuyue

The patch need fix.

Problem:
However, when running from CUPS UI, printer name (for which printer-make-and-model attribute returns "IPP Printer") messed up.

Debugging:
cups-1.2.x/backend > ./snmp printeripaddress
worked well. It returns the SNMP make and model instead of "IPP Printer".

I added debug log in snmp.c / list_devices(), to print all the printers to error_log as well as to a file. In error_log, printer name messed up.

Finding:
in snmp.c / probe_device() / line 1662:
variable temp is not initialized.

if (model)
strlcpy(temp, model->values[0].string.text, sizeof(temp));
else if (info)
backendGetMakeModel(...)

fix_make_model(make_model, temp, sizeof(make_model))

(Variable model and info both are NULL.)

@michaelrsweet
Copy link
Collaborator Author

CUPS.org User: mike

OK, got the printer today, and attached is a fix for both the garbled make and model and to use /printer for the IPP printer-uri...

@michaelrsweet
Copy link
Collaborator Author

CUPS.org User: georgeliuyue

Tested against the latest CUPS-1.2.x svn-r5642.

The discovery part works great! Thanks Michael for the timely fix.

However, I discovered that some Ricoh devices does not support the IPP backend very well. After a job has been submitted (ipp://ipaddress:631/printer) and printed, the printer is stopped, "/usr/lib/cups/backend/ipp failed". A message in error_log shows that

Unable to get job 4 attributes (client-error-bad-request)!
PID 15822 (/usr/lib/cups/backend/ipp) stopped with status 1!

I guess it might because some of the IPP attributes are not supported by the printer? (/backend/ipp.c, around line 980)

A quick fix for this is to remove "/printer" from common resource paths for IPP, (snmp.c, line 1547.) In this way, old generation of Ricoh printers (like Aficio AP400, which only supports ipp://ipaddress:631/printer" will fall back to use socket 9100 protocol. New generation of Ricoh printers (like SP C410, which supports both ipp://ipaddress:631/printer and ipp://ipaddress:631/ipp) will use IPP protocol.

I removed the line "/printer" from str1728p2.patch, and both discovery and print works fine.

Thanks again for the support.

@michaelrsweet
Copy link
Collaborator Author

CUPS.org User: georgeliuyue

Printer discovery in current cups-1.2.x worked fine.

The problem of IPP backend failed (probably because printer does not support job-state and job-media-sheets-completed) is a separate issue regarding the robustness of CUPS and I have filed bug 1762 to address that.

This bug can be closed as Fixed.

@michaelrsweet
Copy link
Collaborator Author

CUPS.org User: mike

Fixed in Subversion repository.

@michaelrsweet
Copy link
Collaborator Author

"str1728.patch":

Index: snmp.c

--- snmp.c (revision 5612)
+++ snmp.c (working copy)
@@ -1641,6 +1641,14 @@
info = NULL;

    /*
  •    \* Don't use the printer-make-and-model if it contains a generic
    
  • * string like "Ricoh IPP Printer"...
  • */
  • if (model && strstr(model->values[0].string.text, "IPP Printer"))
  • model = NULL;
    
  •   /*
     \* If we don't have a printer-make-and-model string from the printer
    
    • but do have the 1284 device ID string, generate a make-and-model
    • string from the device ID info...

@michaelrsweet
Copy link
Collaborator Author

"str1728p2.patch":

Index: snmp.c

--- snmp.c (revision 5638)
+++ snmp.c (working copy)
@@ -1544,6 +1544,7 @@
"/ipp/port2",
"/ipp/port3",
"/EPSON_IPP_Printer",

  •         "/printer",
          "/LPT1",
          "/LPT2",
          "/COM1",
    
    @@ -1658,6 +1659,8 @@
    strlcpy(temp, model->values[0].string.text, sizeof(temp));
    else if (info)
    backendGetMakeModel(info->values[0].string.text, temp, sizeof(temp));
  •    else
    
  • temp[0] = '\0';
    
     fix_make_model(make_model, temp, sizeof(make_model));
    

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant