Gratuitous arping fails and causes pipework to return 1

[kmanna]

The set -e option causes pipework to return 1 after the gratuitous arping fails. My system fails to get an arping reply when running the following manually (copied from set -ex output of pipework):

ip netns exec 7703 arping -A -c 1 -I eth1 192.168.20.2

Tcpdump on the parent interface and remote hosts across a real switch shows the request, but no reply. When I run the arping on the host's parent device the following succeeds:

arping -c 1 -I vlan20 192.168.20.2

Anyone else seeing this?

For reference pipework invocation is as follows on Ubuntu 14.04:

pipework vlan20 <container> 192.168.20.2/24

[kmanna]

It appears that Linux (Ubuntu 14.04) doesn't want to reply to ARPs to itself. Is there an arp filtering or loopback option somewhere?

Consider the following where the first succeeds by lying about the source IP and the second is the same problem re-created on native Linux (no docker containers/net namespaces):

$ sudo arping -v -c 1 -I vlan20 -S 192.168.20.20 192.168.20.2
This box:   Interface: vlan20  IP: 192.168.20.1   MAC address: 84:2b:2b:b0:fe:d5
ARPING 192.168.20.2
42 bytes from 4a:dd:04:11:36:0a (192.168.20.2): index=0 time=1.001 sec

--- 192.168.20.2 statistics ---
1 packets transmitted, 1 packets received,   0% unanswered (0 extra)

$ sudo arping -v -c 1 -I vlan20 -S 192.168.20.2 192.168.20.2
This box:   Interface: vlan20  IP: 192.168.20.1   MAC address: 84:2b:2b:b0:fe:d5
ARPING 192.168.20.2

--- 192.168.20.2 statistics ---
1 packets transmitted, 0 packets received, 100% unanswered (0 extra)

Host 192.168.20.2 is the docker veth interface attached to linux bridge vlan20. Vlan20 is in turn trunked to a managed switch.

Can anyone confirm that pipework returns 0 status code?

[kmanna]

related to #59

[jpetazzo]

I believe that this was fixed in 4400d733da36facac2b160cf5a6064a8ad3fbf2a.