| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 585.1 | some more info | KERNEL::TRAYLER | | Thu Jun 04 1992 03:25 | 79 |
| A bit more info.
I have tried to reproduce the problem here but have been unable to.
Our configuration that works
Vax 6520 + Demfa f/w rev 1.3 h/w rev E03
VMS 5.5
LTDRIVER v6.0-258
FXDRIVER x-16 link date 12-oct-1992
Decbridge 500 - no filters
Decconcentrator 500
Their configuration that doesn't work
Vax 6xxx + Demfa f/w rev 1.2 h/w rev unknown at the moment
VMS 5.4-3
LTDRIVER v6.0-348
FXDRIVER x-16 link date sept 1992
We put a lan analyser on the ethernet to try to trace a vt1200 font load. What
appeared to happen at their site is that a lat message from the vax to the
vt1200 is never seen on the ethernet. We have no way of analysing whether it
gets onto the fddi but the sequence of event is like this.
Msg No. Ack No. Source
09 05 Vax
0B 05 Vax
0C 05 Vax
06 09 vt1200
06 09 vt1200
0B 06 Vax
0C 06 Vax
0D 06 Vax
0E 06 Vax
07 09 Vax
07 09 Vax
07 09 Vax
07 09 Vax
0B 07 vt1200
0C 07 vt1200
0D 07 vt1200
0F 07 vt1200
As message 10 has never been seen by the vt1200 it keeps acknowledging message
9. The latcp counters on the Vax show loads and loads of duplicates received
and messages retransmitted. From latcp we did a set node/hist and looked at the
sequence numbers of messages being sent. Message 10 is sent out but no ack comes
back for it.
This made us suspect that the concentrator/bridge was at fault. We shipped our
concentrator and bridge down there and plugged one of their vaxs in. We
observed exactly the same behaviour.
The only differences between our setup and theirs now are
1. Demfa firmware revision level.
2. FXDRIVER version - ours is vms 5.5 theirs is 5.4-3.
3. VMS version - as above
4. LTDRIVER version - ours v6.0-258, theirs v6.0-348
Today I will try to upgrade our ltdriver to v6.0-348 and attempt to reproduce
the problem again here. I will also try to get their f/w revision to 1.3 on the
demfa.
Does anyone have any thoughts on this? I'd appreciate anything you could
suggest.
Kevin Trayler
|
| 585.2 | | KERNEL::TRAYLER | | Fri Jun 05 1992 03:19 | 7 |
|
It appears that this is a ltdriver problem,
see latmaster notes conference ( note 807 )
Kev.
|
| 585.3 | bug is in VT1200 firmware | ROYALT::RASPUZZI | Michael Raspuzzi - LAT Engineering et al | Wed Jun 30 1993 08:28 | 12 |
| Just to clarify, this was not an LTDRIVER problem per se. It is a
VT1200 problem - it incorrectly states that it uses a data area of 1518
bytes (LAT spec says that the message size field is to NOT include
headers, addresses, CRCs, etc). This was erroneously triggering
LTDRIVER to use larger packets (since FDDI allows larger packets).
These large packets do not go through the 10/100 bridge and
connections to the VT1200 don't work to well because of this.
A *workaround* for this bug in the VT1200 was put into LTDRIVER.
Contact the CSC for the latest patch kit.
Mike
|
| 585.4 | | KONING::KONING | Paul Koning, A-13683 | Thu Jul 01 1993 11:25 | 6 |
| Reminds me of similar problems in MOP implementations -- the fix for which is
a rule that says "values of 1504, 1514, and 1518 shall be treated as 1500".
:-(
paul
|