zabbixlog.txt
[ZBX-2174] snmp poller bug with different snmp versions Created: 2010 Mar 15 Updated: 2017 May 30 Resolved: 2010 Apr 13 |
|
| Status: | Closed |
| Project: | ZABBIX BUGS AND ISSUES |
| Component/s: | None |
| Affects Version/s: | 1.8.1 |
| Fix Version/s: | 1.8.3, 1.9.0 (alpha) |
| Type: | Incident report | Priority: | Major |
| Reporter: | svenw | Assignee: | Unassigned |
| Resolution: | Won't fix | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Attachments: |
zabbixlog.txt
|
| Description |
|
i have a device that does only support snmp v1. most of the items were configured snmpv1 agent, but at least one was misconfigured as v2. this one item misconfigured broke the whole snmp checks of this host. it seems like a poller tried to connect with this first item trying v2, failing and giving up on the whole issue, instead of traeting the v1/v2 items seperately |
| Comments |
| Comment by Aleksandrs Saveljevs [ 2010 Apr 12 ] |
|
Hi, Thank you for the bug report! We could not, however, reproduce the issue in our environment. We have configured two items on SNMP v1 host: one as SNMP v1 item and the other one as SNMP v2 item. The SNMP v2 item correctly became "Not supported", but the server continued to check the SNMP v1 item. We would appreciate more details on the issue. For instance, how exactly the SNMP checks were broken? Did the whole host become "Not monitored"? Or, maybe, nothing changed, just SNMP items stopped updating, even though they were still "Active"? Did SNMP v2 item become "Not supported"? A log with DebugLevel=4 might be useful, too. Aleksandrs |
| Comment by svenw [ 2010 Apr 12 ] |
|
hi there, well, i was just able to reproduce this. running on 1.8.1 i disabled all but one host, on this host disabled snmpv2 so only snmpv1 works since then i dont get any new data setting this single item back to snmpv1 gives me all the data of all the other checks again. |
| Comment by Aleksandrs Saveljevs [ 2010 Apr 12 ] |
|
The issue is still not reproducible in our environment, but based on the log file we have confirmed our suspicions as to the cause of the problem. Thank you! |
| Comment by Aleksandrs Saveljevs [ 2010 Apr 13 ] |
|
The problem was that when server connected to SNMPv1 host with an SNMPv2 check, the connection failed with a timeout. Server treated it as a network error and deactivated (all items for) that host. In other words, server cannot distinguish between our SNMPv1/SNMPv2 case and a real network problem. With NET-SNMP version 5.4.1 we could not reproduce it: as mentioned above, server immediately received "Error in packet Reason: authorizationError (access denied to that object)", marked the item as "Not supported", and proceeded with the other items. We could, however, reproduce the same problem by specifying an incorrect community string in an SNMP item. That is, if a user specifies an incorrect community string in an item (regardless of whether it is misconfigured as SNMPv2 or not), the connection will fail with a timeout, and the problem described in this issue is observed. However, not replying to an incorrect community string seems to be a security feature of SNMP, so there is little that can be done about it. Thus, won't fix. |
| Comment by Aleksandrs Saveljevs [ 2010 Apr 13 ] |
|
Fixed a small memory leak in SNMP checks in pre-1.8.3 in r11463. |
| Comment by Caio arcanjo [ 2010 Nov 10 ] |
|
I found the solution to this problem. I'm using Zabbix 1.8.2 on Slackware 13.1 (x86). My research showed that the native version of Slackware libnetsnmp.so (libnetsnmp.so.20) could be incompatible with binaries Zabbix. Decided to look for other versions. Try unpacking the RPM below. Worked with me, will work with you. http://www.rpmfind.net/linux/rpm2html/search.php?query=libnetsnmp.so.10 |