Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

SNMP request lets program crash

69 views
Skip to first unread message

Michael Jäger

unread,
May 12, 2011, 10:01:11 AM5/12/11
to
Hello Everyone,

I'm currently working on an snmp application, written in C, that requests
certain information from a device.
These requests contain OIDs of the LLDBMIB.

In order to request for different information I've created a function that
wraps
the Net-SNMP function 'snmp_synch_response(...)' called buildAndSend (see at
the bottom of this post).
This function allows for specifiying a textual representation of an
OID(char*) and also the net-snmp specific internal format (oid [])
and takes care of the rest that is necessary to send a request to the
network.

Recently, this function let the program crash, which seems to occur while
considering a specific device and a specific MIB entry.
While debugging the source code, I found out that the program crashes when
executing the function snmp_add_null_var.
After debugging deeper inside this function, the program crashes when the
function SNMP_MALLOC_TYPEDEF is called. (I can not
get any deeper when debugging.)

At that time I was specifying the internal oid format (oid[]) all the time
when sending an SNMP request.

The exact function call looked like this:
oid aulLSN[] = {1,0,8802,1,1,2,1,3,3,0};
netsnmp_pdu *ptResponse = buildAndSend(NULL, SNMP_MSG_GET, ptSess_handle,
aulLSN, 10);


After this problem occurred, I tried to specify the char* oid format.

netsnmp_pdu *ptResponse = buildAndSend("1.0.8802.1.1.2.1.3.3.0",
SNMP_MSG_GET, ptSess_handle, NULL, 0);

This time the program crashes when the function 'read_objid' is called,
which made me try adding the LLDPMIB
by using the functions '' add_mibdir' and 'read_mib', which unfortunately
did not work out.

Both times the program crashes when considering a certain device, but
obviously before the specific pdu is sent.
The same function calls work when considering other network devices; just
for the sake of clarification.

I've read that I can avoid using the char* oid representation when
specifying the internal oid format(oid []) directly, thats why my
'buildAndSend' function is structured like I explained.

Maybe I undstood something completely wrong when using the Net-snmp library
and maybe someone can point out some flaws
in my thought process which makes me find my error. :)

Thanks in advance, for any reply.


/**
* This function builds an SNMP pdu and sends it to the devices
based on the parameter *ptSess_handle.
* Sending an SNMP message is realized by using the Net-SNMP
library (http://www.net-snmp.org/).
* In order to determine what information is requested
by an SNMP request, an identifier, called OID, is used.
* The user is able to specify an OID in two ways.
Either as a char* version, or as an Net-SNMP library specific
* internal version.
* The char* version of an OID (provided via the
parameter *pchOID) is translated into internal format by
* the function read_objid(...). It is also possible to
pass the OID as the Net-SNMP library specific internal
* format via the parameter aulOidInternal[]. In that
case the parameter *pchOIDVarBind should be NULL.
*
*
* \param *pchOidVarBind The OID for an SNMP request
in char* format.
*
* \param iSnmpType Determines the type
of the snmp request, e.g. get, set, etc.
*
* \param ptSess_handle corresponds to the
previously established session with the station we want to talk to.
*
* \param aulOidInternal[] Net-SNMP library internal
format of oid which would be created through read_objid.
* This
can be avoided by directly providing an valid internal format of an oid.
* \param uOidInternal_length Length of the internal OID
format array.
*
* \return The response pdu received from the station we
communicated with.
*
*/

netsnmp_pdu *buildAndSend(const char *pchOid, int iSnmpType, netsnmp_session
*ptSess_handle, oid aulOidInternal[], size_t uOidInternal_length){
#ifdef FUNCCALLS
printf("sendMsg started\n");
printf("\n !! !! !! Request Data !! !! !!\n");
printf("Destination: %s\n", ptSess_handle->peername);
if(NULL == pchOid){
printf("pchOid == NULL\n");
printf("Current OID = ");
int iForIdx = 0;
for(iForIdx = 0; iForIdx < uOidInternal_length;
++iForIdx){
if(iForIdx != uOidInternal_length - 1){
printf("%i.", (int)
aulOidInternal[iForIdx]);
}else{
printf("%i\n", (int)
aulOidInternal[iForIdx]);
}
}

}else{
printf("pchOid != NULL\n");
printf("Current OID = %s", pchOid);
}

#endif


oid aulId_oid[MAX_OID_LEN]; // type = unsigned long
size_t uId_len = MAX_OID_LEN; //type = unsigned int

netsnmp_pdu *ptPduReq = NULL;
netsnmp_pdu *ptResponse = NULL;

ptPduReq = snmp_pdu_create(iSnmpType);

/*read_objid translates an oid in char format into an internal
format. If this is unnecessary, the function call read_objid will be
omitted.*/
if(NULL == pchOid){

int iForCnt = 0;
for(iForCnt = 0; iForCnt < uOidInternal_length; ++iForCnt){
aulId_oid[iForCnt] = aulOidInternal[iForCnt];
}

uId_len = uOidInternal_length;
}
else{read_objid(pchOid, aulId_oid, &uId_len);} //translating oid
into internal oid format (id_oid)
http://fixunix.com/snmp/324746-re-problems-read_objid.html

snmp_add_null_var(ptPduReq, aulId_oid, uId_len);
uId_len = MAX_OID_LEN; //reset id_len

/*PDU will be sent*/
int iStatus = snmp_synch_response(ptSess_handle, ptPduReq,
&ptResponse);


if(iStatus == 0){ //response received in ptResponse
#ifdef FUNCCALLS
printf("sendMsg finished\n");
#endif


return ptResponse;
}
/*Error handling*/
else{printf("Connection Error; status = %i\n", iStatus);}

return NULL;

}


------------------------------------------------------------------------------
Achieve unprecedented app performance and reliability
What every C/C++ and Fortran developer should know.
Learn how Intel has extended the reach of its next-generation tools
to help boost performance applications - inlcuding clusters.
http://p.sf.net/sfu/intel-dev2devmay
_______________________________________________
Net-snmp-coders mailing list
Net-snm...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders

0 new messages