Hi, But snmpget can work well. user@ubuntu1004:~/net-snmp-5.7.2$ snmpget -v 2c -c NETMAN 127.0.0.1 .1.3.6.1.6.3.12.1.2.1.9.0.25.1 -Ofn .1.3.6.1.6.3.12.1.2.1.9.0.25.1 = INTEGER: notReady(3)
zhuyj On 07/10/2013 06:54 PM, zhuyj wrote: > Hi, > > After I applied this patch, the following is the test result. > When we made the name bigger than 2, we can not snmpwalk it. > I will look into it. > > Zhuyj > > user@ubuntu1004:~/net-snmp-5.7.2$ snmpwalk -v 2c -c NETMAN 127.0.0.1 > .1.3.6.1.6.3.12.1.2.1.9 -Ofn > .1.3.6.1.6.3.12.1.2.1.9.0.25 = INTEGER: notReady(3) > .1.3.6.1.6.3.12.1.2.1.9.2.26 = INTEGER: notReady(3) > .1.3.6.1.6.3.12.1.2.1.9.3.25 = INTEGER: notReady(3) > user@ubuntu1004:~/net-snmp-5.7.2$ snmpset -v 2c -c NETMAN 127.0.0.1 > .1.3.6.1.6.3.12.1.2.1.9.0.25.1 i 5 > SNMP-TARGET-MIB::snmpTargetAddrRowStatus.'...' = INTEGER: > createAndWait(5) > revo@ubuntu1004:~/net-snmp-5.7.2$ snmpwalk -v 2c -c NETMAN 127.0.0.1 > .1.3.6.1.6.3.12.1.2.1.9 -Ofn > .1.3.6.1.6.3.12.1.2.1.9.0.25 = INTEGER: notReady(3) > .1.3.6.1.6.3.12.1.2.1.9.2.26 = INTEGER: notReady(3) > .1.3.6.1.6.3.12.1.2.1.9.3.25 = INTEGER: notReady(3) > > On 07/10/2013 05:52 PM, Magnus Fromreide wrote: >> On Wed, 2013-07-10 at 17:41 +0800, zhuyj wrote: >>> On 07/10/2013 04:53 PM, Magnus Fromreide wrote: >>>> On Wed, 2013-07-10 at 10:34 +0800, zhuyj wrote: >>>>> Hi, >>>>> >>>>> Attempting to create a new entry with a zero index fails silently. >>>> Ok, You want to index your entry with the string <NUL><EM>. >>>> >>>> The mess up is, just as usual, that people believes that <NUL> is a >>>> string terminator. That is wrong. >>>> >>>> Your idea of using \xff as a string terminator is, while not wrong >>>> (\xff >>>> is forbidden in utf-8 strings), confusing for a casual reader of the >>>> code. >>>> >>>> The correct solution is to store the length of the passed in octet >>>> sequence. >>>> >>>> A completely untested patch against master is attached. >>>> >>>> Does it help you? >>>> >>>> Note - the rename of name to nameData and get_addrForName to >>>> get_addrForName2 was to make it easier to find unconverted code. >>>> >>>> /MF >>> Hi, >>> >>> A little modifications: >>> Can we store name_len in octect sequence? >>> struct targetAddrTable_struct { >>> - char *name; >>> + char *nameData; >>> + unsigned char nameLen; >>> oid tDomain[MAX_OID_LEN]; >>> int tDomainLen; >>> unsigned char *tAddress; >>> >>> I mean that we store nameLen in name[0]. Then we need not modify a lot >>> of source code. >> Wrong. >> >> One still have to modify all the source code that expects the name >> member to contain only the data and not the length. >> >>> Maybe it is better? >> I doubt it - less clear. The only way should be with some kind of >> "string class". >> >> /MF >> >> > > ------------------------------------------------------------------------------ See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk _______________________________________________ Net-snmp-coders mailing list Net-snmp-coders@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/net-snmp-coders