From: pp@informatik.uni-kiel.dbp.de (Peter Pichol)
Newsgroups: comp.sys.sun.admin
Subject: Upgrade Sunlink 6.0 -> 7.0 (MHS,OSI,X.25): doesn't work ?
Date: 18 Dec 1992 18:58:57 +0100
Organization: Dept. of Computer Science, University of Kiel, FRG
NNTP-Posting-Host: daisy.informatik.uni-kiel.dbp.de
Keywords: upgrade,Sunlink,X.25,OSI,MHS


We are in the process of upgrading our Sunlink 6.0 versions to 7.0 on a
ss10/20 (name=gutemine, X.121=10001505...) running SunOS 4.1.3.
We succeded in installing X.25, OSI and MHS (only CONS over X.25) and
we additionally have run the Patches 100328-12 (X.25), 100517-01 (OSI)
and 100480-01 (MHS) to get rid of some nasty error messages.

Our mta partners are are PDP-11 and a SUN SPARCserver 4/390 (Sunlink 6.0
for X.25, OSI and MHS, SunOS 4.1.1, name=majestix, X.121=10001503...).
The PDP-11 supports only the transport layer protocol TP0, so we have
to change our OSI configuration with the command:

/usr/sunlink/osi/etc/osi_config set tp t_propose_tp2 no

The current state is, that we have no problems in obtaining connections
from our ss10/20 to PDP-11 and ss4/390, but we can't get any connection
on transport layer and higher the other way around.

Here is a part of the MHS tracefile of the ss4/390:

921218 170342 26939 msi.lib.c:siInit mrt.rts.x at 1302
921218 170342 26939 mrt.dump.c RTS initiator starts for 0Airts 01gutemine -path
921218 170342 26939 mrt.dump.c S-P-ABORT.Ind
921218 170342 26939 mrt.dump.c reason = hex00 stat0 = hex00 stat1 = hex00
921218 170342 26939 mrt.dump.c p1 = hex00 p2 = hex00 p3p4 = hex0000
921218 170342 26939 mrt.dump.c COMMENT: Association has been aborted for reason:
 unexpected transport disconnect
921218 170342 26939 mrt.dump.c Association aborted: unexpected transport disconn
ect
921218 170342 26939 msi.lib.c:mrt.rts.x:siSuspQueue(0Airts,01gutemine,724694922)
921218 170342 26939 mrt.dump.c RTS Queue 01gutemine suspended for 300 seconds
921218 170342 26939 msi.lib.c:siExit mrt.rts.x status 0

Here is the corresponding OSI trace (-i hdlc0 x25) on our ss10/20:

67.45 X.25  Rcvd 17 bytes, lcn=008, CALL REQUEST,  DST:10001505, SRC:10001503,
 67.45 X.25  No facilities
 67.45 X.25  4 bytes user data:
03 01 01 00                                            *                *

 67.45 X.25  Sent 3 bytes, lcn=008, CALL ACCEPT,
 67.45 X.25

 67.55 X.25  Rcvd 23 bytes, lcn=008,  DATA (0, 0) 20 bytes user data:
 67.55 X.25  Last packet
13 e0 00 00 54 5b 00 c0    01 0a c1 03 4d 48 53 c2     * `  T[ @  A MHSB*
03 4d 48 53                                            * MHS            *

 67.55 X.25  Sent 3 bytes, lcn=008, RR(1),

 67.55 X.25  Sent 10 bytes, lcn=008,  DATA (0, 1) 7 bytes user data:
 67.55 X.25  Last packet
06 80 54 5b 00 00 02                                   *  T[            *

 67.59 X.25  Rcvd 3 bytes, lcn=008, RR(1),

 69.15 X.25  Rcvd 3 bytes, lcn=008, RR(1),

127.51 X.25  Sent 5 bytes, lcn=008, CLEAR REQUEST, 00 f2,

127.54 X.25  Rcvd 3 bytes, lcn=008, CLEAR CONFIRM,

129.06 X.25  Rcvd 3 bytes, lcn=008, CLEAR CONFIRM,

The connection succeeds on X.25 level but fails on transport layer level.
We have made all important entries in the OSI configuration files, e. g.:

/etc/sunlink/osi/isoentities:

rz.uni-kiel     mta             NULL    \
                \"MHS"/Int-X25=10001004+PID+65616e31

majestix        mta             NULL    \
                \"MHS"/Int-X25=10001503+PID+03010100

/etc/sunlink/osi/isoservices:

"tsap/mta"                      "MHS"           /etc/sunlink/mhs/x/mrt.rts.x

/etc/sunlink/osi/isotailor:

ts_stacks:      x25

Another hint may be the tsapd.log file, which looks like this:

12/18 17:17:08 tsapd    00706 (root    )  starting
12/18 17:17:08 tsapd    00706 (root    )  listening on X121+
12/18 17:17:08 tsapd    00706 (root    )  listening on '0001'H/
12/18 17:17:08 tsapd    00706 (root    )  listen failed: [Invalid parameter] uns
upported network address (0)
12/18 17:17:08 tsapd    00706 (root    )  listening on '0080'H/
12/18 17:17:08 tsapd    00706 (root    )  listen failed: [Invalid parameter] uns
upported network address (0)
12/18 17:17:08 tsapd    00706 (root    )  listening on '0081'H/
12/18 17:17:08 tsapd    00706 (root    )  listen failed: [Invalid parameter] uns
upported network address (0)
12/18 17:17:08 tsapd    00706 (root    )  listening on '0103'H/
12/18 17:17:08 tsapd    00706 (root    )  listen failed: [Invalid parameter] uns
upported network address (0)
12/18 17:17:08 tsapd    00706 (root    )  listening on '0200'H/
12/18 17:17:08 tsapd    00706 (root    )  listen failed: [Invalid parameter] uns
upported network address (0)
12/18 17:17:08 tsapd    00706 (root    )  listening on '0201'H/
12/18 17:17:08 tsapd    00706 (root    )  listen failed: [Invalid parameter] uns
upported network address (0)
12/18 17:17:08 tsapd    00706 (root    )  listening on '0202'H/
12/18 17:17:08 tsapd    00706 (root    )  listen failed: [Invalid parameter] uns
upported network address (0)
12/18 17:17:08 tsapd    00706 (root    )  listening on '0203'H/
12/18 17:17:08 tsapd    00706 (root    )  listen failed: [Invalid parameter] uns
upported network address (0)
12/18 17:17:08 tsapd    00706 (root    )  listening on '0204'H/
12/18 17:17:08 tsapd    00706 (root    )  listen failed: [Invalid parameter] uns
upported network address (0)
12/18 17:17:08 tsapd    00706 (root    )  listening on '0205'H/
12/18 17:17:08 tsapd    00706 (root    )  listen failed: [Invalid parameter] uns
upported network address (0)
12/18 17:17:08 tsapd    00706 (root    )  listening on '0206'H/
12/18 17:17:08 tsapd    00706 (root    )  listen failed: [Invalid parameter] uns
upported network address (0)
12/18 17:17:08 tsapd    00706 (root    )  listening on "MHS"/
12/18 17:17:08 tsapd    00706 (root    )  listen failed: [Invalid parameter] uns
upported network address (0)

Is there a problem with the tsapd (it seems that it listens on X121+, but it
doesn't listen on "MHS")?

Any help is greatly appreciated !

Peter

--
Peter Pichol, pp@informatik.uni-kiel.dbp.de, Univ. of Kiel, Germany
Newsgroups: comp.sys.sun.admin