auth-user-pass with multiple tunnels fails randomly about android-openvpn-settings HOT 9 CLOSED

Hi,

Thanks for using my app and writing a bug report.
It seems you are 'exploring' some untested areas of OpenVPN-Settings ;-)
See below

On Sat, 2010-03-06 at 13:51 -0800, Jesse wrote:
> Hi,
> 
> Thanks for making OpenVPN Settings. It's very useful.
> 
> I'm encountering a bug occasionally with connections requiring 
> auth-user-pass. OpenVPN Settings queries me for the user/pass, but when I 
> enter them, it sometimes just hangs on 'Connecting'.

I don't have a working config for auth-user-pass, so the current
implementation is a best guess. I simply didn't have the time to produce
a working config. Maybe you could provide a config? So I could set it up
my self?

> Other auth-user-pass connections will work, whether started before or 
> after. Usually it seems like just 1 of my 3 connections refuses to work, 
> while the other two work fine, but which connection it is varies from 
> session to session.

To get that right: You are using 3 simultaneous connections, all using
auth-user-path?

> It may be that the one first in the list has the problems. I also noticed 
> that the user/pass dialog often seems confused about which it is prompting 
> me for. For example, if I have conf files a.conf, b.conf, c.onf, and I try 
> to connect to a.conf, a notification will appear saying a.conf needs me to 
> enter my password. WHen I select the notification, the window text says 
> b.conf needs my password. Maybe it's related to the auth issues.

Well I just had a look in the code. The basic problem is probably that
EnterUserPassword is not really implemented/tested to handle multiple
conenctions. Actually for each tunnel requesting a password the
EnterUserPassword activity should be started separately. 

> Here's what logcat says:
> I/ActivityManager( 1760): Displayed activity 
> de.schaeuffelhut.android.openvpn/.EnterUserPassword: 741 ms
> W/OpenVPN-DaemonMonitor[/sdcard/openvpn/a.conf]-mgmt( 2151): Won't 
> send unexpected user/password to openvpn daemon!
> D/OpenVPN-Settings( 2151): onResume()
> D/OpenVPNDaemonEnabler( 2151): Received OpenVPN daemon state changed from 
> Unknown to Enabled
> D/OpenVPNDaemonEnabler( 2151): Received OpenVPN network state changed from 
> Connecting to Connecting

The DaemonMonitor does not expect a username/password. This probably
means, that the password gets routed to the wrong daemon. Probably the
variable mConfigFile in EnterUserPassword contains the wrong value as it
is not setup correctly.

> Does the code at http://code.google.com/p/android-openvpn-settings/ 
> correspond to the released version on the Market? If so I may try to 
> figure it out, though I'm not very familiar with android coding yet so I 
> may not have much luck.

The repo is up to date and I just set a tag marking the current version.
I appreciate any help.

Attached you'll find a version with a best guess fix. Let me know if it
makes things better or worse. It won't handle the case where multiple
tunnels ask for a password the same time. (Fix is in head.)

> Thanks again for making a great tool.

Well I'm happy if you find it useful. Thanks again for taking the time
and writing a bug report.

Friedrich

> implementation is a best guess. I simply didn't have the time to produce
> a working config. Maybe you could provide a config? So I could set it up
> my self?

I've attached sanitized client and server configs using auth. On the 
server side, other than key stuff, it's basically just one extra line to 
add user/pass auth using PAM again local users. The openvpn manual has the 
details of what /etc/pam.d/openvpn should contain.

The extra line:
plugin /usr/lib64/openvpn/openvpn-auth-pam.so openvpn

On the client side it's just the auth-user-pass option.B

> To get that right: You are using 3 simultaneous connections, all using
> auth-user-path?

Two of the three are using auth-user-pass, the other isn't, which reveals 
a different bug which I'll detail in a moment.

> Attached you'll find a version with a best guess fix. Let me know if it
> makes things better or worse. It won't handle the case where multiple
> tunnels ask for a password the same time. (Fix is in head.)

I gave it a try, though I didn't have an opportunity to test it over 
multiple reboots. Observations:

1) Upon enabling OpenVPN "Turn on OpenVPN", it sometimes immediately tries 
to connect to a server. If this is my conf w/o auth-user-pass, then the 
VPN comes up immediately, even though the UI shows no specific 
configurations as enabled. From my perspective, ideally, enabling OpenVPN 
should never autoconnect any configs, even if they were connected when 
OpenVPN was disabled or last running. This is especially important as long 
as the display of what VPNs are connected remains unreliable (see 
observation #2).  Since connecting to a VPN may route my traffic and DNS 
differently, it's a security matter and one would want to avoid ever being 
unknowningly or unintentionally connected to a VPN.

2) The program often seems to lose connection to the connection management 
interface/port, so it often displays misleading status on the connections. 
For instance, often during connecting the password-less VPN, it shows 
'Connecting', but then reverts back to 'Select to turn on OpenVPN tunnel'. 
However, the VPN is connected, and if I tap that config again, it 
immediately shows 'Connected' and the IP details. So I can be connected 
when it says I'm not, but tapping again once or twice generally shows the 
true status. This happens on 0.4.1, not just 0.4.2test.

3) In 0.4.2test, the mixups in which Username/Password prompt is 
associated with which conf seems to be fixed. If I connect w/a.conf, I am 
notified of a password request for a.conf, and when I open the dialog, it 
shows "Enter password for a.conf". (previously that last part would show a 
different conf). Entering the password appears not to work -- the 
connecton immediately shows disabled, but in reality it works, it's just 
the connection to the connection manager is lost. Leading to a new problem 
in 0.4.2test..

