Hi,
something is wrong with these modifications. The root cause is that
strdup handles string as normal string. We should rewrite strdup function.
@@ -325,7 +326,8 @@ notifyTable_register_notifications(int major, int minor,
return 0;
}
ptr = snmpTargetAddrTable_create();
- ptr->name = strdup(buf);
+ ptr->nameData = strdup(buf);
+ ptr->nameLen = bufLen;
memcpy(ptr->tDomain, t->domain, t->domain_length * sizeof(oid));
ptr->tDomainLen = t->domain_length;
ptr->tAddressLen = t->remote_length;
@@ -334,8 +336,8 @@ notifyTable_register_notifications(int major, int minor,
ptr->timeout = ss->timeout / 1000;
ptr->retryCount = ss->retries;
SNMP_FREE(ptr->tagList);
- ptr->tagList = strdup(ptr->name);
- ptr->params = strdup(ptr->name);
+ ptr->tagList = strdup(buf);
+ ptr->params = strdup(buf);
ptr->storageType = ST_READONLY;
ptr->rowStatus = RS_ACTIVE;
ptr->sess = ss;
zhuyj
On 07/11/2013 01:50 PM, zhuyj wrote:
> 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
