Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I'm scratching my head about this question... I have a debian squeeze machine that is connected to an internal lab network. We have a lot of machines that have default proxy-arp configurations on them, and occasionally one of those machines starts hijacking a lot of lab addresses.

After resolving the latest Proxy-ARP incident which brought down most of our lab, I found a few residual entries like this in /var/log/syslog (below). For those not accustomed to reading arpwatch logs, the machine that owns 00:11:43:d2:68:65 is fighting with and about who owns those address.

Sep 13 14:25:27 netwiki arpwatch: flip flop 00:11:43:d2:68:65 (84:2b:2b:4b:71:b4) eth0
Sep 13 14:26:24 netwiki arpwatch: flip flop 84:2b:2b:4b:71:b4 (00:11:43:d2:68:65) eth0
Sep 13 14:29:03 netwiki arpwatch: flip flop 00:26:b9:4e:d3:71 (00:11:43:d2:68:65) eth0
Sep 13 14:29:03 netwiki arpwatch: flip flop 00:11:43:d2:68:65 (00:26:b9:4e:d3:71) eth0

The very alarming thing is that 00:11:43:d2:68:65 belongs to the same machine I was running arpwatch on... First, I validated that /proc/sys/net/ipv4/conf/eth0/proxy_arp is 0. Next, I used tshark to validate that my machine really is spoofing ARPs to others...

[mpenning@netwiki ~]$ ip addr show eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 00:11:43:d2:68:65 brd ff:ff:ff:ff:ff:ff
    inet brd scope global eth0
    inet6 fe80::211:43ff:fed2:6865/64 scope link
       valid_lft forever preferred_lft forever
[mpenning@netwiki ~]$
[mpenning@netwiki ~]$ arp -an
? ( at 00:15:c5:f5:81:9d [ether] on eth0
? ( at 00:1e:c9:cd:46:c8 [ether] on eth0
? ( at 00:1e:49:11:fe:47 [ether] on eth1
? ( at f0:4d:a2:02:81:66 [ether] on eth0
[mpenning@netwiki ~]$ cat /proc/sys/net/ipv4/conf/eth0/proxy_arp
[mpenning@netwiki ~]$ sudo tshark -i eth0 arp and ether src 00:11:43:d2:68:65
Running as user "root" and group "root". This could be dangerous.
Capturing on eth0
  0.000000 Dell_d2:68:65 -> Dell_02:81:66 ARP is at 00:11:43:d2:68:65
 84.954989 Dell_d2:68:65 -> Dell_f5:81:9d ARP is at 00:11:43:d2:68:65
[mpenning@netwiki ~]$ uname -a
Linux netwiki 2.6.32-5-amd64 #1 SMP Tue Jun 14 09:42:28 UTC 2011 x86_64 GNU/Linux
[mpenning@netwiki ~]$

The facts are undeniable. I have a debian box that is spoofing ARPs and I have no idea why. I am the only user on this machine, I run fail2ban to prevent brute-force attacks, and it's on an internal lab network behind a door that requires a badge for entry; I highly doubt it has been hacked.

Three questions...

  1. First, is there any cause I may have missed? What steps should I use to isolate whether this is an application or kernel problem?
  2. If this is a kernel bug, which mailing-list should I report it on? FYI, the normal kernel.org bug reporting tool seems to be down right now.
  3. Is there anything I can do to to solve the problem other than waiting for a patch?
share|improve this question
up vote 3 down vote accepted

I found the problem... I was demonstrating how proxy-arp worked on a spare ethernet interface a few weeks ago and left the configs on the machine (although I had the interface DOWN).

When I removed these entries for from eth2, I no longer had the problem.

[mpenning@netwiki ~]$ ip add show eth2
4: eth2: <BROADCAST,MULTICAST,PROMISC> mtu 1500 qdisc mq state DOWN qlen 1000
    link/ether 00:10:18:02:32:86 brd ff:ff:ff:ff:ff:ff
    inet scope global eth2
    inet scope global eth2
    inet scope global secondary eth2
    inet scope global secondary eth2
    inet scope global secondary eth2
    inet scope global secondary eth2
    inet scope global secondary eth2
[mpenning@netwiki ~]$

I still think this is a bug and it needs to be filed. I will update with the bug information when it is completed.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.