Conference azur::mcc

    Renato,
    
    I looked at the code several months ago for an unrelated problem and
    noticed that there was a bug where the Ethernet AM was returning a
    "Management Protocol Error" when the actual error was "Cannot communicate
    with target".  I don't this bug was ever fixed.  I would treat the
    exception, "Management Protocol Error" as a "Cannot communicate with
    target" exception until you hear otherwise.
    
    -Matt.

Actually, I tried this on my own MUXserver 100, and got the same results.
(And my MUXserver *was* up.)

I'm not sure what our hardware rev is...but I think its the same as yours.

-Dave

For what its worth, you can do show terminal_server counters on this box...

If some one in LKG needs the ethernet addr of my MUXserver to duplicate this,
just call me...

    
    To .1,
    
    Matt,
    
    If I understand what you mean, "Management Protocol Error" message
    could mean "Cannot communicate with target", from your investigations
    within the STATION AM module code. In my case, only the Counters
    Partition returns the error message, ie Characteristics Partition gives
    no error and returns correct data.
    
    Any other idea ?
    
    Regards,
    Renato
    

    Renato,
    
    The problem I described only happened on Counters, when the "receipt"
    values" did not match AND packet being examined did not have a size
    of 57 bytes (V3 mop counters) or 203 bytes (V4 mop counters).
    
    I'll try to find someone to take a look at it.
    
    -Matt.

    
    Matt,
    
    I'm going onsite next week. Is it possible to have any information
    about the way we can solve this kind of problem ? Do you think it will
    possible to get a solution (new firmware ?) via the current note, OR do
    you think I may have to 'escalade' the problem officially ?
    
    Regards,
    Renato
    

	Hi,

	There are a couple of devices that return counters incorrectly.
	ie: incorrect size. 
	The way the station handles this is by returning the protocol
	error. The cannot communicate is probably from trying a different
	ethernet host port first.


Vin

    Hi Renato and Matt,
    
    MOPV3/MOPV4 counter packets are fixed format packets.  As mentioned
    in the earlier replies to this note, when the Ethernet AM returns 
    'Management Protocol Error', it means that the MOPV3/MOPV4 return 
    packet length for counters was incorrect.  I have seen DS100s and
    DS250s return undersized counter packets (which is a bug in the agent).
    When this happens, the Ethernet AM assumes the packet is bad.
    
    When the common exception 'Cannot communicate with target' is returned
    from the Ethernet AM, it basically means that the station did not
    respond to the request.  The Ethernet AM specialized exception
    'Management Protocol Error' only occurs when the counters data was
    successfully returned, but upon checking had an incorrect packet
    length.
    
    Could you please invoke Ethernet AM packet tracing:
               $ define MCC_ENET_AM_LOG 26
    and either post or send me the log of the same command:
               MCC> SHOW STATION <mux-server> ALL COUNT
    
    We don't have a MUXserver 100 to test with at MKO, but the packet
    tracing output should verify any packet length and/or receipt errors.
    
    Thanks,
    
    Linda
    
    P.S. - Matt submitted QAR #161 from MCC013_INT for this (or a similar)
           problem. I answered it with IQ (inquire) since more information 
           is needed.

Hi Renato and Matt,

I got a MUXserver 100 SHOW STATION ALL COUNTERS log with packet tracing 
enabled (thanks Dave :-).  The packet tracing verified that the counter 
packet returned from the MUXserver 100 is only 55 bytes.  It also 
displayed that the receipt numbers matched.

Since MOPV3 Counters are 57 bytes long and MOPV4 Counters are 203 bytes long,
the Ethernet AM is correct in returning 'Management Protocol Error'.

Re: .6, 
Since this version of the MUXserver didn't implement the MOP counters 
correctly, maybe a more recent version of the agent did.  An upgrade
*might* help (I can't say for sure).

Hope this helped :-)

Linda

===============================================================================

DECmcc (V1.2.0)

