software does not connect to LAT ports on DEC700 servers

[Markus Waldorf_1]

Hi,

I have probem with a custom software that is using LAT to connect to a bunch of DEC700 terminalservers. We have two identical machines, same OS, same software and configuration. One is supposed to be cold standby in case the other breaks. I re-configured the cold standby to do the same job, albeit with a different set of Terminalservers and physical location. I renamed some of the standby terminalservers and added them to NCP using their correct hardware address.

Due to Network port security I had to purge some lines since it was overwriting the Interface MAC addresses. Something went wrong - remote sessions started to hang right after login using telnet and set host, and I used @netconfig again, which seemed to have corrected the problem. I also renamed the computer and Decnet name.

Ever since the custom software does not seem to connect to the terminalserver anymore. I think I have compared everything between the still working and now not working, previous standby node checking things like: LAT$SYSTARTUP.COM where the interface and LAT ports are defined. I compared "mc ncp sho known circuit, lines and objects. Everything looks the same. I also compared the terminalservers and cannot see the difference.

I can connect to the Terminalservers using mc ncp connect node TS012, etc. on both computers, but there seems to be something missing. I have spend all weekend trying to find the reason....

On the node where it is not working: mc latcp sho ports shows:

_LTA1203: Application Connecting TS012/PORT_3/
_LTA1204: Application Connecting TS012/PORT_4/
_LTA1205: Application Inactive TS012/PORT_5/
_LTA1206: Application Inactive TS012/PORT_6/
The "connecting later changes to inactive"

On the node where it's working it shows:

_LTA1301: Application Inactive TS013/PORT_1/
_LTA1302: Application Inactive TS013/PORT_2/
_LTA1303: Application Active TS013/PORT_3/
_LTA1304: Application Active TS013/PORT_4/

working node>mc latcp sho port LTA1306

Local Port Name: _LTA1306: Local Port Type: Application (Queued)
Local Port State: Active
Connected Link: 1ST$LINK

Target Port Name: PORT_6 Actual Port Name: PORT_6
Target Node Name: TS013 Actual Node Name: TS013
Target Service Name: Actual Service Name:


not working node>mc latcp sho port lta1306

Local Port Name: _LTA1306: Local Port Type: Application (Queued)
Local Port State: Inactive
Connected Link:

Target Port Name: PORT_6 Actual Port Name:
Target Node Name: TS013 Actual Node Name:
Target Service Name: Actual Service Name:

not working node>mc ncp show node TS013 char


Node Volatile Characteristics as of 29-JUN-2009 09:25:33

Remote node = 1.1013 (TS013)

Service circuit = EWA-0
Hardware address = 00-00-F8-51-FB-15
Load file = MOM$LOAD:WWENG2.SYS

working node>mc ncp show node TS013 char


Node Volatile Characteristics as of 29-JUN-2009 09:28:12

Remote node = 2.1015 (TS013)

Service circuit = EWA-0
Hardware address = 08-00-2B-91-D6-AF
Load file = MOM$LOAD:WWENG2.SYS



working node>mc latcp sho con

ID Type Remote Node (Address) Sessions/Limit
---- -------- ------------------------------------- --------------
0230 Incoming TS011 (08-00-2B-91-D7-32) 6/ 64
04A0 Incoming TS013 (08-00-2B-91-D6-AF) 4/ 64


not working node>mc latcp sho con
%LAT-W-CMDERROR, error reported by command executor
-LAT-F-NOMORECONN, no more connections in database

not working node>mc ncp sho known lines


Known Line Volatile Summary as of 29-JUN-2009 09:28:30

Line State

EWA-0 on

working node>mc ncp sho known lines


Known Line Volatile Summary as of 29-JUN-2009 09:31:09

Line State

EWA-0 on

[Markus Waldorf_1]

I forgot to mention that this is Decnet phase IV. The link between the terminalserves and alphaserver is through it's own separate switch, with all ports set to auto-neg, and working. There is no firewall or anything else involved here. There is only one of the 3 interfaces on the Alpha connected to the outside world for email, for which I removed decnet in order not to overwrite its MAC hardware address. That all seems to be working fine.

Only devices EWA and EWB are connected to the switch and DEC terminalservers, port EIA goes to the LAN.

tcpip sho int
Packets
Interface IP_Addr Network mask Receive Send MTU

IE0 172.18.136.65 255.255.255.0 226 297 1500
LO0 127.0.0.1 255.0.0.0 387 387 4096
WE1 192.168.100.201 255.255.255.0 1826 1172 1500
SYSTEM@NG2>tcpip sho int /full
Interface: IE0
IP_Addr: 172.18.136.65 NETWRK: 255.255.255.0 BRDCST: 172.18.136.255
Ethernet_Addr: 00-06-2B-03-B6-09 MTU: 1500
Flags: UP BRDCST RUN MCAST SMPX
RECEIVE SEND
Packets 227 298
Errors 0 0
Collisions: 0

Interface: LO0
IP_Addr: 127.0.0.1 NETWRK: 255.0.0.0 BRDCST: 172.18.136.255
MTU: 4096
Flags: UP LOOP NOARP MCAST SMPX
RECEIVE SEND
Packets 387 387
Errors 0 0
Collisions: 0

Interface: WE1
IP_Addr: 192.168.100.201 NETWRK: 255.255.255.0 BRDCST: 192.168.100.255
Ethernet_Addr: 08-00-2B-86-D6-4C MTU: 1500
Flags: UP BRDCST RUN MCAST SMPX
RECEIVE SEND
Packets 1845 1184
Errors 0 1
Collisions: 0

[marsh_1 · Accepted solution]

hi,

have you logged the ports out on the decserver, this sometimes helps to kick things into life. use mon po 'n' stat (where n = port number) on the decserver to monitor individual port status.

hth

[Oswald Knoppers_1]

I think here is a clue:

not working node>mc latcp sho port lta1306

Local Port Name: _LTA1306: Local Port Type: Application (Queued)
Local Port State: Inactive
Connected Link:

There is no link defined here. You can create a link with:

$ mc latcp create link link_name /dev=wea0/state=on

But it looks like LAT did not start up properly. Do you see any messages during lat$startup?

Oswald

[Markus Waldorf_1]

I figured out what the problem was - very silly.

LAT$SYSTARTUP.COM was defining ports like:

$lcp set port lat1101 /node=ts011 /port=port_1

However on the Terminalserver the port name was different. e.g. AFP

Typing:
Local> set port 1 name port_1
on the Termnalserver corrected the problem.

I later used define port 1 name port_1 so it remains after a restart of the TS.

Greetings