0

I have a tcpdump for a HTTP request that I need to analyse. It consists of three connections. First one is established, then another. Then, after ~190 segments the client abruptly closes the first conneciton through a RST flag and starts the third, presumably to replace the first.

But prior to the first RST segment everything was going normally so I'm not sure why it could have happened. Another odd thing is that the server continues to send data, another 9 segments for 900 microseconds even though the client responds with a RST to every segment. Could this be because it took 900 microseconds before the server received and processed the RST, therefor kept sending data before then? Or is there another reason it would continue to send data?

Here is the relevant segment of the data: 

15:08:01.189085 IP 128.186.6.14.80 > 172.16.2.1.45243: P 24904:25243(339) ack 3359 win 49248
15:08:01.189657 IP 172.16.2.1.45243 > 128.186.6.14.80: P 3359:3760(401) ack 25243 win 8610 <nop,nop,timestamp 3136070386 173340265>
15:08:01.226055 IP 172.16.2.1.45242 > 128.186.6.14.80: . ack 59543 win 8312 <nop,nop,timestamp 3136070423 173340249>
15:08:01.318224 IP 128.186.6.14.80 > 172.16.2.1.45242: . 59543:60923(1380) ack 3458 win 49248
15:08:01.318328 IP 128.186.6.14.80 > 172.16.2.1.45242: . 60923:62215(1292) ack 3458 win 49248
15:08:01.318346 IP 172.16.2.1.45242 > 128.186.6.14.80: . ack 62215 win 8312 <nop,nop,timestamp 3136070515 173340249>
15:08:01.318475 IP 128.186.6.14.80 > 172.16.2.1.45242: . 62215:63595(1380) ack 3458 win 49248
15:08:01.318537 IP 172.16.2.1.45242 > 128.186.6.14.80: R 3458:3458(0) ack 63595 win 8312 <nop,nop,timestamp 3136070515 173340249>
15:08:01.318612 IP 128.186.6.14.80 > 172.16.2.1.45242: . 63595:64975(1380) ack 3458 win 49248
15:08:01.318629 IP 172.16.2.1.45242 > 128.186.6.14.80: R 1577678365:1577678365(0) win 0
15:08:01.318727 IP 128.186.6.14.80 > 172.16.2.1.45242: . 64975:66355(1380) ack 3458 win 49248
15:08:01.318740 IP 172.16.2.1.45242 > 128.186.6.14.80: R 1577678365:1577678365(0) win 0
15:08:01.318825 IP 172.16.2.1.45244 > 128.186.6.14.80: S 1580873046:1580873046(0) win 5840 <mss 1460,sackOK,timestamp 3136070515 0,nop,wscale 2>
15:08:01.318849 IP 128.186.6.14.80 > 172.16.2.1.45242: . 66355:67735(1380) ack 3458 win 49248
15:08:01.318860 IP 172.16.2.1.45242 > 128.186.6.14.80: R 1577678365:1577678365(0) win 0
15:08:01.318984 IP 128.186.6.14.80 > 172.16.2.1.45242: . 67735:69115(1380) ack 3458 win 49248
15:08:01.318997 IP 172.16.2.1.45242 > 128.186.6.14.80: R 1577678365:1577678365(0) win 0
15:08:01.319093 IP 128.186.6.14.80 > 172.16.2.1.45242: . 69115:70407(1292) ack 3458 win 49248
15:08:01.319104 IP 172.16.2.1.45242 > 128.186.6.14.80: R 1577678365:1577678365(0) win 0
15:08:01.319222 IP 128.186.6.14.80 > 172.16.2.1.45242: . 70407:71787(1380) ack 3458 win 49248
15:08:01.319232 IP 172.16.2.1.45242 > 128.186.6.14.80: R 1577678365:1577678365(0) win 0
15:08:01.319338 IP 128.186.6.14.80 > 172.16.2.1.45242: . 71787:73167(1380) ack 3458 win 49248
15:08:01.319351 IP 172.16.2.1.45242 > 128.186.6.14.80: R 1577678365:1577678365(0) win 0
15:08:01.319454 IP 128.186.6.14.80 > 172.16.2.1.45242: . 73167:74547(1380) ack 3458 win 49248
15:08:01.319465 IP 172.16.2.1.45242 > 128.186.6.14.80: R 1577678365:1577678365(0) win 0
15:08:01.319569 IP 128.186.6.14.80 > 172.16.2.1.45242: . 74547:75927(1380) ack 3458 win 49248
15:08:01.319581 IP 172.16.2.1.45242 > 128.186.6.14.80: R 1577678365:1577678365(0) win 0
15:08:01.324493 IP 128.186.6.14.80 > 172.16.2.1.45243: P 25243:25513(270) ack 3760 win 49248
15:08:01.325287 IP 128.186.6.14.80 > 172.16.2.1.45243: P 25513:26594(1081) ack 3760 win 49248
15:08:01.325587 IP 172.16.2.1.45243 > 128.186.6.14.80: P 3760:4160(400) ack 26594 win 8610 <nop,nop,timestamp 3136070522 173340265>
15:08:01.452627 IP 128.186.6.14.80 > 172.16.2.1.45244: S 3542691101:3542691101(0) ack 1580873047 win 49248 <nop,nop,timestamp 173340450 3136070515,mss 1380,nop,wscale 0,nop,nop,sackOK>

128.186.6.14.80 is the server, and 172.16.2.1.4524(2/3/4) is the client. Port 45243 belongs to the second connection, 45242 is the first that gets closed by RST and 45244 is the third that starts immediately after the client sends the initial RST for the first.

Is there any way to know what caused this RST from the logs? Perhaps a particular behaviour of HTTP? The other two connections closed normally with FIN handshakes.

Jansky
  • 101
  • 1
  • 3
    Too few context so one can only guess widely. A simple explanation might be that the client just hit stop or closed the browser tab or rejected the offered download of a file. And yes, it takes some time for the server to get and process the RST and in that time it keeps sending data. – Steffen Ullrich Dec 04 '16 at 13:09
  • Cheers man I appreciate the reply. Looks like I'll have to assume that it's due to either client disconnect or an error. – Jansky Dec 05 '16 at 20:11
  • This capture is what you can expect to see on the receiving end of a connection when the connection is closed in the middle of the stream. The timing and order of the packets would look very different if you captured the same thing on the sending side of the connection. – kasperd Dec 05 '16 at 21:06

0 Answers0