MCC> SHOW STATION 08-00-2B-12-22-B2 ALL COUNT
*
* Module mcc_enet_am_show entry point Fri Nov 20 09:55:05 1992
*
*
* mcc_enet_am__call_cea REQUEST: Fri Nov 20 09:55:07 1992
*
* Buffer Dump :
* Buffer Address = 00176727  (1533735 dec)
* Buffer Size    = 00000003  (3 dec)
*
*                    Hex                                 Ascii        Offset
* 09 01 00                                         ...                00000010
*
*
* mcc_enet_am__call_cea Completed. RESPONSE: Fri Nov 20 09:55:08 1992
*
* Buffer Dump :
* Buffer Address = 00176D6D  (1535341 dec)
* Buffer Size    = 00000037  (55 dec)
*
*                    Hex                                 Ascii        Offset
* 0B 01 00 00 00 A7 56 F7 B0 B7 19 03 00 04 DE BB  ......V..........  00000010
* 01 BD 06 00 00 49 9E C5 6F E1 60 09 01 5F 00 00  .....I..o.`.._...  00000020
* 00 0D 00 00 00 15 00 00 00 00 00 00 00 ED 00 FF  .................  00000030
* FF 00 00 60 00 00 00                             ...`...            00000040
*
*
* Module mcc_enet_am_show exit point Fri Nov 20 09:55:08 1992
*

Station LAA:.ts.station_ms100
AT 20-NOV-1992 09:55:08 Counters

Management protocol error
MCC>
    

    
    Matt, Linda,
    
    Hereunder traces of protocol data exchanges between MUXserver 100 and
    DECmcc platform (Traces caught with IRIS PC-based software).
    
    Effectively, the MOP request (ie Counter Data) seems to get a 52 bytes
    length counters.

    I hope this problem will be solved in a future version (V1.2.3 ?).
    
    Thank you for your help.
    
    Regards,
    Renato
    
    ===========================================================================
    
Subject: Traces entre TAURUS et PC0MX1

IRIS capture data                                                    
 Page   1
Trames entre TAURUS et PC0MX1                                11/20/92
 17:06:08


** Summary for frame 0 **

     0        08002B0DE6B4<-      TAURUS   60  DIX 6002     MOPRC Reque
stCounters
                                                            DLL DIX
 PType=60-02

** Detail for frame 0 **

DLL: 
DLL: - - - - - Datalink Header - - - - -
DLL: 
DLL: Frame 0 arrived at 9257 milliseconds, length = 60 bytes
DLL: 
DLL: Destination Address            = 08-00-2B-0D-E6-B4 (08002B0DE6B4)
DLL: Source Address                 = AA-00-04-00-53-04 (TAURUS)
DLL: DIX format, Protocol Type      = 60-02
MOPRC: 
MOPRC: - - - - - Maintenance Operation Protocol (MOP) - - - - -
MOPRC: 
MOPRC: Message Length                 = 4
MOPRC: 
MOPRC: Function Code                  = 9 (RequestCounters)
MOPRC: 
MOPRC: Receipt Number                 = 0004

** Hex for frame 0 **

0000: 08 00 2B 0D E6 B4 AA 00 04 00 53 04 60 02 04 00    ..+.......S.�
 ...  
0010: 09 04 00 00 00 00 00 00 00 00 00 00 00 00 00 00   
 ................  
0020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ....
............  
0030: 00 00 00 00 00 00 00 00 00 00 00 00                ............  
    

IRIS capture data                                                    
 Page   2
Trames entre TAURUS et PC0MX1                                11/20/92
 17:06:08


** Summary for frame 1 **

     1    +6m       TAURUS<-08002B0DE6B4   71  DIX 6002     MOPRC
 Counters
                                                            DLL DIX
 PType=60-02

** Detail for frame 1 **

DLL: 
DLL: - - - - - Datalink Header - - - - -
DLL: 
DLL: Frame 1 arrived at 9263 milliseconds, length = 71 bytes
DLL: 
DLL: Destination Address            = AA-00-04-00-53-04 (TAURUS)
DLL: Source Address                 = 08-00-2B-0D-E6-B4 (08002B0DE6B4)
DLL: DIX format, Protocol Type      = 60-02
MOPRC: 
MOPRC: - - - - - Maintenance Operation Protocol (MOP) - - - - -
MOPRC: 
MOPRC: Message Length                 = 55
MOPRC: 
MOPRC: Function Code                  = 11 (Counters)
MOPRC: 
MOPRC: Receipt Number                 = 0004
MOPRC: Counter Data, 52 bytes

** Hex for frame 1 **

