DNS settings are sometimes not restored

[GoogleCodeExporter]

Run the app and connect to a VPN. Disconnect from it. Your DNS may no
longer be correctly set and new domain names would not be resolved. A
reboot would restore them.

Original issue reported on code.google.com by babak.mozaffari on 25 Jul 2009 at 10:26

[GoogleCodeExporter]

I've noticed the same problem.  the quick fix is to enable & disable airplane 
mode

Original comment by pmu...@gmail.com on 25 Jul 2009 at 10:56

[GoogleCodeExporter]

Fixed now! New version will be uploaded soon.

Original comment by babak.mozaffari on 25 Jul 2009 at 11:01

• Changed state: Fixed

[GoogleCodeExporter]

still happening after update to v05

Original comment by pmu...@gmail.com on 25 Jul 2009 at 12:42

[GoogleCodeExporter]

Could you help me reproduce it? The issue no longer occurs on my phone and that 
makes
it hard to debug if you still have it.

Do the following and record the responses:

getprop net.dns1
getprop net.dns2
cat /proc/net/route

Connect to your VPN and while still connected, perform the following and record 
the
responses:

getprop net.dns1
getprop net.dns2
cat /proc/net/route
cat /data/data/org.codeandroid.vpnc_frontend/files/dns1.txt
cat /data/data/org.codeandroid.vpnc_frontend/files/dns2.txt

Finally, disconnect from your VPN and record the response to the following 
again:

getprop net.dns1
getprop net.dns2
cat /proc/net/route

Thanks!

Original comment by babak.mozaffari on 25 Jul 2009 at 7:25

• Changed state: Accepted

[GoogleCodeExporter]

Hi, here's the results of the requested tests.

one reason for our differing results might be that my vpn is configured to 
disable split tunnels.

I've noticed also a curious behaviour when running nslookup, that it says that 
it's dafault name server is: 4.2.2.5
so I've included a simple nslookup test

1st run.... (after boot - wifi connected)

/ # getprop net.dns1
getprop net.dns1
192.168.69.254
/ # getprop net.dns2
getprop net.dns2

/ # cat /proc/net/route
cat /proc/net/route
Iface   Destination     Gateway         Flags   RefCnt  Use     Metric  Mask    
        MTU     Window  IRTT
tiwlan0 0045A8C0        00000000        0001    0       0       0       
00FFFFFF        0       0       0
tiwlan0 00000000        FE45A8C0        0003    0       0       0       
00000000        0       0       0

2nd run.... (vpn connected)

getprop net.dns1
192.168.1.37

/ # getprop net.dns2
getprop net.dns2
192.168.1.38

/ # cat /proc/net/route
cat /proc/net/route
Iface   Destination     Gateway         Flags   RefCnt  Use     Metric  Mask    
        MTU     Window  IRTT
tiwlan0 2D0BDCCB        FE45A8C0        0007    0       0       0       
FFFFFFFF        0       0       0
tiwlan0 0045A8C0        00000000        0001    0       0       0       
00FFFFFF        0       0       0
tun0    000CA8C0        00000000        0001    0       0       0       
00FFFFFF        0       0       0
tun0    00000000        00000000        0001    0       0       0       
00000000        0       0       0

/ # cat /data/data/org.codeandroid.vpnc_frontend/files/dns1.txt
cat /data/data/org.codeandroid.vpnc_frontend/files/dns1.txt
192.168.69.254
/ # cat /data/data/org.codeandroid.vpnc_frontend/files/dns2.txt
cat /data/data/org.codeandroid.vpnc_frontend/files/dns2.txt

3rd run (vpn disconnected)

/ # getprop net.dns1
getprop net.dns1
192.168.69.254
/ # getprop net.dns2
getprop net.dns2
192.168.1.38
/ # cat /proc/net/route
cat /proc/net/route
Iface   Destination     Gateway         Flags   RefCnt  Use     Metric  Mask    
        MTU     Window  IRTT
tiwlan0 0045A8C0        00000000        0001    0       0       0       
00FFFFFF        0       0       0

nslookup behaviour after reboot
/ # nslookup muney.net
nslookup muney.net
Server:    4.2.2.5
Address 1: 4.2.2.5 vnsc-bak-dsl.genuity.net

