duplicate ICMP response packets?

Jay Libove <[email protected]>
Newsgroups gmane.linux.network.bridge.ebtables.user
Message-ID <[email protected]>
Thanks again to those who helped me get my curious external proxy ARP
configuration working last month.

I have noticed something since then:  I have a couple of PING processes
set up to monitor reliability of my Internet connection (one PINGs the
access device at the immediate other end of my DSL line, and the other
PINGs the next hop outside of the local POP, to help isolate problems to
either the line itself or something more in the ISP's core).  Since I put
my bridge configuration in place to allow an unaddressed ethernet
interface to receive and respond to ARPs, my two PINGs are getting
duplicate answers for every packet sent.  Here's one of the regular emails
I get from the processes:

> From [email protected] Fri May 27 15:59:57 2005
> Date: Fri, 27 May 2005 15:59:56 -0400
> From: Cron Daemon <[email protected]>
> To: [email protected]
> Subject: Cron <root@panther7> /usr/local/bin/ISP-ping.sh 4
>
> Fri May 27 15:59:56 EDT 2005 gate [216.27.163.1]:   --- 216.27.163.1 ping statistics ---
> 2868 packets transmitted, 2868 received, +2865 duplicates, 0% packet loss, time 14334611ms
> rtt min/avg/max/mdev = 12.792/17.115/414.140/13.008 ms, pipe 2
> Fri May 27 15:59:56 EDT 2005 uplink [69.17.82.170]: --- 69.17.82.170 ping statistics ---
> 2868 packets transmitted, 2868 received, +2866 duplicates, 0% packet loss, time 14334598ms
> rtt min/avg/max/mdev = 25.212/29.949/426.481/9.366 ms, pipe 2


Here's a live example:
[root@panther7 hde4]# ping -c 2 216.27.163.1
PING 216.27.163.1 (216.27.163.1) 56(84) bytes of data.
64 bytes from 216.27.163.1: icmp_seq=0 ttl=127 time=16.7 ms
64 bytes from 216.27.163.1: icmp_seq=0 ttl=126 time=17.0 ms (DUP!)
64 bytes from 216.27.163.1: icmp_seq=1 ttl=127 time=13.9 ms

--- 216.27.163.1 ping statistics ---
2 packets transmitted, 2 received, +1 duplicates, 0% packet loss, time 1000ms
rtt min/avg/max/mdev = 13.965/15.911/17.059/1.383 ms, pipe 2

Of course the second packet had the dup also, just PING did not wait
around for it to arrive.


tcpdump on all network interfaces (including the br0 interface) fails to
see the duplicate packet.  This makes me wonder if the presence of the
bridge is causing the packet to be processed twice?  (This of course might
also mean that EVERY packet is being processed twice, and it is only PING
which makes it so easy to see; clearly, that would be an unnecessary CPU
load which I'd like to fix).

Any suggestions on this?


Here is some information about the host config:
# ifconfig -a
br0       Link encap:Ethernet  HWaddr 00:00:BC:11:46:AD
           inet6 addr: fe80::200:bcff:fe11:46ad/64 Scope:Link
           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
           RX packets:196840 errors:0 dropped:0 overruns:0 frame:0
           TX packets:5 errors:0 dropped:0 overruns:0 carrier:0
           collisions:0 txqueuelen:0
           RX bytes:31787831 (30.3 MiB)  TX bytes:378 (378.0 b)

# eth0 is the outer pointing interface going to a hub segment
# between the firewall and the Voice Over IP adaptor's inside
# interface
eth0      Link encap:Ethernet  HWaddr 00:D0:09:72:81:95
           inet addr:216.27.163.42  Bcast:216.27.163.255  Mask:255.255.255.0
           inet6 addr: fe80::2d0:9ff:fe72:8195/64 Scope:Link
           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
           RX packets:6877005 errors:0 dropped:0 overruns:0 frame:0
           TX packets:8317310 errors:0 dropped:0 overruns:0 carrier:0
           collisions:90451 txqueuelen:1000
           RX bytes:2097294315 (1.9 GiB)  TX bytes:1104492545 (1.0 GiB)
           Interrupt:10 Base address:0xe000

# this alias is to make it possible to communicate with the
# Voice Over IP adaptor which is wired to 192.168.15.1
# (Linksys RT31P2)
eth0:1    Link encap:Ethernet  HWaddr 00:D0:09:72:81:95
           inet addr:192.168.15.2  Bcast:192.168.15.255  Mask:255.255.255.0
           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
           Interrupt:10 Base address:0xe000

# this is the general internal interface for my network
eth1      Link encap:Ethernet  HWaddr 00:00:BC:11:46:AF
           inet addr:192.168.255.2  Bcast:192.168.255.127  Mask:255.255.255.128
           inet6 addr: fe80::200:bcff:fe11:46af/64 Scope:Link
           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
           RX packets:11237894 errors:0 dropped:0 overruns:0 frame:0
           TX packets:10272337 errors:8 dropped:0 overruns:3 carrier:14
           collisions:1343169 txqueuelen:1000
           RX bytes:3590318877 (3.3 GiB)  TX bytes:1492199406 (1.3 GiB)
           Interrupt:7 Base address:0x8000

# this is another internal interface- it goes to a wireless net
eth2      Link encap:Ethernet  HWaddr 00:00:BC:11:46:AE
           inet addr:192.168.254.1  Bcast:192.168.254.255  Mask:255.255.255.0
           inet6 addr: fe80::200:bcff:fe11:46ae/64 Scope:Link
           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
           RX packets:910226 errors:0 dropped:0 overruns:0 frame:0
           TX packets:516123 errors:4 dropped:0 overruns:0 carrier:10
           collisions:4 txqueuelen:1000
           RX bytes:1207672258 (1.1 GiB)  TX bytes:36905953 (35.1 MiB)
           Interrupt:5 Base address:0xa000

# this has no IP address; it is "up"; it is the physical interface
# associated with bridge device br0
eth3      Link encap:Ethernet  HWaddr 00:00:BC:11:46:AD
           inet6 addr: fe80::200:bcff:fe11:46ad/64 Scope:Link
           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
           RX packets:15423210 errors:2 dropped:0 overruns:0 frame:1
           TX packets:186 errors:3 dropped:0 overruns:0 carrier:6
           collisions:1 txqueuelen:1000
           RX bytes:3257791284 (3.0 GiB)  TX bytes:7868 (7.6 KiB)
           Interrupt:10 Base address:0xc000

# this is not up
eth4      Link encap:Ethernet  HWaddr 00:00:BC:11:46:AC
           BROADCAST MULTICAST  MTU:1500  Metric:1
           RX packets:0 errors:0 dropped:0 overruns:0 frame:0
           TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
           collisions:0 txqueuelen:1000
           RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)
           Interrupt:11 Base address:0xe000

lo        Link encap:Local Loopback
           inet addr:127.0.0.1  Mask:255.0.0.0
           inet6 addr: ::1/128 Scope:Host
           UP LOOPBACK RUNNING  MTU:16436  Metric:1
           RX packets:6962 errors:0 dropped:0 overruns:0 frame:0
           TX packets:6962 errors:0 dropped:0 overruns:0 carrier:0
           collisions:0 txqueuelen:0
           RX bytes:782845 (764.4 KiB)  TX bytes:782845 (764.4 KiB)

sit0      Link encap:IPv6-in-IPv4
           NOARP  MTU:1480  Metric:1
           RX packets:0 errors:0 dropped:0 overruns:0 frame:0
           TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
           collisions:0 txqueuelen:0
           RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)

