Re: vpnc and determining correct routes

[Dan Williams <dcbw redhat com>]

On Mon, 2006-10-23 at 18:16 +0200, Thomas Liebetraut wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Dan Williams schrieb:
> > If you look at nm-vpnc-service-helper.c, around line 254, you'll see
> > that the config bits are just pulled in from environment variables set
> > by vpnc. 
> I actually missed this. I did not see that there is already a program
> that is invoked by vpnc upon startup. Thanks for pointing this out.
> 
> > I've added a dict-based VPN config interface to 0.7/HEAD, which is what
> > should be used here.  The vpnc plugin hasn't been converted over yet,
> > but it will need to be for this to work.  We then simply add a new dict
> > entry with a standard name, say "vpn_routes", which is a dbus array of
> > ipv4 addresses formatted as dbus_uint32_t.
> ACK. I use HEAD, anyway, I'll have a look at your dict interface.

The core NM dict bits are in src/vpn-manager/nm-vpn-service.c,
nm_vpn_service_stage4_ip4_config_get().

The core vpn plug dict bits are implemented in the
pptp/src/nm-ppp-starter.c, nm_ppp_dbus_process_helper_ip4_config().

> >> > details in vpnc's code and we already have an interface for those
> >> > variables, but I don't really want to add a dbus interface to vpnc which
> >> > has not seen a new update for more than  12 months.
> >> > 
> > 
> > That's fine, 0.7/HEAD is open for changing.  More than just the VPN DBus
> > API is going to change in 0.7.
> I was talking about vpnc itself, not NM's vpnc plugin. But my statement
> was obsoletet by your pointer to the right direction ;-)
> 
> > Note that since NM uses dbus to communicate with the local caching
> > nameserver, it's easy to plug in another nameserver (ie, not bind), that
> > uses the same DBus interface.  Some people have a kneejerk reaction to
> > running bind.
> I have a kneejerk reaction to running any DNS daemon on my local machine
> which I consider a client, not a server ;-)
> I can understand people not wanting to run a caching DNS on their box if
> they don't really need one.

Well, if you don't run a local caching nameserver, then you will never
get split DNS.  That's just the way it is, because the glibc folks don't
want to complicated the core resolver with the split DNS stuff.

> > Do we care about the 'never route this' case?  That would be where, for
> > example, you don't override what the VPN returned, but just say that
> > 192.168.1/24 is never routed over the VPN.  If we could at least plan
> > for that, it would be great, but we don't need to put it in the UI for
> > now.
> ACK. I don't see many situations where such an option would be really
> necessary, except for situations where I would blame the VPN admin's
> configuration and not NM. I'll see how I can prepare the interface for
> such an option and if people start complaining, we can still add this
> feature.

Yup, no problem.  Again, let me know if there are more questions.

Dan

> Thanks for your explanations which saved me some hours of grepping NM's
> code!
> 
> Regards,
> Thomas
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.3 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
> 
> iD8DBQFFPOroxVmZpTAq4IgRArDqAKCP2U69VdqkxjvnLAsH7Gw+I3yjkgCfXJLj
> O7C8+Tc7IWahA47/v2y2Svo=
> =82NH
> -----END PGP SIGNATURE-----