[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference azur::mcc

Title:DECmcc user notes file. Does not replace IPMT.
Notice:Use IPMT for problems. Newsletter location in note 6187
Moderator:TAEC::BEROUD
Created:Mon Aug 21 1989
Last Modified:Wed Jun 04 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:6497
Total number of notes:27359

4533.0. "Can't read info from agent" by DAGWST::PIAZZA (Yabadabadoo) Thu Feb 11 1993 14:52

    Hello, I'm having a problem retrieving data from an agent running on a
    VMS system via an EXCELAN board.  DECmcc V1.2 is running on a
    DECstation 5200 with ULTRIX 4.2a.  We ran the translator utility, and
    the mib entity shows up in the IP hierarchy.  When we select a child
    entry (which is a table), we get the message "No response from
    entity."  But, through some dump prints on the VMS machine from the
    agent, we can see that the agent reads an initial request of system
    uptime, and processes the request.  The agent sends a block back to the
    DECmcc station but it rejects the block with an error status of "5".
    
    I would appreciate it if anyone could tell me what an error status of
    "5" is, and where this may be documented. 
    
    Thanks,
    
    /Dave
T.RTitleUserPersonal
Name		DateLines
4533.1might be some system group's objectsANNECY::HAGENMULLEREIC Annecy - dtn 7887.41.99Fri Feb 12 1993 02:5011
Dave, if 5 is the error status in the SNMP frame it means "generic error". You
should then have a look at the following field (error-index) which sometimes 
indicate the variable being in question (generally the SNMP manager sends a 
request containing more than one object : I guess DECmcc sends fisrt a request 
asking for sysDescr, sysObjectId and sysUpTime objects) : the snmp agent might
not implement some of these objects (system group's objects in this case).

Otherwise (DECmcc error and not SNMP error) I don't know ...

hope this helps, Ch.
4533.2More InformationDAGWST::PIAZZAYabadabadooFri Feb 12 1993 18:4921
    Here is some more info:
    
    1)  Agent reads a data block from DECmcc.  This is a GET_REQ_MSG.
    2)  Agent processes the three requests within the data block.
    3)  Agent formats the response message and sends it back via snmp_send.
    4)  DECmcc processes the GET_RSP_MSG but doesn't like something in the
    	data.  It transmits back a copy of the message block and sets the
    	"error_status" field to "5".
    5)  The agent then reads the block but doesn't process it.
    6)  The agent reads again and DECmcc sends the original request again.
    
    This process happens three times, then DECmcc gives up and says the
    agent doesn't respond...
    
    7) Help!
    
    Any help that can be given will be greatly appreciated.
    
    Thanks,
    
    /Dave
4533.3more details neededANNECY::HAGENMULLEREIC Annecy - dtn 7887.41.99Mon Feb 15 1993 03:35124
 Dave, a few remarks,


    Here is some more info:

    1)  Agent reads a data block from DECmcc.  This is a GET_REQ_MSG.
>>> a snmp get-request PDU with 3 oids. The format of this request is as follows
>>>
>>> a snmp get-request PDU with 3 oids. The format of this request is as follows
Dave, a few remarks,


    Here is some more info:

    1)  Agent reads a data block from DECmcc.  This is a GET_REQ_MSG.
>>>
>>> a snmp get-request PDU with 3 oids. The format of this request is as follows
>>>
>>>     request-id (integer)
>>>     error-status (integer)
>>>     error-index (integer)
>>>     sequence of {   name    (object id)
>>>                     value   (according to object syntax)  }
>>>
>>> here the 3 oids are those of sysDescr, sysObjectID and sysUpTime
>>> and the values are NULL since it's like a "show" request.
>>>
    2)  Agent processes the three requests within the data block.
>>>
>>> it handles the 3 requested objects (sysDescr which oid is 1.3.6.2.1.1.1,
>>> sysObjectID and sysUpTime)
>>>
>>> it handles the 3 requested objects (sysDescr which oid is 1.3.6.2.1.1.1,
>>> sysObjectID and sysUpTime)
>>>
    3)  Agent formats the response message and sends it back via snmp_send.
>>>
>>> the answer is a snmp get-response PDU with the following structure
>>>
>>>     request-id (integer) -- the same as the initial request
>>>     error-status (integer) -- kind of error if any
>>> a snmp get-request PDU with 3 oids. The format of this request is as follows
>>>
>>>     request-id (integer)
>>>     error-status (integer)
>>>     error-index (integer)
>>>     sequence of {   name    (object id)
>>>                     value   (according to object syntax)  }
>>>
>>> (all fields BER-encoded in a UDP/IP frame)
>>>
>>> here the 3 oids are those of sysDescr, sysObjectID and sysUpTime
>>> and the values are NULL since it's like a "show" request.
>>>
    2)  Agent processes the three requests within the data block.
>>>
>>> it handles the 3 requested objects (sysDescr which oid is 1.3.6.2.1.1.1,
>>> sysObjectID and sysUpTime)
>>>
    3)  Agent formats the response message and sends it back via snmp_send.
>>>
>>> the answer is a snmp get-response PDU with the following structure
>>>
>>>     request-id (integer) -- the same as the initial request
>>>     error-status (integer) -- kind of error if any
>>>     error-index (integer) -- the number of the object in fault, sometimes
>>>                           -- ignored
>>>     sequence of {   name    (object id) -- the same as the initial request
>>>                     value   -- the values of the object or NULL in case of
>>>
    3)  Agent formats the response message and sends it back via snmp_send.
>>>
>>> the answer is a snmp get-response PDU with the following structure
>>>
>>>     request-id (integer) -- the same as the initial request
>>>     error-status (integer) -- kind of error if any
>>>     error-index (integer) -- the number of the object in fault, sometimes
>>>                           -- ignored
>>>     sequence of {   name    (object id) -- the same as the initial request
>>>                           -- ignored
>>>     sequence of {   name    (object id) -- the same as the initial request
>>>                     value   -- the values of the object or NULL in case of
>>>                             -- error }
>>>
    4)  DECmcc processes the GET_RSP_MSG but doesn't like something in the
        data.  It transmits back a copy of the message block and sets the
        "error_status" field to "5".
>>>
>>> Do you mean the snmp get-response PDU is sent by the agent without an
>>> error-status. In that case could you please put as a reply a complete
>>> dump of the frame sent by the agent.
>>>
>>> Usually, it is the agent which set the error-status and error-index fields.
>>> Thus it seems strange that DECmcc sends back the same frame with an error-
>>> index.
>>>
    5)  The agent then reads the block but doesn't process it.
    6)  The agent reads again and DECmcc sends the original request again.
>>>
>>>
>>> snmp is over UDP/IP is is therefore connectionless : you seem to outline
>>> a kind of control flow between the snmp manager and agent that doesn't
>>> exist. Each snmp request sent by the manager (and identified by the
>>> request-id) must be answered by the agent in a reasonable interval with the
>>> same request-id. If the frame is lost or the interval elapsed, it is up to
>>> the manager to issue a new request (which may be identical to the initial
>>> one
>>>
    This process happens three times, then DECmcc gives up and says the
    agent doesn't respond...

    7) Help!


  Any help that can be given will be greatly appreciated.
>>>
>>> please, try to put in a reply a complete dump of the first snmp get-response
>>> PDU sent back by the snmp agent.
>>>
    Thanks,

    /Dave
>>>
>>> Christophe
4533.4More info--DumpsDAGWST::PIAZZAYabadabadooTue Feb 16 1993 00:3268
Thanks for the replies.  I will enter dump info below, but a little background
first.  The customer used a CMU agent on a BSD UNIX machine and it worked fine. 
A programmer then duplicated the code for the VMS agent, and it doesn't work.

Following is a dump of the original read from DECmcc:

30 82 00 4A 02 01 00 04 06 70 75 62 6C 69 63 A0
82 00 3B 02 01 01 02 01 00 02 01 00 30 30 30 82
00 0C 06 08 2B 06 01 02 01 01 03 00 05 00 30 82
00 0C 06 08 2B 06 01 02 01 01 01 00 05 00 30 82
00 0C 06 08 2B 06 01 02 01 01 02 00 05 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00


Following is various data from the agent process:

setup_retrieve: rw = 1   exact = 1
setup_retrieve: name: .iso.org.dod.internet.mgmt.mib.system.sysUpTime.0
setup_retrieve: name_length= 9 var no = 1 type = 5  5
setup_retrieve: community = 0
setup_retrieve: acl = 43690  community = 0 rw = 1
setup_retrieve: vp->type= 67  vp->val_len= 4 vp->val.integer= 0

