putty disconnects from centos 74 after 30 secs

[bigdaddy68]

hi,

i just staged centos 7.4 minimal in a vmguest on vpshere 6.5 but when i putty in as root i keep getting disconnected after ~ 30 secs. i can use vmware standalone remote console fine.

i notice the pids/ptys of the bash sessions are still there. Doing a kill -1 <bash_pid> gets rid of them.

i disabled SElinux and firewalld and i have TCP keepalives going out every 15 secs in putty but it still happens.

the network vNIC appears to stay up and running according to ip addr and ping of a known ip address on same subnet ( at least from the console)

i checked dmesg and /var/log/messages and there's nothing of interest in either file..

anyone seen or run into this - i may have to try centos 7.3 to see if it happens there too

thx for any help/guidance
bigdaddy68

2018-04-24 04:39:25 Connecting to 10.16.123.2 port 22
2018-04-24 04:39:25 We claim version: SSH-2.0-PuTTY_Release_0.70
2018-04-24 04:39:25 Server version: SSH-2.0-OpenSSH_7.4
2018-04-24 04:39:25 Using SSH protocol version 2
2018-04-24 04:39:25 Doing ECDH key exchange with curve Curve25519 and hash SHA-256
2018-04-24 04:39:25 Server also has ecdsa-sha2-nistp256/ssh-rsa host keys, but we don't know any of them
2018-04-24 04:39:25 Host key fingerprint is:
2018-04-24 04:39:25 ssh-ed25519 256 a7:d1:20:52:b7:fe:09:37:44:0c:67:70:c5:8d:e0:b4
2018-04-24 04:39:25 Initialised AES-256 SDCTR client->server encryption
2018-04-24 04:39:25 Initialised HMAC-SHA-256 client->server MAC algorithm
2018-04-24 04:39:25 Initialised AES-256 SDCTR server->client encryption
2018-04-24 04:39:25 Initialised HMAC-SHA-256 server->client MAC algorithm
2018-04-24 04:39:29 Using SSPI from SECUR32.DLL
2018-04-24 04:39:29 Attempting GSSAPI authentication
2018-04-24 04:39:29 GSSAPI authentication initialisation failed
2018-04-24 04:39:29 The target was not recognized.
2018-04-24 04:39:32 Sent password
2018-04-24 04:39:32 Access granted
2018-04-24 04:39:32 Opening session as main channel
2018-04-24 04:39:32 Opened main channel
2018-04-24 04:39:32 Allocated pty (ospeed 38400bps, ispeed 38400bps)
2018-04-24 04:39:32 Started a shell/command
2018-04-24 04:40:29 Network error: Software caused connection abort

[pjwelsh]

Doest this link help https://superuser.com/questions/294824/ ... tion-abort ?
Summarized as:
Start Putty
Load your connection settings if you have them saved
Click on “Connection”
On the section that says "Sending of null packets to keep session active", Changed it to 5 seconds. 300 seconds ...

[TrevorH]

It's not a timeout if you have a bash loop with sleep 2, echo in it running. I'd suspect you have a duplicate ip address and some of your packets are going to the "wrong" system and getting invalid responses which cause the session to terminate.

[bigdaddy68]

I can tell you its not a dup ip address on the same subnet 10.16.123.0/24 - i used 'ip neighbour show' to check the arp tables and the only ip addr was my router at 10.16.123.1

(they should have left the 'arp' cmd in linux ... )

thx
bigdaddy68

[TrevorH]

The arp command is still there if you install the net-tools package, it's just not installed by default. Adn I wouldn't trust arp or ip ne sh to show a duplicate ip. Take your system down or give it a different ip and then try to ping or arping the original.

[bigdaddy68]

there is no dup ip addr.... see attached... this is now happening w/ CentOS 7.3 minimal as well...

The only thing I can note as different is that the VLAN I am on is 10.16.123 while the VLAN that my Win10 VMguest is on is 10.16.125
I can still ping between the 2 VLANs and I'm told that the upstream physical switch is in L2 mode and all switch ports have all VLANs on them...

I will try to stage my CentOS 74 VMGuest on 10.16.125 VLAN and see if issue still happens..
failing that - I will back-rev my PuTTY version to see if that matters..

thx
bigdaddy68

[bigdaddy68]

sure enough - once i put my vmguest on the same VLAN as my Windows VMguest (running PuTTY) - problem went away
there must be an upstream switch ( or maybe VMware vSwitch/dvSwitch) setting causing this to happen - i'm not sure what that setting is but i really dont care at this point

friggin network guys...

[yubby]

Yes, 'Network Service' groups will implement 'idle timeout' rules on the switches, or router/firewalls, especially if they're attempting to comply with 'audit' requirements (i.e. SOX, CCA networks, etc).

BUT, you can try to implement the 'keepalive' functionality in Putty, to see if 'that' helps...
(also, make sure you're using the 'latest' version of Putty (0.70) )

Putty-KeepAlive.jpg (74.97 KiB) Viewed 1507 times

[yubby]

OH, I see someone beat me to that.... (and uses the same '5 minute' value for 'pings')
hee hee...