Home/Support/Support Forum/SNMP problem setting name (and maybe other strings)
Welcome to Digi Forum, where you can ask questions and receive answers from other members of the community.

SNMP problem setting name (and maybe other strings)

0 votes
Running Net+OS7.4.1 (fully patched) on ME9210, with SNMP V1/2c enabled. My code sets the various 'system' strings (name, description, location, contact) and starts the SNMP agent. I found it wasn't returning these strings to my SNMP client, so added code to get and print out these strings. All the strings printed out correctly, but naSnmpGetSysName() returns error NA_SNMP_NO_MEMORY - "Failure to allocate memory for the agent global variables" (and it still returns the correct name string).
There was no error returned when I initially set the variables. I also have plenty of free RAM - about 3.5M if I read the return from NABspGetHeapSnapshot() correctly.

The strange thing is that basically identical code worked fine in another application written on NET+O/S 7.1 for the ME - so looks like some functionality change between the two versions, or possibly a subtle difference between ME and ME9210 platforms.

Anyone else encountered this?

Update: even if the strings are never changed from defaults, naSnmpGetSysName() returns error NA_SNMP_NO_MEMORY.
Also, naSnmpGetIfDescr("eth0", tempBuf); returns NASTATUS_SNMP_GENERAL_ERROR, which is unhelpful!

As a separate issue, has anyone found where to set the size of the SNMP agent stack? I might be getting a bit near the bone on that, as well.

Message was edited by: steved
asked Apr 2, 2009 in NET+OS by steved1 Community Contributor (85 points)
recategorized Dec 18, 2013 by tuxembb

Please log in or register to answer this question.

4 Answers

0 votes
I've been playing with this some more, on both ME and ME9210, and with both my application, a test harness, and the Digi namib example. In most cases, consistent, apparently incorrect, bahaviour.

It appears that the MIB-II ifTable.ifEntry.ifDescr fields aren't set up on NET+O/S 7.4.1. Reading with a tree browser, on 7.1 these fields are set to 'LOOPBACK' and 'eth0', which seems very reasonable. However, on 7.4.1 I get a variety of answers, ranging from empty strings, through what looks like garbage/uninitialised RAM, to not being able to read the whole tree because the application crashes when attempting to return ifDescr.

Any thoughts?
answered Apr 3, 2009 by steved1 Community Contributor (85 points)
0 votes

Thank you for reporting this issue. This is a bug. It is being addressed and will be in a patch to NET+OS V7.4.2 available by the end of of the month.
answered Apr 3, 2009 by sparkys_dad Community Contributor (99 points)
0 votes
Thanks for the info - I can stop wondering where my code's going wrong now.

Its a pity there isn't a list of outstanding bugs published - could have saved me a lot of time.
answered Apr 3, 2009 by steved1 Community Contributor (85 points)
0 votes
In the meantime, is there any workaround to stop the ME crashing? Attempting to read the ifDescr fields in the mib-II subtree sometimes crashes the processor - presumably because an overlong string is returned
answered Apr 6, 2009 by steved1 Community Contributor (85 points)