ICMP echo reply breaks wifi p2p DHCP association

[timespace314]

With Block when source app is unknown -> on ICMP echo request are still replied.

# From phone running rethink
$ ping 1.1.1.1
PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data.
64 bytes from 1.1.1.1: icmp_seq=1 ttl=64 time=8.29 ms
64 bytes from 1.1.1.1: icmp_seq=2 ttl=64 time=12.5 ms
64 bytes from 1.1.1.1: icmp_seq=3 ttl=64 time=10.4 ms
64 bytes from 1.1.1.1: icmp_seq=4 ttl=64 time=9.74 ms
64 bytes from 1.1.1.1: icmp_seq=5 ttl=64 time=11.9 ms
64 bytes from 1.1.1.1: icmp_seq=6 ttl=64 time=11.4 ms
64 bytes from 1.1.1.1: icmp_seq=7 ttl=64 time=13.9 ms
64 bytes from 1.1.1.1: icmp_seq=8 ttl=64 time=10.9 ms
64 bytes from 1.1.1.1: icmp_seq=9 ttl=64 time=11.8 ms
64 bytes from 1.1.1.1: icmp_seq=10 ttl=64 time=12.5 ms
^C
--- 1.1.1.1 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 9014ms
rtt min/avg/max/mdev = 8.299/11.375/13.983/1.526 ms

I guess these are fake replies from netstack cuz I dont see any ICMP packet while running tcpdump on router. During connection establishment between two android phone using WIFI Direct (p2p), android seems to ping all host in DHCP range to check for ip availability. udp port 67-68 are using different route table I believe. So, only ICMP are captured by rethink tunnel which is fine.

Rethink logcat pcap capture.txt

So, these fake ICMP Echo reply from network engine is breaking DHCP association as it makes all host available. As, it cannot get any ip address WIFI Direct disconnects and makes it completely unusable.

dnsmasq fails with no address available.

# adb logcat -s dnsmasq
07-06 13:25:26.479 16367 16367 I dnsmasq : started, version 2.51 cachesize 150
07-06 13:25:26.479 16367 16367 I dnsmasq : compile time options: IPv6 GNU-getopt no-I18N DHCP no-scripts
07-06 13:25:26.479 16367 16367 W dnsmasq : warning: no upstream servers configured
07-06 13:25:26.480 16367 16367 I dnsmasq : DHCP, IP range 192.168.49.100 -- 192.168.49.199, lease time 1h
07-06 13:25:26.480 16367 16367 I dnsmasq : read /etc/hosts - 2 addresses
07-06 13:25:26.480 16367 16367 I dnsmasq : Closing wildcard listener family=2
07-06 13:25:26.481 16367 16367 I dnsmasq : Closing wildcard listener family=10
07-06 13:26:59.895 16367 16367 I dnsmasq : DHCPDISCOVER(p2p-wlan0-0) F6:1D:ED:89:F2:45 no address available
07-06 13:27:04.756 16367 16367 I dnsmasq : DHCPDISCOVER(p2p-wlan0-0) F6:1D:ED:89:F2:45 no address available

Is it possible to just not reply at all ? Are fake ICMP echo reply really necessary ?

[ignoramous]

Is it possible to just not reply at all?

Unsure, but I'll take a look.

Are fake ICMP echo reply really necessary?

Some reply is needed by the API (or at least as I remember it).

[funkypunkyz]

So, these fake ICMP Echo reply from network engine is breaking DHCP association as it makes all host available.

Does Rethink reply with "fake ICMP" packets - and if so, why? Would be curious to get more information.

Possibly related: ping and nmap with Termux are basically useless, as they report all hosts being up/online:

$ ping 192.168.1.200 # there is no running host here
PING 192.168.1.200
64 bytes from 192.168.1.200: icmp_seq=1 ttl=64 time=13.6ms
...

nmap -sn 192.168.1.0/24
Nmap scan report for 192.168.1.1
Host is up.
...
Nmap scan report for 192.168.1.200
Host is up.
...

Environment: Using Rethink v0.5.5n in VPN lockdown mode. Disabling VPN lockdown mode will change to expected network monitoring behavior.

[ignoramous]

Does Rethink reply with "fake ICMP" packets - and if so, why?

It should not, but our ICMP (echo) handling is currently totally broken, that's why.

Disabling VPN lockdown mode will change to expected network monitoring behavior.

Strange. It in fact should not change behaviour with respect to ICMP Echo?

[funkypunkyz]

Strange. It in fact should not change behaviour with respect to ICMP Echo?

Ah, you're right. I probably forgot to re-enable Rethink at one test step, after having disabled VPN lockdown mode before. Hence my perception is, Rethink always disturbs output of ICMP-related commands like ping and nmap independent of lockdown mode choice.

It should not, but our ICMP (echo) handling is currently totally broken, that's why.

Honest statement :-), appreciated. At least we know, what is the cause now and what is to be improved.