Next host poll fail

[Tough]

Hi.
I have problem with poll next host after someone. Running spine from command line give me such result for two variants (files in attach).

play with amount of threads without results.

any ideas?

[gandalf]

Does this happen even when switching to SNMP V2 od V1?
Reinhard

[Tough]

under SNMP V2, all look ok

[gandalf]

Which set of SNMP V3 parameters are you using? Please do NOT post exact values
Reinhard

[Tough]

auth: MD5
privacy: DES
Privacy Passphrase: nou use
target hosts configure with use view

spine
timeout: 500
maxOIDs: 10
threads: 15


what more data interest for you?

[gandalf]

Will try to verify at home
Reinhard

[Tough]

I Have several hosts with LEAF (leaf.sourceforge.net) and several with Fedora. While the hosts only with Fedora a enabled into polling, there are no problems. But when the LEAF hosts are enabled too, trouble begin.
LEAF hosts split in two groups. In first group only the first host reply to SNMP query.
Work of hosts of second group is normal. Version and configuration of SNMP of hosts from both group are the same.

rouser StatsCollector

# rwuser: a SNMPv3 read-write user
# arguments: user [noauth|auth|priv] [restriction_oid]
#
# rouser _rw_auth_user_ auth system
# rouser _rw_noauth_user_ noauth system
# rouser _rw_priv_user_ priv all

# rwcommunity: a SNMPv1/SNMPv2c read-write access community name
# arguments: community [default|hostname|network/bits] [oid]
#
# rwcommunity _rw_Private_Community_Name_ default system

# rocommunity: a SNMPv1/SNMPv2c read-only access community name
# arguments: community [default|hostname|network/bits] [oid]
#
#rocommunity public default
#rwcommunity public


# -----------------------------------------------------------------------------
# snmpd supports the View-Based Access Control Model (vacm) as defined
# in RFC 2275. To this end, it recognizes the following keywords in the
# configuration file: com2sec, group, access, and view. See:
# <http://net-snmp.sourceforge.net/FAQ.htm ... ss_control_>
# -----------------------------------------------------------------------------


####
# First, map the community name (COMMUNITY) into a security name
# (local and mynetwork, depending on where the request is coming
# from). NOTE: First match wins!
#
# sec.name source community
#com2sec paranoid default _ltd_Private_Community_Name_
com2sec paranoid default public
com2sec readonly default dddd
#com2sec readwrite default _rw_Private_Community_Name_


####
# Second, map the security names into group names:
#
# groupName sec.model sec.name
group RO_Group usm readonly
group RO_Group usm StatsCollector
group RO_Group v1 readonly
group RO_Group v2c readonly
group RO_System usm paranoid
group RO_System v1 paranoid
group RO_System v2c paranoid
group RW_Group usm readwrite
group RW_Group v1 readwrite
group RW_Group v2c readwrite


####
# Third, create a view for us to let the groups have rights to:
#
# name incl/excl subtree mask (optional)
view all included .1
#view system included .iso.org.dod.internet.mgmt.mib-2.system
view system included .1.3.6.1.2.1.1


####
# Finally, grant the 2 groups access to the 1 view with different
# write permissions:
#
# group context sec.model sec.level match read write notif
access RO_System "" any noauth exact system none none
access RO_Group "" any noauth exact all none none
access RW_Group "" any noauth exact all all none


# -----------------------------------------------------------------------------


101-m1.seti.kr.ua# snmpd -v

NET-SNMP version: 5.3.1
Web: http://www.net-snmp.org/
Email: net-snmp-coders@lists.sourceforge.net