setup_retrieve: name: .iso.org.dod.internet.mgmt.mib.system.sysDescr.0
setup_retrieve: name_length= 9 var no = 2 type = 5  5
setup_retrieve: community = 0
setup_retrieve: acl = 43706  community = 0 rw = 1
setup_retrieve: vp->type= 4  vp->val_len= 11 vp->val.string= Unix 4.3BSD
	(Note: The original value was VMS 5.4-3, but was hard coded for
	       debugging purposes)

setup_retrieve: name: .iso.org.dod.internet.mgmt.mib.system.sysObjectID.0
setup_retrieve: name_length= 9 var no = 3 type = 5  5
setup_retrieve: community = 0
setup_retrieve: acl = 43690  community = 0 rw = 1
setup_retrieve: vp->type= 6  vp->val_len= 36 vp->val.integer= 16912


The following is a dump of the agent transmit response:

30 56 02 01 00 04 06 70 75 62 6C 69 63 A2 49 02
01 01 02 01 00 02 01 00 30 3E 30 0D 06 08 2B 06
01 02 01 01 03 00 43 01 00 30 17 06 08 2B 06 01
02 01 01 01 00 04 0B 55 6E 69 78 20 34 2E 33 42
53 44 30 14 06 08 2B 06 01 02 01 01 02 00 06 08
2B 06 01 04 01 03 01 01


The following is a dump of the DECmcc error response:

30 82 00 5E 02 01 00 04 06 50 55 42 4C 49 43 A2
82 00 4F 02 01 01 02 01 05 02 01 00 30 44 30 82
00 0D 06 08 2B 06 01 02 01 01 03 00 43 01 00 30
82 00 17 06 08 2B 06 01 02 01 01 01 00 04 0B 55
6E 69 78 20 34 2E 33 42 53 44 30 82 00 14 06 08
2B 06 01 02 01 01 02 00 06 08 2B 06 01 04 01 03
01 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00


Next, a second read from DECmcc is performed with a dump resulting like the
first dump above.  A total of three reads are issued and then a "No response
from entity" is returned to the DECmcc screen.

Hope this information helps.  Thanks alot for all of your help.

/Dave
4533.5IP and UDP headers ?ANNECY::HAGENMULLEREIC Annecy - dtn 7887.41.99Tue Feb 16 1993 05:3193
>>>Dave, here are some comments on the dumped frames :


Thanks for the replies.  I will enter dump info below, but a little background
first.  The customer used a CMU agent on a BSD UNIX machine and it worked fine. 
A programmer then duplicated the code for the VMS agent, and it doesn't work.

Following is a dump of the original read from DECmcc:

>>>30 82 00 4A 02 01 00 04 06*70 75 62 6C 69 63*A0*-- public, A0 = get-request
>>>82 00 3B 02 01*01*02 01*00*02 01*00*30 30 30 82 -- requestid = 1, errors = 0
>>>00 0C 06 08*2B 06 01 02 01 01 03 00*05 00 30 82 -- sysUtime (2B....03)
>>>00 0C 06 08*2B 06 01 02 01 01 01 00*05 00 30 82 -- sysDescr (2B....01)
>>>00 0C 06 08*2B 06 01 02 01 01 02 00*05 00 00 00 -- sysObjectID (2B....02)
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00


Following is various data from the agent process:

setup_retrieve: rw = 1   exact = 1
setup_retrieve: name: .iso.org.dod.internet.mgmt.mib.system.sysUpTime.0
setup_retrieve: name_length= 9 var no = 1 type = 5  5
setup_retrieve: community = 0
setup_retrieve: acl = 43690  community = 0 rw = 1
setup_retrieve: vp->type= 67  vp->val_len= 4 vp->val.integer= 0

setup_retrieve: name: .iso.org.dod.internet.mgmt.mib.system.sysDescr.0
setup_retrieve: name_length= 9 var no = 2 type = 5  5
setup_retrieve: community = 0
setup_retrieve: acl = 43706  community = 0 rw = 1
setup_retrieve: vp->type= 4  vp->val_len= 11 vp->val.string= Unix 4.3BSD
	(Note: The original value was VMS 5.4-3, but was hard coded for
	       debugging purposes)

setup_retrieve: name: .iso.org.dod.internet.mgmt.mib.system.sysObjectID.0
setup_retrieve: name_length= 9 var no = 3 type = 5  5
setup_retrieve: community = 0
setup_retrieve: acl = 43690  community = 0 rw = 1
setup_retrieve: vp->type= 6  vp->val_len= 36 vp->val.integer= 16912
>>>
>>> sysObjectID returned is 1.3.6.1.4.1.3.1.1 (the second 3 means CMU)
>>>

