IMHO val_len is not used for the purpose you mentioned.
Going over the parse_one_oid_index() code,
(In the 'ASN_PRIV_IMPLIED_OCTET_STR' case section)
I don't see how var->val_len is used to parse fixed-length strings.
It is assigned a new value before the old one is ever used.
********************************************
case ASN_PRIV_IMPLIED_OCTET_STR:
if (var->type == ASN_PRIV_IMPLIED_OCTET_STR) {
uitmp = *oidLen;
} else {
if (*oidLen) {
uitmp = *oidIndex++;
--(*oidLen);
} else {
uitmp = 0;
}
if ((uitmp > *oidLen) && (complete == 0))
return SNMPERR_GENERR;
}
/*
* we handle this one ourselves since we don't have
* pre-allocated memory to copy from using
* snmp_set_var_value()
*/
if (uitmp == 0)
break; /* zero length strings shouldn't malloc
*/
if (uitmp > MAX_OID_LEN)
return SNMPERR_GENERR; /* too big and illegal */
/*
* malloc by size+1 to allow a null to be appended.
*/
var->val_len = uitmp; // Erez Makavy: val_len is
overwritten, so it is never read from!
****************************************************
-----Original Message-----
From: Wes Hardaker [mailto:[EMAIL PROTECTED]
Sent: Wednesday, March 08, 2006 4:50 PM
To: Makavy, Erez (Erez)
Cc: Wes Hardaker; [email protected]
Subject: Re: Can parse_oid_indexes() parse fixed-length string indexes?
>>>>> On Wed, 8 Mar 2006 13:56:14 +0200, "Makavy, Erez (Erez)"
<[EMAIL PROTECTED]> said:
Erez> It looks like the ASN_PRIV_IMPLIED_OCTET_STR switch case, assumes
Erez> that the rest of the instance is the fixed length string (and it
Erez> does not look for a preceeding string length component).
Erez> But what if the instance includes some other index type after this
Erez> fix-length string?
If you set var->val_len as well it'll assume that this is the length of
the data you want to pull out. That should just remove a fixed size of
data.
Erez> By the way:
Erez> -----------------
Erez> I saw something that looks like a bug:
Erez> In the parse_one_oid_index() function (Net-SNMP 5.3.0.1):
Erez> *********************************************
Erez> if (uitmp > (int) (*oidLen)) {
Erez> for (i = 0; i < *oidLen; ++i)
var-> val.string[i] = (u_char) * oidIndex++;
Erez> for (i = 0; i < uitmp; ++i) // Erez
Erez> Makavy: Is this a BUG?!!!
var-> val.string[i] = '\0';
Yep. That's indeed a bug. The patch is actually this:
Index: mib.c
===================================================================
RCS file: /cvsroot/net-snmp/net-snmp/snmplib/mib.c,v
retrieving revision 5.94
diff -u -p -r5.94 mib.c
--- mib.c 2 Feb 2006 22:08:39 -0000 5.94
+++ mib.c 8 Mar 2006 14:48:12 -0000
@@ -3799,7 +3799,7 @@ parse_one_oid_index(oid ** oidStart, siz
if (uitmp > (int) (*oidLen)) {
for (i = 0; i < *oidLen; ++i)
var->val.string[i] = (u_char) * oidIndex++;
- for (i = 0; i < uitmp; ++i)
+ for (i = *oidLen; i < uitmp; ++i)
var->val.string[i] = '\0';
(*oidLen) = 0;
} else {
Erez> In this if cluase, the first 'for' startement is overridden by the
Erez> second 'for' statement.
Erez> (val.string, will always be set to all zeros)
Note that the only time this will ever be hit is if the string length
was supposed to be longer than the data encoded in the OID. This should
actually never ever happen (IE, the OID is too short in the first place
for the expected data).
I've fixed it anyway because we like to handle exceptions...
--
Wes Hardaker
Sparta, Inc.
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642
_______________________________________________
Net-snmp-users mailing list
[email protected]
Please see the following page to unsubscribe or change other options:
https://lists.sourceforge.net/lists/listinfo/net-snmp-users
