net-snmp fails to create entries with a zero in the OID

[zhuyj]

Hi,

Attempting to create a new entry with a zero index fails silently.

root@localhost:/root> snmpset -v 2c -c public 192.168.2.15
.1.3.6.1.6.3.12.1.2.1.9.0.25 i 5
SNMP-TARGET-MIB::snmpTargetAddrRowStatus.'..' = INTEGER: createAndWait(5)
root@localhost:/root> snmpget -v 2c -c NETMAN 192.168.2.15
.1.3.6.1.6.3.12.1.2.1.9.0.25 i 5
snmp_build: unknown failuresnmpget: Error building ASN.1 representation
(Can't build OID for variable)

Notice that there is no error when setting, only when trying to get.

The version:

usr@ubuntu1004:~$ snmpset --version
NET-SNMP version: 5.7.2
usr@ubuntu1004:~$ snmpget --version
NET-SNMP version: 5.7.2
usr@ubuntu1004:~$ snmpd --version

NET-SNMP version: 5.7.2
Web: http://www.net-snmp.org/
Email: net-snm...@lists.sourceforge.net

I want to support 0.25 in snmpAdminString. What should I pay attention to?

Best regards.

zhuyj

------------------------------------------------------------------------------
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-snm...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders

[zhuyj]

On 07/10/2013 10:34 AM, zhuyj wrote:
> Hi,
>
> Attempting to create a new entry with a zero index fails silently.
>
> root@localhost:/root> snmpset -v 2c -c public 192.168.2.15
> .1.3.6.1.6.3.12.1.2.1.9.0.25 i 5
> SNMP-TARGET-MIB::snmpTargetAddrRowStatus.'..' = INTEGER: createAndWait(5)
> root@localhost:/root> snmpget -v 2c -c NETMAN 192.168.2.15
> .1.3.6.1.6.3.12.1.2.1.9.0.25 i 5
> snmp_build: unknown failuresnmpget: Error building ASN.1
> representation (Can't build OID for variable)
>
> Notice that there is no error when setting, only when trying to get.
>
> The version:
>
> usr@ubuntu1004:~$ snmpset --version
> NET-SNMP version: 5.7.2
> usr@ubuntu1004:~$ snmpget --version
> NET-SNMP version: 5.7.2
> usr@ubuntu1004:~$ snmpd --version
>
> NET-SNMP version: 5.7.2
> Web: http://www.net-snmp.org/
> Email: net-snm...@lists.sourceforge.net
>
> I want to support 0.25 in snmpAdminString. What should I pay attention
> to?
>
> Best regards.
>
> zhuyj
>

agent/mibgroup/target/snmpTargetAddrEntry.c: snmpTargetAddr_createNewRow

...
for (i = 0; i < (int) newNameLen; i++) {
temp_struct->name[i] = (char) name[i + snmpTargetAddrOIDLen];
}

temp_struct->name[newNameLen] = '\0';
temp_struct->rowStatus = SNMP_ROW_NOTREADY;
...
After name is set 0.25, 0 is set as terminated. So there are two 0
(NULL) in a string.
So 0.25 can not be found.
I want to fix this. But how should I do?
If I fix this, will this fix take effect other mib files?
I search snmpTarget. And I found that SNMP-COMMUNITY-MIB.txt，SNMP-
NOTIFICATION-MIB.txt，DISMAN-EVENT- MIB.txt，SNMP-PROXY-MIB.txt depend
on it.
Anyone can discuss this with me?

Zhuyj

[zhuyj]

I want to modify the temp_struct->name to 32,
then memset(temp_struct->name, -1 ,32 );
when this name is set, it will not end with 0 (NUL).
when snmpget or snmpwalk is executed, it will parse this 32 bytes
string. When -1 is confronted, it will end.
the string before -1 is returned.

Can the above method work?

Zhu Yanjun

[zhuyj]

I have 2 concerns about this:
1. this file is generated from mib2c. Is it appropriate to modify like
this?
2. Many mibs are based on this file. Will this fix affect other mibs?

Zhuyj

[Niels Baggesen]

On Wed, Jul 10, 2013 at 10:34:05AM +0800, zhuyj wrote:
> root@localhost:/root> snmpset -v 2c -c public 192.168.2.15
> .1.3.6.1.6.3.12.1.2.1.9.0.25 i 5
> SNMP-TARGET-MIB::snmpTargetAddrRowStatus.'..' = INTEGER: createAndWait(5)
> root@localhost:/root> snmpget -v 2c -c NETMAN 192.168.2.15
> .1.3.6.1.6.3.12.1.2.1.9.0.25 i 5
> snmp_build: unknown failuresnmpget: Error building ASN.1 representation
> (Can't build OID for variable)
>
> Notice that there is no error when setting, only when trying to get.

That is natural. You are setting one object to the value 5, but you
are trying to get 3 objects, 1.3.6.1.6.3.12.1.2.1.9.0.25, i, and 5.

snmpget complains that it cannot build the ASN.1 representation for the
object 5, which is quite correct as the first element of an object
identifier must be 0 or 1.

What you want is just

snmpget -v 2c -c NETMAN 192.168.2.15 .1.3.6.1.6.3.12.1.2.1.9.0.25

I admit that the error message could have been clearer.

/Niels

--
Niels Baggesen - @home - Århus - Denmark - n...@users.sourceforge.net
The purpose of computing is insight, not numbers --- R W Hamming

[zhuyj]

On 07/10/2013 01:41 PM, Niels Baggesen wrote:

On Wed, Jul 10, 2013 at 10:34:05AM +0800, zhuyj wrote:

root@localhost:/root> snmpset -v 2c -c public 192.168.2.15 
.1.3.6.1.6.3.12.1.2.1.9.0.25 i 5
SNMP-TARGET-MIB::snmpTargetAddrRowStatus.'..' = INTEGER: createAndWait(5)
root@localhost:/root> snmpget -v 2c -c NETMAN 192.168.2.15 
.1.3.6.1.6.3.12.1.2.1.9.0.25 i 5
snmp_build: unknown failuresnmpget: Error building ASN.1 representation 
(Can't build OID for variable)

Notice that there is no error when setting, only when trying to get.

That is natural. You are setting one object to the value 5, but you
are trying to get 3 objects, 1.3.6.1.6.3.12.1.2.1.9.0.25, i, and 5.

snmpget complains that it cannot build the ASN.1 representation for the
object 5, which is quite correct as the first element of an object
identifier must be 0 or 1.

What you want is just
snmpget -v 2c -c NETMAN 192.168.2.15 .1.3.6.1.6.3.12.1.2.1.9.0.25

I admit that the error message could have been clearer.

/Niels

Sorry. Maybe I am wrong with the command.

These command can work well.

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.8.25 i 5

SNMP-TARGET-MIB::snmpTargetAddrRowStatus.'..' = INTEGER: createAndWait(5)

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.8.25 -Ofn
.1.3.6.1.6.3.12.1.2.1.9.8.25 = INTEGER: notReady(3)

But these command can not work.

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$ snmpget -v 2c -c NETMAN 127.0.0.1 .1.3.6.1.6.3.12.1.2.1.9.0.25 -Ofn
.1.3.6.1.6.3.12.1.2.1.9.0.25 = No Such Instance currently exists at this OID

The difference is in OID. One is .1.3.6.1.6.3.12.1.2.1.9.8.25, the other is .1.3.6.1.6.3.12.1.2.1.9.0.25.
.1.3.6.1.6.3.12.1.2.1.9.8.25 can work
.1.3.6.1.6.3.12.1.2.1.9.0.25 can not work.

Zhuyj

[zhuyj]

Hi, all

In OID .1.3.6.1.6.3.12.1.2.1.9.0.25, 0.25 is snmpTargetAddrName. The following is its definition.

snmpTargetAddrName OBJECT-TYPE
    SYNTAX      SnmpAdminString (SIZE(1..32))
    MAX-ACCESS  not-accessible
    STATUS      current
    DESCRIPTION
        "The locally arbitrary, but unique identifier associated
         with this snmpTargetAddrEntry."
    ::= { snmpTargetAddrEntry 1 }

The type of snmpTargetAddrName is SnmpAdminString.
The definition of SnmpAdminString is:
SnmpAdminString ::= TEXTUAL-CONVENTION
    DISPLAY-HINT "255t"
    STATUS       current
    DESCRIPTION "An octet string containing administrative
                 information, preferably in human-readable form.

                 To facilitate internationalization, this
                 information is represented using the ISO/IEC
                 IS 10646-1 character set, encoded as an octet
                 string using the UTF-8 transformation format
                 described in [RFC2279].

                 Since additional code points are added by
                 amendments to the 10646 standard from time
                 to time, implementations must be prepared to
                 encounter any code point from 0x00000000 to
                 0x7fffffff.  Byte sequences that do not
                 correspond to the valid UTF-8 encoding of a
                 code point or are outside this range are
                 prohibited.

                 The use of control codes should be avoided.

                 When it is necessary to represent a newline,
                 the control code sequence CR LF should be used.

                 The use of leading or trailing white space should
                 be avoided.

                 For code points not directly supported by user
                 interface hardware or software, an alternative
                 means of entry and display, such as hexadecimal,
                 may be provided.

                 For information encoded in 7-bit US-ASCII,
                 the UTF-8 encoding is identical to the
                 US-ASCII encoding.

                 UTF-8 may require multiple bytes to represent a
                 single character / code point; thus the length
                 of this object in octets may be different from
                 the number of characters encoded.  Similarly,
                 size constraints refer to the number of encoded
                 octets, not the number of characters represented
                 by an encoding.

                 Note that when this TC is used for an object that
                 is used or envisioned to be used as an index, then
                 a SIZE restriction MUST be specified so that the
                 number of sub-identifiers for any object instance
                 does not exceed the limit of 128, as defined by
                 [RFC3416].

                 Note that the size of an SnmpAdminString object is
                 measured in octets, not characters.
                "
    SYNTAX       OCTET STRING (SIZE (0..255))

In its definition, it mentions "The use of control codes should be avoided.". In rfc20, 0 (NUL) is
control code.
So it can not used in snmpAdminString as normal codes.
Can we explain it like this?

Best Regards!
Zhuyj

[zhuyj]

Anyone likes to discuss it with me?

[Magnus Fromreide]

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

> root@localhost:/root> snmpset -v 2c -c public 192.168.2.15
> .1.3.6.1.6.3.12.1.2.1.9.0.25 i 5
> SNMP-TARGET-MIB::snmpTargetAddrRowStatus.'..' = INTEGER: createAndWait(5)
> root@localhost:/root> snmpget -v 2c -c NETMAN 192.168.2.15
> .1.3.6.1.6.3.12.1.2.1.9.0.25 i 5
> snmp_build: unknown failuresnmpget: Error building ASN.1 representation
> (Can't build OID for variable)
>
> Notice that there is no error when setting, only when trying to get.
>

> The version:
>
> usr@ubuntu1004:~$ snmpset --version
> NET-SNMP version: 5.7.2
> usr@ubuntu1004:~$ snmpget --version
> NET-SNMP version: 5.7.2
> usr@ubuntu1004:~$ snmpd --version
>
> NET-SNMP version: 5.7.2
> Web: http://www.net-snmp.org/
> Email: net-snm...@lists.sourceforge.net
>
> I want to support 0.25 in snmpAdminString. What should I pay attention to?
>
> Best regards.
>
> zhuyj
>

[zhuyj]

OK. Thanks a lot.
I will make tests about this.

Zhuyj

[zhuyj]

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,

I found that SNMP-COMMUNITY-MIB.txt，SNMP- NOTIFICATION-MIB.txt，DISMAN-

EVENT- MIB.txt，SNMP-PROXY-MIB.txt depend on snmpTargetMIB.txt.
Does this patch make difference on the above mibs?

Zhuyj

[zhuyj]

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.
Maybe it is better?
How about you?

[Magnus Fromreide]

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

[Niels Baggesen]

On Wed, Jul 10, 2013 at 10:53:30AM +0200, Magnus Fromreide wrote:
> 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.

You should probably replace the strdup's with memdup's ?

/Niels

--
Niels Baggesen -- @home -- Århus -- Denmark -- ni...@baggesen.net
The purpose of computing is insight, not numbers -- R W Hamming

[zhuyj]

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
>
>

[zhuyj]

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

[zhuyj]

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)

[zhuyj]

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

[zhuyj]

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

[zhuyj]

Hi, Magnus && Niels

Thanks for your help! I am testing your patch. This patch can solve the
most problems.
But Ihave a question, is this a bug? I mean that '0' in snmpAdminString
is a bug, or not?
Would you like to discuss this with me?

zhuyj

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
>

>> root@localhost:/root> snmpset -v 2c -c public 192.168.2.15

>> .1.3.6.1.6.3.12.1.2.1.9.0.25 i 5
>> SNMP-TARGET-MIB::snmpTargetAddrRowStatus.'..' = INTEGER: createAndWait(5)

>> root@localhost:/root> snmpget -v 2c -c NETMAN 192.168.2.15
>> .1.3.6.1.6.3.12.1.2.1.9.0.25 i 5
>> snmp_build: unknown failuresnmpget: Error building ASN.1 representation
>> (Can't build OID for variable)
>>
>> Notice that there is no error when setting, only when trying to get.
>>
>> The version:
>>
>> usr@ubuntu1004:~$ snmpset --version
>> NET-SNMP version: 5.7.2
>> usr@ubuntu1004:~$ snmpget --version
>> NET-SNMP version: 5.7.2
>> usr@ubuntu1004:~$ snmpd --version
>>
>> NET-SNMP version: 5.7.2
>> Web: http://www.net-snmp.org/
>> Email: net-snm...@lists.sourceforge.net
>>
>> I want to support 0.25 in snmpAdminString. What should I pay attention to?
>>
>> Best regards.
>>
>> zhuyj
>>

[zhuyj]

Hi,

If I fix all the problems, do you want to merge this patch into master?

zhuyj

>>> .1.3.6.1.6.3.12.1.2.1.9.0.25 i 5
>>> SNMP-TARGET-MIB::snmpTargetAddrRowStatus.'..' = INTEGER:
>>> createAndWait(5)

>>>>>>> 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
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>

[Bill Fenner]

On Thu, Jul 11, 2013 at 6:39 AM, zhuyj <zyjzy...@gmail.com> wrote:

Hi, Magnus && Niels

Thanks for your help! I am testing your patch. This patch can solve the
most problems.
But Ihave a question, is this a bug? I mean that '0' in snmpAdminString
is a bug, or not?
Would you like to discuss this with me?

I think it's worth exploring.  I think the most relevant part of the definition has already been quoted in this thread:

                 The use of control codes should be avoided.

So, even though the previous paragraph says

                 ... implementations must be prepared to
                 encounter any code point from 0x00000000 ...

 

and you are finding that there is a problem with net-snmp's implementation using code point 0x00000000, you are using a code point that "should be avoided".  In other words, net-snmp may be wrong, but your use is also (very nearly) wrong.

Are you going to be using any systems other than net-snmp?  Implementing this string with a NUL-terminated C string, which causes the bug that you're seeing, is pretty likely to be a common implementation strategy inside SNMP servers, so you're reasonably likely to run into this problem in other contexts, which you may not be able to fix by submitting a patch.

Implementing counted-string support inside net-snmp is a fine thing to do, but identifying and changing all of the places that it needs to be used could be a pretty big task.  Is it easier to change your usage model and pick a different value (for this string that is supposed to be "preferably in human-readable form"?)

  Bill

zhuyj

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
>

>> root@localhost:/root> snmpset -v 2c -c public 192.168.2.15

>> .1.3.6.1.6.3.12.1.2.1.9.0.25 i 5
>> SNMP-TARGET-MIB::snmpTargetAddrRowStatus.'..' = INTEGER: createAndWait(5)

>> root@localhost:/root> snmpget -v 2c -c NETMAN 192.168.2.15
>> .1.3.6.1.6.3.12.1.2.1.9.0.25 i 5
>> snmp_build: unknown failuresnmpget: Error building ASN.1 representation
>> (Can't build OID for variable)
>>
>> Notice that there is no error when setting, only when trying to get.
>>
>> The version:
>>
>> usr@ubuntu1004:~$ snmpset --version
>> NET-SNMP version: 5.7.2
>> usr@ubuntu1004:~$ snmpget --version
>> NET-SNMP version: 5.7.2
>> usr@ubuntu1004:~$ snmpd --version
>>
>> NET-SNMP version:  5.7.2
>> Web:               http://www.net-snmp.org/
>> Email:             net-snm...@lists.sourceforge.net
>>
>> I want to support 0.25 in snmpAdminString. What should I pay attention to?
>>
>> Best regards.
>>
>> zhuyj
>>