Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

HTC not routing through tunnel. #18

Closed
GoogleCodeExporter opened this issue Mar 19, 2015 · 13 comments
Closed

HTC not routing through tunnel. #18

GoogleCodeExporter opened this issue Mar 19, 2015 · 13 comments

Comments

@GoogleCodeExporter
Copy link 


On HTC Sensation XE when you run ics-openvpn, it connects as expected, however 
nothing is routed through the tunnel.

This is because of an HTC idiosyncrasy regarding "ip rule" tables.
Described in this issue: 
http://code.google.com/p/android-openvpn-settings/issues/detail?id=35

I'm not sure this can be dealt with without root.

But "up"/"down" commands would help, letting you change the routes manually.


currently I run this script as root after:
vpn up:
--------8<--------
#!/system/xbin/busybox ash

tun=tun0

ip route show dev $tun table main scope link | while read r; do
    case "$r" in
        *" "*)
            true
            ;;
        *)
            ip route del dev $tun $r
            ip route add dev $tun $r table vpn
            ;;
    esac
done
ip rule show | while read no r; do
    if [ $no != 0: ]; then
        case "$r" in
            "from all lookup vpn")
                no=${no/:/}
                break
                ;;
            "from all lookup"*)
                no=$((${no/:/} - 1))
                ip rule add pref $no from all lookup vpn
                break
                ;;
        esac
    fi
done

--------8<--------
and after:
vpn down:
--------8<--------
#!/system/xbin/busybox ash


ip route show table vpn scope link | while read l; do
    ip route del $l
done
ip rule show | while read no r; do
    case "$r" in
        "from all lookup vpn")
            no=${no/:/}
            ip rule del pref $no from all lookup vpn
            break
            ;;
    esac
done
--------8<--------

Original issue reported on code.google.com by bogeskov...@gmail.com on 11 May 2012 at 8:23
@GoogleCodeExporter
Copy link
Author 

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 arne@rfc2549.org on 11 May 2012 at 9:24

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

@GoogleCodeExporter
Copy link
Author 


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 bogeskov...@gmail.com on 11 May 2012 at 11:14

@GoogleCodeExporter
Copy link
Author 

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

Original comment by arne@rfc2549.org on 11 May 2012 at 11:44

@GoogleCodeExporter
Copy link
Author 

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 arne@rfc2549.org on 20 May 2012 at 2:19

@GoogleCodeExporter
Copy link
Author 

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 bogeskov...@gmail.com on 22 May 2012 at 9:36

@GoogleCodeExporter
Copy link
Author 

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 arne@rfc2549.org on 1 Jun 2012 at 1:17

@GoogleCodeExporter
Copy link
Author 

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 ryansca...@gmail.com on 18 Jun 2012 at 6:04

@GoogleCodeExporter
Copy link
Author 


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 bogeskov...@gmail.com on 18 Jun 2012 at 10:54

@GoogleCodeExporter
Copy link
Author 

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 bogeskov...@gmail.com on 1 Aug 2012 at 7:08

@GoogleCodeExporter
Copy link
Author 

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 arne@rfc2549.org on 1 Aug 2012 at 9:01

  • Changed state: WontFix

@GoogleCodeExporter
Copy link
Author 

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

Original comment by fredrik....@gmail.com on 1 Aug 2012 at 9:11

@GoogleCodeExporter
Copy link
Author 

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 arne@rfc2549.org on 1 Aug 2012 at 9:19

@Manak0786

This comment was marked as spam.

Sign in to view
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@GoogleCodeExporter @Manak0786