4) There seems to be an error which causes connections to the connection 
manager to fail much more often. Thus after entering the correct 
user/pass, the VPN is established, but the app displays a disabled status. 
Tapping the conf doesn't change this -- in 0.4.1 it reconnected to the 
management port and updated to show the VPN was up -- but in 0.4.2test it 
stays disabled.

So in 0.4.2test, auth seems to work properly now, but it can't stay 
connected to the management port, so it looks non-functional, and 
moreover, since it can never go to an 'enabled' state, I can never 
disconnect the VPN (through the UI).

logcat shows this error during the initial connect, and on each subsequent 
tap of the conf:
E/OpenVPN-DaemonMonitor[/sdcard/openvpn/a.conf]-mgmt( 9455): Lost 
connection to OpenVPN daemon
E/OpenVPN-DaemonMonitor[/sdcard/openvpn/a.conf]-mgmt( 9455): 
java.io.IOException: Invalid Mark.
E/OpenVPN-DaemonMonitor[/sdcard/openvpn/a.conf]-mgmt( 9455):    at 
java.io.BufferedReader.reset(BufferedReader.java:465)
E/OpenVPN-DaemonMonitor[/sdcard/openvpn/a.conf]-mgmt( 9455):    at 
java.io.LineNumberReader.reset(LineNumberReader.java:237)
E/OpenVPN-DaemonMonitor[/sdcard/openvpn/a.conf]-mgmt( 9455):    at 
de.schaeuffelhut.android.openvpn.service.ManagementThread.block(DaemonMonitor.ja
va:440)
E/OpenVPN-DaemonMonitor[/sdcard/openvpn/a.conf]-mgmt( 9455):    at 
de.schaeuffelhut.android.openvpn.service.ManagementThread.monitor(DaemonMonitor.
java:408)
E/OpenVPN-DaemonMonitor[/sdcard/openvpn/a.conf]-mgmt( 9455):    at 
de.schaeuffelhut.android.openvpn.service.ManagementThread.run(DaemonMonitor.java
:332)
D/OpenVPN-DaemonMonitor[/sdcard/openvpn/a.conf]-mgmt( 9455): terminated

or

D/OpenVPN-DaemonMonitor[/sdcard/openvpn/a.conf]-mgmt( 9455): started
D/OpenVPN-DaemonMonitor[/sdcard/openvpn/a.conf]-mgmt( 9455): attach(): 
using management port at 30638
V/OpenVPN-DaemonMonitor[/sdcard/openvpn/a.conf]-mgmt( 9455): Successfully 
attached to OpenVPN monitor port
V/OpenVPN-DaemonMonitor[/sdcard/openvpn/a.conf]-mgmt( 9455): Socket IO 
established
W/OpenVPN-DaemonMonitor[/sdcard/openvpn/a.conf]( 9455): start(): 
ManagementThread is already alive!
D/OpenVPN-DaemonMonitor[/sdcard/openvpn/a.conf]-mgmt( 9455): >INFO:OpenVPN 
Management Interface Version 1 -- type 'help' for more info
V/OpenVPN-DaemonMonitor[/sdcard/openvpn/a.conf]-mgmt( 9455): 
onState("1267954200,CONNECTED,SUCCESS,10.35.50.2,64.127.116.132")
D/dalvikvm( 9455): GC freed 7769 objects / 504056 bytes in 114ms
E/OpenVPN-DaemonMonitor[/sdcard/openvpn/a.conf]-mgmt( 9455): Lost 
connection to OpenVPN daemon
E/OpenVPN-DaemonMonitor[/sdcard/openvpn/a.conf]-mgmt( 9455): 
java.io.IOException: Invalid Mark.
E/OpenVPN-DaemonMonitor[/sdcard/openvpn/a.conf]-mgmt( 9455):    at 
java.io.BufferedReader.reset(BufferedReader.java:465)
E/OpenVPN-DaemonMonitor[/sdcard/openvpn/a.conf]-mgmt( 9455):    at 
java.io.LineNumberReader.reset(LineNumberReader.java:237)
E/OpenVPN-DaemonMonitor[/sdcard/openvpn/a.conf]-mgmt( 9455):    at 
de.schaeuffelhut.android.openvpn.service.ManagementThread.block(DaemonMonitor.ja
va:440)
E/OpenVPN-DaemonMonitor[/sdcard/openvpn/a.conf]-mgmt( 9455):    at 
de.schaeuffelhut.android.openvpn.service.ManagementThread.monitor(DaemonMonitor.
java:408)
E/OpenVPN-DaemonMonitor[/sdcard/openvpn/a.conf]-mgmt( 9455):    at 
de.schaeuffelhut.android.openvpn.service.ManagementThread.run(DaemonMonitor.java
:332)
D/OpenVPN-DaemonMonitor[/sdcard/openvpn/a.conf]-mgmt( 9455): terminated

Point 4 is the same as issue #3

I think point 2 is the same as issue #3, but  #4 is a new bug introduced in 
0.4.2test. It 
happens on almost every reconnect attempt, rather than just dropping now and 
then. 
With point 4 on 0.4.2test, one in many cases cannot reconnect at all (thus 
preventing 
you from telling it to close the vpn).

And the report of the java.io.IOException: Invalid Mark.  I believe is new and 
related to 
that.

Pardon, the Invalid Mark is present in both, but as said, it happens constantly 
in 
0.4.2test, preventing connecting at all to management, whereas in 0.4.1 it 
would just 
occasionally cause disconnects, but one could reconnect to management the 
majority of 
the time.

Please try attached apk and check if the IOException still appears.
For explanation see issue #3.

Tried 0.4.2test1.  No longer get the IOException and management port 
connections 
seem much more stable, but the password/vpn confusion is back. One of two auth-
user-pass VPNs shows the wrong conf name at the user/pass dialog.

Please confirm fix in attached apk.