Using GDB, I found out that when netsnmp_iquery_pdu_session() derived from v2c pdu, check_access() returned errorcode=1 which causes handle_snmp_packet() to drop the GET request of the pdu. See the GDB results below.
Breakpoint 6, check_access (pdu=0x100f7590) at agent_registry.c:1465
1465 return view_parms.errorcode;
(gdb) p view_parms
$14 = {pdu = 0x100f7590, name = 0x0, namelen = 0, test = 2142282752,
errorcode = 1,
check_subtree = 0}
(gdb) p *view_parms.pdu
$15 = {version = 1, command = 160, reqid = 127671010, msgid = 155649372,
transid = 0,
sessid = 0, errstat = 0, errindex = 0, time = 0, flags = 0, securityModel
= -1,
securityLevel = 0, msgParseModel = 0, transport_data = 0x10171788,
transport_data_length = 4, tDomain = 0x0, tDomainLen = 0, variables =
0x101c5730,
community = 0x1015e628 "private", community_len = 7, enterprise = 0x0,
enterprise_length = 0, trap_type = 0, specific_type = 0, agent_addr =
"\000\000\000",
contextEngineID = 0x0, contextEngineIDLen = 0, contextName = 0x0,
contextNameLen = 0,
securityEngineID = 0x0, securityEngineIDLen = 0, securityName = 0x0,
securityNameLen = 0, priority = 0, range_subid = 0, securityStateRef =
0x0}
(gdb) bt
#0 check_access (pdu=0x100f7590) at agent_registry.c:1465
#1 0x0fe5d1a4 in handle_snmp_packet (op=1, session=0x100190f8,
reqid=127671010,
pdu=0x100ec668, magic=0x0) at snmp_agent.c:1795
#2 0x0fd68ab8 in _sess_process_packet (sessp=0x10018e18, sp=0x100190f8,
isp=0x100190c0, transport=0x10017f28, opaque=0x10168250, olength=4,
packetptr=0x10125fa0 "\017-_è\017-_è", length=1) at snmp_api.c:5346
#3 0x0fd69e68 in _sess_read (sessp=0x10018e18, fdset=0x7fb0a600) at
snmp_api.c:5759
#4 0x0fd69f00 in snmp_sess_read (sessp=0x10018e18, fdset=0x7fb0a600) at
snmp_api.c:5778
#5 0x0fd68c5c in snmp_read (fdset=0x7fb0a600) at snmp_api.c:5398
#6 0x0fd3a70c in snmp_synch_response_cb (ss=0x101c3dd8, pdu=0x100ef9c0,
response=0x7fb0a7f8, pcb=0xfd38944 <snmp_synch_input>) at
snmp_client.c:1036
#7 0x0fd3a92c in snmp_synch_response (ss=0x101c3dd8, pdu=0x100ef9c0,
response=0x7fb0a7f8) at snmp_client.c:1077
#8 0x0fd3aec4 in _query (list=0x101c3430, request=160, session=0x101c3dd8)
at snmp_client.c:1226
#9 0x0fd3b074 in netsnmp_query_get (list=0x101c3430, session=0x101c3dd8)
at snmp_client.c:1286
#10 0x0fed9928 in alarmTable_run (reg=8, clientarg=0x101c3898)
at mibgroup/Rmon/alarmTable.c:176
#11 0x0fd944a0 in run_alarms () at snmp_alarm.c:252
#12 0x10004b74 in receive () at snmpd.c:1186
#13 0x10004120 in main (argc=4, argv=0x7fb0ade4) at snmpd.c:1001
Emi
Yanagi/Radisys_Co
rporation/US To
Wes Hardaker
05/22/2007 11:51 <[EMAIL PROTECTED]>
AM cc
[EMAIL PROTECTED]
et
Subject
Re: New Rmon alarmTable implemented
(Document link: Emi Yanagi)
Hi Wes,
I submitted 1723611 for the new RMON alarmTable code. I also have some
update bug report on netsnmp_iquery_pdu_session().
I changed to use netsnmp_iquery_pdu_session() instead of
netsnmp_iquery_user_session() by switching #if 0 to 1 at the end of
alarmTable.c.
(See attached file: alarmTable.c)
It seems netsnmp_iquery_pdu_session() only works with pdu of
SNMP_VERSION_3, the following sequence works fine to generate alarmRising
notification.
snmpset -v3 -ufoo 10.1 eventStatus.1 i 2
snmpset -v3 -ufoo 10.1 eventStatus.1 i 1
snmpset -v3 -ufoo 10.1 eventType.1 i 4
snmpset -v3 -ufoo 10.1 alarmStatus.1 i 3
snmpset -v3 -ufoo 10.1 alarmVariable.1 o ifInOctets.3
snmpset -v3 -ufoo 10.1 alarmStatus.1 i 1
But it doesn't work with pdu of SNMP_VERSION_2c, the following sequence
caused infinite loop.
snmpset -v2c -cprivate 10.1 eventStatus.1 i 2
snmpset -v2c -cprivate 10.1 eventStatus.1 i 1
snmpset -v2c -cprivate 10.1 eventType.1 i 4
snmpset -v2c -cprivate 10.1 alarmStatus.1 i 3
snmpset -v2c -cprivate 10.1 alarmVariable.1 o ifInOctets.3
snmpset -v2c -cprivate 10.1 alarmStatus.1 i 1
Since the debug log(attached at the end of the email) looks so similar to
internal query for delegated objects, only this time it is not delegated
object but the query session is derived from SNMP_VERSION_2c pdu, I suspect
there may be some problem in internal query session creation.
Emi Yanagi
-------- Debug log --------------------------------------
sess_select: for all sessions: 13 (to in 1179849204.71662 sec) 11 10 9 8 5
6 3
sess_select: next alarm 0.1 sec
verbose:sess_select: timer due *real* soon. 1 usec
verbose:sess_select: setting timer to 0.1 sec, clear block (was 1)
sess_read: not reading 13 (fdset 0x7fc1a540 set 0)
sess_read: not reading 11 (fdset 0x7fc1a540 set 0)
sess_read: not reading 10 (fdset 0x7fc1a540 set 0)
sess_read: not reading 9 (fdset 0x7fc1a540 set 0)
sess_read: not reading 8 (fdset 0x7fc1a540 set 0)
sess_read: not reading 5 (fdset 0x7fc1a540 set 0)
sess_read: not reading 6 (fdset 0x7fc1a540 set 0)
snmp_agent: agent_sesion 0x1010c530 created
verbose:asp: asp 0x1010c530 reqinfo 0x100f5e98 created
snmp_agent: REMOVE session == 0x1010c530
snmp_agent: agent_session 0x1010c530 released
verbose:asp: asp 0x1010c530 reqinfo 0x100f5e98 freed
sess_select: for all sessions: 13 (to in 1179849204.71662 sec) 11 10 9 8 5
6 3
sess_select: next alarm 0.1 sec
verbose:sess_select: timer due *real* soon. 1 usec
verbose:sess_select: setting timer to 0.1 sec, clear block (was 1)
sess_select: for all sessions: 13 (to in 1179849204.71662 sec) 11 10 9 8 5
6 3
sess_select: next alarm 0.1 sec
verbose:sess_select: timer due *real* soon. 1 usec
verbose:sess_select: setting timer to 0.1 sec, clear block (was 1)
Wes Hardaker
<[EMAIL PROTECTED]
ourceforge.net> To
[EMAIL PROTECTED]
05/22/2007 11:29 cc
AM [EMAIL PROTECTED]
et
Subject
Re: New Rmon alarmTable implemented
>>>>> "EY" == Emi Yanagi <[EMAIL PROTECTED]> writes:
EY> I would like to contribute my alarmTable code to net-snmp-coders,
EY> in hoping to receive some helps from Net-SNMP experts to resolve
EY> the internal query for delegated objects problem, also reported in
EY> net-snmp-Bugs-1689163.
Thanks very much for contributing to the rmon code! It certainly
needed work.
If possible, please always submit your patches to our patch database
so we can properly track them and ensure we can't forget about it!
http://www.net-snmp.org/patches/
--
Wes Hardaker
Sparta, Inc.
alarmTable.c
Description: Binary data
------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/
_______________________________________________ Net-snmp-coders mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
