[prev in list] [next in list] [prev in thread] [next in thread] 

List:       net-snmp-bugs
Subject:    [ net-snmp-Bugs-508126 ] usmUser MIB walking problem
From:       noreply () sourceforge ! net
Date:       2002-02-16 1:02:21
[Download RAW message or body]

Bugs item #508126, was opened at 2002-01-24 12:24
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=112694&aid=508126&group_id=12694

Category: agent
Group: None
> Status: Closed
> Resolution: Fixed
Priority: 5
Submitted By: Dale Sulzle (dales)
> Assigned to: Wes Hardaker (hardaker)
Summary: usmUser MIB walking problem

Initial Comment:
The following bug causes incorrect results when 
searching the usmUserMIB subtree.

The code is found in file: 
agent/mibgroup/snmpv3/usmUser.c line 306

Solution:
========
  The var_usmUser function was invoking

  result = snmp_oid_compare(name, *length, indexOid, 
len);
  
  when it should have been invoking
  
  result = snmp_oid_compare(indexOid, len, name, 
*length);
  
which cause confusion on which OID to keep later - 
when the provided OID was padded with irrelevant 
subids - to determine the next OID in its subtree.

NOTE: I would wait for the official blessing from Wes 
before assuming my hack fixes more than it breaks :)



----------------------------------------------------------------------

> Comment By: Wes Hardaker (hardaker)
Date: 2002-02-15 17:02

Message:
Logged In: YES 
user_id=76242

Ok, I think I agree (bless) this problem.  However, there might actually be a few \
pieces wrong  with the code.  Boy I'm tempted to just rewrite the entire section \
(arg).

I'm nerviously compiling and testing it now.  This is the whole reason I rewrote the \
agent API for  5.0  because getting index parsing so it's done properly is very \
non-trivial and it would be better  to do it once all in one place so that we don't \
screw it up in half of the module code sections. (it's much more efficient to screw \
it up in just one place)

I've, um, got the jitters now but it seems to work ok ;-)  Committing the fixes now.
(done slightly differently)


----------------------------------------------------------------------

Comment By: John Naylon (jbpn)
Date: 2002-01-28 03:41

Message:
Logged In: YES 
user_id=93926

Okay, I use SilverCreek too.  I don't see this problem
however.  What version of the toolkit are you testing?

----------------------------------------------------------------------

Comment By: Dale Sulzle (dales)
Date: 2002-01-25 11:41

Message:
Logged In: YES 
user_id=133274

We are using an automated test tool called SilverCreek: http://www.iwl.com.  It \
reported the following error  (It's going to get a little smooshed in this window)

1.1.6   The purpose of this test is to see how many sub-identifiers the agent can \
handle while performing  correct lexicographic ordering with long instance-IDs.  This \
test is run on each variable returned in test  1.1.2.

Each variable is padded to 128 sub-identifiers using a pattern of 
0.127.128.255.256.65535.65536.1677215.1677216.4294967295.0.127.128... and a GET-NEXT \
is issued from  the resulting OID.

The expected outcome is for the agent to return the first variable greater than the \
argument.

Reference	RFC 1157 § 4.1.3 


[FAILED] Remarks: get-next operation failed or had errors
Lexicographic error detected in response to get-next
Request OID 
1.3.6.1.6.3.15.1.2.2.1.3.13.128.0.7.229.128.193.32.87.31.218.7.200.35.7.82.47.79.85.115.101.114.1677721
 6.4294967295.0.127.128.255.256.65535.65536.16777215.16777216.4294967295.0.127.128.255.256.65535.6
 5536.16777215.16777216.4294967295.0.127.128.255.256.65535.65536.16777215.16777216.4294967295.0.1
 27.128.255.256.65535.65536.16777215.16777216.4294967295.0.127.128.255.256.65535.65536.16777215.1
 6777216.4294967295.0.127.128.255.256.65535.65536.16777215.16777216.4294967295.0.127.128.255.256.
 65535.65536.16777215.16777216.4294967295.0.127.128.255.256.65535.65536.16777215.16777216.429496
 7295.0.127.128.255.256.65535.65536.16777215.16777216.4294967295.0.127 > response OID \
 1.3.6.1.6.3.15.1.2.2.1.3.13.128.0.7.229.128.193.32.87.31.218.7.200.35.7.82.47.79.85.115.101.114
 Message Data {
	Error-Status: noError,
	Error-Index : 0,
	Bindings {
		
usmUserSecurityName.13.128.0.7.229.128.193.32.87.31.218.7.200.35.7.82.47.79.85.115.101.114,
  SnmpAdminString,
			"ReadOnlyUser"
	}
}




----------------------------------------------------------------------

Comment By: John Naylon (jbpn)
Date: 2002-01-25 02:49

Message:
Logged In: YES 
user_id=93926

Could you give an example of this going wrong?  I've just
been doing some work on the USM module (mostly fixing up the
row creation state machines) and I haven't noticed anything
funny.  When you say "when the provided OID was padded with
irrelevant subids", is this some type of automated test? 
Which tool?

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=112694&aid=508126&group_id=12694

_______________________________________________
Net-snmp-bugs mailing list
Net-snmp-bugs@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-bugs


[prev in list] [next in list] [prev in thread] [next in thread]