[Search for users]
[Overall Top Noters]
[List of all Conferences]
[Download this site]
| Title: | DECnet/OSI for {ULTRIX,OSF/1} |
| Notice: | Indicate version and platform when writing...see #2 for kits |
| Moderator: | BULEAN::CARR |
|
| Created: | Wed Sep 25 1991 |
| Last Modified: | Thu Jun 05 1997 |
| Last Successful Update: | Fri Jun 06 1997 |
| Number of topics: | 2187 |
| Total number of notes: | 10469 |
2181.0. "help needed in understanding the trace ..." by MLNORO::MALACRIDA () Wed May 21 1997 06:40
Cross posted in mailbus_400 notes.
<<< FORTY2::USER66:[NOTES$LIBRARY]MAILBUS_400.NOTE;1 >>>
-< MAILBUS 400 User Forum >-
================================================================================
Note 3194.0 help needed here ... 1 reply
MLNORO::MALACRIDA 213 lines 16-MAY-1997 09:21
--------------------------------------------------------------------------------
Can someone clarify what's going on here between MTA 400 (version 1.4)
and the Peer MTA?
I took both a transport trace and a trace of the upper layers (see below):
as far as I can understand we are claiming that something is missed in the
received AC-SPDU, but on the other hand the received AB-SPDU seems to i
ndicate that the peer mta was expecting an ARU/ARP-PPDU that we didn't send
(that probably we never sent do the error detected in the first AC-SPDU
received).
The manager of the peer mta is telling me that the process managing
the RTS on his machine dies several times a day, but it's not clear
if this is the cause that fires the problem.
Any help appreciated.
Thanks,
giovanni
----- UPPER LAYER TRACE ------
Input trace file name : TELEMAIL_RCV_122700_15063
Output trace file name : /supporto/osaktrace_telemail.err
Trace options selected : Transport SPCI PPCI ACSEPCI Errors
14:12:27.29 on 15-MAY-1997 : Trace started
14:12:27.29 on 15-MAY-1997 : Issued T-DATA request [complete]
0E 65 01 23 09 06 14 04 33 32 33 32 0B 13 17 11 39 37 30 35 31 35
31 34 31 32 34 36 2B 30 32 30 30 0C 04 14 02 30 31 05 09 13 01 00
16 01 01 1A 01 00 14 02 02 49 33 02 32 32 C1 2B 31 29 A0 03 80 01
00 A1 22 80 01 0A 81 01 03 A2 1A A0 18 A1 80 80 06 58 34 30 30 4D
41 A1 80 16 06 58 34 30 30 4D 41 00 00 00 00
AC-SPDU = 0E 65
{
Connection Identifier = 01 23
{
Called SS-user Reference = 14 04 33 32 33 32 09 06 14
Common Reference = 17 11 39 37 30 35 31 35 31 34 31 32 3(More) 0B 13 17
Additional Reference Info = 14 02 30 31 0C 04 14
}
Connect/Accept Item = 05 09
{
Protocol Options = { } 13 01 00
Version Number = {version-1} 16 01 01
Token Setting Item = {initiator-data, initiator-sync-minor, 1A 01 00
initiator-sync-major/activity, initiator-release}
}
Session User Requirements = {half-duplex, minor-sync, 14 02 02
activity-management, exceptions}
Calling Session Selector = "22" 33 02 32
User Data = 31 29 A0 03 80 01 00 A1 22 80 01 0A 81 01 03 A2(More) C1 2B 31
CPA-PPDU SET = 31 29
{
[0] IMPLICIT Mode-selector SET = A0 03
{
[0] IMPLICIT INTEGER = x410-1984-mode 80 01 00
}
[1] IMPLICIT PAccept SET = A1 22
{
checkpointsize [0] IMPLICIT INTEGER = 10 80 01 0A
windowsize [1] IMPLICIT INTEGER = 3 81 01 03
[3] ConnectionData CHOICE = A2 1A
{
open [0] ANY = A0 18
{
[1] IMPLICIT SET = A1 80
{
mTAName [0] IMPLICIT IA5String = "X400MA" 80 06 58
password [1] ANY = A1 80
{
IA5String = "X400MA" 16 06 58
}
}
}
}
}
}
-- Error: no matching CP-PPDU received for this PPDU
-- Error: DCS not updated
}
14:12:30.86 on 15-MAY-1997 : Received T-DATA indication [complete]
01 00 2D 05 29 03 02 01 01
GT-SPDU = 01 00
{
}
AS-SPDU = 2D 05
{
Activity Identifier = 02 01 01 29 03 02
}
14:12:31.92 on 15-MAY-1997 : Received T-EXPEDITED-DATA indication [complete]
19 0A 11 01 03 C1 05 31 03 80 01 00
AB-SPDU = 19 0A
{
Transport Disconnect = {transport-connection-released} 11 01 03
User Data = 31 03 80 01 00 C1 05 31
[UNIVERSAL 49] 31 03
-- Error: expected ARU/ARP-PPDU
}
14:12:31.92 on 15-MAY-1997 : Issued T-DISCONNECT request
Trace Analyzer finished.
------ TRANSPORT TRACE --------
-----------+----+-----+<-------------------Transport-Header---------------------->+------------------------------------------------
Rem Time |Evnt|Data | |DATA
hh:mm:ss.ms| |Size | |
-----------+----+-----+<--------------------------------------------------------->+------------------------------------------------
13:12:25.78|Rx | 47| Type: CR Length: 34 |
| Li: 21, Credit: 08 |
| Source Ref: 0000, Destination Ref: 0001, TC_id: 0000 |
| Class 2, Extended |
| Remote NSAP: 5200001200250000 |
| Variable Part: |
| C0 01 0A C2 0C 4D 54 41 38 34 2D 58 34 30 30 4D 41 C1 02 |
| 04 09 C6 01 01 C7 01 00 |
| |
|
13:12:25.79| Tx| 44| Type: CC Length: 31 |
| Li: 1E, Credit: 0F |
| Source Ref: 0001, Destination Ref: 0224, TC_id: 0224 |
| Class 2, Extended |
| Remote NSAP: 5200001200250000 |
| Variable Part: |
| C6 01 01 C0 01 0A C1 02 04 09 C2 0C 4D 54 41 38 34 2D 58 |
| 34 30 30 4D 41 |
| |
|
13:12:26.89|Rx | 120| Type: DT Length: 107 |0d 61 01 23 0a 06 14 04 33 32 33 32 0b 13 17 11
| Li: 07, Nr: 00000000, EOT |39 37 30 35 31 35 31 34 31 32 34 36 2b 30 32 30
| Destination Ref: 0224, TC_id: 0001 |30 0c 04 14 02 30 31 05 09 13 01 00 16 01 01 1a
| Class: 2, Extended |01 00 14 02 02 49 33 02 32 32 c1 27 31 25 a0 03
| Remote NSAP: 5200001200250000 |80 01 00 a1 1e 82 01 00 a3 16 a0 14 a1 12 80 04
| |53 4e 41 4d a1 0a 16 08 54 45 4c 45 4d 41 49 4c
|84 01 0c
13:12:27.29| Tx| 124| Type: DT Length: 111 |0e 65 01 23 09 06 14 04 33 32 33 32 0b 13 17 11
| Li: 07, Nr: 00000000, EOT |39 37 30 35 31 35 31 34 31 32 34 36 2b 30 32 30
| Destination Ref: 0001, TC_id: 0224 |30 0c 04 14 02 30 31 05 09 13 01 00 16 01 01 1a
| Class: 2, Extended |01 00 14 02 02 49 33 02 32 32 c1 2b 31 29 a0 03
| Remote NSAP: 5200001200250000 |80 01 00 a1 22 80 01 0a 81 01 03 a2 1a a0 18 a1
| |80 80 06 58 34 30 30 4d 41 a1 80 16 06 58 34 30
|30 4d 41 00 00 00 00
13:12:30.85|Rx | 30| Type: DT Length: 17 |01 00 2d 05 29 03 02 01 01
| Li: 07, Nr: 00000001, EOT |
| Destination Ref: 0224, TC_id: 0001 |
| Class: 2, Extended |
| Remote NSAP: 5200001200250000 |
| |
|
13:12:31.92|Rx | 33| Type: ED Length: 20 |19 0a 11 01 03 c1 05 31 03 80 01 00
| Li: 07, Nr: 00000000, EOT |
| Destination Ref: 0224, TC_id: 0001 |
| Class: 2, Extended |
| Remote NSAP: 5200001200250000 |
| |
|
13:12:31.92| Tx| 21| Type: EA Length: 8 |
| Li: 07, Yr-Tu-Nr: 00000000 |
| Destination Ref: 0001, TC_id: 0224 |
| Class: 2, Extended |
| Remote NSAP: 5200001200250000 |
| |
|
13:12:31.93| Tx| 20| Type: DR Length: 7 |
| Li: 06 |
| Source Ref: 0001, Destination Ref: 0224, TC_id: 0224 |
| Class: 2, Extended |
| Remote NSAP: 5200001200250000 |
| Reason: 80 |
| - Normal disconnect initiated by session |
| |
|
13:12:32.26|Rx | 19| Type: DC Length: 6 |
| Li: 05 |
| Source Ref: 0224, Destination Ref: 0001, TC_id: 0001 |
| Class: 2, Extended |
| Remote NSAP: 5200001200250000 |
| |
|
| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 2181.1 | | ABBYRD::RMULAC::S_WATTUM | Scott Wattum - FTAM/VT/OSAK Engineering | Wed May 21 1997 09:09 | 21 |
| >we are claiming that something is missed in the
>received AC-SPDU,
Actually that's not the case. OSAKTRACE is claiming that it didn't see a
CN-SPDU (which it didn't), so consequently it cannot verify certain aspects of
the AC-SPDU that we sent, and it is not maintaining a DCS because of this (or at
least not an accurate one). This would appear to be a result of a connection
which was "handed off" - probably the MTA listener saw the inbound CN-SPDU and
forked off a child to handle the request; the child didn't enable tracing until
right before it sent the AC-SPDU; if the child had enabled tracing earlier, the
trace would have picked up the CN-SPDU that was re-directed to the child. So
this isn't really a problem, just an anomoly in the way the child started
tracing the connection.
Beyond that, I don't remember enough about X.400 protocol to tell you what is
normally supposed to happen after the association is established. I can tell
you that the other implementation sent an Activity Start and then sent the Abort
(we didn't initiate the abort). You're going to have to query the other side to
see why they decided to abort the association.
--Scott
|
| 2181.2 | thanks | MLNORO::MALACRIDA | | Thu May 22 1997 13:11 | 10 |
| >>Beyond that, I don't remember enough about X.400 protocol to tell you
>>what is normally supposed to happen after the association is
>>established. I can tell you that the other implementation sent an Activity Start and then sent
>>the Abort (we didn't initiate the abort). You're going to have to query the
>>other side to see why they decided to abort the association.
Thanks Scott, I was actually looking for a confirmation that the other side
was releasing the association.
giovanni
|