Hi
name is .0.25.1, we can not snmpwalk it. But .3.25.1, we can snmpwalk it.
Maybe it is related with 0. I will look into it.
zhuyj
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.3.25.1 i 5
SNMP-TARGET-MIB::snmpTargetAddrRowStatus.'...' = INTEGER: createAndWait(5)
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.3.25 = INTEGER: notReady(3)
.1.3.6.1.6.3.12.1.2.1.9.3.25.1 = 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)
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.3.25 = INTEGER: notReady(3)
.1.3.6.1.6.3.12.1.2.1.9.3.25.1 = 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 i 5
SNMP-TARGET-MIB::snmpTargetAddrRowStatus.'..' = INTEGER: createAndWait(5)
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.3.25 = INTEGER: notReady(3)
.1.3.6.1.6.3.12.1.2.1.9.3.25.1 = 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.2 i 5
SNMP-TARGET-MIB::snmpTargetAddrRowStatus.'...' = INTEGER: createAndWait(5)
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.3.25 = INTEGER: notReady(3)
.1.3.6.1.6.3.12.1.2.1.9.3.25.1 = INTEGER: notReady(3)
On 07/10/2013 07:02 PM, zhuyj wrote:
> 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
