-device 'dns0' works, -device 'tun0' default does not.

[rocket-pig]

Android 4.2.2

After many many other attempts to troubleshoot, I downloaded the iodine android binary from http://code.kryo.se/iodine/iodine-0.7.0-android.zip

executing it without setting a device name and it will default to 'dns0'. Why is this? I don't know. When the tun device is 'dns0' though, the tunnel works. When it is 'tun0' it does not.

Why is this, I have no idea. /proc/sys/net/ipv4/conf/tun0/ and /sys/class/net/ipv4/conf/tun0/ both hold settings, but are identical when system sets up 'dns0' instead.

tcpdump traffic looks very similar between working and non-working, so it's not a network configuration issue. It must have something to do with permissions of tun0 vs dns0 virtual device..

any suggestions? Simply changing the interface to allow for setting the -d device paramter would solve this.

[yvesf]

To clarify, the iodine c client calls open_tun() (in tun.c) and there can specificy the name of the tun device.

Andiodine gets the tun-device from the Android VPN Framework and just passes a file-descriptor into the actual iodine client code, thus it skips the open_tun() call.

I doubt that just the different naming plays any role in the end. Also I can confirm that it worked once for me™ on an android 4.2.2.

For the question about why the name 'dns0'. See in tun.c#L110, there is a loop trying dns0,dns1,....

[rocket-pig]

Thank you. Reading and experimenting further I see that the iodine binary, with no "-d" setting, will use "dns0" and NOT "tun0". Why does andiodine use tun0? In the tun.c it appears that tun0 is used for darwin, and that different network config is loaded.

[yvesf]

In andiodine in IodineVpnService L 380 we call [establish()](https://developer.android.com/reference/android/net/VpnService.Builder.html#establish()). By this android will create 'tun0' (or whetever android likes as a name) for us.

[rocket-pig]

So why does android decide to use tun0 when it is called by vpn service, and dns0 when called by iodine binary? the naming seems to be the point of failure, at least in my environment. tun0 = tunnel comes up, data is sent / received, but software using tunnel cannot see it. dns0 = same, but browser etc works.

[rocket-pig]

Ive looked everywhere for a permission, ownership etc that was preventing a virtual device named 'tun0' from having the same function as one named 'dns0'. They appear identical, yet something prevents one from working and not the other.

[yvesf]

In case of iodine cmdline binary there is no Android involved but just Linux. There iodine requests the name 'dns0'.

From your error description I would guess something with the routing is not set up properly. In case of iodine on cmdline it fires some "route add .. gateway .." commands to set up routing. With andiodine we again rely on the Android VPN Framework. So something could be wrong here. Did you validate/compared the routing settings in both cases?

[rocket-pig]

Top is andiodine/ vpn setup, bottom is from command line.

shell@android:/ $ ip route show default via 192.168.2.1 dev wlan0 default via 192.168.2.1 dev wlan0 metric 233 10.0.0.0/27 dev tun0 proto kernel scope link src 10.0.0.4 192.168.2.0/24 dev wlan0 proto kernel scope link src 192.168.2.104 metric 233 192.168.2.1 dev wlan0 scope link shell@android:/ $ ip route show default via 192.168.2.1 dev wlan0 default via 192.168.2.1 dev wlan0 metric 233 10.0.0.0/27 dev dns0 proto kernel scope link src 10.0.0.2 192.168.2.0/24 dev wlan0 proto kernel scope link src 192.168.2.104 metric 233 192.168.2.1 dev wlan0 scope link

other places to look besides 'ip route show'?

[yvesf]

I think ip route show should contain all necessary info.

Both versions don't set the default gateway to 10.0.0.1 (the dns-tunnel endpoint).

Can you ping 10.1.0.1 (the dns-tunnel endpoint where iodined runs) in both cases?

Can you verify that for iodine commandline version, when you use the browser that it's really using the tunnel?

[rocket-pig]

Yes, i have optware installed and have used both 'tsocks' and another android tool to point traffic into the tunnel. using the 'default route' setting in andiodine does not change the inability for clients to see the responses/traffic. the traffic still happens, just nobody at client side of tunnel can see it. I have verified that the tunnel still sets up properly with 'tcpdump' and other traffic monitoring ways.

[rocket-pig]

sorry, let me back up. 'tsocks' works with either 'tun0' or 'dns0'. So, youre right, the naming is not what is at fault.

[yvesf]

tsocks is intended for SOCKS tunnels. iodine is a layer 3 tunnel. So it should be unrelated.

[rocket-pig]

the iodined server has a socks proxy set up. see http://dnstun.com

[rocket-pig]

'tsocks' only works with elevated permissions. android apps don't have access to the tunnel due to some permissions issue...somewhere.

[yvesf]

I wasn't aware that you are using that service from dnstun.com, I haven't heard of it before. Therefore I was irritated by your mention of tsocks. Now things make more sense. However, for debugging this makes it more complicated. I recommended that you first try to get things going using a iodined server under your control.

[rocket-pig]

having access to the server would definitely cut down on the guessing!

How do I ask the client to add a device name? "clientset..?" I dont see it anywhere in client.c.

[yvesf]

In iodine.c https://github.com/yvesf/andiodine/blob/master/jni/iodine/src/iodine.c#L346 It passes either the device name from -d or NULL, if NULL then tun.c open_tun() starts probing dns0,dns1,etc.. Regarding the Android VPN Framework I'm not aware of any method to fix the device-name.

[rocket-pig]

i am working to add the option of forcing "dns0". Learning as I go. If I can get it working, it will appear as a fork.

Thank you for your responses! Much appreciated. I'm learning a lot from you and your project. :)

[rocket-pig]

Upon further study, this is really not an issue with andiodine but more an issue with connecting via socks to remote proxy over the tunnel.

Thanks for your interaction, much appreciated.

[yvesf]

Thanks for the update, you're welcome :smile: