Conference azur::mcc

	Steve,
		The mib query utility is an undocumented tool which can be
	used to diagnose problems in communication between DECmcc and
	SNMP agents. The location of the utility on VMS is

		SYS$SYSTEM:MCC_TCPIP_MQ.EXE

	while on Ultrix it can be found at

		/usr/mcc/mmexe/mcc_tcpip_mq

		The utility accepts the internet name, the community name
	and the mode of operation as arguments. So it has to be defined as
	a foreign command on VMS.

		MQ :== $SYS$SYSTEM:MCC_TCPIP_MQ.EXE

	Trying to run the utility without any parameters will inform you of
	the different arguments that you can specify.

	eg.

$ mq
Program usage:  MIB_Query   Identifier   Pdu   Mode

Parameters:
        Identifier - The host (domain) name
        Pdu        - The SNMP Pdu ( 0 for Get, 1 for GetNext )
        Mode       - 0 for stepwise, 1 for continuous

----------

	A sample session which asks for the MIB II objects sysDescr, sysObjID,
	and sysUptime is provided below:

$ mq myunix 1 0
Enter a starting object identifier in dot notation.
Example: 1.3.6.1.2.1.1<CR>
OID> 1.3.6.1.2.1.1
Request id: 1   Error number: 0   Error index: 0
------------------------------------------------

Object ID: 1.3.6.1.2.1.1.1.0.
Value = 6d 79 75 6e 69 78 2e 6d 63 63 2e 64 65 63 2e 63 6f 6d 3a 56 41 58 32 30
30 30 3a 55 4c 54 52 49 58 20 56 34 2e 32 20 28 52 65 76 2e 20 39 36 29 20 53 79
 73 74 65 6d 20 23 31 myunix.mcc.dec.com:VAX2000:ULTRIX V4.2 (Rev. 96) System #1



 Enter <CR> for lexinext object, N for new object, anything else to quit

Request id: 1   Error number: 0   Error index: 0
------------------------------------------------

Object ID: 1.3.6.1.2.1.1.2.0.
Value = 1.3.6.1.4.1.36.1.



 Enter <CR> for lexinext object, N for new object, anything else to quit

Request id: 1   Error number: 0   Error index: 0
------------------------------------------------

Object ID: 1.3.6.1.2.1.1.3.0.
Value = 130559800
 

	You can determine what object id to specify for a particular object
	by reading the mib. If you do not want to learn how to read a mib, 
	then look in the *.lis file outputted by MTU. At the bottom of the
	file you will find a list of mib objects and their corresponding
	oids.

	Hope this helps.

	Rahul.

Rahul,
    
    Thanks for the information on the Mib Query utility, hope you don't
    wind up regreting tellin me about it.  Attached is the reason for 
    requesting the information.  Can you shed any light on these 2
    problems? 
    
    Steve
    
Two questions, two different customers, one with a Proteon the other 
with a Cisco.

Proteon:
    When doing a 'show SNMP xxx proteon xface peth all count' all
    attributes are returned as 'Attribute Not Gettable'. After giving
    the standard 'agent on entity is not returning the information'
    answer, the customer pushes back with 'Proteon says it works for 
    them', and this is at the customer site.

    After finding a Proteon CNX500, I get the same results as the 
    customer.  Then using the MIB Query utility, I enter thge OID
    for one of these attributes.  After the query walks the tree for 
    awhile I start getting:

	Request id: 1   Error number: 2   Error index: 1
	------------------------------------------------

    Can someone explain the error number and error index?  A list of
    values and their meanings would be nice. 

    As an attempt to have MCC walk the tree a little I tried:
	MCC> sh snmp cnx500 proteon xface
	Using default ALL IDENTIFIERS
	
	SNMP cnx500 proteon xface
	AT 11-NOV-1992 07:25:05 Identifiers
	
	Examination of attributes shows:
	
	MCC>
    Nothing was returned.

