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
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.
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
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".
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.
Asked: 2022-01-07 09:29:18 +0000
Seen: 1,185 times
Last updated: Jan 08 '22
Copyright Wireshark Foundation, 2017-2023 Content on this site is licensed under a Creative Commons Attribution Share Alike 3.0 license.
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