Figured it out! One of the configuration scripts dhcpcd was running on my device was not agreeing with the hardware/drivers I was using. I modified the script and it resolved the buggy TCP/IP connections.
Android HttpClient sending rst packet during execute
-
07-03-2022 - |
Вопрос
I have encountered a rather befuddling conundrum when attempting to use an HttpClient
in my application. Seemingly at random, HttpClient.execute(HttpRequest)
will never return! Well... if I set a timeout using HttpConnectionParams.setConnectionTimeout(HttpParams, int)
it will throw a timeout exception. Otherwise my background thread will hang forever.
I tried everything under the sun to remedy the issue, but to no avail. Left with no alternatives I took a packet capture of the issue and found something surprising! (Or maybe not so surprising, I'm not really a network guy)
Successful call:
905 75.286537 192.168.20.163 192.168.20.171 TCP 74 34340 > http [SYN] Seq=0 Win=5840 Len=0 MSS=1460 SACK_PERM=1 TSval=411399 TSecr=0 WS=16
906 75.286634 192.168.20.171 192.168.20.163 TCP 74 http > 34340 [SYN, ACK] Seq=0 Ack=1 Win=8192 Len=0 MSS=1260 WS=256 SACK_PERM=1 TSval=2129684 TSecr=411399
919 78.280782 192.168.20.163 192.168.20.171 TCP 74 34340 > http [SYN] Seq=0 Win=5840 Len=0 MSS=1460 SACK_PERM=1 TSval=411783 TSecr=0 WS=16
920 78.286704 192.168.20.171 192.168.20.163 TCP 74 http > 34340 [SYN, ACK] Seq=0 Ack=1 Win=8192 Len=0 MSS=1260 WS=256 SACK_PERM=1 TSval=2129984 TSecr=411399
955 84.280710 192.168.20.163 192.168.20.171 TCP 74 34340 > http [SYN] Seq=0 Win=5840 Len=0 MSS=1460 SACK_PERM=1 TSval=412551 TSecr=0 WS=16
956 84.287958 192.168.20.171 192.168.20.163 TCP 70 http > 34340 [SYN, ACK] Seq=0 Ack=1 Win=65535 Len=0 MSS=1260 SACK_PERM=1 TSval=2130584 TSecr=411399
957 84.288332 192.168.20.163 192.168.20.171 TCP 66 34340 > http [ACK] Seq=1 Ack=1 Win=93440 Len=0 TSval=412551 TSecr=2130584
959 84.648812 192.168.20.163 192.168.20.171 TCP 294 [TCP segment of a reassembled PDU]
960 84.649333 192.168.20.163 192.168.20.171 HTTP 411 POST /xxxxx.Service/xxxxx.asmx/GetReservations HTTP/1.1 (application/json)
961 84.649368 192.168.20.171 192.168.20.163 TCP 66 http > 34340 [ACK] Seq=1 Ack=574 Win=16630272 Len=0 TSval=2130620 TSecr=412598
962 84.656518 192.168.20.171 192.168.20.163 TCP 1314 [TCP segment of a reassembled PDU]
963 84.656560 192.168.20.171 192.168.20.163 HTTP 580 HTTP/1.1 200 OK (application/json)
964 84.657192 192.168.20.163 192.168.20.171 TCP 66 34340 > http [ACK] Seq=574 Ack=1249 Win=119808 Len=0 TSval=412599 TSecr=2130621
965 84.686906 192.168.20.163 192.168.20.171 TCP 66 34340 > http [ACK] Seq=574 Ack=1764 Win=159744 Len=0 TSval=412603 TSecr=2130621
968 85.187509 192.168.20.163 192.168.20.171 TCP 66 34340 > http [FIN, ACK] Seq=574 Ack=1764 Win=159744 Len=0 TSval=412667 TSecr=2130621
969 85.187567 192.168.20.171 192.168.20.163 TCP 66 http > 34340 [ACK] Seq=1764 Ack=575 Win=16630272 Len=0 TSval=2130674 TSecr=412667
Failing call:
2653 195.296440 192.168.20.163 192.168.20.171 TCP 74 60962 > http [SYN] Seq=0 Win=5840 Len=0 MSS=1460 SACK_PERM=1 TSval=426761 TSecr=0 WS=16
2656 195.296894 192.168.20.171 192.168.20.163 TCP 74 http > 60962 [SYN, ACK] Seq=0 Ack=1 Win=8192 Len=0 MSS=1260 WS=256 SACK_PERM=1 TSval=2141685 TSecr=426761
2658 195.297191 192.168.20.163 192.168.20.171 TCP 66 60962 > http [ACK] Seq=1 Ack=1 Win=5840 Len=0 TSval=426761 TSecr=2141685
2659 195.669276 192.168.20.163 192.168.20.171 TCP 294 [TCP segment of a reassembled PDU]
2660 195.669749 192.168.20.163 192.168.20.171 HTTP 411 POST /xxxxx.Service/xxxxx.asmx/GetReservations HTTP/1.1 (application/json)
2661 195.669783 192.168.20.171 192.168.20.163 TCP 66 http > 60962 [ACK] Seq=1 Ack=574 Win=66048 Len=0 TSval=2141722 TSecr=426809
2662 195.670095 192.168.20.163 192.168.20.171 TCP 60 60962 > http [RST] Seq=574 Win=0 Len=0
2802 215.154316 192.168.20.163 192.168.20.171 TCP 74 48450 > http [SYN] Seq=0 Win=5840 Len=0 MSS=1460 SACK_PERM=1 TSval=429303 TSecr=0 WS=16
2803 215.154397 192.168.20.171 192.168.20.163 TCP 74 http > 48450 [SYN, ACK] Seq=0 Ack=1 Win=8192 Len=0 MSS=1260 WS=256 SACK_PERM=1 TSval=2143671 TSecr=429303
2804 215.154704 192.168.20.163 192.168.20.171 TCP 60 48450 > http [RST] Seq=1 Win=0 Len=0
2807 215.716852 192.168.20.163 192.168.20.171 TCP 66 60962 > http [FIN, ACK] Seq=574 Ack=1 Win=5840 Len=0 TSval=429375 TSecr=2141685
2826 218.152321 192.168.20.163 192.168.20.171 TCP 74 48450 > http [SYN] Seq=0 Win=5840 Len=0 MSS=1460 SACK_PERM=1 TSval=429687 TSecr=0 WS=16
2827 218.152387 192.168.20.171 192.168.20.163 TCP 74 [TCP Previous segment lost] http > 48450 [SYN, ACK] Seq=821395 Ack=1 Win=8192 Len=0 MSS=1260 WS=256 SACK_PERM=1 TSval=2143970 TSecr=429687
2828 218.152669 192.168.20.163 192.168.20.171 TCP 60 48450 > http [RST] Seq=1 Win=0 Len=0
2957 224.152259 192.168.20.163 192.168.20.171 TCP 74 48450 > http [SYN] Seq=0 Win=5840 Len=0 MSS=1460 SACK_PERM=1 TSval=430455 TSecr=0 WS=16
2958 224.152379 192.168.20.171 192.168.20.163 TCP 74 [TCP Previous segment lost] http > 48450 [SYN, ACK] Seq=1936893 Ack=1 Win=8192 Len=0 MSS=1260 WS=256 SACK_PERM=1 TSval=2144570 TSecr=430455
2959 224.152722 192.168.20.163 192.168.20.171 TCP 60 48450 > http [RST] Seq=1 Win=0 Len=0
3032 230.130084 192.168.20.163 192.168.20.171 TCP 639 [TCP Retransmission] 60962 > http [FIN, PSH, ACK] Seq=1 Ack=1 Win=5840 Len=573 TSval=431220 TSecr=2141685
The weirdness starts at line 2662 when for no apparent reason, my device sends a RST packet to the server? Why on earth would it do that? You can see the termination of the connection that occurs at packet 2802 ~20s later (which is my timeout value). The thing is, when the device sends the RST packet HttpClient.execute
doesn't return, it just sits there!
Maybe I missed something when configuring my client?
private static DefaultHttpClient newClient()
{
HttpParams params = new BasicHttpParams();
ConnManagerParams.setMaxConnectionsPerRoute(params, new ConnPerRouteBean(30));
ConnManagerParams.setMaxTotalConnections(params, 100);
HttpProtocolParams.setContentCharset(params, HTTP.DEFAULT_CONTENT_CHARSET);
HttpProtocolParams.setUseExpectContinue(params, false);
HttpProtocolParams.setUserAgent(params, "XXXXX XXXXXXXXXX/1.0");
HttpProtocolParams.setVersion(params, HttpVersion.HTTP_1_1);
HttpConnectionParams.setConnectionTimeout(params, SOCKET_OPERATION_TIMEOUT);
HttpConnectionParams.setSoTimeout(params, SOCKET_OPERATION_TIMEOUT);
HttpConnectionParams.setSocketBufferSize(params, 8192);
HttpConnectionParams.setStaleCheckingEnabled(params, true);
SchemeRegistry reg = new SchemeRegistry();
reg.register(new Scheme("http", PlainSocketFactory.getSocketFactory(), 80));
reg.register(new Scheme("https", SSLSocketFactory.getSocketFactory(), 443));
ThreadSafeClientConnManager mgr = new ThreadSafeClientConnManager(params, reg);
DefaultHttpClient client = new DefaultHttpClient(mgr, params);
return client;
}
Or maybe it has to do with how I issue the request?
private JSONObject performRequest(String url, JSONObject values)
throws ClientProtocolException, IOException, JSONException {
HttpPost httpPost = new HttpPost(url);
httpPost.setHeader("content-type", "application/json");
httpPost.setHeader(HTTP.CONN_DIRECTIVE,HTTP.CONN_CLOSE);
StringEntity requestEntity;
requestEntity = new StringEntity(values.toString(), HTTP.UTF_8);
httpPost.setEntity(requestEntity);
HttpResponse response;
HttpEntity responseEntity = null;
String responseString;
try {
//this is the line that never returns
response = _httpClient.execute(httpPost);
responseEntity = response.getEntity();
responseString = EntityUtils.toString(responseEntity);
} finally {
if (responseEntity != null)
responseEntity.consumeContent();
}
String d = new JSONObject(responseString).getString("d");
if (d.length() > 0)
return new JSONObject(d);
else
return new JSONObject();
}
The same HttpClient
is used for all web service calls in my application and multiple threads have access to this client. I has assumed that the use of a ThreadSafeClientConnManager
would provide the thread safety I need, but I guess there might be something else I missed.
Any help is much appreciated, I've been beating my head against the keyboard all day trying to solve this.
edit I suppose I should mention this only occurs when I use a machine name as the url, not if I use the specific ip address.
Решение 2
Другие советы
I've had a very similar problem before. It turned out that I had some data in my POST body that the server didn't like. I used trial and error to eliminate what I was throwing into my HttpPost object until the request went through.
For me, I was throwing in a bad key-value pair.
In other words, I believe your problem is somewhere in your "values" object. My problem was that I had the JSON key "_b" in my POST request. Try removing JSON values until the server stops timing out.
One more tip: To test for this, I created an app that just repeatedly makes a network request, one that I know is prone to timing out, in a loop until I get the timeout. Normally I'd time out within the first 100 requests. May help if you do the same.