[sane-devel] Warnings from SNMP (was Epson Perfection)

[Olaf Meeuwissen]

Hi Charles,

Charles Lindsey writes:

> On 18/10/2020 01:33, Olaf Meeuwissen wrote:
>> Hi Ralph, Charles,
>
>>>> Also, when running xsane and even simple-scan, it produced massive
>>>> warnings of the form:
>>>> MIB search path:
>>>> /home/chl/.snmp/mibs:/usr/share/snmp/mibs:/usr/share/snmp/mibs/iana:/usr/share/snmp/mibs/ietf:/usr/share/mibs/site:/usr/share/snmp/mibs:/usr/share/mibs/iana:/usr/share/mibs/ietf:/usr/share/mibs/netsnmp
>>>> Cannot find module (SNMPv2-MIB): At line 1 in (none)
>>>> Cannot find module (IF-MIB): At line 1 in (none)
>>>> Cannot find module (IP-MIB): At line 1 in (none)
>>>> Cannot find module (TCP-MIB): At line 1 in (none)
>>>> Cannot find module (UDP-MIB): At line 1 in (none)
>>>> Cannot find module (HOST-RESOURCES-MIB): At line 1 in (none)
>>>> Cannot find module (NOTIFICATION-LOG-MIB): At line 1 in (none)
>>>> Cannot find module (DISMAN-EVENT-MIB): At line 1 in (none)
>>>> Cannot find module (DISMAN-SCHEDULE-MIB): At line 1 in (none)
>>>> Cannot find module (HOST-RESOURCES-TYPES): At line 1 in (none)
>>>> Cannot find module (MTA-MIB): At line 1 in (none)
>>>> Cannot find module (NETWORK-SERVICES-MIB): At line 1 in (none)
>>>> Cannot find module (SNMPv2-TC): At line 15 in
>>>> /usr/share/snmp/mibs/UCD-DISKIO-MI
>>>> and much more. But I did not see them when using my own compiled
>>>> backend-plustek.
>>>>
>>> Sorry, don't know about that.
>>
>> Those warnings are courtesy of libsnmp and I think you compiled without.
>>
>> The Ubuntu bug report you mentioned talks about the possibility that
>> colord-sane may be causing this.  FWIW, we fixed a couple of backends a
>> few months ago so that they no longer generate network traffic when the
>> local-only option is used.  See
>>
>>    https://gitlab.com/sane-project/backends/-/issues/130
>>
>> for details.
>>
> I have followed up that link, and also earlier discussions on this
> list referenced there. It all seems to boil down to the function
>     SANE_Status sane_get_devices (const SANE_Device *** device_list,
>                                   SANE_Bool local_only);
> and the exact meaning of local_only, and even the developers on this
> list can't seem to agree on what that means. Note that there are more
> than one implementation of that function throughout the whole
> system. So here is my take on it:

Every SANE backend *must* provide an implementation.  So, yes, there are
93 implementations of it in sane-backends alone.  Any external backends
you may or may not have installed would add to that.

> Every usage of Sane starts from some frontend.

Correct.

> For example xsane (of which I have the code in front of me) has to
> decide what backend it is going to use.

Nitpick: It has to decide which scanner/backend combination it is going
to use.

> If a backend is specified on
> the command line (and you specify it by a Name (e.g. "Alice's
> Scanner"), then all is straightforward.

That depends on the frontend and the backend you told it to use.  In an
ideal world, it would be straightforward but both frontend and backend
are still free to call sane_get_devices if they feel the need.

> Otherwise, xsane calls
>    sane_get_devices(&xsane.devlist, SANE_FALSE /* local and network devices */);
> which presumably looks at every SCSI Bus, and then any available Usb,
> and then any server on the LAN which is running saned (with proper
> authorisation for you), and then any such server on the internet; so
> if all it can find is a server in Timbuktu, you will have to hire a
> camel to take your document to Timbuktu to be scanned.

Apart from the exact order you sketch above, looking for servers (on the
LAN and the internets at large) running saned should not happen in the
case local-only was set to true.  The `net` backend has observed that
value correctly since version 1.0.1 (released over 20 years ago).

However, certain backends also search for scanners directly attached to
the network.  They may use SNMP or AVAHI or ... well, whatever and would
normally use an appropriate library to do so.

Standard compliant backends should not be doing those probes for network
attached scanners but some of our backends did.  That has been fixed and
will be in the next sane-backends release.  Until such time, you can
disable backends in your dll.conf file.  The kodakaio and magicolor
backends use SNMP to detect devices (and have been fixed recently).

> Now I have run xsane under gdb, and observe that by the time that call
> returns, the deluge of warnings from snmp has already appeared, and
> note also that at that stage all that xsane is aware of is a list of
> [name/vendor/model/type]; NO specific device has been chosen, so the
> instance of sane_get_devices obeyed must have been the generic one in
> libsane. We don't have a specific SANE_Handle available, and therefore
> we cannot have obeyed and code in any SANE_handler.

The "generic" sane_get_devices is normally the one from the dll backend
and that one calls the sane_get_devices implementations of all the SANE
backends you have enabled (normally in /etc/sane.d/dll.conf but see the
sane-dll manual page for details).

> Therefore this is not a backend problem. The culprit for the deluge of
> warnings about snmp MUST be that sane_get_devices function in libsane,
> and that is where you should look.

We have looked there and we have fixed all the backends in sane-backends
so they do not generate network traffic when local-only is true.  That
fix will be in the next sane-backends release.

Please be advised that the messages you see are *not* output by the SANE
backends.  It's libsnmp that generates these messages when a backend has
the audacity to use its API.

> Now it is quite reasonable for a backend to seek advice from colord as
> to how to process the stuff it scans (and I see that I do have a
> colord running, though nothing in /etc/init.d), but that is for later
> when an actual backend has been activated.

To the best of my knowledge, our sane-backends don't use colord in any
way.  Perhaps your frontend does.  I don't think XSane does, BTW.

> The plustek backend, which my scanner uses, has no interest in
> colord. It Does seem to envisage that is may have several devices of
> the same type under control, and it Does have a local implementation
> of sane_get_devices (which merely ignores its local_only parameter and
> returns a list of devices it has already been asked to activate). Who
> calls that local implementation is entirely unknown.

If the plustek does not and will not, ever, support directly network
attached devices, it can safely ignore the local-only parameter.

> The colord-sane daemon is a more interesting problem. It is known
> known that it incorporates a call of sane_get_devices, but I am not
> running colord-sane (that I know of). And why it should get involved
> when sane_get_devices gets called from xsane I cannot imagine.
>
> I would suggest that some investigation of what the sane_get_devices
> in libsane actually does and likewise what colord-sane is up to would
> lead to the solution for this deluge.

If commenting out the kodakaio and magicolor backends in your dll.conf
does not solve this for you, you have external backends installed that
are responsible for the "deluge".  If the plustek backend is all you
need, simply comment out every other backend.

Hope this helps,
--
Olaf Meeuwissen, LPIC-2            FSF Associate Member since 2004-01-27
 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13  F43E B8A4 A88A F84A 2DD9
 Support Free Software                        https://my.fsf.org/donate
 Join the Free Software Foundation              https://my.fsf.org/join