Name:      muney.net
Address 1: 203.88.117.161 greatwhite.cbr.hosting-server.com.au

after vpn connection & disconnection

/ # nslookup muney.net
nslookup muney.net
Server:    4.2.2.5
Address 1: 4.2.2.5

nslookup: can't resolve 'muney.net'
/ # nslookup muney.net 192.168.69.254
nslookup muney.net 192.168.69.254
Server:    192.168.69.254
Address 1: 192.168.69.254

Original comment by pmu...@gmail.com on 26 Jul 2009 at 2:58

[GoogleCodeExporter]

I don't know if it's relevant but I've also noticed that whenever I change 
networks, ie 
change from wi-fi to 3g or vice versa, the property net.dnschange seems to 
increment, 
but when I connect or disconnect the vpn connection, this property doesn't 
change.

I've also noticed that dnslookups don't actually seem to be working within the 
vpn.
it might have something the do with this address 4.2.2.5 

ps, I'm running CyanogenMod-3.6.8.1

Original comment by pmu...@gmail.com on 26 Jul 2009 at 3:21

[GoogleCodeExporter]

checked resolv.conf to confirm the public DNS, presumably carried over from the 
source 
build.
not sure if removing these might help
cat /etc/resolv.conf
nameserver 4.2.2.5
nameserver 4.2.2.4
nameserver 4.2.2.3
nameserver 4.2.2.2

Original comment by pmu...@gmail.com on 26 Jul 2009 at 5:05

[GoogleCodeExporter]

I've done some debugging and it appears dns entries are restored properly.

However, routing table doesn't get restored properly. In particular, default 
route is
missing. This occurs for both, Tmobile network access as well as the wifi.

Here is an example. When connected to Tmobile network routing table looks 
something
like this:

<before VPN connection>
% ip route
25.1.168.224/30 dev rmnet0 src 25.1.168.224
default via 25.1.168.225

<after VPN connect, disconnect>
% ip route
25.1.168.224/30 dev rmnet0 src 25.1.168.224

and no default setting.

It is easy to add it back such as:

ip route add default <ip> dev rmnet0

but it should get restored automagically.  Here is the kicker, one time, I saw 
it
properly restored on the wifi, but only one time. I couldn't get it to behave 
again.

Original comment by dragomir...@gmail.com on 4 Aug 2009 at 7:17

[GoogleCodeExporter]

Happening to me every time, even on .08.

Original comment by marshall...@gmail.com on 21 Aug 2009 at 10:04

[GoogleCodeExporter]

Marshall, can you confirm that it's your "ip route default" that changes after a
connect/disconnect, as dragomirmnikolic noted?

Original comment by babak.mozaffari on 22 Aug 2009 at 8:09

[GoogleCodeExporter]

I notice my default route is lost after a disconnect as well. I looked at the 
utility
script (vpnc-script) and the variable $DEFAULT_ROUTE_FILE is not defined. This 
would
cause the original default route to be backed up to nowhere.

A simple work around: run this command to add the default route
# iproute add default dev DEVICE

DEVICE should be rmnet0 for cell network and tiwlan0 for WiFi.

Original comment by billc...@gmail.com on 23 Aug 2009 at 7:21

[GoogleCodeExporter]

