Traceroute and ping doesn't properly work

[Lordcorvin1]

On rooted device, Android 8.1 When Firewall is on, every IP in termux and network mapper respond on every port. When only DNS is active, no pinging can be done. When RethinkDNS is turned off the ping functions as needed.

This also crashes RethinkDNS if you attempt to network scan a single IP as the log fills up so quickly the Firewall can't keep up. This is probably related to issue #343

Pic attached of the ping attempts with various settings, the correct ping is over 10ms

Traceroute fails entirely while RethinkDNS is active. Either no reply if firewall active or send failed if only DNS is active.

[ignoramous]

Thanks for the bug report. We don't support root, yet.

That said, I don't have a clue as to what could be the issue here. Until such a time I have access to a rooted Android which can run Termux (presumably Android 9 and below, only?), I doubt I'd be able to get to bottom of this.

[Uldiniad]

Thanks for the bug report. We don't support root, yet.

That said, I don't have a clue as to what could be the issue here. Until such a time I have access to a rooted Android which can run Termux (presumably Android 9 and below, only?), I doubt I'd be able to get to bottom of this.

It also happens if you su to another UID

[ignoramous]

So, ping and traceroute don't work in DNS-only mode, but work in Firewall-only and DNS+Firewall modes?

[Uldiniad]

So, ping and traceroute don't work in DNS-only mode, but work in Firewall-only and DNS+Firewall modes?

ping works in all modes here but tracepath only works in DNS-only mode

[Lordcorvin1]

Ping doesn't actually work for me. @Uldiniad, you should double check with IPs from across the globe, I tested the Russian DNS server 195.88.154.11 from Canada. It's 200ms on the router, while on the phone it's below 1ms connected to the same router. Everything pings below 1ms. It's as if the device is hijacking the IP and responding to every IP you attempt to ping. It includes IPs that are not actually online.

[ignoramous]

Oh, ICMP remains untouched. I guess the dependency's (tun2socks) default behaviour is to fake reply unhandled ICMP?

ICMP support is being worked upon in a new branch by another volunteer with tun2socks replaced with gvisor/netstack. Likely one or two months away from making it in the app itself: celzero/firestack#3

[ignoramous]

We've integrated gvisor/netstack (available since the v053i release; currently live on the website only; F-Droid and Play Store releases in 5 days or so), but haven't touched ICMP yet. It is really hairy, and I don't understand half of it. I do intend to work on it, but it isn't priority right now... given QUIC/UDP connections are very problematic with the way we use gvisor/netstack, it is going to take up my time for now (followed by WireGuard integration).

[ignoramous]

Everything pings below 1ms. It's as if the device is hijacking the IP and responding to every IP you attempt to ping.

@Lordcorvin1 I think you may just have helped us debug connectivity issues we see relating to IPv6... some clients (usually Meta/Facebook apps) think there's v6 Internet, even when there isn't. May be, our incorrect ICMP[v6] handling is at fault.

[missingcharacter]

@Lordcorvin1 do you know if ping and traceroute in termux use /data/data/com.termux/files/usr/etc/resolv.conf

[Lordcorvin1]

@missingcharacter Not sure, is there a way to find out? The file does exist and has Google DNS set there, 8.8.8.8 and 8.8.4.4

Edit: According to the internet it does but if you know a way to check for sure let me know. I have root access.

[missingcharacter]

@Lordcorvin1 I believe termux' ping does not use /data/data/com.termux/files/usr/etc/resolv.conf

I tested on my own phone without root, using strace

Install strace

pkg install strace

nslookup seems to use /data/data/com.termux/files/usr/etc/resolv.conf

