HTC not routing through tunnel.

[GoogleCodeExporter]

HTC not routing through tunnel.

[GoogleCodeExporter]

You should file a bug report at HTC. The openvpn app is using an official API 
that has to work in Android 4.0 images.

You can always try to add the up down script as custom options under obscure 
options. You will also have to set script-security 3 (or something like this). 
But the scripts will be executed as non root.

I also have not looked into iptables/ip rule/routing what android does to 
protect the vpn connection socket.

I am not really sure what the best way to fix this in my application is 
considering this a bug in the ROM.

Original comment by [email protected] on 11 May 2012 at 9:24

• Added labels: Priority-Low, Type-Enhancement
• Removed labels: Priority-Medium, Type-Defect

[GoogleCodeExporter]

Thanks for the quick reply.

I've now reported the issue to HTC, trying my best to be diplomatic (and 
unfortunately that isn't one of my strong suits) while claiming that they have 
apparently broken the ICS-api.

I'm not too well traveled in the ics-openvpn yet, But i've trued Custom Options 
(and checked the generated config, that they appear):
--------8<--------
up /data/local/vpn.up
down /data/local/vpn.down
script-security 3
--------8<--------

Results in:

P:Fri May 11 12:54:25 2012 us=595568 OPTIONS IMPORT: timers and/or timeouts 
modified
P:Fri May 11 12:54:25 2012 us=595599 OPTIONS IMPORT: LZO parms modified
P:Fri May 11 12:54:25 2012 us=595629 OPTIONS IMPORT: --ifconfig/up options 
modified
P:Fri May 11 12:54:25 2012 us=595690 OPTIONS IMPORT: route options modified
P:Fri May 11 12:54:25 2012 us=595721 OPTIONS IMPORT: route-related options 
modified
P:Fri May 11 12:54:25 2012 us=595751 OPTIONS IMPORT: --ip-win32 and/or 
--dhcp-option options modified
P:Fri May 11 12:54:25 2012 us=596178 ROUTE_GATEWAY 
10.162.86.229/255.255.255.252 IFACE=rmnet0 HWADDR=00:00:00:00:00:00
P:Fri May 11 12:54:25 2012 us=596362 do_ifconfig, tt->ipv6=0, 
tt->did_ifconfig_ipv6_setup=0
P:Fri May 11 12:54:25 2012 us=601153 MANAGEMENT: CMD 'needok 'IFCONFIG' ok'
P:Fri May 11 12:54:25 2012 us=602496 MANAGEMENT: CMD 'needok 'ROUTE' ok'
P:Fri May 11 12:54:25 2012 us=603655 MANAGEMENT: CMD 'needok 'ROUTE' ok'
P:Fri May 11 12:54:25 2012 us=604601 MANAGEMENT: CMD 'needok 'DNSSERVER' ok'
P:Fri May 11 12:54:25 2012 us=609606 MANAGEMENT: CMD 'needok 'DNSDOMAIN' ok'
P:Fri May 11 12:54:26 2012 us=15551 MANAGEMENT: CMD 'needok 'OPENTUN' ok'
P:Fri May 11 12:54:26 2012 us=15917 MANAGEMENT: Client disconnected
P:Fri May 11 12:54:26 2012 us=15978 Assertion failed at 
openvpn//src/openvpn/misc.c:116
P:Fri May 11 12:54:26 2012 us=16039 Exiting due to fatal error
MGMT:Got unrecognized command>FATAL:Assertion failed at 
openvpn//src/openvpn/misc.c:116

I'm not entirely sure up/down is actually supported.

I've modified my scripts to be runnable as any user, and without "Custom 
Options", I can connect run them as user shell and return value is 0 ($?), and 
then everything is working.

Original comment by [email protected] on 11 May 2012 at 11:14

[GoogleCodeExporter]

I will look into the assert failed failed. I believe that is something I fix on 
my side :)

Original comment by [email protected] on 11 May 2012 at 11:44

[GoogleCodeExporter]

I have not looked into the up script issue but on a sidenote in issue #24 the 
fix of setting the routes with /30 for net30 fixed the routing. Perhaps that 
will help you too.

Original comment by [email protected] on 20 May 2012 at 2:19

[GoogleCodeExporter]

