Hello folks,
Run into a nasty issue with the snmp daemon in 3.5U4 (with all current patches), namely that a get-bulk request from OpenNMS causes the daemon to panic with a floating point exception.
dumph_recv: Name
dumpx_recv: 06 09 2B 06 01 04 01 8F 65 04 0B
dumpv_recv: ObjID: UCD-SNMP-MIB::memTotalFree
trace: snmp_pdu_parse(): snmp_api.c, 4231
dumph_recv: Value
trace: snmp_pdu_parse(): snmp_api.c, 4222
dumph_recv: VarBind
trace: snmp_parse_var_op(): snmp.c, 151
dumph_recv: Name
dumpx_recv: 06 09 2B 06 01 04 01 8F 65 04 0D
dumpv_recv: ObjID: UCD-SNMP-MIB::memShared
trace: snmp_pdu_parse(): snmp_api.c, 4231
dumph_recv: Value
trace: init_agent_snmp_session(): snmp_agent.c, 921
snmp_agent: agent_sesion 0x8944f38 created
trace: snmp_call_callbacks(): callback.c, 99
callback: START calling callbacks for maj=1 min=5
trace: snmp_call_callbacks(): callback.c, 107
callback: calling a callback for maj=1 min=5
trace: vacm_in_view(): mibII/vacm_vars.c, 724
mibII/vacm_vars: vacm_in_view: ver=1, community=public
trace: netsnmp_udp_getSecName(): snmpUDPDomain.c, 712
netsnmp_udp_getSecName: resolve <"public", 0x0314960a>
trace: netsnmp_udp_getSecName(): snmpUDPDomain.c, 717
netsnmp_udp_getSecName: compare <"public", 0x0314960a/0xffffffff>... SUCCESS
trace: netsnmp_subtree_find_first(): agent_registry.c, 144
subtree: looking for subtree for context: ""
trace: netsnmp_subtree_find_first(): agent_registry.c, 148
subtree: found one for: ""
trace: vacm_in_view(): mibII/vacm_vars.c, 830
mibII/vacm_vars: vacm_in_view: sn=anonymousSecName000, gn=anonymousGroupName000, Done checking setup
trace: snmp_call_callbacks(): callback.c, 119
callback: END calling callbacks for maj=1 min=5 (1 called)
Floating point exception
Has anyone else encountered this before? I've trimmed the .conf file down to pretty much 'allow this community from this IP' - both the HP agent and the VMware agent have been commented out, so this is bare-bones snmpd.