$ strace nslookup [google.com](http://google.com/) 2>&1| grep resolv
read(3, "droid_resolv.link.default.shared"..., 1024) = 1024
read(3, "_android_resolv.link.system.shar"..., 1024) = 1024
read(3, "ex/com.android.resolv/${LIB}\nnam"..., 1024) = 1024
read(3, "droid_resolv.link.system.shared_"..., 1024) = 1024
read(3, "om_android_resolv.shared_libs = "..., 1024) = 1024
read(3, "B}\nnamespace.com_android_resolv."..., 1024) = 1024
openat(AT_FDCWD, "/apex/com.android.resolv/lib64", O_RDONLY|O_CLOEXEC|O_PATH) = 3
readlinkat(AT_FDCWD, "/proc/self/fd/3", "/apex/com.android.resolv/lib64", 4095) = 30
newfstatat(AT_FDCWD, "/apex/com.android.resolv/lib64", {st_mode=S_IFDIR|0755, st_size=4096, ...}, 0) = 0
newfstatat(AT_FDCWD, "/apex/com.android.resolv/lib64", {st_mode=S_IFDIR|0755, st_size=4096, ...}, 0) = 0
openat(AT_FDCWD, "/data/data/com.termux/files/usr/etc/resolv.conf", O_RDONLY) = 12

ping does not seem to use /data/data/com.termux/files/usr/etc/resolv.conf

$ strace ping -c2 [google.com](http://google.com/) 2>&1| grep resolv
read(3, "droid_resolv.link.default.shared"..., 1024) = 1024
read(3, "_android_resolv.link.system.shar"..., 1024) = 1024
read(3, "ex/com.android.resolv/${LIB}\nnam"..., 1024) = 1024
read(3, "droid_resolv.link.system.shared_"..., 1024) = 1024
read(3, "om_android_resolv.shared_libs = "..., 1024) = 1024
read(3, "B}\nnamespace.com_android_resolv."..., 1024) = 1024
openat(AT_FDCWD, "/apex/com.android.resolv/lib64", O_RDONLY|O_CLOEXEC|O_PATH) = 3
readlinkat(AT_FDCWD, "/proc/self/fd/3", "/apex/com.android.resolv/lib64", 4095) = 30
newfstatat(AT_FDCWD, "/apex/com.android.resolv/lib64", {st_mode=S_IFDIR|0755, st_size=4096, ...}, 0) = 0
newfstatat(AT_FDCWD, "/apex/com.android.resolv/lib64", {st_mode=S_IFDIR|0755, st_size=4096, ...}, 0) = 0
read(3, "droid_resolv.link.default.shared"..., 1024) = 1024
read(3, "_android_resolv.link.system.shar"..., 1024) = 1024
read(3, "ex/com.android.resolv/${LIB}\nnam"..., 1024) = 1024
read(3, "droid_resolv.link.system.shared_"..., 1024) = 1024
read(3, "om_android_resolv.shared_libs = "..., 1024) = 1024
read(3, "B}\nnamespace.com_android_resolv."..., 1024) = 1024
openat(AT_FDCWD, "/apex/com.android.resolv/lib64", O_RDONLY|O_CLOEXEC|O_PATH) = 3
readlinkat(AT_FDCWD, "/proc/self/fd/3", "/apex/com.android.resolv/lib64", 4095) = 30
newfstatat(AT_FDCWD, "/apex/com.android.resolv/lib64", {st_mode=S_IFDIR|0755, st_size=4096, ...}, 0) = 0
newfstatat(AT_FDCWD, "/apex/com.android.resolv/lib64", {st_mode=S_IFDIR|0755, st_size=4096, ...}, 0) = 0

[Lordcorvin1]

Seems so, but I get no previous entries like you do, one line result for me

strace nslookup google.com 2>&1| grep resolv I get openat(AT_FDCWD, "/data/data/com.termux/files/usr/etc/resolv.conf", O_RDONLY) = 12

strace ping -c2 google.com 2>&1| grep resolv Blank result

Tried sudo as well, same result.

[missingcharacter]

@Lordcorvin1, maybe the libraries and other file names do not contain the word 'resolv'

[Rhys-T]

I'm seeing this part too, on an unrooted Android 13 device:

When Firewall is on, every IP in termux and network mapper respond on every port.

(I can split this into a separate issue if you'd prefer, since it doesn't seem to be related to the ping/ICMP issues. I didn't start one yet because I wasn't sure if it would be a duplicate, since that was mentioned above.)

Details

If I have Rethink on, then almost any conceivable TCP connection that isn't blocked will 'succeed', even if it shouldn't. The only exception seems to be loopback addresses (127.*; 0.0.0.0 also works like one). I can try connecting to 192.0.2.1 (a reserved fake address in the TEST-NET-1 range) while in airplane mode, and see:

$ nc -v 192.0.2.1 80
Connection to 192.0.2.1 80 port [tcp/http] succeeded!
[nc hangs here until I Ctrl-C it]

When Rethink is paused or stopped, the same command hangs without any output.

I get similar results trying to connect to a valid address on a port it's not listening on. Through Rethink, it does the same thing as above. Without Rethink:

$ nc -v some-server.example 12345
nc: connect to some-server.example (198.51.100.42) port 12345 (tcp) failed: Connection refused
$ 

This part doesn't look like an ICMP thing - it's almost like some part of the firewall (netstack?) is spoofing the SYN/ACK part of the TCP handshake for some reason.

[ignoramous]

Yeah, SYN/ACK are spoofed (as an optimization), and if there's no route, then a RST must be sent. Or so, I think. See also: https://github.com/tailscale/tailscale/issues/9480

[ignoramous]

We've implement a reconstructed ICMPv4 echo (over UDP) in v054c (commit) that is now live on both F-Droid and the Google Play Store. It works just fine in my experiments.

For ICMPv6, unfortunately something is broken in the network engine we use (gVisor/netstack); it doesn't forward any v6 echo packets (like it does for v4). Unsure why.