Conference help::decnet-osi_for_vms

3863.0. "Triggering a VXT doesnt work under V6.3-6 (Alpha)" by TAGAUS::AURAND () Mon Feb 10 1997 10:14

Hi, 

a customer of us has problems loading/triggering a VXT2000 from a Alpha system 
running DECnet/OSI V6.3-ECO#6. The problem only occurs if the boot process is
triggered from the loadhost via the NCL LOAD or BOOT command, the Alpha sends 
out a BOOT MOP message but it didn't get any message back from the VXT (see
the MOP trace below)

The customer told me, that the Ethernetaddresse, the Maintenance Password for 
the MOP Client are correct and that the load image is located under MOM$SYSTEM

The customer has also received the following new NET$MOP image:

 Image Identification Information
  image name: "NET$MOP"
  image file identification: "V6.3-ECO06"
  image file build identification: ""
  link date/time: 20-DEC-1996 16:12:19.80
  linker identification: "T11-11"

It seems to be the same problem already mentioned in CFS_32529 for V6.2, is this
behaviour also known under V6.3-ECO36

	Many thanks in advance

		Andreas                                  


1. MOP circuit

Node 0 MOP Circuit CSMACD-0
at 1997-02-05-13:38:22.138+01:00I258.756

Identifiers

    Name                              = CSMACD-0

Status

    UID                               = 53814513-7F4F-11D0-8004-AA0004008C46
    Functions                         = 
       {
          Loop Requester ,
          Console Requester ,
          Load Server ,
          Dump Server ,
          Test Requester
       }

Characteristics

    Type                              = CSMA-CD
    Link Name                         = CSMA-CD Station CSMACD-0
    Retransmit Timer                  = 4
    Known Clients Only                = False

Counters

    Creation Time                     = 1997-02-05-11:59:47.387+01:00Iinf
    Load Requests Completed           = 2
    Unrecognized Load Clients         = 0
    Failed Load Requests              = 0
    Dump Requests Completed           = 0
    Unrecognized Dump Clients         = 0
    Failed Dump Requests              = 0

2. MOP Circuit Entry: 

Node 0 MOP Client IZXT01
at 1997-02-05-13:38:54.065+01:00I258.759

Identifiers

    Name                              = IZXT01

Characteristics

    Circuit                           = CSMACD-0
    Addresses                         = 
       {
          08-00-2B-90-01-F6 ,
          AA-00-04-00-BF-46 (LOCAL:.IZXT01)
       }
    Secondary Loader                  = 
       {
       }
    Tertiary Loader                   = 
       {
       }
    System Image                      = 
       {
          
          VXT020.SYS
       }
    Diagnostic Image                  = 
       {
       }
    Management Image                  = 
       {
       }
    Script File                       = 
       {
       }
    Phase IV Host Name                = IZBL02
    Phase IV Host Address             = 17.652
    Phase IV Client Name              = IZXT01
    Phase IV Client Address           = 17.703
    Dump File                         = 
       {
       }
    Dump Address                      = 0
    Verification                      = '1234567890ABCDEF'H
    Device Types                      = 
       {
       }

3. MOP Trace

CTF V1.0-00                                                       Page 1        
Trace started on  5-FEB-1997 16:38:23.66  Analyzed on  5-FEB-1997 16:43:50.33   
Trace File [SYSMGR]MOP.DAT;1            Output File [SYSMGR]TRACE1.LIS;1        
-----------+----+-----+-------+-------------------------------------------------
    Time   |Evnt|Data |MOP    |Parameters                                       
