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. Regards ------------------------------------------------------------------------------ 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
