Ask Your Question
0

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 gravatar image

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 gravatar imageSYN-bit ( 2020-04-11 11:21:20 +0000 )edit

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

Chuckc gravatar imageChuckc ( 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 gravatar imagevainquit ( 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 gravatar imagevainquit ( 2020-04-12 09:42:12 +0000 )edit

1 Answer

Sort by ยป oldest newest most voted
0

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

SYN-bit gravatar image

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 more

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 gravatar imagevainquit ( 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 gravatar imageSYN-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 gravatar imagevainquit ( 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 gravatar imagevainquit ( 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 gravatar imageSYN-bit ( 2020-04-12 20:09:53 +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: 2020-04-11 08:42:45 +0000

Seen: 820 times

Last updated: Apr 13 '20