Conference azur::mcc

	For every management request that it receives across the call
	interface (with handle = first), the V1 SNMP AM first issues a 
	message requesting sysDescr, sysObjectid, and sysUptime.
	This message is hardcoded to avoid ASN encoding overhead, and hence 
	always uses the default community name of 'public'.

	The messages sent that map to the service request always use the
	community name if present in the By Password qualifier.

	Any UDP datagrams sent from the AM, that are not responded to
	in the timeout period, are resent until the max retry value is reached,
	at which time the "No response" exception is returned.

	The timeout period and number of retries are settable via the 
	AM's management interface, and can be viewed with

		MCC> show mcc 0 tcpip_am all char

	The defaults is to retry twice, hence the sets of 3 message you see 
	before timeout is returned.

	The next release of the AM will use the By Password qualifier
	for all communications.  For now, to get expected behavior, the agent
	must be configured to allow read access to the 3 MIB vars mentioned 
	above to the community "public".

	Regards,
	Mike

Case 2.

The system elos5.epfl.ch has a standard community name ("public"). After 
issuing the registration command:

>MCC> register snmp elos5.epfl.ch, by password "sicsti"
>
>SNMP elos5.epfl.ch
>AT 11-JUN-1991 16:58:52
>
>Registration Successful

No need for Sniffer to see that the BY PASSWORD is ignored ...

****  Please put the sniffer on this one.

****  Registration is dispatched to the registration FM, which eventually issues
****  a SHOW ALL IDENTS to the AM.  I don't know if the qualifiers would 
****  accompany that.  someone from Registration please comment.

****  If the agent is not configured with "sicsti" as a valid community
****  Then it looks like Registration is not passing it down.


Case 3.

On an already registered Entity:

>MCC> dir snmp elsica.epfl.ch
>
>SNMP elsica.epfl.ch
>AT 11-JUN-1991 16:58:36
>
>Directory successful.
>                                   Name = elsica.epfl.ch
>                                Address = 128.178.50.5

>MCC> show snmp elsica.epfl.ch all count, by password "secret"
>
>SNMP elsica.epfl.ch
>AT 11-JUN-1991 17:03:26 Counters
>
>No response from entity.

Sniffer shows that there is a first request with community name "public" to 
which there is a reply, then 3 requests with community name "secret" without 
reply.

****  Exactly, and since the service request timed out, you got "No response"

I've created QAR#708 in the MCC_INTERNAL database to track this problem.

    What is observed with the Sniffer seems to be consistent with your
    explanations i.e. registration will only issue the first management
    request with the default name 'public'.
    
    As for the suggestion to configure the agent to allow read access to the 
    3 MIB vars to the community "public", this is quite impossible to acheive. 
    Normally, the community name protect the access to the whole MIB, and not 
    to a set of particular variables.


>	The next release of the AM will use the By Password qualifier
>	for all communications.

    What is the availability date of the next release ?

    Thanks and regards,
    	Georges.
    
    
    
    Instead of node elos5.epfl.ch, we just take the node elos4, which belongs
    to the same cluster and run the same SNMP agent (community name 'public'), 
    but which is not yet registered in DECmcc.

    
>MCC> register snmp elos4.epfl.ch, by password "secret"
>
>SNMP elos4.epfl.ch
>AT 12-JUN-1991 14:08:40
>
>Registration Successful

The Sniffer trace gives :

1. DNS request for name elos4.epfl.ch
2. DNS answer to name elos4.epfl.ch
3. SNMP Get Request from MCC to elos4 :
   Version = 0
   Community = public
   Request ID = 1
   Error status = 0
   Error index = 0
   Object ={1.3.6.1.2.1.1.1.0} (sysDescr.0)
   Value  = NULL

   Object = {1.3.6.1.2.1.1.2.0} (sysObjectId.0}
   Value  = NULL

   Object = {1.3.6.1.2.1.1.3.0} (sysUpTime.0)
   Value  = NULL

4. A second packet similar to the packet in 3), after 5 seconds (I think
  its just because of routers delays, there are 3 cisco routers between
  the MCC station and elos4, and each router needs to find the next hop).

