Ask Your Question
0

TCP Connection disconnect

asked 2022-01-07 09:29:18 +0000

updated 2022-01-07 10:32:58 +0000

grahamb gravatar image

Hello,

we have an issue with Server receiving data from external Server. Server (13.248.140.239) sends last data packet seq 1633924067 and the client ACKs this packet (packet 48990). After 20 sec. Server (10.2.3.239) sends a reset, but no Keep-Alives occurs. Is this a server side TCP Stack or Application Problem?

PS: Download PCAP https://1drv.ms/u/s!AtvGTDjAxDJngzdcX...

thanks in advanced for all your feedbacks

RG Dirk

edit retag flag offensive close merge delete

Comments

Hi,

unfortunatly I am not able to go further in that case because the problem has gone untill now I have no idear what causes the issue. Thank you all for spending time I will keep you updated.

RG Dirk

dmayer gravatar imagedmayer ( 2022-01-12 16:26:58 +0000 )edit

2 Answers

Sort by ยป oldest newest most voted
1

answered 2022-01-08 11:29:45 +0000

SYN-bit gravatar image

Without decrypting the data it would be very difficult to determine what is going on at the application level. Are you able to reproduce the error with Edge, Firefox or Chrome with SSLKEYLOGFILE environment variable to collect the TLS session keys?

I'm assuming the session that ends normal with FINs (tcp.stream==1) is working and the one that ends with the RST (tcp.stream==2) is not working. Looking at the encrypted packets, I see the communication ending with a 29 bytes TLS record in the working and non-working situation. As TLS reconds can only be 16384 bytes long cleartext and I see TLS records of 16408 bytes, I assume TLS has added 24 bytes to each record (which is quite common). This would mean the last TLS record of each tranfser contains 29 -24 = 5 bytes of unencrypted payload. With a chunked HTTP response, the last chunk has a length marker of '0' followed by \r\n\r\n. Which is 5 bytes too. So I suspect that HTTP object has ben transferred fully (from the HTTP client/server point of view).

My guess would be that the HTTP object itself has been transferred fine (at HTTP, TLS and TCP level), but that the content of the HTTP object is not acceptable by the client. Again, decryption of the traffic is needed to properly see what is going on.

edit flag offensive delete link more

Comments

Hello,

thanks for deep diving in to that case and also for your proffessional answer ;)

unfortunatly we are not able to reproduce that error with any browser because the application use a windows task loading a script. I am going to capture also on other places like firewall etc.and I will post my results.

RG Dirk

dmayer gravatar imagedmayer ( 2022-01-08 14:55:53 +0000 )edit

Capturing on other locations will not help analyze this issue unless the data transmitted in this TLS stream is visible unencrypted at the other capture locations.

Can the application be proxied? If so, you could proxy it through mitmproxy or similar.

SYN-bit gravatar imageSYN-bit ( 2022-01-08 16:02:14 +0000 )edit
0

answered 2022-01-07 10:37:31 +0000

grahamb gravatar image

10.2.3.239 is the client, so the client closes the connection with a RST 20 seconds after receiving the previous packet.

Could either be the client has received all the expected data and is using a RST to close the connection, or the client has gotten fed up waiting for more data and closed the connection as "dead".

edit flag offensive delete link more

Comments

Hi,

The Client did not receive all the data for sure. Could it be an issue at client 10.2.3.239 becuase TCP usaly hold the connection but client it sends a reset before Keep Alive occurs?

PS: thanks for your answer ;)

RG Dirk

dmayer gravatar imagedmayer ( 2022-01-07 10:46:00 +0000 )edit

I would suspect the client application, check for any logs from it to determine what it's up to. This is one of those occasions where Wireshark can tell you what happened but not why.

grahamb gravatar imagegrahamb ( 2022-01-07 11:14:21 +0000 )edit

Thanx Graham

dmayer gravatar imagedmayer ( 2022-01-07 11:27:52 +0000 )edit

The last TCP packets between the client and server were frames 48989 and 48990. It appears that the client was waiting for the data from the server. The session was dropped when the application or user didn't receive data. I think it was dropped because it wasn't TCP FIN.

BigFatCat gravatar imageBigFatCat ( 2022-01-07 12:49:35 +0000 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

1 follower

Stats

Asked: 2022-01-07 09:29:18 +0000

Seen: 73 times

Last updated: Jan 08