On 19 October 2010 16:42, Leo Lin <hayashi_...@yahoo.com> wrote:
> you are correct, table.c is not the source of the problem.
> However, I don't understand why snmpd hangs on AlarmDescription.2 on conf.c
It doesn't.
The client application (snmpwalk or snmpgetnext) issues a GETNEXT request
on alarmDescription.2. The agent is therefore being asked to return the
*NEXT* value that it knows about - i.e. whatever comes after alarmDescription.2
There isn't anything else left inside table1, so control then passes to the next
module within the OID tree. In this case, it's table2.
table2 is then asked for the first entry that it knows about.
Something about this request then hangs.
You'd see exactly the same effect if you asked for
GETNEXT table1Entry.column999
or
GETNEXT table1Table.2
or
GETNEXT table1Table.999
or
GETNEXT table2Table
or
GETNEXT table2Entry
All of these are asking for the next instance after the specified OID,
i.e. the first column entry from table2.
Remember, the SNMP protocol doesn't know (or care) about the boundaries
between different groups, tables, columns, etc. It just works with a sequence
of OIDs, which can be ordered, but are otherwise all equivalent.
Dave
------------------------------------------------------------------------------
Download new Adobe(R) Flash(R) Builder(TM) 4
The new Adobe(R) Flex(R) 4 and Flash(R) Builder(TM) 4 (formerly
Flex(R) Builder(TM)) enable the development of rich applications that run
across multiple browsers and platforms. Download your free trials today!
http://p.sf.net/sfu/adobe-dev2dev
_______________________________________________
Net-snmp-users mailing list
Net-snmp-users@lists.sourceforge.net
Please see the following page to unsubscribe or change other options:
https://lists.sourceforge.net/lists/listinfo/net-snmp-users
