Hi Dave,
I tried using the debug flags you provided and the output is really
surprising... I tried to run the getnext on
"udpLocalPort.134.56.72.221.123" and it fails at ifTable??
I used the command
/usr/sbin/snmpd -Lo -p /var/run/snmpd.pid -f -I-ifTable
-I-udpEndpointTable
-DudpEndpointTable,verbose:udpEndpointTable,internal:udpEndpointTable
-Daccess:udp_endpoint,text:util:tvi -DALL
.................................
snmp_agent: tp->start
SNMPv2-SMI::transmission.131.1.1.1.1.1, tp->end
SNMPv2-SMI::transmission.131.1.1.1.1.2snmp_agent: tp->start
SNMPv2-SMI::transmission.131.1.1.1.1.1, tp->end
SNMPv2-SMI::transmission.131.1.1.1.1.2,
,...........................................
netsnmp_call_handlers():
agent_handler.c, 510:
handler:calling: handler:calling: main
handler bulk_to_next
main handler bulk_to_next
trace: trace: netsnmp_call_handler():
agent_handler.c, 430:
netsnmp_call_handler():
agent_handler.c, 430:
handler:calling: handler:calling:
calling handler bulk_to_next for mode GETNEXT
calling handler bulk_to_next for mode
GETNEXT
trace: trace: netsnmp_call_handler():
agent_handler.c,PuTTYPuTTY 438:
netsnmp_call_handler():
agent_handler.c, 438:
handler:returned: handler:returned:
handler bulk_to_next returned 0
handler bulk_to_next returned 0
trace: trace: netsnmp_call_handler():
agent_handler.c, 430:
netsnmp_call_handler():
agent_handler.c, 430:
handler:calling: handler:calling:
calling handler old_api for mode GETNEXT
calling handler old_api for mode
GETNEXT
trace: trace: var_tunnelIfEntry():
tunnel/tunnel.c, 799:
var_tunnelIfEntry(): tunnel/tunnel.c,
799:
tunnel: var_tunnelIfEntry:
UDP-MIB::udpEntry.3tunnel: var_tunnelIfEntry: UDP-MIB::udpEntry.3 0
0
updateTunnels(): looking for new
index=1
updateTunnels(): looking for new
index=1
trace: trace: ifTable_index_to_oid():
if-mib/ifTable/ifTable_interface.c, 432:
ifTable_index_to_oid():
if-mib/ifTable/ifTable_interface.c, 432:
verbose:ifTable:ifTable_index_to_oid:
verbose:ifTable:ifTable_index_to_oid: called
called
trace: trace: build_oid_noalloc():
mib.c, 3571:
build_oid_noalloc(): mib.c, 3571:
build_oid_noalloc: generated:
isobuild_oid_noalloc: generated: iso
PuTTYPuTTYSegmentation fault (core
dumped)
I would like to mention I do override the ifTable and ifXTable
functionality in my subagent code..and we use Net SNMP 5.4.2.1.
While overriding the ifTable and ifXTable, I used mib2c and MFD to
generate the code and the subagent code works fine.
And also tried to exclude the udpEndpointTable, and I still see the
segfault and the same output.
Thanks for your help again.
Regards,
Malathi
________________________________
From: Dave Shield <[email protected]>
To: Malathi Panyam <[email protected]>
Cc: [email protected]
Sent: Wed, March 31, 2010 12:05:19 PM
Subject: Re: Seg fault when querying for the UDP table
On 31 March 2010 17:26, Malathi Panyam <[email protected]> wrote:
> Here is the response for the getnext queries;
> 1. snmpwalk for "snmp" is fine
Good.
> 2. snmpgetnext .... udpLocalPort.134.56.72.221.123
> snmpgetnext .... udpEntry.3
> snmpgetnext .... udpEndpointProcess
> All the above three requests result in a segfault.
That's what I half-expected.
The problem therefore lies in the udpEndpointTable.
(Which is not too surprising, since this is relatively new code)
Please start the agent using the following debug flags:
-DudpEndpointTable,verbose:udpEndpointTable,internal:udpEndpointTable
-Daccess:udp_endpoint,text:util:tvi
and re-run any of the GetNext commands above.
What debug output does the agent display before it crashes?
> As a side note we dont support the "egp" in our code..
That's fine.
If there's nothing in the agent code to implement these objects,
then there's no code that can crash the agent.
The problem will almost certainly lie in the udpEndpointTable code.
If you want to confirm this, then run the agent using "-I-udpEndpointTable".
This should then be able to walk the udpTable successfully.
Dave
------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Net-snmp-users mailing list
[email protected]
Please see the following page to unsubscribe or change other options:
https://lists.sourceforge.net/lists/listinfo/net-snmp-users
