2009/5/21 Robert L Mathews <lists@xxxxxxxxxxxxx>: > > Perhaps I'm misunderstanding, but I don't think this will fix it. > > Although the original example I gave involved TCP retransmits that > "reanimated" the connection, the problem is unfortunately not limited to > that case, and there don't need to be any TCP retransmits involved. (The > subject of this thread is now a little misleading and overly-specific, > unfortunately.) > > Here's the opening of a telnet connection that I injected a bogus RST packet > into (the packet has sequence 522209353 instead of the correct 522209354): > > client.52665 > server.23: S 522209223:522209223(0) win 5840 <mss > 1460,sackOK,nop,wscale 7> > server.23 > client.52665: S 3233007698:3233007698(0) ack 522209224 win 5792 > <mss 1460,sackOK,nop,wscale 6> > client.52665 > server.23: . ack 3233007699 win 46 <nop,nop> > server.23 > client.52665: P 3233007699:3233007711(12) ack 522209224 win 91 > <nop,nop> > client.52665 > server.23: . ack 3233007711 win 46 <nop,nop> > client.52665 > server.23: P 522209224:522209236(12) ack 3233007711 win 46 > <nop,nop> > server.23 > client.52665: . ack 522209236 win 91 <nop,nop> > server.23 > client.52665: P 3233007711:3233007735(24) ack 522209236 win 91 > <nop,nop> > client.52665 > server.23: . ack 3233007735 win 46 <nop,nop> > client.52665 > server.23: P 522209236:522209327(91) ack 3233007735 win 46 > <nop,nop> > server.23 > client.52665: P 3233007735:3233007750(15) ack 522209327 win 91 > <nop,nop> > client.52665 > server.23: P 522209327:522209351(24) ack 3233007750 win 46 > <nop,nop> > server.23 > client.52665: P 3233007750:3233007753(3) ack 522209351 win 91 > <nop,nop> > client.52665 > server.23: P 522209351:522209354(3) ack 3233007753 win 46 > <nop,nop> > server.23 > client.52665: P 3233007753:3233007947(194) ack 522209354 win 91 > <nop,nop> > client.52665 > server.23: R 522209353:522209353(0) win 65535 > client.52665 > server.23: . ack 3233007947 win 54 <nop,nop> > > At this point, the telnet connection with the server is fully established > and waiting for me to type something (because the server ignored the bogus > RST). But conntrack incorrectly considers it CLOSEd (because conntrack > didn't ignore the RST). No retransmits were involved, though. > > Even if nf_conntrack_tcp_loose is true, and conntrack treats subsequent > packets as a new connection when I type something in telnet, I can make it > forget about the connection again by sending another bogus RST. If I send a > bogus RST after every legitimate packet, conntrack will almost always think > the open connection is actually closed. > > Since no retransmits are necessary, I don't think a solution that looks for > retransmits will help, unfortunately. > > -- > Robert L Mathews, Tiger Technologies http://www.tigertech.net/ > -- > To unsubscribe from this list: send the line "unsubscribe netfilter" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html > The problem consists in that RST-packet with wrong sequence number must be treated as INVALID. IMHO, the conntrack code should be changed in this way. I wrote a fix( sorry, I don't experienced in kernel tcp stack - correct me if I somewhere wrong). *** nf_conntrack_proto_tcp.c 2009-05-22 07:22:43.000000000 +0300 --- /usr/src/linux/1/nf_conntrack_proto_tcp.c 2008-09-08 13:20:51.000000000 +0300 *************** static int tcp_packet(struct nf_conn *ct *** 969,979 **** problem case, so we can delete the conntrack immediately. --RR */ if (th->rst) { ! if (ntohl(th->seq) < ct->proto.tcp.last_seq) { ! ct->proto.tcp.state = old_state; ! return -NF_DROP; ! } ! else if (del_timer(&ct->timeout)) ct->timeout.function((unsigned long)ct); return NF_ACCEPT; } --- 969,975 ---- problem case, so we can delete the conntrack immediately. --RR */ if (th->rst) { ! if (del_timer(&ct->timeout)) ct->timeout.function((unsigned long)ct); return NF_ACCEPT; } -- Best regards Anatoly Muliarski -- To unsubscribe from this list: send the line "unsubscribe netfilter" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
