Newly configured MSSQL2008, TIME_WAIT but no ESTABLISHED?

by

Windows 2008 R2, standard. No firewall locally on it. Newly setup because an old SQL2000 had two disks die (or could it be the raid controller?) at the same time.
Luckily, I had fresh backups.
The databases have been restored, and SP2 for SQL2008 applied.

I can see various hosts trying to establish a session, but the (customer) sites does not work and I don’t see the expected established sessions. A wireshark reveals a full three-way handshake. Since it’s customer machines connecting, I cannot logon to them and restart application pools..

What on earth could be causing this?

No.     Time        Source                Destination           Protocol Info
  1 0.000000    1.2.5.127         1.2.6.133         TCP      desktop-dna > ms-sql-s [SYN] Seq=0 Win=65535 Len=0 MSS=1380 SACK_PERM=1

Frame 1: 62 bytes on wire (496 bits), 62 bytes captured (496 bits)
Ethernet II, Src: Cisco_31:5e:09 (00:26:0b:31:5e:09), Dst: Vmware_b7:00:05 (00:50:56:b7:00:05)
Internet Protocol, Src: 1.2.5.127 (1.2.5.127), Dst: 1.2.6.133 (1.2.6.133)
Transmission Control Protocol, Src Port: desktop-dna (2763), Dst Port: ms-sql-s (1433), Seq: 0, Len: 0

No.     Time        Source                Destination           Protocol Info
  2 0.000123    1.2.6.133         1.2.5.127         TCP      ms-sql-s > desktop-dna     [SYN, ACK] Seq=0 Ack=1 Win=8192 Len=0 MSS=1460 SACK_PERM=1

Frame 2: 62 bytes on wire (496 bits), 62 bytes captured (496 bits)
Ethernet II, Src: Vmware_b7:00:05 (00:50:56:b7:00:05), Dst: Cisco_31:5e:09 (00:26:0b:31:5e:09)
Internet Protocol, Src: 1.2.6.133 (1.2.6.133), Dst: 1.2.5.127 (1.2.5.127)
Transmission Control Protocol, Src Port: ms-sql-s (1433), Dst Port: desktop-dna (2763), Seq: 0, Ack: 1, Len: 0

No.     Time        Source                Destination           Protocol Info
  3 0.000884    1.2.5.127         1.2.6.133         TCP      desktop-dna > ms-sql-s [ACK] Seq=1 Ack=1 Win=65535 Len=0

And netstat

TCP    1.2.6.133:1433     1.2.2.98:26895     TIME_WAIT       0
TCP    1.2.6.133:1433     1.2.2.98:26912     TIME_WAIT       0
TCP    1.2.6.133:1433     1.2.2.98:26918     TIME_WAIT       0
TCP    1.2.6.133:1433     1.2.2.98:26931     TIME_WAIT       0
TCP    1.2.6.133:1433     1.2.5.127:2736     TIME_WAIT       0
TCP    1.2.6.133:1433     1.2.5.127:2737     TIME_WAIT       0
TCP    1.2.6.133:1433     1.2.5.127:2738     TIME_WAIT       0
TCP    1.2.6.133:1433     1.2.5.127:2739     TIME_WAIT       0

Edit:
Seems it’s the master/msdb/model databases that can’t be restored due to the version mismatch.

Answer

Are you looking at this based on reports of failure, or because the network trace looks funny?

If you can get a simultaneous capture at the server and an affected client, that will tell you more.

Possible reasons for seeing a 3-way handshake succeed but nothing thereafter:

  • TCP Offload Engine is enabled and the NIC is running in Chimney mode
    • (TOE- use netsh int tcp sh gl to check whether the OS thinks TCP offload is off or on, but note that the NIC driver must also have it enabled in order for it to work)
    • Just noticed the VMWare entry in the trace; TOE doesn’t work on VMs yet.
  • MTU issues between server and client
  • Server is nonresponsive, or
  • Client never sends initial command

Attribution
Source : Link , Question Author : 3molo , Answer Author : TristanK

Leave a Comment