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?

-- 
Crash while trying to connect to PPTP server
https://launchpad.net/bugs/67881

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Reply via email to