0000: AA 00 04 00 53 04 08 00 2B 0D E6 B4 60 02 37 00    ....S...+...`
 .7.  
0010: 0B 04 00 FF FF BD 5B 84 73 F6 F8 8E 05 14 3E 01   
 ......[.s.....>.  
0020: 01 1D 27 16 00 0D 76 D9 15 CA 55 35 00 DA 0D 01   
 ..'...v...U5....  
0030: 00 BF 16 00 00 C7 29 00 00 00 00 00 00 2E 00 FF   
 ......).........  
0040: FF 00 00 00 00 00 00                               .......       
    

    
    

Hi Renato,

I wanted to add some clarification re: .10:

You are correct in stating that the counters data portion of the return packet
is 52 bytes.  In my reply in .9, I included the ID (1 byte) and the receipt 
number (2 bytes) when I referred to my counter packet of 55 bytes.  We are 
both looking at packets which are the same size :-)

Regardless, both MUXserver 100's are not returning MOP counters correctly:
          Since   MOPV3 counters are 57 bytes long 
                  (54 w/out the ID and receipt number)
            and   MOPV4 counters are 203 bytes long 
                  (200 w/out the ID and receipt number)
the MUXserver 100 packet size of 55 bytes (or 52 bytes) is still incorrect.

>>>> I hope this problem will be solved in a future version (V1.2.3 ?).

This is a bug in the agent, not in DECmcc/Ethernet AM!
The MUXserver 100 did not implement the MOP counters correctly.  If you need
this problem solved, try a hardware/microcode update. 

Regards,

Linda

BTW -  QAR #161 from MCC013_INT for a similar problem was CLOSED since 
       'Management Protocol Error' is the correct exception to display
       when the return counter packet size is too small.  Also the 
       'Cannot communicate with target' and the 'Management Protocol Error' 
       error messages toggling was not reproducible.
    

The error is in the MUXserver 100 software, you can also see the same error in
old versions of the DECserver 100, DECserver 200, DECserver 250, and MUXserver 300
all of which were modified from the origional DECserver 100 code.

The MUXserver 100 is now maintained by CSS in Merrimack, the last contact name
I have is Dave Smolinski (SOLVIT::SMOLINSKI).

Peter.

Management stations  should do their best to function even when networks are
broken.  That includes when things are broken due to software bugs.

Given the  amount  of  broken hardware out there, and the fact that they all
fail  in  exactly the same way (leaving out the same counter) it seems to me
that  to  be  a  useful product DECmcc should add code to handle this broken
hardware.

Of course, I don't expect the implementors to handle this in advance but now
that  it  has  been identified DECmcc should treat it as an important change
for  the  next  release.   Even if sustaining engineering fix the ROMs there
won't  be  a  worldwide mandatory FCO, will there? There is no point whining
about  it  being someone else's bug: your product (DECmcc) is broken by this
bug so you need to work round it.

Graham

    The MUXserver 100 problem is in the DOWNLINE LOADED software not in the
    ROMS.
    
    Peter.

RE: 4049.13  MARVIN::COBB "Graham R. Cobb (DECNIS development), REO
    Title:  Management stations should work

>  Management stations  should do their best to function even when networks
>  are broken.  That includes when things are broken due to software bugs.

 I agree completely with the above statement!  BTW, You have no idea how
 much "special case code" exists in the Ethernet based (and SNMP) AMs to
 handle "differences" in agent implementation...


> Given the  amount  of  broken hardware out there, and the fact that they all
> fail  in  exactly the same way (leaving out the same counter) it seems to me
> that  to  be  a  useful product DECmcc should add code to handle this broken
> hardware.

 The MOP Counters packet is a block of data (no encoding) with fixed
 offsets for each of the counter values. How does one "leave out a counter"
 and expect anything to work?

 Do you (or does anyone reading this) have a spec that documents how
 MUXserver 100 actually implemented MOP Counters?
 
						Chris

The MUXserver 100 software when it receives the MOP Counter request message, 
grabs some memory and copies a selection of its internal counters into the buffer
the buffer is then transmitted. The only problem is that the size of the 
transmitted buffer is not calculated correctly, its Two Bytes too small.

The only documentation is the MOP V3 spec, and the code (of which my only copy 
has been archived)

Peter.

Thanks for the response, Chris.

>  The MOP Counters packet is a block of data (no encoding) with fixed
>  offsets for each of the counter values. How does one "leave out a counter"
>  and expect anything to work?

I meant  by  special-casing  based on the packet length.  .16 seems to imply
that  it  is  the last counter that is missing.  I seem to remember that the
MOP  architecture  already  includes  some such special cases (if the packet
length is XX assume counter YY is missing) so this adds to those.

It might  be  nice  to just assume that whenever a short message is received
it should be treated as valid but with the last N counters missing.

Graham

In the MUXserver 100 case the two bytes missing are half of a 32 bit counter.

But I agree its a good idea. 

I also think that the broken products should be fixed, but in the 
MUXserver 100 case, I think that that is unlikely.

Peter.