Please (someone) download an updated vpnc-script
(http://get-a-robot-vpnc.googlecode.com/files/vpnc-script) and copy it over your
version (under /data/data/*frontend/files) and give it a try. Let me know if it 
fixes
the problem so I can do a build.

Thanks!

Original comment by babak.mozaffari on 23 Aug 2009 at 8:34

[GoogleCodeExporter]

Hi,

just tested the script, it dosn't work.

If you use the script inside vour 0.8 Version apk and only put

DEFAULT_ROUTE_FILE=`dirname $0`/def_route.txt

at the beginning then it Works!

Backup is then done by the function set_default_route() and restore by
reset_default_route()

Original comment by volker.m...@gmail.com on 25 Aug 2009 at 3:12

[GoogleCodeExporter]

Volker,

The script is used from the ../files and not from within the apk, so you should 
be
able to try and verify any changes right from the files directory.

If you can, please elaborate on why/how the script didn't work. Does it create a
def_route.txt file? If so, does that file contain the right route or not? If 
not, is
it because it backs up the route too late?

We've experienced that variables set at the top of the script do not stick by 
the
time methods are called.

Original comment by babak.mozaffari on 25 Aug 2009 at 3:39

[GoogleCodeExporter]

Hi,

you're right, I modified the ../files/vpn-script file.
What i want to say is, that i used the script installed with the apk Version 
0.8 and
not the linked one in Comment # 12 

If I use the above linked script, the backup of the default route is done to 
late.
The script creates the def_route.txt file, but the default route to the tun 
device is
saved in there.

Example:

<before VPN connection>
% ip route
10.212.74.136/30 dev rmnet0  src 10.212.74.136 
default via 10.212.74.137 dev rmnet0

<after VPN connect>
% cat def_route.txt
default dev tun0

If you take a look at the script, it will save the default route inside the 
function
modify_resolvconf_android() (Line 147)
This function is called from do_connect() (Line 245),
but there it's to late because with Line 241 the function set_default_route() 
is called.

set_default_route() wants also backup the "previous default route"
it want it to write in the "$DEFAULT_ROUTE_FILE" which is not declared.
So the Script throws an error.

So i think it's only necessary to define the "File-Handle" "DEFAULT_ROUTE_FILE"
and it will do the job.

Because of your experiences its also possible to declare it inside
set_default_route() and reset_default_route

I've attached my vpnc-script file.

Original comment by volker.m...@gmail.com on 26 Aug 2009 at 6:57

Attachments:

• vpnc-script

[GoogleCodeExporter]

I'm not sure if this is related or not but for some reason my DNS after 
connection
doesn't work. The values for net.dns1 and net.dns2 are in fact correct (IP's 
changed)

# getprop net.dns1                                                              

192.168.1.1                                                                     

# getprop net.dns2
192.168.1.2

Where 192.168.1.1 and 1.2 are in fact the dns servers on the internal network,
however I can't resolve addresses. I can successfully ping both dns servers when
connected but even if I try an nslookup on a local machine using either 1.1. or 
1.2
as the server it just hangs. I've verified that there is nothing in IPTables 
running
(all policies set to accept etc)

Any ideas why nothing would honour the net.dnsX entries or why even when I try 
to do
it manually from CLI they return nothing?

Example:
# getprop net.dns1                                                              

192.168.1.1

# ping 192.168.1.1
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
64 bytes from 192.168.1.1: icmp_seq=1 ttl=127 time=771 ms
64 bytes from 192.168.1.1: icmp_seq=2 ttl=127 time=769 ms
^C                                                                              

--- 192.168.1.1 ping statistics ---                                             

2 packets transmitted, 2 received, 0% packet loss, time 1002ms                  

rtt min/avg/max/mdev = 769.073/770.126/771.179/1.053 ms

# nslookup host.on.local.network 192.168.1.1
Server:    192.168.1.1
^C

it'll just hang there. I also tried hitting local web servers on the network 
and they
also would not resolve. I can however connect to them by IP with no issues. 
I'll keep
looking but does anyone have any ideas? I'm not positive about structure so I 
don't
know how services (browser etc) use the variables net.dn1 and net.dns2 or why
nslookup wouldn't work specifying the host explicitly.

Original comment by lonny.se...@gmail.com on 26 Aug 2009 at 1:25

[GoogleCodeExporter]

EDIT: just for clarification when I said "after connected" I meant "while 
connected
to the private network via VPN"  :-)

Original comment by lonny.se...@gmail.com on 26 Aug 2009 at 1:27

[GoogleCodeExporter]

Version 0.9 has been uploaded and should resolve the problems. Let me know how 
it goes.

Original comment by babak.mozaffari on 26 Aug 2009 at 4:30

• Changed state: Fixed

[GoogleCodeExporter]

I am using 0.99 and I am seeing the issue on my HTC Desire.

It seems like the diconnect part of the script is never called...

Original comment by uhutt...@gmail.com on 22 Jun 2010 at 9:39