SNMP problem setting name (and maybe other strings)

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

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?

Hello

 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.

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.

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