| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 41.1 | problem with address returned from driver | DANZO::CARR | | Mon Jan 22 1990 15:37 | 20 |
|
This appears to be a problem with the ethernet device driver. When
the host port selected (VIA PORT) is running DECnet and the circuit has service
enabled, a sensemode QIO returns a broadcast address instead of the hardware
address. We are using the sensemode QIO to obtain the host port hardware
address. This address is included in the enet_v2 loopback message as a
forward address. Apparently when a station sends the loopback message
to all stations on the lan the high end terminal servers crash.
We are currently investigating the problem and hope to find a
reasonable work around or alternate method of finding the hardware address.
For EFT the station am will check the address returned from the QIO
before sending the enet_v2 loopback message. If the address is a broadcast
address we won't send the loopback message and the TEST directive will fail.
Until EFT we recommend that the TEST be issued only using ports
that do not have service enabled.
|
| 41.2 | Terminal Servers Shouldn't Crash so Easily! | ULTRA::MYTH | Mark T. Hollinger | Thu Mar 08 1990 11:42 | 19 |
| This problem looks interesting, so I'll throw in my two cents even though
the developers have now had over a month to investigate and have probably
gotten it fixed by now.
Based on my experience with using a SENSEMODE QIO to the Ethernet driver to
determine the local address, it will return FF-FF-FF-FF-FF-FF when a previous
SETMODE QIO has failed. For example, if DECnet had requested exclusive use
of the MOP protocol type and then MCC came along with a SETMODE asking for
that protocol type, the SETMODE would fail, and subsequent SENSEMODEs would
return incorrect information. You should be checking the returned IOSB to
determine whether the SETMODE failed. If it did, then stop right there;
return an error to the user, and don't even bother with the SENSEMODE.
In spite of the above, this is clearly a DECserver problem, not just an MCC
problem. It shouldn't be possible to crash all the DECservers on the LAN
just by sending out one badly-formed packet. I hope the QAR has been passed
along to the high-end terminal server maintainers.
Mark "MyTH"
|
| 41.3 | Agreed! | CHRISB::BRIENEN | Christopher J. Brienen | Thu Mar 08 1990 13:41 | 10 |
| RE: Note 41.2 by ULTRA::MYTH "Mark T. Hollinger"
Yes, the IOSB wasn't being checked in the (temporary) Ethernet AM
code which was attempting to get the address.
The problem has been fixed: the offending AM code has been replaced
by a call to a MCC$EA Common Routine which correctly returns this
address.
I believe the Terminal Server people have been told about this...
|
| 41.4 | | TOOK::STRUTT | Colin Strutt | Fri Mar 09 1990 09:25 | 5 |
| re: .3 I believe the Terminal Server people have been told about this...
I *know* the T/S people have been told about the problem - I told them.
Colin
|
| 41.5 | Need an update on test station | KAOFS::R_DOIRON | DECmcc ==ALL in ONE for Networks | Thu Mar 07 1991 14:01 | 10 |
| My customer has a similar problem to the base note but the server does
not crash. His problem is that if he specifies the decnet name of the
ds200, the test command fails, but the show command completes.
If he uses the ethernet address of the server both commands work.
Is using the decnet name of a server supported? He is running the
released version of the ethernet am.
Richard
|
| 41.6 | No update necessary!? | CHRISB::BRIENEN | DECmcc Bridge|Station|SNMP Management. | Thu Mar 07 1991 15:59 | 35 |
| RE: 41.5 "Need an update on test station"
The problem documented in the base note occured in temporary (aka "hack")
Ethernet AM code in an IFT base level of MCC pre-dating DECmcc V1.0.
The documented problem no longer exists.
-------
The problem you're describing is:
For a DECserver 200:
TEST STATION <station-name> ...fails
SHOW STATION <station-name> ?? ...works
TEST STATION <enet-address> ...works
SHOW STATION <enet-address> ?? ...works
(did I get it right?)
Mention of "decnet name of a server" doesn't make any sense to me, the
STATION NAME must be unique (as in: unique FullName).
I need to have the following information before I can even guess at what
the problem might be:
1. Type of system DECmcc is running on.
2. Output of: SHOW STATION station-name ALL ATTRIBUTES
(need to check ADDRESS, FUNCTION SUPPORTED, possibly ALTERNATE ADDRESS)
3. Output of: SHOW MCC 0 ETHERNET_AM ALL STATUS
SHOW MCC 0 ETHERNET_AM ALL CHARACTERISTICS
Chris Brienen
|
| 41.7 | The precise info on TEST STATION X (fails)
| KAOU15::T_ROSS | CSC/CTH : 5 years on the I-stack... | Thu Mar 14 1991 14:48 | 122 |
| Chris;
I'm filling in for Richard for note .4..
Here's an example of the customer's problem, reproduced on our in-house
3600, against a DS550. As you can see, the only command that fails is the
TEST STATION station-name command.
Username: SYSTEM
Password:
Welcome to VAX/VMS V5.3-2
Last interactive login on Thursday, 14-MAR-1991 13:37
Last non-interactive login on Wednesday, 6-MAR-1991 08:41
FATBOB> manage/ent
DECmcc (T1.1.0)
MCC> test station .mcc_station.csc550
STATION CSC:.mcc_station.csc550
AT 14-MAR-1991 13:46:02
Cannot communicate with target
MCC> test station 08-00-2b-0e-01-71
STATION CSC:.mcc_station.CSC550
AT 14-MAR-1991 13:46:19
Test successful.
MCC> show station .mcc_station.csc550 all attr
STATION CSC:.mcc_station.csc550
AT 14-MAR-1991 13:43:32 All Attributes
Address = 08-00-2B-0E-01-71
Name = CSC:.mcc_station.CSC550
Boot Supported = True
Console Carrier Reserved = False
Console Carrier Supported = True
Data Link Counters Supported = True
Dump Supported = False
Loop Supported = True
Multiblock Loader Supported = False
Primary Loader Supported = False
Receive Block Check Error Failure = False
Receive Frame Too Long Failure = False
Receive Framing Error Failure = False
Responding Address = 08-00-2B-0E-01-71
Send Carrier Check Failed Failure = False
Send Excessive Collisions Failure = False
Send Frame Too Long Failure = False
Send Open Circuit Failure = False
Send Remote Failure To Defer Failure = False
Send Short Circuit Failure = False
Bytes Received = 7512347
Bytes Sent = 79369
Counter Creation Time = 13-MAR-1991 19:31:57.54
Data Overruns = 0
Frames Received = 81679
Frames Sent = 1155
Frames Sent Initially Deferred = 0
Frames Sent Multiple Collisions = 0
Frames Sent Single Collisions = 0
Multicast Bytes Received = 7458757
Multicast Frames Received = 80514
Seconds Since Last Zeroed = 65535 Seconds
System Buffers Unavailable = 0
Unrecognized Frame Destination = 18116
User Buffers Unavailable = 0
Alternate Address = AA-00-04-00-09-34
Console Command Size = 86
Console Response Size = 250
Console User = 00-00-00-00-00-00
Data Link Buffer Size = 1518
Functions Supported = DEC_ENETV2
Implementation = DECserver 500/DSRVS CSMA/CD comm link
Maintenance Version = V3.0.0
Reservation Timer = 10 Seconds
Implementation Desc = ""
Location = ""
MAIL Account = ""
Phone Number = ""
Remarks = ""
Responsible Person = ""
Text File = ""
MCC> show mcc 0 all attr
MCC 0
AT 14-MAR-1991 13:46:49 All Attributes
Component Name =
CSC:.MCC.FATBOB_DIRECTOR
Component Identification = "DECmcc"
Component Version = T1.1.0
MCC> show mcc 0 ethernet_am all attrib
MCC 0 ETHERNET_AM
AT 14-MAR-1991 13:47:22 All Attributes
Available Ports = { "XQA0:" }
Component Identification = "DECmcc Ethernet AM"
Component Version = T1.1.0
MCC> show mcc 0 ethernet_am all status
MCC 0 ETHERNET_AM
AT 14-MAR-1991 13:47:44 Status
Examination of attributes shows:
Available Ports = { "XQA0:" }
MCC> show mcc 0 ethernet_am all char
MCC 0 ETHERNET_AM
AT 14-MAR-1991 13:47:59 Characteristics
Examination of attributes shows:
Component Identification = "DECmcc Ethernet AM"
Component Version = T1.1.0
MCC> exit
FATBOB> log
SYSTEM logged out at 14-MAR-1991 13:48:13.93
|
| 41.8 | Correction: - note .7 refers to notes .5 & .6, *not* .4
| KAOU15::T_ROSS | CSC/CTH : 5 years on the I-stack... | Thu Mar 14 1991 14:50 | 0 |
| 41.9 | Problem explained. | CHRISB::BRIENEN | DECmcc Bridge|Station|SNMP Management. | Fri Mar 15 1991 12:23 | 30 |
| Notes 41.5 through 41.8 have identified a DECmcc Ethernet AM V1.1 bug which
has been (partially) QAR'd. I'll clean up the QAR description when the NACQAR
MCC_INTERNAL database straightens out.
Here are the problem details:
Given: Station Registered with Name, ADDRESS (08-00-*),
ALTERNATE ADDRESS (AA-*), Functions Supported = DEC_ENETV2.
Responding Address is ADDRESS (08-*).
Observed Behavior:
SHOW STATION Name ...succeeds
TEST STATION 08-00-* ...succeeds (note: ADDRESS)
--> TEST STATION Name ...fails
In other words, if a "TEST STATION Name" command is issued that
involves a Station with ADDRESS and ALTERNATE ADDRESS, and ADDRESS is
the Responding Address, the TEST command fails.
Reason for Behavior:
What the Ethernet AM is *supposed* to do, when a Name is
specified on a TEST STATION command, is to:
------------
Step 1. Try EnetV2 Loopback to ALTERNATE ADDRESS.
Step 2. If no response Try it to ADDRESS.
The Ethernet AM is only doing Step 1 (i.e., if ALTERNATE ADDRESS
doesn't respond, it's being considered a failure).
|
| 41.10 | **TOPIC CLOSED** | TOOK::CALLANDER | | Fri Mar 15 1991 13:24 | 6 |
|
.9 answers the problems described in the base note. I am locking this note; and
requesting that any new station problems found please be placed in new topics.
thanks
moderator
|