snmp backend can be very slow

[michaelrsweet]

Version: 1.2.1
CUPS.org User: twaugh.redhat

With some devices, the snmp backend gets stuck in connect() for 10 seconds at a time. Example (includes strace -t log):

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

Do we need to let that time out on its own, or should we time it out earlier?

[michaelrsweet]

CUPS.org User: mike

We actually are timing it out early - the normal TCP connection timeout is 5 minutes (300 seconds). The try_connect() function in snmp.c uses a 1 second alarm to abort the connection early...

The strace output showed a 12 second run time - on the long side for sure, but not out of the question on a large network.

Can you ask the user to do the following with that printer turned on:

CUPS_DEBUG_LEVEL=3 /usr/lib/cups/backend/snmp 2>&1 >snmp.log

and post the results?

[michaelrsweet]

CUPS.org User: twaugh.redhat

Got two logs back, from different people:

https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=130593
https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=130663

[michaelrsweet]

CUPS.org User: mike

Sigh, it is the Kyocera printers that are causing all this trouble. There is another STR (1790) with similar problems...

At this point I'm not sure what we're going to do, but it won't be addressed in 1.2.2...

[michaelrsweet]

CUPS.org User: mike

Please try the attached snmp.c and let me know if it fixes the problem.

If not, please attach the new output from this version...

Thanks!

[michaelrsweet]

CUPS.org User: mike

This STR has not been updated by the submitter for two or more weeks and has been closed as required by the CUPS Configuration Management Plan. If the issue still requires resolution, please re-submit a new STR.