Hi,
in snprintf, we do not consider that 0 is in nameData. strdup(cptr) does
not include that 0 is in cptr.
So we should rewrite this.
@@ -372,7 +366,8 @@ snmpTargetAddr_addName(struct targetAddrTable_struct
*entry, char *cptr)
"ERROR snmpTargetAddrEntry: name out of range
in config string\n"));
return (0);
}
- entry->name = strdup(cptr);
+ entry->nameData = strdup(cptr);
+ entry->nameLen = len;
}
return (1);
} /* addName */
@@ -666,7 +661,7 @@ snmpd_parse_config_targetAddr(const char *token,
char *char_ptr)
return;
}
snprintf(buff, sizeof(buff), "snmp_parse_config_targetAddr, read:
%s\n",
- newEntry->name);
+ newEntry->nameData);
buff[ sizeof(buff)-1 ] = 0;
for (i = 0; i < newEntry->tDomainLen; i++) {
snprintf(&buff[strlen(buff)], sizeof(buff)-strlen(buff)-1,
@@ -711,7 +706,7 @@ store_snmpTargetAddrEntry(int majorID, int minorID,
void *serverarg,
(curr_struct->rowStatus == SNMP_ROW_ACTIVE ||
curr_struct->rowStatus == SNMP_ROW_NOTINSERVICE)) {
snprintf(line, sizeof(line),
- "targetAddr %s ", curr_struct->name);
+ "targetAddr %s ", curr_struct->nameData);
line[ sizeof(line)-1 ] = 0;
for (i = 0; i < curr_struct->tDomainLen; i++) {
snprintf(&line[strlen(line)],
zhuyj
On 07/10/2013 07:17 PM, zhuyj wrote:
> 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