# OpenVPN 1
tun0      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
           inet addr:192.168.253.1  P-t-P:192.168.253.2  Mask:255.255.255.255
           UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
           RX packets:24031 errors:0 dropped:0 overruns:0 frame:0
           TX packets:22013 errors:0 dropped:0 overruns:0 carrier:0
           collisions:0 txqueuelen:100
           RX bytes:5367747 (5.1 MiB)  TX bytes:4972830 (4.7 MiB)

# OpenVPN 2
tun1      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
           inet addr:192.168.253.129  P-t-P:192.168.253.130  Mask:255.255.255.255
           UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
           RX packets:0 errors:0 dropped:0 overruns:0 frame:0
           TX packets:1 errors:0 dropped:0 overruns:0 carrier:0
           collisions:0 txqueuelen:100
           RX bytes:0 (0.0 b)  TX bytes:40 (40.0 b)


ebtables configuration:
# ebtables -L
Bridge table: filter

Bridge chain: INPUT, entries: 0, policy: ACCEPT

Bridge chain: FORWARD, entries: 0, policy: DROP

Bridge chain: OUTPUT, entries: 0, policy: ACCEPT


# ebtables -t nat -L
Bridge table: nat

Bridge chain: PREROUTING, entries: 9, policy: ACCEPT
-p ARP -i eth3 --arp-op Request --arp-ip-dst 216.27.163.42 -j arpreply --arpreply-mac 0:13:10:75:88:f5
-p ARP -i eth3 --arp-op Request --arp-ip-dst 216.27.163.44 -j arpreply --arpreply-mac 0:13:10:75:88:f5
-p ARP -i eth3 --arp-op Request --arp-ip-dst 216.27.163.45 -j arpreply --arpreply-mac 0:13:10:75:88:f5
-p ARP -i eth3 --arp-op Request --arp-ip-dst 216.27.163.46 -j arpreply --arpreply-mac 0:13:10:75:88:f5
-p ARP -i eth3 --arp-op Request --arp-ip-dst 216.27.163.47 -j arpreply --arpreply-mac 0:13:10:75:88:f5
-p ARP -i eth3 --arp-op Request --arp-ip-dst 216.27.163.48 -j arpreply --arpreply-mac 0:13:10:75:88:f5
-p ARP -i eth3 --arp-op Request --arp-ip-dst 216.27.163.49 -j arpreply --arpreply-mac 0:13:10:75:88:f5
-p ARP -i eth3 --arp-op Request --arp-ip-dst 216.27.163.50 -j arpreply --arpreply-mac 0:13:10:75:88:f5
-p ARP -i eth3 --arp-op Request --arp-ip-dst 216.27.163.51 -j arpreply --arpreply-mac 0:13:10:75:88:f5

Bridge chain: OUTPUT, entries: 0, policy: ACCEPT

Bridge chain: POSTROUTING, entries: 0, policy: ACCEPT



Thanks!
-Jay




-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.  How far can you shotput
a projector? How fast can you ride your desk chair down the office luge track?
If you want to score the big prize, get to know the little guy.  
Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.