After transmitting many normal packets in response to a post request,the server suddently sent [rst,ack]

asked 2020-04-11 08:42:45 +0000

vainquit
3 ●1 ●1 ●6

updated 2020-04-13 13:38:41 +0000

The cilent (emulator of android studio) makes a post request to a remote server (port:80, built by Flask in centos7). The connection was built successfully, and the server began to transmit a lot of packets to the cilent.

At first, everything seemed to go well: the cilent has received many normal packets and read infomation from them. But suddently, the server sent a packet flagged with [RST,ACK], and the cilent got an erro "java.net.SocketException: Connection reset".

(screenshot: https://imgur.com/6l7PQ8Z) (download the pcapng: https://easyupload.io/vophjy, password:wireshark) (Packets were captured on client side. I also captured both on server side and client side at the meantime, and uploaded them in the "update" section below)

My code in Android Studio (worte with JAVA) is like this:

        ..........
        InputStream in=connection.getInputStream(); //connection is a HttpURLConnection
        StringBuilder strbd =new StringBuilder(); 
        byte[] bbuf=new byte[1024];
            while(in.read(bbuf)>0){
                strbd.append(new String(bbuf,0,in.read(bbuf)).trim());
            }
        } catch (IOException e) {
            e.printStackTrace();
            Log.d("ppppx", String.valueOf(strbd.length()));//output:7784, or 9187, or 10079, etc...
        }
        ............

I have tried everything I can to find the reason, but failed, due to my limited knowledge in TCP/IP protocol. I will be really grateful if you can give me an enlightenment, thanks!

----------------------------------------------------------update---------------------------------------------------------------

I just captured the packets both on the client side and the server side at the meantime. I do this work twice, and upload all of them ( view the images and download the packets on http://118.89.144.241/)

edit retag flag offensive close merge delete

Comments

May I ask how you made the capture? It is interesting to me that there are frames from both sides that are shorter than the minimum ethernet frame length. Normally you would see that only for outgoing packets. But maybe the trace was made in a virtualized environment where the padding of incoming packets is stripped before being forwarded.

SYN-bit ( 2020-04-11 11:21:20 +0000 )edit

Have you done any logging on the server side?
https://stackoverflow.com/questions/4...

Chuckc ( 2020-04-11 15:41:57 +0000 )edit

@SYN-bit Hi, I made the capture on the client side. My wireshark captured all the packets under the "wifi" option ( which may mean all the packets from my computer will be captured? I assume). And I take some time to upload some packets which were captured on both server side and client side at the meantime on http://www.vainquit.com/download. If you are interested.

vainquit ( 2020-04-12 09:39:05 +0000 )edit

@bubbasnmp emmm....the original answer didn't include the log of the server side. And I just re-captured them on both server side (by tcpdump) and client side(by wireshark) on http://www.vainquit.com/download.

vainquit ( 2020-04-12 09:42:12 +0000 )edit

add a comment

answered 2020-04-11 11:21:11 +0000

SYN-bit

18344 ●9 ●301 ●255 https://SYN-b.it

A TCP RST can sent by a system for numerous reasons. It's meaning is "Hey, I'm terminating this connection right now, so don't bother to try to communicate anymore". Look at it as if you are on a phonecall and the other sides hangs up without saying goodbye or anything.

A TCP RST is normally sent by one of the endpoints, but it can also be sent by an intermediate device like an Intrusion Prevention System (IPS) or a Firewall or any other device that is put in the path the protect the systems behind it.

In your trace it looks like it was the server itself (because the IP TTL and IP ID seem to match previous packets). So the question is why does this server break the conenction in the middle of sending data? That can't be determined from the packets, that needs to be investigated on the server.

edit flag offensive delete link

Comments

Thank you for you reply :) At least I can locate the problem on the server side now. I would send a ticket to the customer service of the host provider later.

vainquit ( 2020-04-12 09:48:07 +0000 )edit

Thank you for uploading traces from both sides. In the server traces you can see that the server starts to respond before the full request was received. Then when later parts of the request are received, it sends out TCP RST packets. So on the server side the software needs to be fixed to read the full request before starting to answer.

The way the http chunking of the request is done is not normal. Sending one byte of the post data at a time in a http chunk is far from optimal. But it could of course be on purpose to see how the server would respond (for pentesting purposes). If you post the request data in one go (you could try using HTTP/1.0 as it does not have chunking) I think you will not trigger this buggy behavior of the server.

