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 _______________________________________________ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list