On 05/04/17 23:01, debbie10t wrote: > > > On 05/04/17 22:57, debbie10t wrote: >> Hi, >> >> On 05/04/17 22:39, David Sommerseth wrote: >>> On 05/04/17 23:13, debbie10t wrote: >>>> I don't believe there is any need to specify "max" because that >>>> would be >>>> --reneg-sec as is. Otherwise specify a smaller or larger --reneg-sec >>> >>> I think you, probably without being aware of it, are agreeing to what >>> the current proposal is: >>> >>> --reneg-sec max >>> A renegotiation happens within 'max' seconds, but with a 10%-ish >>> randomness >>> >>> --reneg-sec min max >>> A renegotiation happens within 'min' and 'max' seconds, fully >>> controllable >>> >>> So using --reneg-sec 3600 3600, effectively removes the randomness. >> >> I understand the proposed methods .. >> >> Of the two above, I would be inclined toward option 2. >> eg: (for me) --reneg-sec 0 3600 is ideal. >> >> Thanks :) > > With the proviso of "First-run only" ..
sorry to not shut up ! :) (due to logic errors) --reneg-sec reneg-sec "first-run random offset" eg: --reneg-sec 3600 0 is equal to --reneg-sec 3600 --reneg-sec 3600 3600 is equal to --reneg-sec 3600 * * with a first time run of any random number between 0 and 3600. (regardless of sign) (the opposite of the actual proposal) --reneg-sec 3600 360 would be equal to the 10% jitter proposal. Sound ok ? 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
