Crash while trying to connect to PPTP server

[exactt]

Binary package hint: network-manager-pptp

when I choose the newly added connection to start connecting to the PPTP server Bug Buddy comes up with the attached error message.

Running edgy RC on AMD64 here with latest updates installed. no useful info in /var/log/syslog or dmesg . anywhere else i should have a look.

[Craig Box (craig.box)]

Please read http://www.students.ncl.ac.uk/a.j.mee/blog/index.php/2006/11/24/networkmanager-pptp-with-ubuntu-610-edgy-eft-on-amd64-crash-workaround/ and see if this describes your error, and if the workaround is relevant.

[onlymee (a-j-mee)]

Thanks to Craig for pointing this out to me. Yes, this is precisely the problem I encountered with my colleagues AMD64 Ubuntu Edgy box.

I got as far as determining that it is the gnomeui code behind the gtk_widget_destroy call that causes the crash. That means that if the fault is in the plugin it could be any one of a number of memory allocation related calls. I will have a scan over the most likely bits of the code again to see if I spot anything obvious, but I don't have an AMD64 Edgy box to try this with.

Things to do/Questions to answer:
  1) Is this only an AMD64 issue? (I can't reproduce it on my Intel Core Duo)
  2) Is this only an Ubuntu issue? And is it only Edgy?
  3) Does the version in CVS HEAD work?

The issue can be tested for quite simply without the need to install the plugin or even NetworkManager in full (though most of the dev libs will still be needed to get the plugin to configure). In my tests simply running the auth-dialog tool on it's own was sufficient to see the error.

(This is from memory so please excuse any minor mistakes)
As a normal (non-root) user simply run:
    nm-ppp-auth-dialog
which on an Ubuntu box is in
    /usr/lib/networkmanager
but may be in
   /usr/libexec
on other distros.

The tools requires two options, a NetworkManager DBUS service name and a VPN connection name. Both can be fake as they are only used to to label any information stored in the keyring. So running for example:

   /usr/lib/networkmanager/nm-ppp-auth-dialog -s org.freedesktop.NetworkManager.ppp_starter -n "Test Connection"

should display a dialog prompting for the username+password to access "Test Connection".

Enter a username and password and hit OK. Don't tick the session or keyring boxes for a fake connection or else you'll have to go and delete the entries using Keyring manager later! After hitting OK, the dialog should sit there doing nothing. It will be waiting for a carriage return in the terminal (some handshaking method not implemented by me!)where you should also find it has printed out "CHAP" followed by the username and password you entered. Return keyboard focus to the terminal, hit enter and the program should terminate normally.

If the fault occurs it should happen immediately on hitting OK I think.

Maybe I have just found the issue. It seems that despite a call to gtk_widget_hide in the gnome_two_password_dialog code, the dialog stays visible after hitting OK on my Intel box. I wonder if it is trying to destroy a widget that is currently visible and whether or not that is allowed.

If building the plugin from source, once built this test may also be performed with the binary in the auth-dialog directory without performin "make install".

Any assistance would be appreciated.

[exactt (giesbert)]

can confirm your test (see below). now trying to compile the latest
version of the applet...

onlymee wrote:
> Thanks to Craig for pointing this out to me. Yes, this is precisely the
> problem I encountered with my colleagues AMD64 Ubuntu Edgy box.
>
> I got as far as determining that it is the gnomeui code behind the
> gtk_widget_destroy call that causes the crash. That means that if the
> fault is in the plugin it could be any one of a number of memory
> allocation related calls. I will have a scan over the most likely bits
> of the code again to see if I spot anything obvious, but I don't have an
> AMD64 Edgy box to try this with.
>
> Things to do/Questions to answer:
> 1) Is this only an AMD64 issue? (I can't reproduce it on my Intel Core Duo)
> 2) Is this only an Ubuntu issue? And is it only Edgy?
> 3) Does the version in CVS HEAD work?
>
> The issue can be tested for quite simply without the need to install the
> plugin or even NetworkManager in full (though most of the dev libs will
> still be needed to get the plugin to configure). In my tests simply
> running the auth-dialog tool on it's own was sufficient to see the
> error.
>
> (This is from memory so please excuse any minor mistakes)
> As a normal (non-root) user simply run:
> nm-ppp-auth-dialog
> which on an Ubuntu box is in
> /usr/lib/networkmanager
> but may be in
> /usr/libexec
> on other distros.
>
> The tools requires two options, a NetworkManager DBUS service name and a
> VPN connection name. Both can be fake as they are only used to to label
> any information stored in the keyring. So running for example:
>
> /usr/lib/networkmanager/nm-ppp-auth-dialog -s
> org.freedesktop.NetworkManager.ppp_starter -n "Test Connection"
>
> should display a dialog prompting for the username+password to access
> "Test Connection".
>
> Enter a username and password and hit OK. Don't tick the session or
> keyring boxes for a fake connection or else you'll have to go and delete
> the entries using Keyring manager later! After hitting OK, the dialog
> should sit there doing nothing. It will be waiting for a carriage return
> in the terminal (some handshaking method not implemented by me!)where
> you should also find it has printed out "CHAP" followed by the username
> and password you entered. Return keyboard focus to the terminal, hit
> enter and the program should terminate normally.
>
> If the fault occurs it should happen immediately on hitting OK I think.
it does! on hit hitting "OK" Bug Buddy comes up...

>
> Maybe I have just found the issue. It seems that despite a call to
> gtk_widget_hide in the gnome_two_password_dialog code, the dialog stays
> visible after hitting OK on my Intel box. I wonder if it is trying to
> destroy a widget that is currently visible and whether or not that is
> allowed.
>
> If building the plugin from source, once built this test may also be
> performed with the binary in the auth-dialog directory without performin
> "make install".
>
> Any assistance would be appreciated.
>

--
Max Giesbert - exactt technology

Schießstättstr. 16 T: [phone]
D-80339 München F: [phone]

[exactt (giesbert)]

i guess compiling the plugin is a bit too much for me.
or at least compiling the latest networkmanager from cvs.

but feel free to let me test any new packages available.

thx

[stefab (bluefuture)]

I can also confirm this bug. I have the same connection on i386 and works fine. The crash is only on amd64.

[William Hood (william-a-hood)]

I can also confirm this. System is AMD64, originally installed as Kubuntu but switched to Ubuntu Desktop. Output of bug buddy is as follows:

Memory status: size: 157569024 vsize: 157569024 resident: 13443072 share: 9125888 rss: 13443072 rss_rlim: -1
CPU usage: start_time: 1168484468 rtime: 40 utime: 35 stime: 5 cutime:0 cstime: 0 timeout: 0 it_real_value: 0 frequency: 100

Backtrace was generated from '/usr/libexec/nm-ppp-auth-dialog'

(no debugging symbols found)
Using host libthread_db library "/lib/libthread_db.so.1".
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
[Thread debugging using libthread_db enabled]
[New Thread 47846418088560 (LWP 5739)]
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
0x00002b841aac3eb5 in waitpid () from /lib/libpthread.so.0
#0 0x00002b841aac3eb5 in waitpid () from /lib/libpthread.so.0
#1 0x00002b841786aa07 in gnome_gtk_module_info_get ()
   from /usr/lib64/libgnomeui-2.so.0
#2 <signal handler called>
#3 0x00002b841ac3b86b in free () from /lib/libc.so.6
#4 0x0000000000404c9b in ?? ()
#5 0x00002b841a0dc358 in g_object_unref ()
   from /...

[exactt (giesbert)]

just testing feisty herd 2 on my amd64 box. and the bug is still there. bug report attached.

[exactt (giesbert)]

sorry. just realized it's still the same version. a fix would be nice anyway...

[stefab (bluefuture)]

It's is probably fixed upstream two weeks ago. Anybody can test this patch?

This is for the cvs version:
http://svn.gnome.org/viewcvs/NetworkManager/trunk/vpn-daemons/pptp/auth-dialog/main.c?rev=2212&r1=1920&r2=2212&makepatch=1&diff_format=u

This apply to the last stable version 0.6.4 but i think that is fully compatible with edgy version 0.6.3+cvs20060819 becuase the diff was against 2006/08/04 version of the mail file:

http://people.redhat.com/dcbw/main.c.patch

[stefab (bluefuture)]

Please, if this patch really works consider also a motu SRU to the last 0.6.4 stable version + patch.

[Craig Box (craig.box)]

I can have a go at patching and upload the fixed version for testing this week sometime.

If it's worth stepping up a version, I can look at that too, but the trouble I had was that development was happening on the 0.7 branch, which is incompatible with 0.6.x. I'm not sure if there's anything hugely new in CVS, except possibly lots of bugfixes - as good a reason as any to upgrade :)

[stefab (bluefuture)]

I think that the patch could be applied to edgy and do an upload because actually is not usable on ubuntu 64 bit.

Then if you want to package a cvs version for festy take a look at the svn changelog and talk with upstream developers:

http://svn.gnome.org/viewcvs/NetworkManager/trunk/vpn-daemons/pptp/ChangeLog?view=markup

I think that 0.7 will be ready for spring.

[edschofield (schofield)]

I still get a segfault with this patch. I'm using Feisty AMD-64, network-manager-pptp-0.6.3+cvs20060819. Here's a backtrace from gdb:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 47328421673936 (LWP 30782)]
0x00002b0b7e41022b in free () from /lib/libc.so.6
(gdb) bt
#0 0x00002b0b7e41022b in free () from /lib/libc.so.6
#1 0x0000000000404cfb in gnome_two_password_dialog_finalize (object=0x67c050)
    at gnome-two-password-dialog.c:166
#2 0x00002b0b7da9f6a8 in g_object_unref () from /usr/lib/libgobject-2.0.so.0
#3 0x0000000000402fe1 in main (argc=1, argv=0x7fff31bb42c8) at main.c:202

Valgrind shows much the same thing; its output is attached.

[Gustavo Carneiro (gjc)]

gnome-two-password-dialog.c?! Who provides this source file? I'm sure it's not libgnomeui. Could it be a Gtk# bug?

[edschofield (schofield)]

Gustavo: It's from the source tree of network-manager-pptp-0.6.3+cvs20060819, in the auth-dialog/ directory.

[stefab (bluefuture)]

Edschofiled could you try to test this patch for the gnome-two-password-dialog error?
http://svn.gnome.org/viewcvs/NetworkManager/trunk/vpn-daemons/pptp/auth-dialog/gnome-two-password-dialog.c?rev=2215&r1=1220&r2=2215&makepatch=1&diff_format=u

[stefab (bluefuture)]

So i think that festy run network-manager 0.6.4 no so i doesn't think that the old pptp plugin network-manager-pptp-0.6.3+cvs20060819 is compatible with this version. There is need to try 0.6.4 version of pptp plugin with our without dialog patch.

[edschofield (schofield)]

Feisty has the same pptp version as edgy. If it's not compatible with network-manager 0.6.4, does that explain the segfaults?

I tried compiling the 0.6.4-tagged branch from SVN, but I get a linker error: relocation R-X86_64_32 against `a local symbol' ... recompile with -fPIC. Passing --with-pic to ./configure doesn't help. So I'm stumped.

[edschofield (schofield)]

Some progress: I compiled it with the right CFLAGS. Version 0.6.4 produces a nm-pptp-auth-dialog binary instead of nm-ppp-auth-dialog from the previous version. Was it renamed?

If I run the test given by onlymee earlier in the thread, but with the new filename, I get:

$ /usr/libexec/nm-pptp-auth-dialog -s org.freedesktop.NetworkManager.ppp_starter -n "Test Connection"
This dialog works only with the 'org.freedesktop.NetworkManager.pptp' service.

Using this instead:
$ /usr/libexec/nm-pptp-auth-dialog -s org.freedesktop.NetworkManager.pptp -n "Test Connection"

outputs the username and password in stdout correctly (no segfault). The program doesn't terminate at all, though -- it keeps the dialog open until I give it Ctrl-C; is this intended?

Executive summary: segfault is gone with the two patches to main.c and gnome-two-password-dialog.c applied to NetworkManager-0.6.4/vpn-daemons/pptp/. Removing the second patch brings it back again. This is on AMD64.

[stefab (bluefuture)]

I actually think that we need to have more info from onlymee as upstream author.

[onlymee (a-j-mee)]

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?

[onlymee (a-j-mee)]

Just read back my previous comment -- my apologies for my use of absolutes in the first paragraph. I am open to the possibility that the issue isn't resolved! :-)

Also, I just fixed the --enable-nm-vpn-dbus-old upstream... It seems it wasn't switching properly.

[edschofield (schofield)]

Onlymee: thanks for the info. A clarification: nm-ppp-starter.c doesn't exist in the source tree for version 0.6.4. And by your definition the NM in Feisty is "old": there's no 'dict' in nm-vpn-service.c.

I think we should push Feisty's network-manager-pptp to version 0.6.4 with the above trivial patches, to avoid this crasher on AMD64.

[edschofield (schofield)]

I've changed my mind. I now think we should package an SVN version for Feisty. I've compiled the SVN version and I'm impressed. It works for me.

This is a big deal for me. DSL providers in Austria like inode.at *require* PPTP connections for authentication. Without this one gets no access at all. I've spent two days unsuccessfully trying to get a connection with pptp from the command-line and with the older network-manager-pptp versions 0.6.3+cvs and 0.6.4. The SVN version is substantially improved.

I'm happy to help out with the packaging.

[onlymee (a-j-mee)]

As I understand, Craig Box's original PPTP package was indeed based on a (slightly patched for Ubuntu) CVS snapshot -- so perhaps using a slightly newer snapshot (now SVN of course) would not be terribly difficult.

[stefab (bluefuture)]

As nobody seems working on this issue i switch the status from in progress to confirmed.

[johnnymac (jnorden)]

Is there a planned fix for this to be added as an upgrade feature? I've hit this as well on my AMD64 and it's a bit annoying.

[Mead (ma9mjo)]

The bug is still there on Feisty Beta amd64, the workaround posted at the top of this page works fine though.

[stefab (bluefuture)]

I try to assine to motu-uvf for seek if a new upstream or cvs version has fix this issue

[Craig Box (craig.box)]

I have a feisty machine to have a look with now. No guarantees at all there'll be a UVF-exception-quality package before release time, however. Anyone who is interested in helping with packaging can contact me and I'll tell them everything I know!

[Daniel Holbach (dholbach)]

Unassigning from motu-uvf. Please read the process documentation and attach all necessary data before: https://wiki.ubuntu.com/FreezeExceptionProcess#head-9523bc4076ff011324d67cddc97969ec609618d6

[Matthew Monteleone (mgm-protenus)]

I am experiencing the same problem, and the fix works on compaq nx6325 laptop with feisty.

[kalyp (kalyp)]

Hi everyone,
I am new to Linux and Ubuntu and am experiencing the same problem (Ubuntu 6.10 AMD 64). I read through this page but cannot find the fix you speak about...
Is there a solution to fix this problem? could someone explain what I should do?
Thank you by advance.

[edschofield (schofield)]

kalyp: I suggest you remove the network-manager and
network-manager-pptp packages, install the subversion package, and
compile the latest SVN version from source. You'll find instructions
for this online.

[Craig Box (craig.box)]

If someone can confirm the exact fix (or first revision in SVN where it was fixed) I will try and whip up a newer package this weekend.

[stefab (bluefuture)]

Craig i think that last stable release network-manager 0.6.5 + vpn plugin have this bug fixed.

[stefab (bluefuture)]

Probably VPN plugin are not released with the network-manager ftp tarball so u need to checkout http://svn.gnome.org/viewcvs/NetworkManager/tags/NETWORKMANAGER_0_6_5_RELEASE/

[Craig Box (craig.box)]

I have built a new package for the SVN trunk, which ought to fix this issue. Please feel free to try it: http://craig.dubculture.co.nz/blog/2007/05/13/new-networkmanager-pptp-package-fixes-amd64-crashes/

If it works for everyone, I will get it uploaded to the Ubuntu archive for gutsy, and push for an -updates release.

[kalyp (kalyp)]

ok thanks for the package!
However, if I understood correctly, there's still nothing available for AMD64 - edgy? no way to fix the AMD64 bug for edgy users?
should I try to install subversion as suggested by edschofield or is it exactly the same thing anyway?
thanks...

[Craig Box (craig.box)]

Thanks to ajmitch, there's now an AMD64 Edgy package. Please check the link on http://craig.dubculture.co.nz/blog/2007/05/13/new-networkmanager-pptp-package-fixes-amd64-crashes/ again.

[exactt (giesbert)]

i just tested the AMD 64 package provided and it fixes the problem for me.

thx a lot

[Craig Box (craig.box)]

network-manager-pptp (0.6.4+svn2574-0ubuntu1) gutsy; urgency=low

  * New upstream release (fixes LP: #67881, LP: #80541).
  * Fix properties dialog so an option is always selected. (fixes LP: #89120)
  * Set NoDisplay=true in the .desktop file to hide spurious menu item
    (fixes LP: #109856).
  * Bump Standards-version to 3.7.2 and fix Maintainer: field in
    debian/control.

 -- Craig Box <email address hidden> Sun, 4 Jun 2007 11:18:03 +1200