search

glpi-project / glpi-agent

GLPI Agent
GNU General Public License v2.0
251 stars 62 forks source link

SNMP v3 - Time synchronization failed during discovery #778

Open kmpm opened 1 month ago

kmpm commented 1 month ago

Bug reporting acknowledgment

Yes, I read it

Professional support

Yes, I know

Describe the bug

Trying to do a snmp scan using v3 protocol but getting [debug] #1, - scanning 172.16.10.130 with SNMP, credentials [v3_glpi]: no result, Time synchronization failed during discovery in the log.

To reproduce

  1. Go to agent toolbox
  2. Add a snmp v3 credential with username, md5 authentication and des pricacy.
  3. Add IP range that targets device
  4. Add Inventory task that uses range and credentials.
  5. Run Task
  6. getting error in the log [debug] #1, - scanning 172.16.10.130 with SNMP, credentials [v3]: no result, Time synchronization failed during discovery

Expected behavior

I expect the agent being able to get information from the device using snmp v3 protocol. It works with snmpwalk -v3 -l authPriv -u "$SNMP_USER" -a MD5 -A "$SNMP_AUTH" -x DES -X "$SNMP_PRIV" $SNMP_IP

Operating system

Windows

GLPI Agent version

v1.11

GLPI version

10.0.15

GLPIInventory plugin or other plugin version

GLPI Inventory v1.x.x (See additional context below)

Additional context

GLPI Inventory plugin version 1.4.0 but it never gets that far.

beginning of snmp walk output 

SNMPv2-MIB::sysDescr.0 = STRING: Network Management Card for UPS
SNMPv2-MIB::sysObjectID.0 = OID: SNMPv2-SMI::enterprises.935.10.1
DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (5883044) 16:20:30.44
SNMPv2-MIB::sysContact.0 = STRING: Technical Support Center
SNMPv2-MIB::sysName.0 = STRING: NMC
SNMPv2-MIB::sysLocation.0 = STRING: Containern
SNMPv2-MIB::sysServices.0 = INTEGER: 72
SNMPv2-MIB::sysORLastChange.0 = Timeticks: (0) 0:00:00.00
SNMPv2-MIB::sysORID.1 = OID: SNMPv2-MIB::snmpMIB
g-bougard commented 1 month ago

Hi @kmpm

just found this Net::SNMP issue: https://rt.cpan.org/Public/Bug/Display.html?id=75191

The error by itself is not originally generated by glpi-agent but by the Net::SNMP library we are using. The Net::SNMP issue seems to suggest this could be a device problem not fully supporting RFC 3414. Have you checked if a device firmware update is available ? If not, you should first contact the device manufacturer support to know if they are aware of the problem and if they have a solution.

From the glpi-agent point of view, for such a poorly designed device, you can only use an older protocol. Or maybe try to use SHA protocol and/or AES encryption, using more recent standard may also help device to behave as expected by our used library.

PS: Maybe using TCP protocol can help