2012/2/23 Simon Deziel <[email protected]>: > On 12-02-23 10:53 AM, Teodor MICU wrote: >> This is not about "advantages" but for keeping the previous >> configuration (default or explicitly set by the user). I saw you have >> the logic for one but not for both. > > I'm not sure what you imply by "both" here so I maybe missing your > point. In the patch, 2 sysctl keys are altered: the default and the all > ones.
both: net.ipv4.conf.all.send_redirects, net.ipv4.conf.default.send_redirects > The default is only altered to allow the tun to derive its own > send_redirects based on the default one (that is to have it =0). Once > the tun is up, the default is restored to its original value so in > effect the user's setting is retained. > > Now for the all key, this has to be =0 as otherwise the tun one wouldn't > have any effect. I think I understand what you're trying to do now. You want net.ipv4.conf.all.send_redirects to remain disabled and to be actively disabled by every execution of oVPN init script. >> That's why I though if you already have to get the current value why >> not check if =0 to avoid two sysctl call for each parameter. Thus, >> this would be more optimal. > > OK, that would avoid uselessly calling sysctl -w to set/restore the > default key to its current value when it is already disabled. > > You convinced me, your suggestion is cleaner. Here is the fixed patch > (which is now based on the Debian package as my previous ones were based > on the one from Lucid). > > This was tested on OpenVPN 2.2.1-4 (Sid) and 2.1.0-1ubuntu1.1 (Lucid). The implementation appears correct with the desired action. However, this would require at least a note on README.Debian and preferably a NEWS entry to warn users that openvpn actively disables all.send_redirects on configurations with tun + topology subnet. I think that all.send_redirects should be disabled by default. But this is not the case nor in Debian nor in Ubuntu. Cheers -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
