odd client comms. problem

[wesd]

I've installed the 5.2.3 client on a couple of W2003 clients with the server at 5.2.4 on aix5.2. It's an install that I've done before with no problems but this time I can't connect to the server using the command line client or with the gui. I get the error "ANS1017E Session rejected: tcp/ip connection failure. There's an entry in dsmerror.log - ANS1005E TCP/IP read error on socket = 1452, errno = 10054, reason : 'An existing connection was forcibly closed by the remote host.'.



Sounds like a simple comms. problem except that I can successfully ping the server and , as soon as I do this, I can connect with both command line and gui clients. I can then run backups etc. with no problems until the next day when the comms. failure is repeated. The pattern is entirely consistent on both clients - run dsmc, I get ANS1017E. Ping the server and then run dsmc, no problems.



There are no firewalls involved and the dsm.opt setup is as simple as it can get - commethod tcpip using port 1500.



Any suggestions?

 

[LED888]

errno=10054



WSAECONNRESET -- Connection reset by peer. This occurs when an established connection is shut down for some reason by the remote computer.





On the TSM Server check the actlog around the time frame when the TSM Client lost connection. It could be that the TSM Client reach either the idletimeout or the commtimeout vaule.



Good Luck,

Sias

 

[wesd]

Timeout issues was all I could find about this error message on the web but I don't think it's the problem here. The client connection can't be timing out since it never gets to connect in the first place- the actlog shows nothing at all for the client. At the command prompt, I get the connection failure as soon as I type dsmc and no entry of any sort appears in the actlog. If I ping the server and then run dsmc, there's no problem.



I'm using identical client option files on several identical servers (ibm blades running w2003, all I'm changing is the node name) but only these 2 are having the problem. Unfortunately it's one of these weird problems where the comms. folk say it's not a comms problem since I can ping the server and it's not a tsm problem since everything runs perfectly as long as I ping the server first!

 

[Harry_Redl]

Hi,



I would try to monitor the traffic between client and server (using tcpdump or equivalent on the AIX side and Wireshark - used to be Ethereal - on the Windows side) - you have to be sure if the session request reached the server.

Try to start with this and let us know ...



Harry

 

[wesd]

I tried using tcpdump on the server side to monitor the problem. The dump showed no traffic coming from/to the client when the session was rejected. When I pinged the server, the dump showed the echo request and echo reply. When I then retried the client connection, the dump shows traffic passing between the client and server on port 1500 and everything works normally.



It's as if the client's network adaptor was "sleeping". Using ping wakes it up but using dsmc doesn't. While it's looking like more like a comms. or hardware issue, is there anything in the tsm setup that could result in behaviour like this? Sometimes, persuading the comms. people that a fault is their problem is like having teeth pulled so I'm trying to rule out as many things as possible. At least I'll probably learn something while I'm trying.

 

[Harry_Redl]

Hi,



well - atleast the server side is out



So you do not see outgoing packet on the client network adapter?

I would try to use "telnet <tsmserver> <tsmport>" from the client to see if it "wakes up" your adapter or not ...

How your dsm.opt (comm section) looks like? Do not think it can be there but .... just to be sure ...

How is your netcard configured? Do not use AutoNegotiation - use fixed setting (like 100Mbit Full Duplex) - Auto may result in VERY strange behaviour ....



All for now - let us know how you proceed ...



Harry

 

[wesd]

I'm not too sure about the client's network setup as it's W2003 and I'm a unix administrator. The tcpdump I was running was on the unix server, not the client so I know that no packets were reaching the server but I don't know what (if anything) left the client. The server's network cards are 100 full duplex - I would never have auto negotiate! - do you know how to check this on a windows box?



The only comms. settings I have in dsm.opt are



commmethod tcpip

tcpserveraddress {ip address}

tcpport 1500

tcpbuffsize 32

tcpwindowsize 2048



Running telnet on the client didn't wake up the adapter; only ping seems to do this.

 

[wesd]

I ran a few more experiments with ping and now I'm even more confused!



I can ping other boxes on the network so the adapter must be working correctly but I still can't connect with dsmc. The tsm server has 2 IP addresses; its normal address plus an alias. The normal address is the one specified in dsm.opt. If I ping the alias, dsmc still fails; the only way I've found to get dsmc to connect is to first ping the address used in dsm.opt.



All this suggests to me that both the hardware and comms. are working fine, especially since the client is a live box in daily use (and I have 2 clients having the same problem). Other identical clients are working fine, though, so I know that the tsm server is working. These clients are all using the same dsm.opt file; only the node name is different.