snmpwalk in a threaded agent

[Jasvant Singh]

Hi James,

I have highlighted two lines in the log which seems to create the
problem.
You have received the request 1567562870 but you are trying to answer
request #30 also.
Since this request does not exist it can't be answered. check from where
request #30 is being answered.
It can be caused by multithreading try disabling threads.
It looks like you are trying to answer the request yourself by calling
RequestList::answer()
you should not do that. You should just call MibLeaf::get_request()
instead of answering request yourself.
I think you are doing both. The request passed to you is not same as
received.
That's way it contain a different request id. This number is just a
counter of number of requests received by agent.

Another Tip: You can define BEGIN_LOG() to contain  printf("F>%s
L>%d\n",__FILE__,__LINE__);
this will print filename and line number before every log. It will make
debugging easier.

Regards,
Jasvant.

"Nakamura, James" wrote:

> I'm still working my way through getting my agent to work with an
> snmpwalk.
> The setup is a process talking via a tcp
> socket to my agent (using the agent++ library). I have it set up with
> threads to handle the fact that data is being
> passed asynchronously through the tcp socket. Anyway, when I do a
> snmpwalk,
> it gets through all of the snmp
> oids, but when it hits the first mib object that I create, it (or
> something)
> gets confused: the logs indicate that
> the data that needed to be exchanged between the process and the agent
>
> occured correctly, with the following
> sequence is logged (meccmib is the derived mib object):
>
> 20010227.16:15:13: 01493: (2)EVENT  : RequestList: request received
> (id)(siz)(fro)(ver)(com): (1567562870), (1), (206.64.210.9/48262),
> (SNMPv1),
> (public).
> 20010227.16:15:13: 01493: (6)EVENT  : main: GOT MIB REQUEST.
> 20010227.16:15:13: 01527: (2)EVENT  : Agent: starting thread
> execution.
> 20010227.16:15:13: 01527: (2)EVENT  : Mib: process request: getnext
> request,
> oid: (30), (1.3.6.1.2.1.11.32.0).
> 20010227.16:15:13: 01527: (3)EVENT  : Mib: process subrequest: getnext
>
> request, oid: (30), (1.3.6.1.2.1.11.32.0).
> 20010227.16:15:13: 01527: (6)EVENT  : meccmib(get_request)::
> (MCDN.MCDN.REG_COUNT).
> 20010227.16:15:13: 01527: (6)EVENT  : DataFromProcess: got data: :
> (VMCDN.MCDN.REG_COUNT=0 ), (23).
> 20010227.16:15:13: 01527: (6)EVENT  : DataFromProcess:MibData::
> (MCDN.MCDN.REG_COUNT=0).
> 20010227.16:15:13: 01527: (6)EVENT  : DataFromProcess:calling handle
> request.
> 20010227.16:15:13: 01527: (6)EVENT  : meccmib(handle_request from
> meccano)::
> (MCDN.MCDN.REG_COUNT=0).
> 20010227.16:15:13: 01527: (3)EVENT  : RequestList: finished
> subrequest::
> (0), (1.3.6.1.4.1.1102.1.3.6.30), (0).
> 20010227.16:15:13: 01527: (2)EVENT  : RequestList: answer request:
> (30).
> 20010227.16:15:13: 01527: (4)EVENT  : RequestList: request answered:
> (1567562870), (30), (206.64.210.9/48262), (0), (0).
> 20010227.16:15:13: 01527: (1)ERROR  : RequestList: done: can't find
> request
> id: (30).
> 20010227.16:15:13: 01527: (2)EVENT  : Agent: finished thread
> execution.
>
> The disturbing line is the "can't find request id" which implies that
> the
> request object got blasted along the way.
> It's interesting to note that the "request answered" deletes the
> request
> after the conclusion which probably is
> the reason why the request is no longer available. Why is the library
> now
> trying to access an object that appears
> to have been freed? Is there something amiss in the way I built my mib
>
> objects (and placed them into the tree)?
>
> The effect is that the snmpwalk only gets to the snmp data and then
> stops
> without getting any of the process
> specific data. Any ideas what's going on here?
>
> James Nakamura
> naka at metricom.com
> Work like you don't need the money. Love like you've never been hurt.
> Dance
> like nobody is watching. -- Mark Twain
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.agentpp.org/pipermail/agentpp/attachments/20010228/bd0b8237/attachment.htm