5. SNMP answer from elos4 to MCC :

   Version  = 0
   Community = public
   Command = Get response
   Request ID = 1
   Error status = 0
   Error index = 0

   Object = {1.3.6.1.2.1.1.1.0} (sysDescr.0)
   Value  = VAX/VMS Multinet V2.2

   Object = {1.3.6.1.2.1.1.2.0} (sysObjectID.0)
   Value  = {1.3.6.1.4.1.58.1.1.1}

   Object = {1.3.6.1.2.1.1.3.0} (sysUpTime.0)
   Value  = 111281100 hundredths of a second

And that's all. There has been no packet emited containing the community
name "secret", and the SNMP AM accepts to register the node just because
it received a successfull answer to the initial request. 

RE: What is the availability date of the next release ?
-----------------------------------------------------
TCP/IP SNMP AM V1.1 (the "next" version) will be entering
external field test at the end-of-July (maybe beginning of August).
That version, which layers onto DECmcc V1.1/VMS (the currently shipping
version), will contain the Community Name fix, along with fixes for
many other known problems.

Some significant functionality (e.g. MIB II, dynamic vendor MIBs) will
also be added.

If all goes according to plan, SSB submission will be end-of-September
(making FCS end-of-October/beginning-of-November).


RE: Register dataflow 
---------------------
Thanks for taking the time to Trace packets!

The dataflow for SNMP Register is as expected, given the bug reported
in the base note. 

    Hello,

    Thanks for making available the new version of the SNMP AM. It appears
    that the community  name is now handled correctly except the
    registration command. 

    In note .1 Mike raised the point: does the Registration FM propagate 
    the password qualifier to the SNMP AM? The answer seems to be no. If 
    this verifies, how can one make an SNMP entity appear on the iconic 
    map?

    Cheers,
    	Georges.



    Configuration: DECmcc BMS 1.1 patched as per Note 1267.
    		   SNMP AM T1.1

MCC> show mcc 0 tcpip_am all char

MCC 0 TCPIP_AM
AT 31-JUL-1991 09:02:18 Characteristics

Examination of attributes shows:
                      Component Version = T1.1.0
               Component Identification = "DECmcc TCP/IP SNMP AM"
                            UDP Timeout = 5
                            UDP Retries = 2

    Case 1. 

    System diktat is running Ultrix V4.2 with community name 'secret'

MCC> show snmp diktat all char, by password "secret"

SNMP diktat
AT 31-JUL-1991 08:55:32 Characteristics

Examination of attributes shows:
                             sysContact = -- Attribute Not Gettable
                                sysName = -- Attribute Not Gettable
                            sysLocation = -- Attribute Not Gettable
                            sysServices = -- Attribute Not Gettable
                               sysDescr = "diktat.zsw.dec.com:DECstation3100:ULT
                                          RIX V4.2 (Rev. 96) System #1"
                            sysObjectID = "1.3.6.1.4.1.36.1"
                               ifNumber = 2

MCC> set  snmp diktat interface 1 ifAdminStatus up ,by password "secret"

SNMP diktat Interface 1
AT 31-JUL-1991 08:56:47 Characteristics

Examination of Attributes Shows
                          ifAdminStatus = up

MCC> reg snmp diktat, by pass "secret"

SNMP diktat
AT 31-JUL-1991 08:57:06

The requested operation cannot be completed
            MCC Unhandled Service Reply = No response from entity.



Case 2. After resetting community name to 'public' .

MCC> reg snmp diktat

SNMP diktat
AT 31-JUL-1991 09:06:54

Registration Successful

MCC> dereg snmp diktat

SNMP diktat
AT 31-JUL-1991 09:07:25

Deregistration Successful


MCC> reg snmp diktat, by pass "secret"

SNMP diktat
AT 31-JUL-1991 09:06:54

Registration Successful

MCC> dereg snmp diktat, By pass "secret"

SNMP diktat
AT 31-JUL-1991 09:07:25

Deregistration Successful

Georges,

	Thanks for pointing this problem out.  As much as I'd like to point
the finger of blame at the Registration FM it turns out that the problem lies
in the TCP/IP AM.

	The Show SNMP x all identifiers command does not use the by password
qualifier properly, show all identifiers is called during the registration by
the Registration FM.

	We've reproduced the problem here, have identified the problem,
fixed it and are in the process of testing it.  I'll make a new executable 
available as soon as possible.

	Stay tuned.


Dan