0

I'm getting below exception in my Android application sometime in a while, not very frequent one.

11-18 10:24:39.621 D/OkHttp  (19124): <-- HTTP FAILED: java.net.ConnectException: Failed to connect to www.test.com/abc.abc.2.4:443
11-18 10:24:39.621 D/MSRetrofitCallBack(19124): https://www.test.com/webservices/response
11-18 10:24:39.622 D/TransactionActivity(19124): postUpdateTxn FailFailed to connect to www.test.com/abc.abc.2.4:443

After started decode it further at server end, I come to know there is problem in three way handshake of TCP/IP protocol. My app sending SYN to server and server responds with SYN-ACK to my app, post that my app failed to send ACK back to server. Not sure what happened at my app end, I could see network connection in phone is good, however, my app not sending ACK to server. This situation is occurred only when mobile data was used, same app is working fine when WiFi is connected.

Kindly share ideas to find out root cause of this problem.

Few details:

OS: Android 7

Library: com.squareup.retrofit2:retrofit:2.3.0

TCP/IP Communication:

enter image description here

Could you please check the above image, highlighted in Green have [ FIN, ACK ] from server to client and client sends [ ACK ] to server. However, client sends [ SYN ] from same port, is this expected behaviour, if not, who is responsible to fix this.

Thank you!

EDIT 1:

I did followed How to close http client connection after getting the response? to close HTTP connection. Now client(Android) is initiating [ FIN, ACK ] first and server responding [ ACK ]. However, client is not sending [ ACK ] for [ FIN, ACK ] coming from server, not sure this would cause any issue, please help.

SathishKumar
  • 1,644
  • 1
  • 14
  • 28
  • 1
    The error of *"Failed to connect"* suggests that the SYN-ACK from the server is not reached by your mobile device and that's why it does not send its ACK back to finish the TCP handshake. Looks more like a problem caused by the mobile ISP. You might try to use a VPN and see if the problem vanishes. – Steffen Ullrich Nov 20 '22 at 17:18
  • @SteffenUllrich, Sure, I'll try with VPN whether the SYN-ACK reaches my mobile device or not and confirm you here. Thanks for quick response. – SathishKumar Nov 20 '22 at 17:56
  • @SteffenUllrich, I'm still working on to capture TCP/IP dump. And, our network team is claiming that mobile device is not changing the PORT for communication for subsequent calls, do we have control to change communication port. – SathishKumar Nov 21 '22 at 05:18
  • 1
    *"And, our network team is claiming that mobile device is not changing the PORT for communication for subsequent calls,"* - no idea what they base the claims on. Maybe they are just seeing the retransmission attempts of SYN since the SYN-ACK is not received by the client. These retransmissions are the same packet and thus come also from the same port. Otherwise - TCP clients usually let the OS pick a random source port. If is uncommon that the application explicitly picks its own source port. – Steffen Ullrich Nov 21 '22 at 05:38
  • @SteffenUllrich, could you please check "TCP/IP Communication" section updated in question. – SathishKumar Nov 22 '22 at 10:44
  • The wireshark output shows that a connection was closed and then reopened with the same source port. This looks like a bug in the client to me. – Steffen Ullrich Nov 22 '22 at 11:41
  • @SteffenUllrich, if you have any guidance to fix at client end, could you please help. Android phone is client here and I'm using Retrofit for HTTPS connection. – SathishKumar Nov 22 '22 at 11:58

0 Answers0