The following is a dump of the agent transmit response:

>>>30 56 02 01 00 04 06*70 75 62 6C 69 63*A2*49 02 __ public, A2 = get-response 
>>>01 01 02 01 00 02 01 00 30 3E 30 0D 06 08 2B 06 -- same requestid, no error
>>>01 02 01 01 03 00*43 01 00*30 17 06 08 2B 06 01 -- TimeStick(ap.3, value=0)
>>>02 01 01 01 00 04 0B 55 6E 69 78 20 34 2E 33 42 -- .......Unix 4.3B
>>>53 44 30 14 06 08 2B 06 01 02 01 01 02 00 06 08 -- SD..
>>>2B 06 01 04 01 03 01 01			   -- 1.3.6.1.4.1.3.1.1

>>> this frame seems to be snmp compliant and therefore good
>>> the only strange thing is that the sysUpTime returned as a value of 0
>>> Is DECmcc testing this value ?

The following is a dump of the DECmcc error response:

>>>30 82 00 5E 02 01 00 04 06*50 55 42 4C 49 43*A2* -- PUBLIC ?, A2 = get-resp.
>>>
>>> there is something strange here, because DECmcc sends a response to a
>>> response !?!
>>> futhermore, why is the community string in uppercase ?
>>>
82 00 4F 02 01 01 02 01 05 02 01 00 30 44 30 82
00 0D 06 08 2B 06 01 02 01 01 03 00 43 01 00 30
82 00 17 06 08 2B 06 01 02 01 01 01 00 04 0B 55
6E 69 78 20 34 2E 33 42 53 44 30 82 00 14 06 08
2B 06 01 02 01 01 02 00 06 08 2B 06 01 04 01 03
01 01 //00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00


Next, a second read from DECmcc is performed with a dump resulting like the
first dump above.  A total of three reads are issued and then a "No response
from entity" is returned to the DECmcc screen.

>>> this is a normal behaviour, since after 3 unsuccesful attemps, DECmcc gives
>>> up.

Hope this information helps.  Thanks alot for all of your help.

>>> except for possibly the sysUpTime value of 0, I don't see where the mistake
>>> lies.
>>> However, could you provide us with the beginning of all frames (I mean
>>> the IP and UDP headers) ? May be (unless there is an obvious error I've
>>> missed) there is an error in the UDP port used in the agent's reply for 
>>> example.
>>>
/Dave

>>> Christophe
4533.6More Header InfoDAGWST::PIAZZAYabadabadooWed Feb 17 1993 16:0346
Christophe,

Thanks for the replies.  I got the header information you requested.  It's
posted below.

Following is a dump of the original read from DECmcc:

08 00 14 30 41 33 AA 00 04 00 87 07 08 00 45 00
00 6A C4 6C 00 00 1E 11 6A FF 01 00 4D 0F 01 01
1E 08 07 66 00 A1 00 56 DA 60 30 82 00 4A 02 01 
00 04 06 70 75 62 6C 69 63 A0 82 00 3B 02 01 01 
02 01 00 02 01 00 30 30 30 82 00 0C 06 08 2B 06 
01 02 01 01 03 00 05 00 30 82 00 0C 06 08 2B 06 
01 02 01 01 01 00 05 00 30 82 00 0C 06 08 2B 06 
01 02 01 01 02 00 05 00 


The following is a dump of the agent transmit response:

AA 00 04 00 87 07 08 00 14 30 41 33 08 00 45 00
00 74 AF D0 00 00 FF 11 9E 90 01 01 1E 08 01 00
4D 0F 00 A1 00 A1 00 60 7D FF 30 56 02 01 00 04 
06 70 75 62 6C 69 63 A2 49 02 01 01 02 01 00 02 
01 00 30 3E 30 0D 06 08 2B 06 01 02 01 01 03 00 
43 01 00 30 17 06 08 2B 06 01 02 01 01 01 00 04 
0B 55 6E 69 78 20 34 2E 33 42 53 44 30 14 06 08 
2B 06 01 02 01 01 02 00 06 08 2B 06 01 04 01 03 
01 01


The following is a dump of the DECmcc error response:

