The stack should stop transmitting after receiving a RST
Closed this issue · 1 comments
This is a typical trace in synjitsu:
3134 1814.067582 192.168.2.1 -> 192.168.2.140 TCP 78 63986→80 [SYN] Seq=0 Win=65535 Len=0 MSS=1460 WS=32 TSval=2076397423 TSecr=0 SACK_PERM=1
3135 1815.074428 192.168.2.1 -> 192.168.2.140 TCP 78 [TCP Retransmission] 63986→80 [SYN] Seq=0 Win=65535 Len=0 MSS=1460 WS=32 TSval=2076398423 TSecr=0 SACK_PERM=1
3136 1815.076512 192.168.2.140 -> 192.168.2.1 TCP 62 80→63986 [SYN, ACK] Seq=0 Ack=1 Win=65535 Len=0 MSS=1460 WS=4
3137 1815.076575 192.168.2.1 -> 192.168.2.140 TCP 54 63986→80 [ACK] Seq=1 Ack=1 Win=262144 Len=0
3138 1815.076676 192.168.2.1 -> 192.168.2.140 HTTP 72 GET / HTTP/1.0
3139 1815.080134 192.168.2.140 -> 192.168.2.1 TCP 71 [TCP segment of a reassembled PDU]
3140 1815.080180 192.168.2.1 -> 192.168.2.140 TCP 54 63986→80 [ACK] Seq=19 Ack=18 Win=262112 Len=0
3141 1815.080304 192.168.2.1 -> 192.168.2.140 TCP 54 63986→80 [FIN, ACK] Seq=19 Ack=18 Win=262112 Len=0
3142 1815.081467 192.168.2.140 -> 192.168.2.1 HTTP 135 HTTP/1.1 200 OK
3143 1815.081503 192.168.2.1 -> 192.168.2.140 TCP 54 63986→80 [RST] Seq=19 Win=0 Len=0
3144 1815.081512 192.168.2.140 -> 192.168.2.1 TCP 60 [TCP Dup ACK 3142#1] 80→63986 [ACK] Seq=99 Ack=19 Win=262140 Len=0
3145 1815.081523 192.168.2.1 -> 192.168.2.140 TCP 54 63986→80 [RST] Seq=19 Win=0 Len=0
3146 1815.084058 192.168.2.140 -> 192.168.2.1 TCP 60 80→63986 [ACK] Seq=99 Ack=20 Win=262140 Len=0
3147 1815.084095 192.168.2.1 -> 192.168.2.140 TCP 54 63986→80 [RST] Seq=20 Win=0 Len=0
3148 1815.084718 192.168.2.140 -> 192.168.2.1 TCP 60 [TCP Dup ACK 3146#1] 80→63986 [ACK] Seq=99 Ack=20 Win=262140 Len=0
3149 1815.084744 192.168.2.1 -> 192.168.2.140 TCP 54 63986→80 [RST] Seq=20 Win=0 Len=0
3150 1815.085641 192.168.2.140 -> 192.168.2.1 TCP 60 [TCP Dup ACK 3146#2] 80→63986 [ACK] Seq=99 Ack=20 Win=262140 Len=0
3151 1815.085671 192.168.2.1 -> 192.168.2.140 TCP 54 63986→80 [RST] Seq=20 Win=0 Len=0
3152 1815.086259 192.168.2.140 -> 192.168.2.1 TCP 60 [TCP Dup ACK 3146#3] 80→63986 [ACK] Seq=99 Ack=20 Win=262140 Len=0
3153 1815.086286 192.168.2.1 -> 192.168.2.140 TCP 54 63986→80 [RST] Seq=20 Win=0 Len=0
3154 1817.197359 192.168.2.140 -> 192.168.2.1 TCP 60 [TCP Retransmission] 80→63986 [SYN, ACK] Seq=4294939419 Ack=1 Win=65535 Len=0
3155 1817.197397 192.168.2.1 -> 192.168.2.140 TCP 54 63986→80 [RST] Seq=1 Win=0 Len=0
3156 1817.198888 192.168.2.140 -> 192.168.2.1 TCP 60 80→63986 [ACK] Seq=99 Ack=20 Win=262140 Len=0
3157 1817.198914 192.168.2.1 -> 192.168.2.140 TCP 54 63986→80 [RST] Seq=20 Win=0 Len=0
3158 1819.076863 192.168.2.140 -> 192.168.2.1 TCP 135 [TCP Retransmission] 80→63986 [PSH, ACK] Seq=18 Ack=20 Win=262140 Len=81[Reassembly error, protocol TCP: New fragment overlaps old data (retransmission?)]
3159 1819.076906 192.168.2.1 -> 192.168.2.140 TCP 54 63986→80 [RST] Seq=20 Win=0 Len=0
@balrajsingh analysis:
I think 192.168.2.1 behaviour is common to some HTTP browsers - it is not ideal but it is ok. It sends an HTTP GET and then a FIN because it was not going to send anything else. We reply with with an HTTP packet and then we should send a FIN to close the connection but may not. Because the "browser" side wants to be in charge, as soon as it gets all the data it expects it just destroys the connection with a RST. Once we get an RST we should just completely destroy the connection and not retransmit any more packets. Unfortunately it looks like if we get an RST after a FIN we may be ignoring it. So we have a bug, but not a very serious bug (high priority, but not critical).