ICMP replies seen by tcpdump but ping 100% fails

Question

I have a virtual interface (oip1) configured which has a valid IP config. When I try to ping an address on the internet from oip1, I can see the ICMP echo requests/replies on tcpdump, but ping still reports 100% failing.

root@openair-PC:~/openair4G# ifconfig oip1
      oip1      Link encap:AMPR NET/ROM  HWaddr   
      inet addr:192.188.0.2  Bcast:192.188.0.255  Mask:255.255.255.0
      UP BROADCAST RUNNING NOARP MULTICAST  MTU:1500  Metric:1
      RX packets:10 errors:0 dropped:0 overruns:0 frame:0
      TX packets:10 errors:0 dropped:0 overruns:0 carrier:0
      collisions:0 txqueuelen:100 
      RX bytes:840 (840.0 B)  TX bytes:840 (840.0 B)

I've created a new table "lte":

root@openair-PC:~/openair4G# ip rule show
0:  from all lookup local 
32743:  from all fwmark 0x1 lookup lte 
32766:  from all lookup main 
32767:  from all lookup default

Thus, I'm marking packets to/from oip1 address:

root@openair-PC:~/openair4G# iptables -t mangle -L
Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination         
MARK       all  --  anywhere             192.188.0.0/24       MARK set 0x1

Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         
MARK       all  --  192.188.0.0/24       anywhere             MARK set 0x1

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination

Then, I added a default gateway for table "lte":

root@openair-PC:~/openair4G# ip route show table lte
default dev oip1  scope link

ping result:

openair@openair-PC:~/openair4G/cmake_targets$ ping -c 5 -I oip1 8.8.8.8
PING 8.8.8.8 (8.8.8.8) from 192.188.0.2 oip1: 56(84) bytes of data.
^C
--- 8.8.8.8 ping statistics ---
5 packets transmitted, 0 received, 100% packet loss, time 3999ms

tcpdump screen:

openair@openair-PC:~/openair4G$ sudo tcpdump -p -i oip1
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on oip1, link-type LINUX_SLL (Linux cooked), capture size 65535 bytes
17:19:10.576680 IP 192.188.0.2 > google-public-dns-a.google.com: ICMP echo request, id 20987, seq 1, length 64
17:19:11.021851 IP google-public-dns-a.google.com > 192.188.0.2: ICMP echo reply, id 20987, seq 1, length 64
17:19:11.576617 IP 192.188.0.2 > google-public-dns-a.google.com: ICMP echo request, id 20987, seq 2, length 64
17:19:11.752243 IP google-public-dns-a.google.com > 192.188.0.2: ICMP echo reply, id 20987, seq 2, length 64
17:19:12.576583 IP 192.188.0.2 > google-public-dns-a.google.com: ICMP echo request, id 20987, seq 3, length 64
17:19:12.676980 IP google-public-dns-a.google.com > 192.188.0.2: ICMP echo reply, id 20987, seq 3, length 64
17:19:13.576559 IP 192.188.0.2 > google-public-dns-a.google.com: ICMP echo request, id 20987, seq 4, length 64
17:19:13.767922 IP google-public-dns-a.google.com > 192.188.0.2: ICMP echo reply, id 20987, seq 4, length 64
17:19:14.576561 IP 192.188.0.2 > google-public-dns-a.google.com: ICMP echo request, id 20987, seq 5, length 64
17:19:15.097164 IP google-public-dns-a.google.com > 192.188.0.2: ICMP echo reply, id 20987, seq 5, length 64
^C
10 packets captured
10 packets received by filter
0 packets dropped by kernel

As you can see, all packets can be seen by tcpdump.

Does anyone have an idea about this ? Best regards,

This can also happen if you you have a bad route on your computer and even if you have rp_filter off. For example if you do a ping -I eth0 192.168.1.1 the packets will show in tcpdump but may end up on the wrong incoming interface and therefore no reply to the client will be shown. — Areeb Soo Yasir, Mar 25 '19 at 18:24

score 6 · Accepted Answer · answered Aug 20 '15 at 18:56

6

I finally solved this. It was cause by rp_filter activated on the concerned interface and on all the system as well. I disabled it with: sysctl -w net.ipv4.conf.all.rp_filter=0 (replace all with the interface also).

answered Aug 20 '15 at 18:56

Spider

875
2
9
27

score 6 · Answer 2 · answered Aug 25 '15 at 12:20

This could have been caused by the reverse-path-filtering done by kernel. This is likely to occur if you are doing things like proxy-arp in the next hop. The system thinks that the packet received is a spoofed one (if the reverse-path-filtering is enabled) and drops it.

Obvious (but not suggested) way is to disable the reverse-path-filtering. Another way is to set the default gateway in the host for the pinged IP, through the intended interface.

ICMP replies seen by tcpdump but ping 100% fails

2 Answers2