With the new version (with issue #24)


I get 192.168.25.130/24 from the server, and it ends up in the vpn table:

# ip route show table vpn                                  
default dev tun0  scope link 
192.168.25.128/26 dev tun0  scope link  src 192.168.25.130 

But the default route is not pushed from server, and is not selected in the 
config gui.
from serverlog:
SENT CONTROL [sensation]: 'PUSH_REPLY,comp-lzo no,topology subnet,route-gateway 
192.168.25.129,route 192.168.25.0 255.255.255.0,route 172.19.1.48 
255.255.255.240,dhcp-option DNS 172.19.1.49,dhcp-option DOMAIN 
[SNIP],dhcp-option DOMAIN-SEARCH [SNIP],ping 10,ping-restart 60,ifconfig 
192.168.25.130 255.255.255.192' (status=1)


And there's no ip rule for table vpn. If I run:
# ip rule add pref 2500 from all lookup vpn
# ip rule
0:  from all lookup local 
1710:   from all to [SNIP] lookup hipri 
1720:   from all to [SNIP] lookup hipri 
1750:   from all to [SNIP] lookup hipri 
2110:   from all to [SNIP] lookup netshare 
2120:   from all to [SNIP] lookup netshare 
2150:   from all to [SNIP] lookup netshare 
2500:   from all lookup vpn 
3300:   from all lookup gprs 
32766:  from all lookup main 
32767:  from all lookup default 

I can ping everything as expected, due to the default route. but the server 
supplied route (172.19.1.48/28) is only in the global routing table

# ip route
default via 10.36.195.37 dev rmnet0 
10.36.195.36/30 dev rmnet0  proto kernel  scope link  src 10.36.195.36 
10.36.195.37 dev rmnet0  scope link 
172.19.1.48/28 dev tun0  scope link 
192.168.25.0/24 dev tun0  scope link 
192.168.25.128/26 dev tun0  proto kernel  scope link  src 192.168.25.130 
# ip route show table vpn
default dev tun0  scope link 
192.168.25.128/26 dev tun0  scope link  src 192.168.25.130 

I've added:
ip rule add pref 2500 from all lookup vpn
to (my newly created file) /etc/init.post_boot.sh
#!/system/bin/sh

ip rule add pref 2500 from all lookup vpn

This makes it work, except that I get all data routed through the vpn and not 
just the expected 2 subnets.

All the oddities from HTC

But for the time being SUCCESS (with hacks)

Original comment by [email protected] on 22 May 2012 at 9:36

[GoogleCodeExporter]

I have no idea what the rule stuff does. But if someone can provide a solution 
that works without side effects I am happy to include a solution for HTC Users. 
(Like the CM9 ownership fix)

Original comment by [email protected] on 1 Jun 2012 at 1:17

[GoogleCodeExporter]

I'm having this same issue.  However if I disconnect and reconnect about 1 out 
of 4 times the data will be routed through the tunnel I'm using a HTC amaze ics

Original comment by [email protected] on 18 Jun 2012 at 6:04

[GoogleCodeExporter]

I've got great experience just connecting, and then leaving it for a while, 
then it reconnects after write error (11) or something like that. And then 
everything is routed through.

Original comment by [email protected] on 18 Jun 2012 at 10:54

[GoogleCodeExporter]

As of today (August 1st), it all comes together. I don't know if it's updates 
in the app or the new update from HTC (Sensation 3.33.*), but everything works 
as expected.

The last reason not to recommend my current phone to friends has vanished.

Thank you

btw. gui has gone from functional to useful, and the shortcut function is close 
to prefect now.

Original comment by [email protected] on 1 Aug 2012 at 7:08

[GoogleCodeExporter]

Thanks. I will close the bug for now but keep the pointer in the FAQ as some 
people may not have update their phone or run into similar problems.

Original comment by [email protected] on 1 Aug 2012 at 9:01

• Changed state: WontFix

[GoogleCodeExporter]

Well it still fails for me on my very updated HOS so I'll just uninstall it.

Original comment by [email protected] on 1 Aug 2012 at 9:11

[GoogleCodeExporter]

I am sorry to hear that. I still opening to suggestions how to work around the 
bug on HTC phones but cannot look it myself since I don't own a HTC telephone.

Original comment by [email protected] on 1 Aug 2012 at 9:19