20

A linux server of mine is trying to establish a LDAPS connection to a global catalog server and the connection is getting dropped (presumably by the GC side).

For the purpose of discussion, let's say that 1.1.1.1 is the Linux server and 1.2.3.4 is the global catalog server.

If I try to use telnet from the Linux box, I see: 

[root@foobox ~]# telnet gcfoo.exampleAD.local 3269
Trying 1.2.3.4...
Connected to gcfoo.examplead.local.
Escape character is '^]'.
Connection closed by foreign host.

There's no delay between the 4th and 5th lines. It just immediately drops the connection.

I thought that telnet results might be a little misleading (since it's not actually appropriate for any type of secure communication) so I collected a packet capture of the actual connection attempt from the appliance (using the actual program requiring LDAPS).

Here's what I see (again, IPs and source ports have been renamed to protect the innocent): 

No.     Time      Source     Destination      Protocol    Length    Info
1       0.000000  1.1.1.1    1.2.3.4          TCP         66        27246 > msft-gc-ssl [SYN] Seq=0 Win=5840 Len=0 MSS=1460 SAC_PERM=1 WS=128
2       0.000162  1.2.3.4    1.1.1.1          TCP         62        msft-gc-ssl > 27246 [SYN, ACK] Seq=0 Ack=1 Win=8192 Len=0 MSS=1460 SACK_PERM=1
3       0.000209  1.1.1.1    1.2.3.4          TCP         54        27246 > msft-gc-ssl [ACK] Seq=1 Ack=1 Win=5840 Len=0
4       0.003462  1.1.1.1    1.2.3.4          TCP         248       27246 > msft-gc-ssl [PSH, ACK] Seq=1 Ack=1 Win=5840 Len=194
5       0.007264  1.2.3.4    1.1.1.1          TCP         60        msft-gc-ssl > 27246 [RST] Seq=1 Win=64046 Len=0

I'm a bit rusty with TCP/IP so please forgive my ignorance... I see the three-way handshake taking place in packets 1-3. That makes sense. What's going on in packet #4 though? What does [PSH, ACK] mean? This seems like a redundant acknowledgement that's unnecessary. Is actual data being sent in this 4th packet? Or is this some weird continuation of the handshake?

Mike B
  • 11,871
  • 42
  • 107
  • 168

2 Answers2

28

PSH is a Push flag: http://ask.wireshark.org/questions/20423/pshack-wireshark-capture

The Push flag tells the receiver's network stack to "push" the data straight to the receiving socket, and not to wait for any more packets before doing so.

The Push flag usually means that data has been sent whilst overriding an in-built TCP efficiency delay, such as Nagle's Algorithm or Delayed Acknowledgements.

These delays make TCP networking more efficient at the cost of some latency (usually around a few tens of milliseconds). A latency-sensitive application does not want to wait around for TCP's efficiency delays so the application will usually disable them, causing data to be sent as quick as possible with a Push flag set.

On Linux, this is done with the setsockopt() flags TCP_QUICKACK and TCP_NODELAY. See man 7 socket for more information.

suprjami
  • 3,536
  • 21
  • 29
DarkMoon
  • 1,039
  • 15
  • 30
8

@DarkMoon explained what the PSH flag signifies. In regards to your data, the connection establishment completes (3-way handshake), then, yes, the client sent 194 bytes of data to the server (Len=194). The server did not like the data and closed the connection. Potentially the client isn't configured properly to communicate with the server or vice versa e.g. a SSL/TLS mismatch.

If you have access, I'd suggest examining the logs on the server to see if it logged what it didn't like about the client's data.

karyhead
  • 426
  • 3
  • 6