Cisco:
    Customer is trying to get attributes from the 'cisco local lsystem'
    group, when he tries it with an 'all characteristics' it gets to
    a point with one attribute returned with 'Attribute Not Available'.
    Trying it at the CSC the attribute at this stopping point is 
    'netConfigSet'.  Using DAP, the lsystem group has 69 attributes,
    so I tried to get the first in the attribute list, 'romid', 
    specifically:

	MCC> sh snmp bulldog cisco local lsystem romid
	
	SNMP bulldog cisco local lsystem
	AT 11-NOV-1992 07:30:10 Characteristics

	MCC>

    Nothing was returned.
    Using MIB Query with the OID for 'romid' it dies with a parse init:
	FTEST> mq BULLDOG 1 0
	Enter a starting object identifier in dot notation.
	Example: 1.3.6.1.2.1.1<CR>
	OID> 1.3.6.1.4.1.9.2.1.1
	Request id: 1   Error number: 0   Error index: 0
	------------------------------------------------


	parse_init returned status = 52875202
	FTEST>

    Since a parse_init of 52878858 indicates a corrupt ASN1 encoding,
    what does 52875202 indicate. Is there a listing available that
    translates the status # to english.

    Again the customer has already been in contact with Cisco. Cisco
    has queried the customer box over the internet and of course gets
    the correct info for the lsystem group.

    I had someone at the CSC try to get to the Lsystem group with MSU.
    They reported that it worked fine.  By the way both of us (MCC
    and MSU) are touching the same box.

	Steve,
		My guess is that the Proteon agent does not match the mib
	which was provided on the DECmcc kit. We have a newer version of
	Proteon's mib, which we will put on the V1.3 kit. You might want to
	ask the customer to procure the new mib and try it out.

		The reason why nothing is returned when you do a "show snmp
	xxx proteon xface all ident" is that xface does not have any attributes
	defined. The attributes appear at a lower level, (under peth).

		Regarding the Cisco box, I believe we might be running into
	some restrictions in DECmcc regarding ASN.1 encodings. If you could
	mail me the IP address for the box, I will try investigating the
	problem further.

		Here's some more info on mib query :

	Explanation of mib query outputs:

	Request Id : 0   -- SNMP GetRequest operation.
		     1   -- SNMP GetNextRequest operation

	Error Number : 0	-- noError (Everything is fine).
		       1 	-- tooBig (Data cannot fit in request buffer).
		       2	-- noSuchName (Variable unknown to agent).
		       3	-- badValue (Incorrect syntax).
		       4	-- readOnly (Can be read only).
		       5	-- genErr (All other errors).

	Error Index : If non-zero, this indicates which variable in the request
		      was in error. Since mib query only asks for one variable
		      at a time, this can only have a value of 1 when there is
		      an error. Otherwise it is 0.

	Rahul.


		

	RE .2

	Steve,

		I have an update on the Proteon problem. It seems that the
	Proteon mib does not make any distinction between tabular and non-
	tabular objects. As a result, everything ends up modelled as 
	non-tabular objects in DECmcc. That is why the customer is not
	able to specify an interface number for the peth table, and ends
	up seeing "Attribute Not Gettable" for all the attributes. We are
	working with Proteon regarding this issue, our hope being that they
	will add more information in the mib which allows it to work with
	DECmcc.

		Regarding Cisco, I found that the agent is returning a
	readOnly error for some attributes in the lsystem table when one
	tries to do SHOW operations on them. The SNMP AM does not seem
	to handle this unexpected error too gracefully, and refuses too 
	display the the other attributes which were returned correctly by 
	the agent. I have fixed this problem, and it will be available with
	V1.3 field test update.

>>    Since a parse_init of 52878858 indicates a corrupt ASN1 encoding,
>>    what does 52875202 indicate. Is there a listing available that
>>    translates the status # to english.

	A value of 52875202 corresponds to ILV-TOO-BIG. You can look into
	the MCC_MSG.H file in SYS$LIBRARY to find out what these condition
	values mean. The only explanation I can think of regarding the error
	message you got from the mib query utility is that the agent returned
	a value which was too big for us to handle. The mib query utility
	can handle a maximum response size of 512 bytes, while the SNMP AM
	can handle upto 1500 bytes.

	Rahul.

>		Regarding Cisco, I found that the agent is returning a
>	readOnly error for some attributes in the lsystem table when one
>	tries to do SHOW operations on them. The SNMP AM does not seem
>	to handle this unexpected error too gracefully...

	Hi Rahul!

	That's because the ReadOnly error is NOT architected in SNMP as
	a valid response to Get or GetNext.  (At least not in RFC 1098.)

	The code was even documented to state that.

	This is an agent problem again, unless there's been a change to
	the SNMP RFC (entirely possible since I was last current).

	You'll love sunny ZK.

Mike

>>	That's because the ReadOnly error is NOT architected in SNMP as
>>	a valid response to Get or GetNext.  (At least not in RFC 1098.)
>>
>>	The code was even documented to state that.
>>
>>	This is an agent problem again, unless there's been a change to
>>	the SNMP RFC (entirely possible since I was last current).


	Hey Mike,

		How're you doing? I agree that there's a bug in the agent,
	and it should never be returning a readOnly error for a Get request.
	Unfortunately, there are a lot of shaky agents out there. Blaming the
	agent does not go down too well with the customers who frequently 
	come back with a retort that it works fine with other people's
	management stations. As a result the only option we have is to
	make the SNMP AM more flexible, sometimes ignoring some obvious bugs
	in the agent. 

		The code was indeed documented to describe the sort of action
	the SNMP AM would take on a readOnly error. However, ignoring the 
	whole PDU due to an error in one varbind was too strict of action
	to take in light of the varying levels of protocol conformance we have
	seen in the agents.

		See ya in ZK in a couple of weeks.

	Rahul.