Comment 11 for bug 926457

Till,

There are several possibilities here:
1) the SNMP supplies code caches the results of the MIB walk in /var/cache/cups/<ip_addr>.snmp
This cache file survives cupsd restart - this is really another bug - and contains the *previous* supplies[] structure in binary format. This is bad since the supplies[] structure has now changed.

2) the results of SNMP marker parsing are also cached in /etc/cups/printers.conf
This too I feel is a bug in CUPS - this is what is shown if you don't hit 'Refresh'.

3) I doubt HP put a '?' in the supplies description. More likely is that the localization charset is one the SNMP supplies code doesn't recognize (so it defaults to copying ASCII chars only and blows in '?' for everything else).

4) Along the same lines as #3, there could be a bug in one of charset to utf8 converters used by the SNMP supplies code.

Next troubleshooting steps:
1) Delete the printer from CUPS printer management
2) Stop cups, delete the snmp cache file (I'm not sure if CUPS deletes the cache file if the printer is deleted - please report if cache file is present after deleting printer).
3) Restart cups, re-add printer, navigate to supplies tab and hit 'Refresh'.

If those steps didn't resolve the problem, then please post here the following:
1) Output results from 'testsupplies'
'testsupplies' is a binary product not included in the packaging but still built. It's in the 'backend' subdir. It needs the PPD filename in the environment and the target's ip address. It outputs to stderr (that's how it communicates the job results :) How I run mine (from the backend subdir):

$ PPD=/etc/cups/ppd/hp2605dn.ppd ./testsupplies 192.168.1.201 2> supplies.result

It runs in a loop - you have to interrupt it after you see the PASS/FAIL output.

2) The system MIB and print MIB. To dump the mibs:
$ snmpwalk -v 1 -c public <ip address> .1.3.6.1.2.1.25 > hp.system.mib
$ snmpwalk -v 1 -c public <ip address> .1.3.6.1.2.1.43 > hp.print.mib