Date: Sat, 15 Nov 2008 21:51:33 +0000 From: Rui Paulo <rpaulo@freebsd.org> To: Hartmut Brandt <hartmut.brandt@dlr.de> Cc: freebsd-net@freebsd.org Subject: Re: TCP and syncache question Message-ID: <0A4BB2F1-AC9F-4316-94E3-790E2D80F651@freebsd.org> In-Reply-To: <491F2C47.4050500@dlr.de> References: <491F2C47.4050500@dlr.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On 15 Nov 2008, at 20:08, Hartmut Brandt wrote: > Hi, > > in tcp_syncache.c:syncache_expand() there is a test that the > acknowledgement number and the sequence number of an incoming ACK > segment are in the expected range. If they are not, > syncache_expand() returns 0 and tcp_input drops the segment and sets > a reset. So far so good. But syncache_expand() also deletes the > syncache entry, and so destroys the connection. I cannot see why it > does it. It seems to me that such a wrong segment should be > interpreted as to be from another connection and as such the segment > should be ignored (but a reset sent). When the correct ACK comes, > the connection could still be established. As it is now, the > establishment of incoming connections can seriously be disturbed by > someone sending fake ACK packets. > > The same test (for the ack number, not for the sequence number) is > also further down in tcp_input.c:tcp_do_segment() (just after the > header prediction stuff) and here the handling is correct: the goto > dropwithreset just sends a reset and drops the segment but leaves > the connection in the SYN-RECEIVED state. This test is probably > never reached now, because of syncache_expand(), though. > > Maybe I fail to see something obvious, though... Well, if the RST is sent, why should we keep the syncache entry? Regards, -- Rui Paulo
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?0A4BB2F1-AC9F-4316-94E3-790E2D80F651>