virtual - ICMP replies seen by tcpdump but ping 100% fails -


i have virtual interface (oip1) configured has valid ip config. when try ping address on internet oip1, can see icmp echo requests/replies on tcpdump, 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       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 new table "lte":

root@openair-pc:~/openair4g# ip rule show 0:  lookup local  32743:  fwmark 0x1 lookup lte  32766:  lookup main  32767:  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        --  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        --  192.188.0.0/24       anywhere             mark set 0x1  chain postrouting (policy accept) target     prot opt source               destination 

then, added default gateway 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) 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 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 filter 0 packets dropped kernel 

as can see, packets can seen tcpdump.

does have idea ? best regards,

this have been caused reverse-path-filtering done kernel. occur if doing things proxy-arp in next hop. system thinks packet received spoofed 1 (if reverse-path-filtering enabled) , drops it.

obvious (but not suggested) way disable reverse-path-filtering. way set default gateway in host pinged ip, through intended interface.


Comments

Popular posts from this blog

html - Firefox flex bug applied to buttons? -

html - Missing border-right in select on Firefox -

python - build a suggestions list using fuzzywuzzy -