> > > On 05/04/17 17:13, debbie10t wrote: >> >> >> On 05/04/17 16:58, David Sommerseth wrote: >>> On 05/04/17 17:53, David Sommerseth wrote: >>>> On 05/04/17 16:42, debbie10t wrote: >>>>> >> >>>>> >>>>> A different approach could be like so: >>>>> >>>>> --reneg-sec 3600 >>>>> --reneg-sec-1sttime-rand 1|0 (The name here for detail) >>>> >> >>> >>> Oh, and in regards to the first-time/non-first-time .... if we decide >>> for such flexibility, that can be a flag after the randomness. >>> >>> For example --reneg-sec 3600 12 first-only >>> >>> I am far from convinced if that should be configurable or not. But >>> still, this approach is still far better than introducing new options. >>> >> >> Ok - accept that new options is not preferred but .. >> >> I like the idea of "first-only" addition (which is more or less as I >> proposed anyway) - And so, instead of having randomness in the reneg-sec >> itself, it is only randomness in the first run, after that the expected >> behaviour would be restored. eg: --reneg-sec 3600 >> >> To my mind (as a non programmer) this essentially boils down to >> setting the first --reneg-sec timer to something between 1 and >> 3600 (default). This affords a much larger window for the scattering >> of clients and further behaviour is "as expected now". >> >> and it looks very non-instrusive to me .. >> > > To clarify: --reneg-sec 3600 RAND > > Where RAND indicates that the first-run timer should run from a random > integer from 1 upto the value of --reneg-sec. RAND does not require a > user to specify an amount.
But then, why not just do it always and forget about the additional option? Simon ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
