Hi,
If I fix all the problems, do you want to merge this patch into master?
zhuyj
On 07/11/2013 05:29 PM, zhuyj wrote:
> 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
