On Wed, Oct 08, 2003 at 12:18:17AM +0200, Willy Tarreau wrote:
> Fortunately, tcpdump showed to me that all stuck sessions had in common the
> fact that the server aborted them with an RST after the first FIN+ACK, so
> in CLOSE_WAIT. Others which were aborted with an RST just before or just after
> were destroyed without any problem.
Ok, this sounds like a pretty clear case than. This bug has not been
found because replying with RST afer FIN+ACK seems a quite unusual
pattern.
> /*rst*/ {sCL, sCL, sCL, sCL, sCL, sCL, sCL, sCL, sLA, sLI },
>
> But the tcp_window_tracking patch changes this behaviour, I think because of
> a typo, since I see no other reason not to terminate a session upon RST :
>
> /* sNO, sSS, sSR, sES, sFW, sCW, sLA, sTW, sCL, sLI */
> /*rst*/ { sIV, sCL, sCL, sCL, sCL, sIV, sCL, sCL, sCL, sIV },
yes, I totally agree with you. I'll apply your proposed patch to
patch-o-matic. If Jozsef disagrees, he can revert that change.
> BTW, is it normal that an RST received in TIME_WAIT state terminates the
> session ? I would have thought that we should keep it in TIME_WAIT anyway.
again agreed. Jozsef, what do you think?
> BTW, I noticed that the tcp_conntracks[] array takes some memory because every
> entry takes one full int. This is 480 bytes on x86. Wouldn't it be more cache-
> friendly to use compact structures with bit fields instead ?
yes, it was more cache line friendly. But then, wouldn't we get lots of
unaligned accesses? oh you made a u32 aligned version...
> For example, either something like this (byte-aligned) :
> u8 tcp_conntracks[6][10] = { (REPLY_STATE)<<4 | (ORIGINAL_STATE), ... }
> -> read it from (tcp_conntrack[flag][old_state] >> dir?4:0) & 0xF
>
> or (u32 aligned) 80 bytes :
> int tcp_conntracks[2][10] = { /* original */
> { /* old sNO */
> sSS << SYN | sTW << FIN | sES << ACK ...
> -> read id from (tcp_conntrack[dir][old_state] >> flag*4) & 0xF.
this makes the code really hard to read. If you can come up with some
easy-to-read macros, I'd be willing to give it a try.
> Same could be done on unclean(). If someone's interested, I can try to look
> at what seems possible, and propose something.
yes, I'm interested - providing the code is not crippled by bit-shifts
and multiplications everywhere.
> Regards,
> Willy
--
- Harald Welte <laforge@xxxxxxxxxxxxx> http://www.netfilter.org/
============================================================================
"Fragmentation is like classful addressing -- an interesting early
architectural error that shows how much experimentation was going
on while IP was being designed." -- Paul Vixie
Attachment:
pgp00611.pgp
Description: PGP signature
