Native Client Crash During Host Name Resolution

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Sometimes, OpenVPN native client fails to resolve the server host name it is 
trying to connect to although there is network connectivity.
2. Most of the times when issue No 1 happens, this results in the native client 
process getting an assertion and crashing. Below are log lines from the native 
client:

Cannot resolve host address: <hostname>: [TRY_AGAIN] A temporary error occurred 
on an authoritative name server.
SIGUSR1[soft,init_instance] received, process restarting
Assertion failed at openvpn//src/openvpn/buffer.c:331
Exiting due to fatal error


What is the expected output? What do you see instead?
I expect the client to retry resolving the address according to the number 
defined in the configuration and not to crash.

What mobile phone are you using?
Samsung Galaxy S2

Which Android Version and stock ROM or aftermarket like cyanogenmod?
stock ROM, v4.03

Please provide any additional information below.

Original issue reported on code.google.com by [email protected] on 6 Feb 2013 at 2:36

[GoogleCodeExporter]

Which version of the client are you using? 
Can you send a more complete log?
The client should make a minidump, can you send it to me?

Original comment by [email protected] on 6 Feb 2013 at 3:10

[GoogleCodeExporter]

Hi,

Actually, it was one of the older clients (From Aug 7, 2012).
The problem was reproduced several times but now we are unable to do it.
I've attached a dump of minivpn (is this what you were looking?) but I'm not 
sure if it's of the same crash.

1. Is there a chance that with the newer version this won't happen?
2. In your latest version of the client, minivpn is still based on v2.3 alpha 
of the OpenVPn client. is there a reason for this?  (I saw that the official 
release have a lot of bugfixes)

Original comment by [email protected] on 6 Feb 2013 at 4:13

[GoogleCodeExporter]

The August 7 2012 version is very old. I suggest you try the up to date one. 
The versions after Dezember 2012 also have new resolve code. And no the client 
is not based on v2.3alpha. I might have forgotten to update the version string.

Original comment by [email protected] on 6 Feb 2013 at 4:18

[GoogleCodeExporter]

Thanks for your comments. I will update the client.

1. Do you see any connection between the resolution and the assertion?
Do you know if after such an assertion the TUN descriptor is closed? because we 
had connectivity issues which might imply it is open after the crash (and no 
one handles the packets arriving from the TUN) 

2. So The latest version of your client is based on the latest OpenVPN,  2.3 GA 
then? (only the release notes still point to the alpha?)

3. For knowledge, is minivpn is your modified version for the original OpenVPN 
client? (If so, What were your major changes?)

Thanks a lot!!

Original comment by [email protected] on 7 Feb 2013 at 11:14

[GoogleCodeExporter]

1. the whole stack in current version is partly rewritten using proper dual 
stack resolution.

2. It is base on master branch actually

3. minivpn is only a linkage trick. The source is available. It is basically 
2.3master + android patches + dual stack patches

Original comment by [email protected] on 7 Feb 2013 at 11:53

[GoogleCodeExporter]

Dual stack resolution means supporting IPv4 and IPv6 as well?

Master branch means trunk? (latest source)

Does your client has some mechanism for verifying proper closure of the TUN 
file descriptor in case of minivpn crash (like my assertion) to prevent 
connectivity issues?

Original comment by [email protected] on 7 Feb 2013 at 12:04

[GoogleCodeExporter]

master means master. (trunk is a svn term, master a git term).

For closing tun that is not needed. Android will take care of that.

Original comment by [email protected] on 7 Feb 2013 at 12:12

[GoogleCodeExporter]

I'm asking this because of the connectivity issue i had after the crash.

According to android documentation:

"The network is restored automatically when the file descriptor is closed. It 
also covers the cases when a VPN application is crashed or killed by the 
system."

But, in your implementation for onRevoke(), I don't see that the file 
descriptor is being closed.

So it has to be one of the following:
1. Andoid clsoes it if minivpn closes or being crashed.
2. minivpn closes it upon exit?

Or did miss something ...

Original comment by [email protected] on 7 Feb 2013 at 12:24

[GoogleCodeExporter]

The file descriptor is passed to OpenVPN so it is OpenVPNs resposibiity to 
close it.

Original comment by [email protected] on 7 Feb 2013 at 12:33

[GoogleCodeExporter]

So when OpenVPN process crashes, Android closes the file descriptor and when 
OpenVPN exits gracefully the process itself closes the file descriptor that was 
given to him? (no handling is needed at the java code)

Original comment by [email protected] on 7 Feb 2013 at 2:41

[GoogleCodeExporter]

Right.

Original comment by [email protected] on 7 Feb 2013 at 2:42

[GoogleCodeExporter]

I am closing the bug. This discussion is unrelated to the bug. If you find a 
bug in the current version (0.5.31) please open a new ticket.

Original comment by [email protected] on 7 Feb 2013 at 2:43

• Changed state: Invalid

[GoogleCodeExporter]

I am closing the bug. This discussion is unrelated to the bug. If you find a 
bug in the current version (0.5.31) please open a new ticket.

Original comment by [email protected] on 7 Feb 2013 at 2:43