08 00 14 30 41 33 AA 00 04 00 87 07 08 00 45 00
00 7E C4 79 00 00 1E 11 6A DE 01 00 4D 0F 01 01
1E 08 00 A1 00 A1 00 6A CD B6 30 82 00 5E 02 01 
00 04 06 50 55 42 4C 49 43 A2 82 00 4F 02 01 01 
02 01 05 02 01 00 30 44 30 82 00 0D 06 08 2B 06 
01 02 01 01 03 00 43 01 00 30 82 00 17 06 08 2B 
06 01 02 01 01 01 00 04 0B 55 6E 69 78 20 34 2E 
33 42 53 44 30 82 00 14 06 08 2B 06 01 02 01 01 
02 00 06 08 2B 06 01 04 01 03 01 01 


Hope this information helps.  Thanks again for all of your help.

/Dave
4533.7UDP port ANNECY::HAGENMULLEREIC Annecy - dtn 7887.41.99Thu Feb 18 1993 04:1263
>>> Hello Dave,

Christophe,

Thanks for the replies.  I got the header information you requested.  It's
posted below.

Following is a dump of the original read from DECmcc:

08 00 14 30 41 33 AA 00 04 00 87 07 08 00 45 00
>>>00 6A C4 6C 00 00 1E 11 6A FF 01 00 4D 0F 01 01 -- ip source ad= 1.0.77.15
>>>						   -- ip dest ad  = 1.1.30.8
>>>1E 08*07 66*00 A1*00 56 DA 60 30 82 00 4A 02 01 -- udp sour port = 1894
>>>						   -- udp dest port = 161 (snmp)
00 04 06 70 75 62 6C 69 63 A0 82 00 3B 02 01 01 
02 01 00 02 01 00 30 30 30 82 00 0C 06 08 2B 06 
01 02 01 01 03 00 05 00 30 82 00 0C 06 08 2B 06 
01 02 01 01 01 00 05 00 30 82 00 0C 06 08 2B 06 
01 02 01 01 02 00 05 00 


The following is a dump of the agent transmit response:

AA 00 04 00 87 07 08 00 14 30 41 33 08 00 45 00
00 74 AF D0 00 00 FF 11 9E 90 01 01 1E 08 01 00
>>>4D 0F*00 A1*00 A1*00 60 7D FF 30 56 02 01 00 04 -- udp sour port = 161 (ok)
>>>						   -- udp dest port = 161 !!!
>>> Here is the error ! The agent MUST use the 
>>> initial udp source port as the udp destination
>>> port, ie 1894 (it is a mandatory rule).
>>>
06 70 75 62 6C 69 63 A2 49 02 01 01 02 01 00 02 
01 00 30 3E 30 0D 06 08 2B 06 01 02 01 01 03 00 
43 01 00 30 17 06 08 2B 06 01 02 01 01 01 00 04 
0B 55 6E 69 78 20 34 2E 33 42 53 44 30 14 06 08 
2B 06 01 02 01 01 02 00 06 08 2B 06 01 04 01 03 
01 01


The following is a dump of the DECmcc error response:

08 00 14 30 41 33 AA 00 04 00 87 07 08 00 45 00
00 7E C4 79 00 00 1E 11 6A DE 01 00 4D 0F 01 01
1E 08 00 A1 00 A1 00 6A CD B6 30 82 00 5E 02 01
>>>
>>> the DECmccc snmp AM tries to answer was seems to it a new request.
>>> It'd better discard the frame since it is a snmp get-response
>>> with an unkown udp port.
>>>  
00 04 06 50 55 42 4C 49 43 A2 82 00 4F 02 01 01 
02 01 05 02 01 00 30 44 30 82 00 0D 06 08 2B 06 
01 02 01 01 03 00 43 01 00 30 82 00 17 06 08 2B 
06 01 02 01 01 01 00 04 0B 55 6E 69 78 20 34 2E 
33 42 53 44 30 82 00 14 06 08 2B 06 01 02 01 01 
02 00 06 08 2B 06 01 04 01 03 01 01 


Hope this information helps.  Thanks again for all of your help.

/Dave

>>> correct the piece of software which is in fault, and it should work ...
>>> regards, Ch.
4533.8Problem fixed!DAGWST::PIAZZAYabadabadooTue Feb 23 1993 11:129
    Christophe,
    
    Sorry I haven't replied sooner, but I was in class last week, spending
    available time at the customer site.  They didn't get a chance to try
    your recommendation until yesterday.  You were right, they changed the
    destination port to 1894, and it worked!!  Thanks VERY much for your
    help, as the customer was getting antsy.
    
    /Dave