[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 |
2157.0. "DOTI_RCV_TPDU, bad CC tdpu error" by TAGEIN::AURAND () Mon Apr 07 1997 09:24
Hi everybody,
a customer of us has a problem with the sending and receiving X.400 mails
over RFC1006 from an IBM system (Digital UNIX V3.2D, DECnet/OSI V3.2B).
The logfile shows the following error:
mbalpha vmunix: doti_rcv_tpdu: nc[148]: bad CC tpdu: status==3D7, octet=3D11
mbalpha vmunix: doti_rcv_protocl_error: nc[148]
As far as I can see, there are no errors in the traces. Any ideas, what could
be the problem ? (The customer has installed a new dna_base.mod image but NOT
the newest one dna_base.mod.v32b.18mar97.Z)
Many thanks for your help
Andreas
10:21:40.30| Tx| 25| Type: CR Length: 25 =
| Li: 18, Credit: 00 =
| Source Ref: 0000, Destination Ref: D6E0 =
| Class 0, Normal =
| Remote IP Host: 10.25.5.42 =
| Variable Part: =
| (C2) Dst TSAP Id: 78343030 =
| (C1) Src TSAP Id: 78343838 =
| (C0) Tpdu Size: 8192 =
| (C6) Additional Options: 00 =
| Non-use of transport expedited data transfer =
| 16-bit checksum used in class 4 =
| Use of explicit ack variant in class 1 =
| Non-use of network expedited in class 1 =
| Non-use of selective ack in class 4 =
| =
|
10:21:40.38|Rx | 16| Type: CC Length: 16 =
| Li: 0F, Credit: 00 =
| Source Ref: D6E0, Destination Ref: 0168 =
| Class 0, Normal =
| Remote IP Host: 10.25.5.42 =
| Variable Part: =
| (C0) Tpdu Size: 8192 =
| (C1) Src TSAP Id: 78343030 =
CR from Alpha to IBM
--------------------
TCP: <source port=3D1063, destination port=3D102(iso_tsap) >
TCP: th_seq=3Da306602, th_ack=3D5501cc02
TCP: th_off=3D5, flags<PUSH |ACK |>
TCP: th_win=3D33580, th_sum=3De066, th_urp=3D0
TCP: 00000000 0300001d 18e00000 ad5100c2 04783430 |.........Q...x40=
TCP: 00000010 30c10478 343838c0 010dc601 00 |0..x488...... =
E0 = Connect Request
0000 = DST-REF
ad51 = SRC-REF
00 = Class 0
c2 0478343030 = Called TSAP x400
c1 047843838 = Calling TSAP x488
c0 010d = TPDU Size (8192)
c6 0100 = Additional Options
CC from IBM to Alpha
--------------------
TCP: <source port=3D102(iso_tsap), destination port=3D1063 >
TCP: th_seq=3D5501cc02, th_ack=3Da30661f
TCP: th_off=3D5, flags<PUSH |ACK |>
TCP: th_win=3D16060, th_sum=3D6490, th_urp=3D0
TCP: 00000000 03000014 0fd0ad51 00c000c0 010dc104 |.......Q........=
TCP: 00000010 78343030 |x400 =
D0 = Connect Confirm
ad51 = DST-REF
00c0 = SRC-REF
00 = Class 0
c0 010d = TPDU Size (8192)
c1 0478343030 = Calling TSAP x400
T.R | Title | User | Personal Name | Date | Lines |
---|
2157.1 | | alphy.lkg.dec.com::thomas | The Code Warrior | Mon Apr 07 1997 09:44 | 1 |
| calling TSAP in the CC is not the same as the one in the CR.
|
2157.2 | | TAGAUS::AURAND | | Wed Apr 09 1997 10:02 | 10 |
| Thanks for the quick answer !!!
The customer asked me, if this strict checking has changed from
DECnet/OSI V3.2A to V3.2B because he had found an old trace, where the
IBM has also changed the source and destination TSAPs but the Alpha
didn't rejected the connection.
Many thanks for your help
Andreas
|
2157.3 | | alphy.lkg.dec.com::thomas | The Code Warrior | Wed Apr 09 1997 14:36 | 1 |
| This is new in 3.2B (which has a completely new RFC1006) implementation.
|