| 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 |
I've encountered the following two problems with the End-Station AM.
1. When an 802.2 TEST packet is sent to a Macintosh, the Mac responds but
the AM still states the node is unreachable.
Command used:
MCC>test station aa-00-04-00-00-06-25 fun sup ieee802_only
STATION AA-00-04-00-06-25
AT 3-MAY-1991 12:24:20
Cannot communicate with target
An Ethernet trace shows an 802.2 LLC frame with the following data
being sent from the AM to the Mac.
Destination Address
Source Address
Length = X23 35 bytes
DSAP = X00 Individual DSAP 00
SSAP = X02 Command SSAP 02
Control = XE3 TEST function code
Data = All Nulls
Padding
The MAC responds:
Destination Address
Source Address
Length = X03 3 bytes
DSAP = X02 Individual DSAP 02
SSAP = X01 Response SSAP 00
Control = XE3 TEST function code
Data = no Data as Length is only 3 octets
Padding
The response from the Mac appears to be a valid response to a TEST,
but it's data field has no data. I have not seen any information
that states that a TEST response must have a data field the same
length at the frame which initiated the TEST.
2. Second problem.
Over the weekend our cluster was upgraded to VMS 5.4-2. This
upgrade appeared to have solved problem 1 above and many other 802.2
related problems, as all devices which previously didn't respond to
end station TEST directives now worked. After a few minutes I
realized that ALL devices which FAIL the end station 802.2 test are
now begin reported as PASSING the test.
eg:
MCC> test station 12-34-56-78-90-12 fun sup ieee802_only
STATION 12-34-56-78-90-12
AT 8-MAY-1991 13:02:54
Test successful.
MCC>
I would appreciate if some other user of VMS 5.4-2 try the above
test and see if it passes for you. The example below is copy of one
of the 'new' end station I now have registered:
MCC> register station .station.dummy fun sup ieee802_only
ADDRESS = 12-34-56-78-90-99
STATION JPM_DEV:.station.dummy
AT 8-MAY-1991 13:07:51
Registration successful.
MCC> show station .station.dummy all attributes
STATION JPM_DEV:.station.dummy
AT 8-MAY-1991 13:08:48 All Attributes
Address = 12-34-56-78-90-99
Name = JPM_DEV:.station.dummy
Responding Address = 12-34-56-78-90-99
Functions Supported = IEEE802_Only
Implementation Desc = ""
Location = ""
MAIL Account = ""
Phone Number = ""
Remarks = ""
Responsible Person = ""
Text File = ""
MCC>
Where did the responding address field come from ?
- Mike
| T.R | Title | User | Personal Name | Date | Lines |
|---|---|---|---|---|---|
| 995.1 | ALLZS::MORRISON | The world is a network | Thu May 09 1991 18:47 | 26 | |
> I've encountered the following two problems with the End-Station AM. > > 1. When an 802.2 TEST packet is sent to a Macintosh, the Mac responds but > the AM still states the node is unreachable. Since we don't have a Macintosh around here, this one's going to be difficult to test. We'll see if we can check this one out via code inspection and the information you've provided. > 2. Second problem. > > Over the weekend our cluster was upgraded to VMS 5.4-2. This > upgrade appeared to have solved problem 1 above and many other 802.2 > related problems, as all devices which previously didn't respond to > end station TEST directives now worked. After a few minutes I > realized that ALL devices which FAIL the end station 802.2 test are > now begin reported as PASSING the test. We've been unable to reproduce this problem with a cluster running VMS V5.4-2 and DECmcc V1.1.0 (which I assume is the version you're running?). This all works as expected. Can you tell us more about your environment? Perhaps we can figure out what's going on with a bit more information about your system type, ethernet device, DECmcc version, network environment, etc. Wayne | |||||
| 995.2 | Configuration Information | SUBWAY::REILLY | Mike Reilly - New York Bank District | Fri May 10 1991 15:09 | 20 |
The system I'm using is a VAXstation 3100 M38 which is part of a
LAVC. Using DECmcc 1.1.
An $ANAL/IMAGE of mcc_enet_am.exe shows:
Image Identification Information
image name: "MCC_ENET_AM"
image file identification: "DECMCC V1.1"
link date/time: 24-FEB-1991 16:37:28.66
linker identification: "05-05"
This system is running UCX, DNS client, RDB, DFS and the LAST
drivers for access to an Infoserver 100.
Network environment is a large multi-vendor E-LAN with approx 2,000
devices.
- Mike
| |||||
| 995.3 | ALLZS::MORRISON | The world is a network | Fri May 10 1991 17:17 | 6 | |
RE: .-1 You just described the environment that I used to attempt to reproduce your problem. If nobody else has seen this (and I haven't heard anyone else say so), then why don't we try to resolve this off line via email and/or telephone. Wayne | |||||