Ayoi’s

Ok now let’s examine the trace file for communications between 192.168.2.11 and 192.168.2.102 thru port 31300. (It happens that we have Security Centre by tenable installed in here - I forgot about this - and based on the diagram it’s the port used for communication between thunder-client and Log Correlation Engine (LCE) and between LCE and Security Centre)

Ok let assume that 192.168.2.11 is one of the clients installed with the thunder-client and 192.168.2.102 is the LCE.

For first 3 lines it shows that the handshake completed. (I use the -S option for printing the absolute numbers)

17:43:32.682438 IP 192.168.2.11.3452 > 192.168.2.102.31300: S 2402359895:2402359895(0) win 16384 <mss 1460,nop,nop,sackOK>

17:43:32.682566 IP 192.168.2.102.31300 > 192.168.2.11.3452: S 3239928346:3239928346(0) ack 2402359896 win 5840 <mss 1460,nop,nop,sackOK>

17:43:32.685488 IP 192.168.2.11.3452 > 192.168.2.102.31300: . ack 3239928347 win 17520

192.168.2.11 is allowed to establish connection with the LCE at port 31300 where both of the party agreeing in using Selective Acknowledgement with maximum segment size is 1460 bytes. So there’s no problem with that. Now let see the next 3 lines

17:43:32.685618 IP 192.168.2.102.31300 > 192.168.2.11.3452: F 3239928347:3239928347(0) ack 2402359896 win 5840

17:43:32.685691 IP 192.168.2.11.3452 > 192.168.2.102.31300: P 2402359896:2402359908(12) ack 3239928347 win 17520

17:43:32.685810 IP 192.168.2.102.31300 > 192.168.2.11.3452: R 3239928347:3239928347(0) win 0

After completing the handshake, it seems that the LCE is sending a FIN flagged packet meaning finishing sending data and also going into FINWAIT_1 state which LCE expected to received acknowledgement from 192.168.2.11. But instead of acknowledging the FIN request, 192.168.2.11 send 12 bytes worth of data to LCE. And of cause the LCE will respond this activity by sending a RST flagged packet informing 192.168.2.11 that the connection is reset and notice that LCE didn’t acknowledge the data (12 bytes) sent by 192.168.2.11

17:43:32.687122 IP 192.168.2.11.3452 > 192.168.2.102.31300: . ack 3239928348 win 17520

17:43:32.687239 IP 192.168.2.102.31300 > 192.168.2.11.3452: R 3239928348:3239928348(0) win 0

17:43:32.687308 IP 192.168.2.11.3452 > 192.168.2.102.31300: F 2402359908:2402359908(0) ack 3239928348 win 17520

17:43:32.687425 IP 192.168.2.102.31300 > 192.168.2.11.3452: R 3239928348:3239928348(0) win 0

After receiving RST flagged packet from the LCE then 192.168.2.11 acknowledge the F flagged packet sent before by the LCE. And instead of sending any acknowledgement on FIN flagged packet sent by 192.168.2.11, the LCE send RST.

I dun think this behaviour has any relation with half close or half open TCP.

I dun think the LCE is receiving any data from .11 even tho in the trace above .11 did PUSH 12 bytes worth of data.

Why LCE is sending F flagged packet after establishing connection with .11 before that fella even send any data.

Compared to this :

16:12:14.521462 IP 192.168.8.130.80 > 192.168.8.1.2265: P 3687267773:3687268152(379) ack 3484844050 win 65535

16:12:14.521486 IP 192.168.8.1.2265 > 192.168.8.130.80: . ack 3687268152 win 65535

16:12:14.522618 IP 192.168.8.1.2265 > 192.168.8.130.80: F 3484844050:3484844050(0) ack 3687268152 win 65535

16:12:14.522618 IP 192.168.8.130.80 > 192.168.8.1.2265: . ack 3484844051 win 65535

16:12:14.522618 IP 192.168.8.130.80 > 192.168.8.1.2265: F 3687268152:3687268152(0) ack 3484844051 win 65535

16:12:14.522618 IP 192.168.8.1.2265 > 192.168.8.130.80: . ack 3687268153 win 65535

That’s what I called gracefull ending of conversation

Any other ideas?

Comments RSS