On Mon, Sep 21, 2015 at 04:26:51PM +0200, Remi Gacogne wrote: > On 09/21/2015 02:57 PM, Willy Tarreau wrote: > > > > On Mon, Sep 21, 2015 at 10:28:09AM +0000, mlist wrote: > >> We installed "HA-Proxy version 1.6-dev5-caa6a1b 2015/09/17", as you can > >> see conn_cur in stick table seems wrong. Also with a single http access > >> test, we get inizial correct conn_cur=1 but after expired haproxy insert a > >> new record with same expire time with conn_cur like that below. So no more > >> src_conn_cur filtering for DDOS prevention can be done. > >> > >> # table: main_fe, type: ip, size:102400, used:1 > >> 0x1d47cfc: key=192.168.1.21 use=0 exp=26956 conn_cnt=21 conn_rate(6000)=2 > >> conn_cur=4294967275 sess_cnt=21 http_req_cnt=21 > > > > Could you please share your configuration, I'm unable to reproduce the same > > problem and I'd like to understand why. There's clearly a bug here :-/ > > I'm sure you already noticed that, but the value of conn_cur seems to be > 2^32 - conn_cnt. As I don't believe much in that kind of coincidence, I > would bet my money on conn_cur being decremented twice.
Hmmm bad news :-( It's due to something I had to interrupt when working on splitting sessions and streams and that I forgot to finish :-( So here what happens is that the counters in the stream are the copy of those in the session but we don't know which ones were allocated from the session and which ones from the stream, so all stream counters are released then all session counters are released. This happens when the tracking is performed at the connection level. I'll check, I suspect that we *just* need to compare the pointers when doing the store_counters operation in the stream, but I need to validate. Thanks for reporting this issue, it's a really nasty one that we're lucky to find before people start to use it in production. I may delay dev6 a little bit depending on the difficulties I'm facing. Willy
