Hi, On Fri, Jan 06, 2023 at 03:38:41PM +0100, Arne Schwabe wrote: > Patch v2: use strtol instead of atoi to be able to differentiate between > an error parsing and parsing 0. Use int64_t instead int to > avoid overflow errors.
I find this easier to read, so thanks. This said... > + /* Check if we are still below our limit for sending out > + * responses */ > + if (!reflect_filter_rate_limit_check(m->initial_rate_limiter)) > + { > + return false; > + } This does "we kill the packet if reflect_filter returns false(!)". [..] > +bool > +reflect_filter_rate_limit_check(struct initial_packet_rate_limit *irl) > +{ [..] > + return irl->curr_period_counter > irl->max_per_period; > +} This does "return false *while under the limit*". So it kills all UDP for me. 2023-01-09 09:03:01 us=694540 rrl: curr_period_counter=1, max_pp=100 2023-01-09 09:03:01 us=694598 connection killed by reflect_filter 2023-01-09 09:03:17 us=494917 rrl: curr_period_counter=1, max_pp=100 2023-01-09 09:03:17 us=495003 connection killed by reflect_filter 2023-01-09 09:03:22 us=773712 rrl: curr_period_counter=2, max_pp=100 2023-01-09 09:03:22 us=773773 connection killed by reflect_filter 2023-01-09 09:03:25 us=243757 rrl: curr_period_counter=3, max_pp=100 2023-01-09 09:03:25 us=243827 connection killed by reflect_filter Turning around the condition in reflect_filter.c + return irl->curr_period_counter < irl->max_per_period; makes things well-behaved - as in, normal connections succeed, excess RESET_V3 fail - tested with your sendOvpn.py $ python3.9 sendOvpn.py 1000 generating packets creating sockets Round 0 sending packets sleeping 99 packets received 2023-01-09 09:22:47 us=429929 Connection Attempt Dropped 900 initial handshake packets due to --connect-freq-initial 100 10 While at it, I wonder if it would be a useful addition to do a single message if the rate limiter kicks in, like this if ( irl->curr_period_counter == irl->max_per_period ) { msg( M_WARN, "connect-freq-initial rate limiter activated, dropping incoming UDP for the next %d seconds", (irl->last_period_reset + irl->period_length)-now ); } we do have a log entry after the end of the period, but that might be an arbitrary time ("when the next packet comes in") further down the log, with no indication why OpenVPN decided to play dead at this point. gert -- "If was one thing all people took for granted, was conviction that if you feed honest figures into a computer, honest figures come out. Never doubted it myself till I met a computer with a sense of humor." Robert A. Heinlein, The Moon is a Harsh Mistress Gert Doering - Munich, Germany g...@greenie.muc.de
signature.asc
Description: PGP signature
_______________________________________________ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel