Comment 31 for bug 453807

Revision history for this message
falstaff (falstaff) wrote :

I experience this problem too, and its getting really anying. Therefor I started to debug this problem by myself. If have no idea of NetworkManager by grepping through the source I found out that the message is generated from nm-openvpn-service.c.

I compiled the network-manager-openvpn service by cloning it from the git repository and install some additional packages (namely libdbus-glib-1-dev libnm-glib-dev intltool libtool autoconf libgtk2.0-dev libglade2-dev libgconf2-dev libgnome-keyring-dev). Then I executed this...
./autogen.sh --prefix=/usr/bin/ --libexecdir=/usr/lib/network-manager-openvpn/
make

This then compiled the service and i could stat it by invoking

sudo ./src/nm-openvpn-service

The applet then uses this newly compiled service. I added some debug messages and found this out:
The function real_connect calls nm_connection_get_setting, which contains the settings for the choosen vpn. Later then, the settings are verified, and it fails when he tries to verify the secret. Even if there is no secret set at the applet, the applet sets a secret property with the name no-secret to true.

I added right after the nm_connection_get_setting call this code:
tmp = nm_setting_vpn_get_secret (s_vpn, NM_OPENVPN_KEY_NOSECRET);
nm_info("No Secert Property: %s", tmp);

Each time when it worked, this code returns that:
** Message: <info> No Secert Property: true

But most of the time, everytime it fails, this code returns that:
** Message: <info> No Secert Property: (null)

The property is sometimes set, and sometimes not! I do have no idea why this can happen, but I suggest there is a race condition somewhere. I would have to debug the nm_connection_get_setting, which belongs to libnm-util1. Would nice if a developer with more know how in this area could have a look why this property is not set sometimes. Or give me hints what I could test/where to search exactly...