| Title: | DECnet/OSI for OpenVMS |
| Moderator: | TUXEDO::FONSECA |
| Created: | Thu Feb 21 1991 |
| Last Modified: | Fri Jun 06 1997 |
| Last Successful Update: | Fri Jun 06 1997 |
| Number of topics: | 3990 |
| Total number of notes: | 19027 |
A machine running ELN has an image SYSBOOT.EXE on its system disk. Under phase IV DECNET, issuing a NCP TRIGGER nodename caused the system to boot SYSBOOT.EXE from its default boot device. This is the expected behaviour. Under phase V decnet, we expect issuing a NCL BOOT MOP CLIENT nodename to perform the same action. However, issuing this command leaves the target system at the console prompt. The only difference between the PhaseIV and DECnet/OSI inituiated boot is that the DEcnet/OSI system sends MOP V4 in IEEE802.3 format first before sending a MOP V3 Ethernet boot packet. Does anyone have a workaround for this problem ? Andrew/ Cross posted in HELIX::VAXELN ---------------------------------------------------------------------- Attached are the lan capture of the phaseIV and phaseV mop boot packes. >ETHERNET: Source address : AA0004000704 is a VMS 5.5-2 phase IV host >ETHERNET: Source address : AA0004005E05 is a VMS 7.1 phase V host >(decnet+ V7.1) > >Network Monitor trace Wed 02/12/97 14:32:31 MOP1.TXT > >************************************************************************** >************************************************************************** >******* >Frame Time Src MAC Addr Dst MAC Addr Protocol Description > Src Other Addr Dst >Other Addr Type Other Addr >2 11.687 AA0004000704 DEC 9E8C5E ETHERNET ETYPE = 0x6002 : >Protocol = MOP: DEC Maintenance Operation Protoc > > > >+ FRAME: Base frame properties > ETHERNET: ETYPE = 0x6002 : Protocol = MOP: DEC Maintenance Operation >Protocol > + ETHERNET: Destination address : 08002B9E8C5E > + ETHERNET: Source address : AA0004000704 > ETHERNET: Frame Length : 60 (0x003C) > ETHERNET: Ethernet Type : 0x6002 (MOP: DEC Maintenance Operation >Protocol) > ETHERNET: Ethernet Data: Number of data bytes remaining = 46 >(0x002E) > >00000: 08 00 2B 9E 8C 5E AA 00 04 00 07 04 60 02 0C 00 > ..+..^......`... >00010: 06 00 00 00 00 00 00 00 00 00 00 FF 00 00 00 00 > ................ >00020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > ................ >00030: 00 00 00 00 00 00 00 00 00 00 00 00 ............ > > > > > >Network Monitor trace Wed 02/12/97 14:32:59 MOP1a.TXT > >************************************************************************** >************************************************************************** >******* >Frame Time Src MAC Addr Dst MAC Addr Protocol Description > Src Other Addr Dst >Other Addr Type Other Addr >6 60.584 AA0004005E05 DEC 9E8C5E SNAP ETYPE = 0x6002 > > > > >+ FRAME: Base frame properties > ETHERNET: 802.3 Length = 60 > + ETHERNET: Destination address : 08002B9E8C5E > + ETHERNET: Source address : AA0004005E05 > ETHERNET: Frame Length : 60 (0x003C) > ETHERNET: Data Length : 0x0014 (20) > ETHERNET: Ethernet Data: Number of data bytes remaining = 46 >(0x002E) >+ LLC: UI DSAP=0xAA SSAP=0xAA C > SNAP: ETYPE = 0x6002 > SNAP: Snap Organization code = 08 00 2B > SNAP: Snap etype : 0x6002 > SNAP: Snap Data: Number of data bytes remaining = 38 (0x0026) > >00000: 08 00 2B 9E 8C 5E AA 00 04 00 5E 05 00 14 AA AA > ..+..^....^..... >00010: 03 08 00 2B 60 02 06 00 00 00 00 00 00 00 00 00 > ...+`........... >00020: 00 FF 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > ................ >00030: 00 00 00 00 00 00 00 00 00 00 00 00 ............ > > > >************************************************************************** >************************************************************************** >******* >Frame Time Src MAC Addr Dst MAC Addr Protocol Description > Src Other Addr Dst >Other Addr Type Other Addr >7 60.584 AA0004005E05 DEC 9E8C5E ETHERNET ETYPE = 0x6002 : >Protocol = MOP: DEC Maintenance Operation Protoc > > > >+ FRAME: Base frame properties > ETHERNET: ETYPE = 0x6002 : Protocol = MOP: DEC Maintenance Operation >Protocol > + ETHERNET: Destination address : 08002B9E8C5E > + ETHERNET: Source address : AA0004005E05 > ETHERNET: Frame Length : 60 (0x003C) > ETHERNET: Ethernet Type : 0x6002 (MOP: DEC Maintenance Operation >Protocol) > ETHERNET: Ethernet Data: Number of data bytes remaining = 46 >(0x002E) > >00000: 08 00 2B 9E 8C 5E AA 00 04 00 5E 05 60 02 0C 00 > ..+..^....^.`... >00010: 06 00 00 00 00 00 00 00 00 00 00 FF 00 00 00 00 > ................ >00020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > ................ >00030: 00 00 00 00 00 00 00 00 00 00 00 00 ............ > > > >************************************************************************** >************************** >
| T.R | Title | User | Personal Name | Date | Lines |
|---|---|---|---|---|---|
| 3867.1 | MOP booting is a black art | MARVIN::RIGBY | No such thing as an alpha beta | Wed Feb 12 1997 09:02 | 16 |
To determine whether the MOP V4 packet is causing the problem you could try inserting a 2-port bridge between the host and the VAXELN system and blocking the 08-00-2b-60-02 PID. MOP booting is a black art, the problem is that many implementations are implemented empirically rather than in true conformance to the MOP spec. The result is that spec-legal boot frames are sometimes not processed correctly by the device being booted - the presence of the Script ID for example can cause trouble. The other problems are the complete absence of the Software ID which should be legal but doesn't work for some implementations. Even recent implementations can come unstuck, I had to fix a problem in DECNIS that crashed when it got the two BOOT requests in close together (V3 & V4) because the first was being processed when the second initiated a second restart. Perhaps something similar is happenning here. John | |||||
| 3867.2 | can you tell MOP not to send V4 ? | GIDDAY::CHONG | Andrew Chong - Sydney CSC | Sat Feb 15 1997 07:17 | 14 |
John,
I did as you suggested , filtered mop v4, let mop v3 through and
the system booted. Then did the reverse, filtered mop v3 and let mop v4
through and system halted. So it is pretty clear that the system does
not respond correctly to mop v4 boot. Unfortunately, according to
Microvax hardware engineering KA55-A (3100-85) is nolonger supported.
The customer has more then 20 of these systems.
Is there any logical which can be defined to tell MOP not to send V4
packets ?
Andrew
| |||||