Comment 22 for bug 67881

Ok ok... I have been listening in but I'm afraid I've been off planet a bit.
New job, new city.

Anyhow. The whole thread strikes me as a little strange. As a couple of you noticed, I found this crash occured on AMD64s and though not owning one myself, a few others helped to iron out that bug. So, a few things I can clarify for you.

1) The renaming from PPTP -> PPP happened long ago and is because the underlying tool is actually a very general general engine for managing a PPP connection. It is only the configuration dialogs which limit the functionality to PPTP.

2) Most of the structure of the plugin comes from those that existed previously (vpnc and openvpn) though a few of the PPTP innovations have gone back the otherway. For example, the not returning behaviour nm-XXXX-auth-dialog is the same in all plugins. It is actually waiting for a carriage return as some kind of STDIN/STDOUT handshake to finish the interaction. Try hitting return instead of Ctrl-C. If it exits normally then you ha
ve the correct behaviour.

3) There is a version issue as to which version of the plugin works with which version of NetworkManager (NM). The difference is related to how the plugin passed the IP configuration of the established connection back to NM. The symptom if that problem is that the connection will establish (eg. monitoring ifconfig/logs) but then NM will timeout because it didn't get a response from the plugin. The truth table looks like this:
       NM / Plugin
         old / old works
         old / new fails
         new / old works (but can't set some things like MTU)
         new / new works
The plugin can switch behaviour in the source -- grep for NM_VPN_USE_OLD_DBUS_INTERFACE is src/nm-ppp-starter.c -- that define should be settable if needed through the --enable-nm-vpn-dbus-old option to configure.

If you have access to the Ubuntu source package for NM then you can check if you have an old/new NM by doing a grep for "dict" on NetworkManager/src/vpn-manager/nm-vpn-service.c If you get a load of matches... It's a new NM.

My memory is that the AMD64 crash was ONLY related to the auth-dialog/nm-ppp-auth-dialog code and thus the test edschofield describes above is the correct one... Just hit return though. Not Ctrl-C.

What is worrying is that a further patch, added a few months ago, improved the way that nm-ppp-starter handled it's children. A crashing child __should not__ crash nm-ppp-starter anymore, but perhaps that's not the case still on AMD?