SYN-bit ( 2020-04-12 11:45:37 +0000 )edit

OH!!!That's great!!That's great!It works!!You are right!!Everything runs perfectly,as soon as I delete "setChunkedStreamingMode(0)" in my code on Android Studio .If were not for your instruction,I wouldn't remember I had written such piece of shit!!Thank you my friend!!I am really gratefull for that ^_^

vainquit ( 2020-04-12 17:45:33 +0000 )edit

By the way, is it a common phenomenon that sending HTTP post with "Transfer-Encoding: chunked" in header will result in the server starting to respond before the full request was received?

vainquit ( 2020-04-12 17:46:46 +0000 )edit

You're very welcome, glad you were able to make it work!

No, it is a bug on the server side that it does not parse the chunked request body correctly. It should collect data until the last chunk with length 0 is received.

These are actually interesting captures. I can see from the differences in the client and server trace file that there is a device in between that terminates the TCP connections and behaves as an transport layer proxy or even an application layer proxy. Do you have any idea what kind of device that is? As I heard about the chinese firewall, could it be that firewall in this case? Or is it a loadbalancer of some sort?

SYN-bit ( 2020-04-12 20:09:53 +0000 )edit

Oh, since it now works, could you also upload traces of the client and server side of a working connection? (I'm curious to see the difference in bahavior)

SYN-bit ( 2020-04-12 20:11:22 +0000 )edit

Sure!I have uploaded the normal packets of both side on http://118.89.144.241/. Some RST packets are still captured, but I indeed get the full content from the post request, strange...As for the chinese great firewall's(GFW),I doubut it is the case,since the GFW mainly blocks the connections between chinese IPs and a list of specific IPs outside China.While both my client and server are inside China,so they can escape the censorship.But I have totally no idea what's playing the role terminating the TCP connections(sorry, I am new to most of protocols and network working mechanism.Even though the "chunk" and "loadbalancer" are new concepts to me).

vainquit ( 2020-04-13 18:02:15 +0000 )edit

No worries about being new. We were all new to the thing we know once. And we are all new to something else. Just keep learning :-)

HTTP Chunking is a mechanism used when a server does not know in advance how large a response will be, so it can't generate the "Content-Length:xxx" header. So by using chunking, it can send out the response in chunks. Where each chunk is preceded by the length of that chunk (in hex notation). When the full response has been sent, a chunk of length 0 is sent (so only the length line, no data). That way the receiving side knows it has the full object. (See: https://en.wikipedia.org/wiki/Chunked...)

A loadbalancer (often called an Application Delivery Controller as it does more than load-balancing these days) is a device that sits in the data path between the client and a ...(more)

SYN-bit ( 2020-04-13 19:30:37 +0000 )edit

The reason you are still seeing a TCP RST packet (this time from the client, not from the server) is that your code most likely does not close the connection actively after receiving the full content. You can see there is a ~2 sec delay between ACKnowledging the last data (frame 73 is the client trace) and sending the TCP RST (frame 75). I assume this is a timeout setting in the code for half closed connections.

This connection is half-closed as the server has already sent a packet with the FIN flag set (frame 72), normally this should trigger a FIN from the client side to actively close the connection in a normal fashion. But I'm no expert in writing code that uses TCP communication, so I don't know what you should do in your code to make it behave "properly".

SYN-bit ( 2020-04-13 19:39:40 +0000 )edit

Great explanation!Now I know why the loadbalancer has the potential to terminate the connection.

As for all the packets I upload, you can utilize those data as you like! They are not from secret documents, and actually just for experiment to some extent.You have teached me a lot, and I will be very happy if I can do something for you as well :)

I was pointed to take over another project now and hand over the current one to my colleaue.I will share your analysis of the latest packets to him, and also try my best to learn the knowledge of network mechanism. Thank you for these days' help, and have a nice day ヾ(=^▽^=)ノ

vainquit ( 2020-04-14 14:32:12 +0000 )edit

see more comments

After transmitting many normal packets in response to a post request,the server suddently sent [rst,ack]

Comments

1 Answer

Comments

Your Answer

Question Tools

Stats

Related questions

After transmitting many normal packets in response to a post request,the server suddently sent [rst,ack] edit

Comments

1 Answer

Comments

Your Answer

Question Tools

Stats

Related questions

After transmitting many normal packets in response to a post request,the server suddently sent [rst,ack]