Hi, On Thu, Dec 1, 2016 at 3:07 AM, Gert Doering <g...@greenie.muc.de> wrote:
> On Wed, Nov 30, 2016 at 11:06:02PM +0100, Arne Schwabe wrote: > > Slight correction. We actually set 0.0.0.0/0 on Android but Android > > *always* translates that into a 0.0.0.0/1 and a 128.0.0.0/1 rule. > > > > We could do the same and do the translation in the interactive service > > instead of OpenVPN itself. > > We could, but that wouldn't solve the issue of OpenVPN trying to > remove the existing default route (which we would have to special-case-and- > ignore) and reinstall it later on (which must not be translated to > 2x /1, but ignored as well). > > The service code doesn't know whether a route is "for the VPN API" or > "for anything else" (which openvpn on "non VPN API" platforms always > could do) so this would be a much more intrusive change... I think it could work like this: In DeleteRoute() if dest == 0/0 delete routes to 0/1 and 128/1 (ignore any "route does not exist" error) In AddRoute() <-- this function doesn't currently exist if dest == 0/0 add routes to 0/1 and 128/1 (this will add two extra routes when default gateway is restored, but cant hurt) In this scenario, route to 0/0 is never touched by the service. When we ask the service to: delete default route to gw --> nothing happens unless there were routes to 0/1 and 128/1 add default route through tun --> adds routes to 0/1 and 128/1 via tun delete default route through tun --> OK add default route to gw --> adds routes to 0/1 and 128/1 via gw When process exits/crashes, the service thread exits and the extra routes to 0/1 and 128/1 get removed. If service crashes those routes will remain, not ideal, but safe, I suppose. Did I overlook something? Not that I like it. Wonder how android does it. Selva
------------------------------------------------------------------------------
_______________________________________________ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
