I found this while comparing the debugs for the working case (where I
include
"view systemonly included .1.3.6.1.2.1.4.1") the looping case where I
do not include
this:
In the working case, we see this (vacm:getView: , found...) and
we end up at "snmp_agent.c, 3300:" where we break out of that loop:
----
trace: vacm_check_view_contents(): mibgroup/mibII/vacm_conf.c, 1300:
mibII/vacm_vars: vacm_in_view: ver=1, community=public
trace: netsnmp_udp_getSecName(): transports/snmpUDPDomain.c, 425:
netsnmp_udp_getSecName: opaque = 0x13fdd00 (len = 60), sizeof = 60, family
= 2 (2)
trace: netsnmp_udp_getSecName(): transports/snmpUDPDomain.c, 442:
netsnmp_udp_getSecName: resolve <"public", 0x0100007f>
trace: netsnmp_udp_getSecName(): transports/snmpUDPDomain.c, 452:
netsnmp_udp_getSecName: compare <"public", 0.0.0.0/0.0.0.0>... SUCCESS
trace: netsnmp_subtree_find_first(): agent_registry.c, 313:
subtree: looking for subtree for context: ""
trace: netsnmp_subtree_find_first(): agent_registry.c, 317:
subtree: found one for: ""
trace: vacm_check_view_contents(): mibgroup/mibII/vacm_conf.c, 1431:
mibII/vacm_vars: vacm_in_view: sn=comm1, gn=grpcomm1, vn=systemonlytrace:
netsnmp_view_get(): vacm.c, 492:
vacm:getView: , found
, vt=1
trace: snmp_call_callbacks(): callback.c, 370:
callback: END calling callbacks for maj=1 min=0 (1 called)
trace: _callback_unlock(): callback.c, 170:
9:callback:lock: unlocked (APP,null)
trace: netsnmp_handle_request(): snmp_agent.c, 3300:
results: request results (status = 0):
trace: netsnmp_handle_request(): snmp_agent.c, 3303:
results: IP-MIB::ipForwarding.0 = INTEGER: forwarding(1)
trace: _snmp_build(): snmp_api.c, 2918:
snmp_send: Building SNMPv2 message...
trace: _snmp_build(): snmp_api.c, 2921:
dumph_send: RESPONSE
trace: snmp_pdu_realloc_rbuild(): snmp_api.c, 3288:
snmp_pdu_realloc_rbuild: starting
trace: snmp_pdu_realloc_rbuild(): snmp_api.c, 3303:
dumph_send: VarBind
trace: snmp_realloc_rbuild_var_op(): snmp.c, 339:
dumph_send: Value
dumpx_send: 02 01 01
dumpv_send: Integer: 1 (0x01)
trace: snmp_realloc_rbuild_var_op(): snmp.c, 440:
dumph_send: Name
dumpx_send: 06 08 2B 06 01 02 01 04 01 00
dumpv_send: ObjID: IP-MIB::ipForwarding.0
--------
And in the non-working case where we loop, we see
"vacm:getView: , none:" and we loop at "snmp_agent.c, 3123":
----
trace: vacm_check_view_contents(): mibgroup/mibII/vacm_conf.c, 1300:
mibII/vacm_vars: vacm_in_view: ver=1, community=public
trace: netsnmp_udp_getSecName(): transports/snmpUDPDomain.c, 425:
netsnmp_udp_getSecName: opaque = 0x1663860 (len = 60), sizeof = 60, family
= 2 (2)
trace: netsnmp_udp_getSecName(): transports/snmpUDPDomain.c, 442:
netsnmp_udp_getSecName: resolve <"public", 0x0100007f>
trace: netsnmp_udp_getSecName(): transports/snmpUDPDomain.c, 452:
netsnmp_udp_getSecName: compare <"public", 0.0.0.0/0.0.0.0>... SUCCESS
trace: netsnmp_subtree_find_first(): agent_registry.c, 313:
subtree: looking for subtree for context: ""
trace: netsnmp_subtree_find_first(): agent_registry.c, 317:
subtree: found one for: ""
trace: vacm_check_view_contents(): mibgroup/mibII/vacm_conf.c, 1431:
mibII/vacm_vars: vacm_in_view: sn=comm1, gn=grpcomm1, vn=systemonlytrace:
netsnmp_view_get(): vacm.c, 492:
vacm:getView: , none
trace: snmp_call_callbacks(): callback.c, 370:
callback: END calling callbacks for maj=1 min=0 (1 called)
trace: _callback_unlock(): callback.c, 170:
9:callback:lock: unlocked (APP,null)
trace: handle_getnext_loop(): snmp_agent.c, 3123:
results: getnext results, before next pass:
trace: handle_getnext_loop(): snmp_agent.c, 3126:
results: trace: sprint_realloc_by_type(): mib.c, 2008:
output: sprint_by_type, type 199
trace: sprint_realloc_by_type(): mib.c, 2068:
sprint_by_type: bad type: 199
IP-MIB::ipForwarding.0 = Wrong Type (should be INTEGER): Variable has bad
type
trace: netsnmp_add_varbind_to_cache(): snmp_agent.c, 2015:
snmp_agent: add_vb_to_cache(0x16636c0, 1, IP-MIB::ipForwarding.0, 0x14db6e0)
trace: _callback_lock(): callback.c, 136:
9:callback:lock: locked (APP,null)
trace: snmp_call_callbacks(): callback.c, 344:
callback: START calling callbacks for maj=1 min=12
trace: snmp_call_callbacks(): callback.c, 358:
callback: calling a callback for maj=1 min=12
trace: vacm_check_view_contents(): mibgroup/mibII/vacm_conf.c, 1300:
mibII/vacm_vars: vacm_in_view: ver=1, community=public
trace: netsnmp_udp_getSecName(): transports/snmpUDPDomain.c, 425:
netsnmp_udp_getSecName: opaque = 0x1663860 (len = 60), sizeof = 60, family
= 2 (2)
trace: netsnmp_udp_getSecName(): transports/snmpUDPDomain.c, 442:
netsnmp_udp_getSecName: resolve <"public", 0x0100007f>
trace: netsnmp_udp_getSecName(): transports/snmpUDPDomain.c, 452:
netsnmp_udp_getSecName: compare <"public", 0.0.0.0/0.0.0.0>... SUCCESS
trace: netsnmp_subtree_find_first(): agent_registry.c, 313:
subtree: looking for subtree for context: ""
trace: netsnmp_subtree_find_first(): agent_registry.c, 317:
subtree: found one for: ""
trace: vacm_check_view_contents(): mibgroup/mibII/vacm_conf.c, 1431:
mibII/vacm_vars: vacm_in_view: sn=comm1, gn=grpcomm1, vn=systemonly
trace: netsnmp_view_subtree_check(): vacm.c, 531:
9:vacm:checkSubtree: view systemonly
trace: netsnmp_view_subtree_check(): vacm.c, 616:
9:vacm:checkSubtree:
systemonly matched?
trace: netsnmp_view_subtree_check(): vacm.c, 629:
9:vacm:checkSubtree: systemonly matched
trace: netsnmp_view_subtree_check(): vacm.c, 646:
vacm:checkSubtree: , unknown
trace: snmp_call_callbacks(): callback.c, 370:
callback: END calling callbacks for maj=1 min=12 (1 called)
trace: _callback_unlock(): callback.c, 170:
9:callback:lock: unlocked (APP,null)
trace: netsnmp_add_varbind_to_cache(): snmp_agent.c, 2090:
snmp_agent: tp->start IP-MIB::ipForwarding, tp->end IP-MIB::ipDefaultTTL,
trace: netsnmp_add_varbind_to_cache(): snmp_agent.c, 2110:
verbose:asp: asp 0x16636c0 reqinfo 0x164faf0 assigned to request
trace: netsnmp_add_varbind_to_cache(): snmp_agent.c, 2119:
verbose:asp: asp 0x16636c0 reqinfo 0x164faf0 assigned to request
trace: netsnmp_call_handlers(): agent_handler.c, 625:
handler:calling: main handler bulk_to_next
trace: netsnmp_call_handler(): agent_handler.c, 541:
handler:calling: calling handler bulk_to_next for mode GETNEXT
trace: netsnmp_call_handler(): agent_handler.c, 549:
handler:returned: handler bulk_to_next returned 0
trace: netsnmp_call_handler(): agent_handler.c, 541:
handler:calling: calling handler serialize for mode GETNEXT
trace: netsnmp_serialize_helper_handler(): helpers/serialize.c, 69:
helper:serialize: Got request
trace: netsnmp_call_handler(): agent_handler.c, 541:
handler:calling: calling handler scalar for mode GETNEXT
trace: netsnmp_scalar_helper_handler(): helpers/scalar.c, 178:
helper:scalar: Got request:
trace: netsnmp_scalar_helper_handler(): helpers/scalar.c, 184:
helper:scalar: oid:IP-MIB::ipForwarding.0
trace: netsnmp_call_handler(): agent_handler.c, 541:
handler:calling: calling handler instance for mode GETNEXT
trace: netsnmp_instance_helper_handler(): helpers/instance.c, 776:
helper:instance: Got request:
trace: netsnmp_instance_helper_handler(): helpers/instance.c, 781:
helper:instance: oid:IP-MIB::ipForwarding.0
trace: netsnmp_call_handler(): agent_handler.c, 541:
handler:calling: calling handler ipForwarding for mode GET
trace: netsnmp_call_handler(): agent_handler.c, 549:
handler:returned: handler ipForwarding returned 0
trace: netsnmp_call_handler(): agent_handler.c, 549:
handler:returned: handler instance returned 0
trace: netsnmp_call_handler(): agent_handler.c, 549:
handler:returned: handler scalar returned 0
trace: netsnmp_call_handler(): agent_handler.c, 549:
handler:returned: handler serialize returned 0
trace: _callback_lock(): callback.c, 136:
9:callback:lock: locked (APP,null)
trace: snmp_call_callbacks(): callback.c, 344:
callback: START calling callbacks for maj=1 min=0
trace: snmp_call_callbacks(): callback.c, 358:
callback: calling a callback for maj=1 min=0
trace: vacm_check_view_contents(): mibgroup/mibII/vacm_conf.c, 1300:
mibII/vacm_vars: vacm_in_view: ver=1, community=public
trace: netsnmp_udp_getSecName(): transports/snmpUDPDomain.c, 425:
netsnmp_udp_getSecName: opaque = 0x1663860 (len = 60), sizeof = 60, family
= 2 (2)
trace: netsnmp_udp_getSecName(): transports/snmpUDPDomain.c, 442:
netsnmp_udp_getSecName: resolve <"public", 0x0100007f>
trace: netsnmp_udp_getSecName(): transports/snmpUDPDomain.c, 452:
netsnmp_udp_getSecName: compare <"public", 0.0.0.0/0.0.0.0>... SUCCESS
trace: netsnmp_subtree_find_first(): agent_registry.c, 313:
subtree: looking for subtree for context: ""
trace: netsnmp_subtree_find_first(): agent_registry.c, 317:
subtree: found one for: ""
trace: vacm_check_view_contents(): mibgroup/mibII/vacm_conf.c, 1431:
mibII/vacm_vars: vacm_in_view: sn=comm1, gn=grpcomm1, vn=systemonlytrace:
netsnmp_view_get(): vacm.c, 492:
vacm:getView: , none
trace: snmp_call_callbacks(): callback.c, 370:
callback: END calling callbacks for maj=1 min=0 (1 called)
trace: _callback_unlock(): callback.c, 170:
9:callback:lock: unlocked (APP,null)
trace: handle_getnext_loop(): snmp_agent.c, 3123:
results: getnext results, before next pass:
trace: handle_getnext_loop(): snmp_agent.c, 3126:
results: trace: sprint_realloc_by_type(): mib.c, 2008:
output: sprint_by_type, type 199
trace: sprint_realloc_by_type(): mib.c, 2068:
sprint_by_type: bad type: 199
IP-MIB::ipForwarding.0 = Wrong Type (should be INTEGER): Variable has bad
type
---
And in looking at the MIBs themselves, I see that the
IP-MIB (ip from mib-2 4) defines an ipForwarding object as { ip 1 }
an ipDefaultTTL ( ip 2 } skips to ipReasmTimeout { ip 13 }...and skips over
to ipv6IpForwarding { ip 25 }.
ipForward is actually found in a different mib IP-FORWARD-MIB::ipForward
{ ip 24 }. So even though this MIB explicitly imports ip from IP-MIB,
maybe this is
where the registration breaks down.
Is it possible that an explicit
"view systemonly included .1.3.6.1.2.1.4.1 "
must be included in order to see a a table from a different (but related)
MIB IP-FORWARD-MIB::ipForward?
It seems that only a
"view systemonly included .1.3.6.1.2.1.4.24"
is not enough to register the IP-FORWARD-MIB::ipForward table.
(I hesitated in attaching the logs as the working case is 10M and the
nonworking
case is 24M).
--Sam
On Tue, Sep 20, 2016 at 12:56 PM, Sam Tannous <stann...@gmail.com> wrote:
> No message in the logs....and increasing the timeout doesn't help.
> The daemon is off in la-la land...
>
> My forwarding file is empty:
>
> ----
> root@debian-stable:/home/stannous# cat /proc/sys/net/ipv4/conf/all/
> forwarding
> 0
> root@debian-stable:/home/stannous# netstat -rn
> Kernel IP routing table
> Destination Gateway Genmask Flags MSS Window irtt
> Iface
> 0.0.0.0 10.50.10.1 0.0.0.0 UG 0 0 0
> eth0
> 10.50.0.11 10.50.10.1 255.255.255.255 UGH 0 0 0
> eth0
> 10.50.10.0 0.0.0.0 255.255.255.0 U 0 0 0
> eth0
> 169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0
> eth0
> root@debian-stable:/home/stannous#
> ----------
>
> The problem seems to be only in the implementation of 1.3.6.1.2.1.3
> (The address translation table: 1.3.6.1.2.1.3)
>
> If I skip this part of the walk (add 1.3.6.1.2.1.2 and skip directly to
> 1.3.6.1.2.1.4.24, e.g.
>
> view systemonly included .1.3.6.1.2.1.1
> view systemonly included .1.3.6.1.2.1.2
> view systemonly included .1.3.6.1.2.1.4.24
>
> I do not see snmpd hanging.
> I'm poking around in agent/mibgroup/mibII/at.c.
>
> Thanks,
>
>
> On Tue, Sep 20, 2016 at 8:52 AM, Robert Story <rst...@freesnmp.com> wrote:
>
>> On Wed, 7 Sep 2016 14:07:42 -0400 Sam wrote:
>> ST> Any ideas on how to resolve this? The problem seems to be
>> ST> in "transitioning" from one mib to the next.
>> ST>
>> ST> On Mon, Jan 25, 2016 at 4:32 PM, Sam Tannous <stann...@users.sf.net>
>> wrote:
>> ST>
>> ST> > ------------------------------
>> ST> >
>> ST> > * [bugs:#2693] <http://sourceforge.net/p/net-snmp/bugs/2693/>
>> snmpwalk
>> ST> > causes snmpd hang and CPU spike*
>> ST> >
>> ST> > On latest debian (Jessie, snmpd 5.7.2.1, also seen on 5.7.3) we
>> noticed a
>> ST> > nasty bug where the snmpd
>> ST> > CPU spikes (to around 100%) and snmpd becomes completely
>> unresponsive.
>> ST> > Only way to recover is a restart.
>> ST> >
>> ST> > The problem appears to be in the transition (snmpwalk) from
>> .1.3.6.1.2.1.3
>> ST> > to .1.3.6.1.2.1.4
>> ST> >
>> ST> > The bug occurs only when we have "-V systemonly" on our community
>> string
>> ST> >
>> ST> > rocommunity public default -V systemonly
>> ST> >
>> ST> > *and* we expose these tables:
>> ST> >
>> ST> > view systemonly included .1.3.6.1.2.1.1
>> ST> > view systemonly included .1.3.6.1.2.1.2
>> ST> > view systemonly included .1.3.6.1.2.1.3
>> ST> > view systemonly included .1.3.6.1.2.1.4.24
>> ST> >
>> ST> > (Adding a view for .1.3.6.1.2.1.4.1 fixes this
>> problem!)
>> ST> >
>> ST> > The output we see before the freeze is this:
>> ST> >
>> ST> > root@jessie-1:/home/stannous# snmpwalk -v2c -cpublic localhost .1
>> ST> > ...
>> ST> > <output snipped>
>> ST> > ...
>> ST> > SNMPv2-SMI::mib-2.3.1.1.3.2.1.10.50.10.23 = IpAddress: 10.50.10.23
>> ST> > Timeout: No Response from localhost
>>
>> Does increasing the timeout help any? e.g.
>>
>> snmpgetnext -v2c -cpublic -r 0 -t 300 localhost \
>> SNMPv2-SMI::mib-2.3.1.1.3.2.1.10.50.10.23
>>
>> How big is the forwarding file?
>>
>> cat /proc/sys/net/ipv4/conf/all/forwarding | wc -l
>>
>> Any log messages in the log while it's spinning its wheels?
>>
>>
>> \
>> --
>> Robert
>>
>
>
------------------------------------------------------------------------------
_______________________________________________
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
