[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

1191.0. "etherenet station, SUN, HP and Mac ?" by MEO78B::MCCOY (want peace ? -> work for justice) Thu Jun 27 1991 08:20

    My customer has been trying to work with SUN and HP workstations as
    Ethernet Stations without success.   VMS 5.4-2, MCC V1.1
    
    The station module should I believe support the command
    	show station <ether-address> all char
    without the station being registered.  This command works fine against
    DEC and Vitalink devices, but fails with Sun, HP and Mac ethernet
    cards.
    
    On a Sniffer, we see two nearly identical sets of 4 Ethernet frames
    being transmitted with no replies - the first set is identified as
    MOPRC, and the second  as XID Frame, DSAP=00, SSAP=02.   Other traffic
    flows freely between the same address(es)
    
    Does the customer need to qualify the show station with a 'function
    supported' or other qualifier ?
T.RTitleUserPersonal
Name		DateLines
1191.1Try TEST STATION <addr>, FUNCT SUPP=ENETV2_ONLYALLZS::MORRISONThe world is a networkThu Jun 27 1991 11:3120
    I wouldn't expect non-DEC systems to respond to MOP Request-ID (what
you're seeing as MOPRC frames).  That's a DEC-specific protocol.  However,
if the systems are 802.2 compliant, they should support XID & TEST, and if
they're not they should support the Ethernet V2 loopback message.  XID
is sent by

	MCC> SHOW STATION <address> ALL CHAR

if the station is registered as FUNCTIONS_SUPPORTED = IEEE8802_ONLY or if
the station is not registered and doesn't respond to a Request-ID.  TEST
and Ethernet V2 loopback are sent by the TEST command, again based on the
FUNCTIONS_SUPPORTED (TEST for IEEE802_ONLY & DEC_IEEE802, Ethernet V2 loop
for DEC_ENETV2 & ENETV2_ONLY).

> Does the customer need to qualify the show station with a 'function
> supported' or other qualifier?

You cannot specify FUNCTIONS_SUPPORTED on a SHOW, only on TEST & REGISTER.

						Wayne
1191.2SUBWAY::REILLYMike Reilly - New York Bank DistrictThu Jun 27 1991 12:2817
    The Sun machines are not 802.2 compliant with their standard device
    drivers and thus will not respond to the the LLC TEST or XID
    messages.  The Macs when running PATHworks are 802.2 compliant but
    the access module is not able to interpret the responses they send
    back, thus Macs appear unreachable.
    
    The PING AM may have  the 'lowest' level test you will be able to
    perform on the SUN and HP machines.
    
    If you still have access to the Sniffer then try the tests mentioned
    in the previous note against a Lanbridge 200.  The LB200 will
    respond to both REQ ID's and 802.2 TEST and XID directives. You will
    be able to see the various packet formats and their correct
    responses.
    
    - Mike
1191.3PATHworks 802.2 response?CHRISB::BRIENENDECmcc Bridge|Station|SNMP Management.Thu Jun 27 1991 15:1712
Mike mentioned, in the previous reply:

   "The Macs when running PATHworks are 802.2 compliant but
    the access module is not able to interpret the responses they send
    back, thus Macs appear unreachable."

What's being passed back for XID and TEST?

Anyone care to drop some packet traces here so that we can have a look?

					Chris Brienen
					Stations 'R' Us
1191.4more info on .0MEO78B::MCCOYwant peace ? -&gt; work for justiceThu Jun 27 1991 20:467
    Thanks for the replies folks.
    
    Does anyone have experience with HP ??  Also the Macs at this site are
    not in a Pathworks environment - they are running non-Digital TCP/IP
    software - NCSA Telnet (some direct TCP/IP and others TCP/IP
    encapsulated in Appletalk) and the Columbia Appletalk Package.
1191.5answer for HP.HERON::MORALESDEC:.VBO.ACT.DECmcc|828-5383Thu Jun 27 1991 21:418
    
    	Hi Andrew,
    
    most of the HP I tested with the Enet AM answered to the IEEE802 test.
    So they can be registered as station with supp function=IEEE802_only.
    
    		Manuel.
1191.6Waiting for a Sniffer AM....SUBWAY::REILLYMike Reilly - New York Bank DistrictFri Jun 28 1991 16:42120
    
    Here is a trace of an 802.2 TEST to a MAC running PATHworks.
    The MAC responds with a valid 802.2 reply but the length field is
    less than the AM expects.
    
    MCC> TEST STATION AA-00-04-00-06-25 FUN SUPPRORTED IEEE802_ONLY
    
    From Sniffer:
    
    - - - - - - - - - - - - - - - - Frame 1  - - - - - - - - -- - - - --
    
    SUMMARY  Delta T     Destination   Source        Summary
    M    1            MAC          DECmcc            DSAP=00, TEST frame
    
    ???:  ----- SAP data -----
    ???:
    ???:  [32 bytes of information]
    ???:
    
    ADDR  HEX                                                ASCII
    0000  AA 00 04 00 06 25 AA 00  04 00 9F 25 00 23 00 02 .....%.....%.#..
    0010  E3 00 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              ............
    
    >>> Packet length is 23 hex, AM requests a TEST. 
    
    - - - - - - - - - - - - - - - - Frame 2 - - - - - - - - - - - - - -
    
    
    SUMMARY  Delta T     Destination   Source        Summary
         2    0.0003  DECmcc       MAC           LLC R D=02 S=00 TEST
    
    LLC:  ----- LLC Header -----
    LLC:
    LLC:  DSAP = 02, SSAP = 00, Response, Unnumbered frame: TEST
    LLC:
    
    ADDR  HEX                                                ASCII
    0000  AA 00 04 00 9F 25 AA 00  04 00 06 25 00 03 02 01 .....%.....%....
    0010  E3 00 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             ............
    
    >>	The Mac sends a valid response frame but the length field is
    set to only 3 bytes.
    
    Below is a trace of an 802.2 XID packet.
    
    
    MCC> show station aa-00-04-00-06-25 all char
    
    Sniffer shows 4 REQ ID packets from the DEcmcc station and then one
    802.2 XID packet.
    
    
    - - - - - - - - - - - - - - - - Frame 7 - - - - - - - - - - - - - -
    
    SUMMARY  Delta T     Destination   Source        Summary
         7   15.0462  MAC          DECmcc            DSAP=00, XID frame
    
    ???:  ----- SAP data -----
    ???:
    ???:  [6 bytes of information]
    ???:
    
    ADDR  HEX                                                ASCII
    0000  AA 00 04 00 06 25 AA 00  04 00 9F 25 00 09 00 02 .....%.....%....
    0010  AF 01 02 03 04 05 06 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              ............
    
    
    >>> the XID frame has a data length of 09, and has place holders
    for up six response bytes.  
    
    - - - - - - - - - - - - - - - - Frame 8 - - - - - - - - - - - - - -
    
    
    SUMMARY  Delta T     Destination   Source        Summary
         8    0.0003  DECmcc       MAC           LLC R D=02 S=00 XID
    
    LLC:  ----- LLC Header -----
    LLC:
    LLC:  DSAP = 02, SSAP = 00, Response, Unnumbered frame: XID
    LLC:
    LLC:  IEEE 802.2 Basic Format ID = 81
    LLC:  Class of service = 01
    LLC:         .... ...1 = Class I (connectionless)
    LLC:         .... ..0. = Not Class II
    LLC:  Window size = 0
    
    ADDR  HEX                                                ASCII
    0000  AA 00 04 00 9F 25 AA 00  04 00 06 25 00 06 02 01 .....%.....%....
    0010  AF 81 01 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             ............
     
    
    >>> the Mac responds with a packet which has a data length of only
    06 bytes.  It has filled in values for only the first 3 bytes of the
    response. 
    
    Changing the code so that it accepts response frames whose length 
    are not the same as the transmitted frame should solve this problem.
    
    - Mike  
    
    BTW:	When the AM gets ID information from an XID frame or a
    REQ ID frame and that value is not 'known' to the AM it displays
    an 'Unrecognised device ID' message in the Implimentation field.
    I would prefer if the AM displayed the contents of the device
    ID fields from these packets.  A message like:
     
    	Unrecognised device ID nn nn nn nn nn 
    
    would be more informative.
    
    - Mike
1191.7More information (and questions)CHRISB::BRIENENDECmcc Bridge|Station|SNMP Management.Fri Jun 28 1991 20:0748
And Mike delivers yet again (give that guy a raise!) !

Problem #1a: TEST STATION
-------------------------
The IEEE 802.2 book states that an agent is not required to loopback data
on a TEST, but must at least respond.

The command:  TEST STATION <addr> FUNC SUPP = IEEE802_ONLY
handles the "no data" case with the exception mcc_k_no_data_returned,
which should display as something like "Data not returned as requested".

Two problems here: 1) this should be a RESPONSE not an EXCEPTION and
                   2) the message itself ambiguous (does something
                      like "Station responded, but without data"
                      sound better?  Any suggestions?)

[Question]
Mike, Could you verify that this is the message you're getting on the
TEST failure (and not something like "Cannot Communicate" or "Data
returned is invalid").

Problem #1b: REGISTER STATION
-----------------------------
When the REGISTER STATION is issued with FUNC SUPP = IEEE802_ONLY, the
Ethernet AM uses TEST to verify a Station's existence. Since the
mcc_k_no_data_returned is not a failure, the AM's Register code should
be allowing the register to occur (which it obviously is not).

This should (and will) be fixed in the DECmcc V1.2 version of Ethernet AM.

[Question]
Assuming my analysis is correct, does anyone view this problem as serious
enough for us to generate a patch for the AM?

Problem #2: XID
---------------
I'm less familiar with DECmcc's XID code, since it's buried in the
mcc_ea exec routines (Wayne will have to look at this when he gets back
from vacation).

In the short term, can two things be done?
 1. Tell us what the error message is coming back from the SHOW STATION
    request to the PATHworks MAC (is it just "Cannot Communicate"?).
 2. $define mcc_enet_am_log 26
    and post the results here (It'll indicate to us whether the data
    is being lost in MCC_EA or the Ethernet AM).

						Chris
1191.8MCC_ENET_AM_LOG trace...SUBWAY::REILLYMike Reilly - New York Bank DistrictWed Jul 03 1991 12:49146
    
    Chris,
    	When I use the TEST STATION <addr> FUN SUP = IEEE802_ONLY I do
    not get a "Data not returned as requested" message but a "Cannot
    communicate with target" message.  
    
    Logs of a TEST STATION, SHOW ALL CHAR and a SHOW ALL IDENT are
    included here:
    
    _ Mike
    
$MCC

DECmcc (V1.1.0)

MCC> TEST STATION AA-00-04-00-06-25 fun supported ieee802_only

*
* Module mcc_enet_am_test entry point
*  3-JUL-1991 11:25:52.97
*
*
* mcc_enet_am__do_802_test -> mcc_ea_test_802_loopback. request:
*  3-JUL-1991 11:25:55.80
*
* Buffer Dump :
* Buffer Address = 001622C8  (   1450696 dec)
* Buffer size    = 00000020  (        32 dec)
*
*                    Hex                                 Ascii        Offset
* 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................  00000010
* 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................  00000020
*
*
* Module mcc_enet_am_test exit point
*  3-JUL-1991 11:25:55.87
*

STATION AA-00-04-00-06-25 
AT  3-JUL-1991 11:25:55 

Cannot communicate with target


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

MCC> SHOW STATION AA-00-04-00-06-25 ALL CHAR

*
* Module mcc_enet_am_show entry point
*  3-JUL-1991 11:26:19.63
*
*
* mcc_enet_am__call_cea REQUEST:
*  3-JUL-1991 11:26:22.01
*
* Buffer Dump :
* Buffer Address = 7FF18C30  (2146536496 dec)
* Buffer size    = 00000004  (         4 dec)
*
*                    Hex                                 Ascii        Offset
* 05 00 01 00                                      ....              00000004
*
*
* mcc_enet_am__call_cea Completed. RESPONSE:
*  3-JUL-1991 11:26:40.64
*
* Buffer Dump :
* Buffer Address = 7FF18E5C  (2146537052 dec)
* Buffer size    = 00000000  (         0 dec)
*
* Incorrect Buffer for hex dump procedure
*
*
* mcc_enet_am__call_cea REQUEST:
*  3-JUL-1991 11:26:40.66
*
* Buffer Dump :
* Buffer Address = 00000000  (         0 dec)
* Buffer size    = 00000000  (         0 dec)
*
* Incorrect Buffer for hex dump procedure
*
*
* mcc_enet_am__call_cea Completed. RESPONSE:
*  3-JUL-1991 11:26:40.70
*
* Buffer Dump :
* Buffer Address = 7FF18F68  (2146537320 dec)
* Buffer size    = 00000003  (         3 dec)
*
*                    Hex                                 Ascii        Offset
* 81 01 00                                         ...               00000003
*
*
* Module mcc_enet_am_show exit point
*  3-JUL-1991 11:26:40.72
*

STATION AA-00-04-00-06-25 
AT  3-JUL-1991 11:26:40 Characteristics

Cannot communicate with target


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



MCC> SHOW STATION AA-00-04-00-06-25 ALL IDENTIFIERS

*
* Module mcc_enet_am_show entry point
*  3-JUL-1991 11:26:46.43
*
*
* mcc_enet_am__call_cea REQUEST:
*  3-JUL-1991 11:26:48.77
*
* Buffer Dump :
* Buffer Address = 7FF18BA0  (2146536352 dec)
* Buffer size    = 00000004  (         4 dec)
*
*                    Hex                                 Ascii        Offset
* 05 00 02 00                                      ....              00000004
*
*
* mcc_enet_am__call_cea Completed. RESPONSE:
*  3-JUL-1991 11:27:07.36
*
* Buffer Dump :
* Buffer Address = 7FF18E34  (2146537012 dec)
* Buffer size    = 00000000  (         0 dec)
*
* Incorrect Buffer for hex dump procedure
*
*
* Module mcc_enet_am_show exit point
*  3-JUL-1991 11:27:07.38
*

STATION AA-00-04-00-06-25 
AT  3-JUL-1991 11:27:07 Identifiers

Cannot communicate with target
1191.9Update on problems.CHRISB::BRIENENDECmcc Bridge|Station|SNMP Management.Tue Jul 09 1991 18:2050
1. From the packet traces/dumps supplied by Mike Reilly, the Enet AM
   (or routine mcc_ea_test_802_loopback) clearly has a problem on
   TEST STATION <id> FUNC SUPP IEEE802_ONLY. The command should be
   returning the "Data not returned as requested" exception.
   ** QAR #762 has been filed to track this bug **

   [Mike, could you try the above command, adding  "DATA SIZE = 0" ?]

2. The TEST problem above is probably partially (but not totally)
   responsible for the REGISTER STATION failure (since TEST is used
   to verify connectivity).
   ** QAR #763 has been filed to track this bug **

3. We don't believe that the XID problem is the fault of Ethernet AM.
   The response packet (as recorded by Mike in note 1191.6) violates
   the 802.2 specs.

   The response should be something like the following:

    81 80 xx	(for LLC Class I)
	or
    81 C0 xx	(for LLC Class II)
    ...where xx = the hex value of the receive window size, and is
       between 00 and 7F.

    We should probably be returning "Protocol Error" instead of
    "Cannot Communicate" for this one (I'll add this to the Enet AM
    V1.2 list).

4. The value for Implementation field comes from a REQUEST-ID/SYSID
   (i.e. DEC_ENETV2 and DEC_IEEE802). The field is of datatype enumeration.
   The AM, upon receiving a code outside the recognized range, forces
   it to be the code for 'Unrecognised device ID' so that the FCL will
   display it. The FCL currently STOPS PROCESSING an attribute list
   when it encounters a code outside the defined values. When FCL PM
   fixes this (and maybe returns the attribute code like Mike suggested
   in 1191.6), we will change our code to pass back the "real" code.
   ** I believe a QAR against the FCL PM is already open **

We will have problems 1 and 2 fixed in DECmcc V1.2 Ethernet AM.
Whether a patch for V1.1 will be available depends on demand
and on how hard the problem is to fix without recompiling (there's
still lotsa work to do for V1.2)...

					Chris Brienen
1191.10Works, almost!!SUBWAY::REILLYMike Reilly - New York Bank DistrictWed Jul 10 1991 14:0215
    A MCC> TEST STATION <id> fun supp IEEE802_ONLY, data size = 0
    
    worked correctly. TESTs with data size up to 10 also worked.  With
    a data size greater than 10 the test failed. 
    
    A trace with a Sniffer showed the Mac responds with the correct
    data length for TESTs with data up to 10 bytes.  If the data field
    in the TEST request frame is larger than 10 bytes the Mac returns a
    frame with NO data !!! 
    
    I guess a patch that modifies the default data size for TESTs to less
    than 10 bytes would solve this one.
    
    - Mike