hh mm ss cc|    |Size |MsgType|                                                 
-----------+----+-----+-------+-------------------------------------------------
16:38:23.66|  Tx|   12|Boot   |Verif=12 34 56 78 90 AB CD EF  Proc=System  From=
Default  SoftID=OpSys
16:38:23.66|  Tx|   12|Boot   |Verif=12 34 56 78 90 AB CD EF  Proc=System  From=
Default  SoftID=OpSys
16:38:23.66|  Tx|   12|Boot   |Verif=12 34 56 78 90 AB CD EF  Proc=System  From=
Default  SoftID=OpSys
16:38:23.66|  Tx|   12|Boot   |Verif=12 34 56 78 90 AB CD EF  Proc=System  From=
Default  SoftID=OpSys
16:38:58.70|  Tx|   12|Boot   |Verif=12 34 56 78 90 AB CD EF  Proc=System  From=
Default  SoftID=OpSys
16:38:58.70|  Tx|   12|Boot   |Verif=12 34 56 78 90 AB CD EF  Proc=System  From=
Default  SoftID=OpSys
16:38:58.70|  Tx|   12|Boot   |Verif=12 34 56 78 90 AB CD EF  Proc=System  From=
Default  SoftID=OpSys
16:38:58.70|  Tx|   12|Boot   |Verif=12 34 56 78 90 AB CD EF  Proc=System  From=
Default  SoftID=OpSys
16:39:39.42|  Tx|   12|Boot   |Verif=12 34 56 78 90 AB CD EF  Proc=System  From=
Default  SoftID=OpSys
16:39:39.42|  Tx|   12|Boot   |Verif=12 34 56 78 90 AB CD EF  Proc=System  From=
Default  SoftID=OpSys
16:39:39.42|  Tx|   12|Boot   |Verif=12 34 56 78 90 AB CD EF  Proc=System  From=
Default  SoftID=OpSys
16:39:39.42|  Tx|   12|Boot   |Verif=12 34 56 78 90 AB CD EF  Proc=System  From=
Default  SoftID=OpSys
16:40:53.58|  Tx|   12|Boot   |Verif=12 34 56 78 90 AB CD EF  Proc=System  From=
Default  SoftID=OpSys
16:40:53.59|  Tx|   12|Boot   |Verif=12 34 56 78 90 AB CD EF  Proc=System  From=
Default  SoftID=OpSys
16:40:53.59|  Tx|   12|Boot   |Verif=12 34 56 78 90 AB CD EF  Proc=System  From=
Default  SoftID=OpSys
16:40:53.59|  Tx|   12|Boot   |Verif=12 34 56 78 90 AB CD EF  Proc=System  From=
Default  SoftID=OpSys
16:42:06.33|  Tx|   12|Boot   |Verif=12 34 56 78 90 AB CD EF  Proc=System  From=
Default  SoftID=OpSys
16:42:06.33|  Tx|   12|Boot   |Verif=12 34 56 78 90 AB CD EF  Proc=System  From=
Default  SoftID=OpSys
16:42:06.33|  Tx|   12|Boot   |Verif=12 34 56 78 90 AB CD EF  Proc=System  From=
Default  SoftID=OpSys
16:42:06.33|  Tx|   12|Boot   |Verif=12 34 56 78 90 AB CD EF  Proc=System  From=
Default  SoftID=OpSys

I'd suggest getting a LAN trace from as close to the VXT as possible.

As there are two addresses given for the client the host should send 4 (FOUR)
MOP boot or load messages (1 for each address in both MOP V3 and MOP V4
formats). You can't tell from the MOP trace what the LAN frames actually look
like.

When I was testing DECnet/OSI I found the same problem.  I QAR'd it and Ken
Roberts closed it as being fixed.  Aparently not.  Here's the QAR with the
analysis:

-------------------------------------------------------------------------------

QAR # St Sev Pub Cat Maintainer   Component  T Entered-by   Date in     Answer
----- -- --- --- --- ------------ ---------- - ------------ ----------- ------
02319 CL  H  Yes FN  QD_ROBERTS   MOP        M QD_FOX       12-SEP-1995 24-JUL
MOP unable to boot/trigger VXT2000

Site name:        Y5H, NSTG, 96183
Product/Version:  DECNET/OSI V6.2               CPU type:  VAXSTATION
Op Syst/Version:  OPENVMS    V5.5-2
Fixed in release: V7.      Date fixed:

QAR 02319  Version V6.2      12-SEP-1995 11:26:28.6

-- Submitted by --                      -- DIGITAL contact --
DAVID B. FOX (ESE)                      NSTG::FOX
Y5H, NSTG, 96183                        N/A
ARV020                                  RZXX, RFXX, RRD42, TZXX
NSTG LAB @ LKG
DTN 226-5007, LAB=226-7620, 7373 NIO/B18

Attachments: NONE                      		Customer severity: H
Reproducible at will: Y

CPU        Memory     System device
VAXSTATION 32 - 256 M RZXX





Bryan is aware of this issue... DECnet/OSI Notes Conference #2881

Evidently MOP on Phase IV sends out a BOOT or TRIGGER request with the code
for the standard operating system (FF 00 00).  This works properly and thus
can remotely boot or trigger a VXT 2000.  On Phase V, MOP sends no software
id (00 00 00).  The VXT ignores the request.

There may be a MOP spec issue here that Bryan is going to take a look at.  VXT
Engineering is currently looking at 2 - 3 IPMT cases against this problem.

The elevation contact in VXT Engineering is Grace Mai at HANNAH::MAI.

I'm entering this QAR on behalf of Grace and Bryan.

	David

%QAR-I-MODASSIGN, modified during assignment by QD_FOX at 12-SEP-1995 11:36:12.25

QAR reassigned, hopefully, to Bryan Williams


Answer for QAR #02319:
------ --- ------- -------
	Thanks for the QAR.  This problem got fixed in NET$MOP a while ago and
	is now included in the ECO kits for our supported releases.

Ken Roberts
DECnet/OSI Engineering

-------------------------------------------------------------------------------

The node that this error occured on was an Alpha.  Same environment.  I'd
recommend an IPMT case to re-open this QAR.

	David