Hi Bill, I applied and tested the 4 patches from your repo branch V5-7-fix-view-filtering (c6c2fe8, c44b8b0, 7339109, 8be0fe1) and they do indeed fix my problem.
Thanks! --Sam (I'll add a note in my bug and carry the patches until they hit V5-7-patches) On Tue, Oct 4, 2016 at 9:26 PM, Bill Fenner <fen...@gmail.com> wrote: > Sam, > > I have two "big ideas" here; one is already published so, can you run your > test case against the code here: > > https://github.com/fenner/net-snmp/tree/V5-7-fix-view-filtering > > The diffs are > https://github.com/fenner/net-snmp/compare/V5-7-travis...fenner:V5-7-fix-view-filtering > > The other "big idea" has to do with NETSNMP_PRIV_RETRY and the inclusive > flag; there's a fair bit of discussion on this topic in the bug database and > on this list in the past. That code is tangled up with something much > bigger that I'm attempting, though, so isn't as easily shared. > > Bill > > > On Wed, Sep 21, 2016 at 10:51 AM, Sam Tannous <stann...@gmail.com> wrote: >> >> 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 >> > ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot _______________________________________________ Net-snmp-coders mailing list Net-snmp-coders@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
