ZABBIX BUGS AND ISSUES
  1. ZABBIX BUGS AND ISSUES
  2. ZBX-5414

Zabbix mis-handles items that have incorrect SNMPv3 username/passwords set up

    Details

      Description

      When a username/password is set incorrectly for an SNMP item, instead of properly handling the error in configuration and marking the item 'disabled,' Zabbix misinterprets the SNMP response from the device as a network failure.

      "failed: another network error, wait for 5 seconds" is logged and the entire device is taken out of service, instead of what should happen (e.g. the specific item is disabled and the reason for the particular item going to disabled status is that the SNMP username/password is incorrect for that item)

        Activity

        Hide
        Eric Gearhart added a comment -

        I should also note that I've only experienced this issue with SNMPv3

        Show
        Eric Gearhart added a comment - I should also note that I've only experienced this issue with SNMPv3
        Hide
        Oleksiy Zagorskyi added a comment -

        A bit related issue ZBX-4284

        I'd agree that wrong SNMPv3 credentials (if they can be detected properly) should not be considered as the "network error", but should go to an unsupported state.

        p.s. I suppose Eric meant the unsupported state namely but not the disabled state.

        Show
        Oleksiy Zagorskyi added a comment - A bit related issue ZBX-4284 I'd agree that wrong SNMPv3 credentials (if they can be detected properly) should not be considered as the "network error", but should go to an unsupported state. p.s. I suppose Eric meant the unsupported state namely but not the disabled state.
        Hide
        Alexei Vladishev added a comment -

        Unfortunately it's impossible to detect that SNMP get failed due to wrong credentials. SNMP response is exactly the same in case of timeout and wrong user name/password.

        Standard snmpwalk/snmpget utilities work similarly.

        Show
        Alexei Vladishev added a comment - Unfortunately it's impossible to detect that SNMP get failed due to wrong credentials. SNMP response is exactly the same in case of timeout and wrong user name/password. Standard snmpwalk/snmpget utilities work similarly.
        Hide
        richlv added a comment -

        reopening, as snmpv3 does provide different responses (as opposed to v1/v2c)

        Show
        richlv added a comment - reopening, as snmpv3 does provide different responses (as opposed to v1/v2c)
        Hide
        Eric Gearhart added a comment -

        I knew I wasn't crazy when I opened this I originally though that the mismatched auth/priv password issue was directly causing this issue, but I agree, I remember thinking that they were separate issues

        Show
        Eric Gearhart added a comment - I knew I wasn't crazy when I opened this I originally though that the mismatched auth/priv password issue was directly causing this issue, but I agree, I remember thinking that they were separate issues
        Hide
        Alexander Vladishev added a comment -

        Fixed in the development branch svn://svn.zabbix.com/branches/dev/ZBX-5414

        Show
        Alexander Vladishev added a comment - Fixed in the development branch svn://svn.zabbix.com/branches/dev/ZBX-5414
        Hide
        richlv added a comment -

        user-friendly description of the new behaviour would be appreciated

        Show
        richlv added a comment - user-friendly description of the new behaviour would be appreciated
        Hide
        Andris Mednis added a comment - - edited

        Successfully tested.

        SNMPv3 authentification uses 3 elements:

        • security name,
        • auth passphrase,
        • priv passphrase.

        If "SNMPv3 security name" is wrong:

        • Item status becomes "Not supported",
        • Item error is like "Could not connect to "xxxxx:161": Unknown user name".

        If "SNMPv3 security name" is correct, but "SNMPv3 auth passphrase" is wrong:

        • Item status becomes "Not supported",
        • Item error is like "Could not connect to "xxxxx:161": Authentication failure (incorrect password, community or key)".

        If both "SNMPv3 security name" and "SNMPv3 auth passphrase" are correct, but "SNMPv3 priv passphrase" is wrong:

        • Item status remains "Enabled",
        • Zabbix server logfile shows a message like "4504:20120928:110144.681 SNMP item [xxxxx] on host [xxxxxxxx] failed: first network error, wait for 15 seconds".
        • after some time the host will be marked as unavailable.

        <richlv> great, mentioned in http://www.zabbix.com/documentation/2.0/manual/introduction/whatsnew204#daemon_improvements
        assumed this will go in 2.0.4

        Show
        Andris Mednis added a comment - - edited Successfully tested. SNMPv3 authentification uses 3 elements: security name, auth passphrase, priv passphrase. If "SNMPv3 security name" is wrong: Item status becomes "Not supported", Item error is like "Could not connect to "xxxxx:161": Unknown user name". If "SNMPv3 security name" is correct, but "SNMPv3 auth passphrase" is wrong: Item status becomes "Not supported", Item error is like "Could not connect to "xxxxx:161": Authentication failure (incorrect password, community or key)". If both "SNMPv3 security name" and "SNMPv3 auth passphrase" are correct, but "SNMPv3 priv passphrase" is wrong: Item status remains "Enabled", Zabbix server logfile shows a message like "4504:20120928:110144.681 SNMP item [xxxxx] on host [xxxxxxxx] failed: first network error, wait for 15 seconds". after some time the host will be marked as unavailable. <richlv> great, mentioned in http://www.zabbix.com/documentation/2.0/manual/introduction/whatsnew204#daemon_improvements assumed this will go in 2.0.4
        Hide
        Alexander Vladishev added a comment -

        Fixed in pre-2.0.4 r30508 and pre-2.1.0 (trunk) r30509.

        Show
        Alexander Vladishev added a comment - Fixed in pre-2.0.4 r30508 and pre-2.1.0 (trunk) r30509.

          People

          • Assignee:
            Unassigned
            Reporter:
            Eric Gearhart
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: