Re: PPTP Support

[Dan Williams <dcbw redhat com>]

On Tue, 2005-11-22 at 16:29 +0000, Antony J Mee wrote:
> That discusses the two issues mentioned already.  And a third, more 
> annoying one that I only discovered on connecting to a different network 
> today.  This is related to the lack of a way to get the VPN server's IP 
> which is needed for adjusting the routing tables.  I think I have a work 
> around for that now though by getting NetworkManager to resolve the IP 
> of the VPN server before spawning pptp.

What's the issue here?  Is the VPN server specified as a hostname or
something?  I don't think we support VPN servers as hostnames in NM at
this time, but if you've got a patch I'm sure we'll take it :)  Seems
like something quite useful.

> >In the case of the secrets file, I suppose you could write that data out
> >yourself, no?
> >  
> >
> That I have considered, but was unsure how to proceed.  If I were to do 
> so how would people like to see it done?
>    a) NM maintains lines in chap-secrets
>    b) before connecting backup chap-secrets, and replace it with an NM 
> generated file
>         and replace the original when the connection has been established
>    c) other

The best way to do this (without a lot of invasive crap) is to have
command line options to specify what script to run in place of ifup.
Ideally, pppd would take a '--everything-working-script' (it already has
a 'connect-script' parameter that _wont_ do what you want) that by
default would be /sbin/ifup, but that pptp could specify itself.  Then,
pptp takes a command line parameter that's the script to pass to pppd.
This script would be the 'nm-pptp-service-helper' binary from the NM vpn
package.  It should ideally parse everything and anything required to
pass info to NM, including DNS servers and such.  The idea here is that
we want as _few_ scripts and tools as possible so that the call chain
from tool to tool is as simple and efficient as possible.

It's hard to see why the pppd and pptp guys wouldn't add an option for
this, it seems entirely reasonable to me.  It's not like we're asking
them to add full DBus support to their tools and it certainly doesn't
change default behavior of either one.

Dan