Closed xandercrews closed 10 years ago
Sorry for the slow response. Can you try to remove >/dev/null >&1
to see the error message in that case?
Thank you!
no problem, of course.
so, i think what i was wondering was if arping ever receives replies querying against the ip address that was assigned in that net namespace:
=======8<========
(the ip has been set to 10.249.0.98/24 for eth1 in that interface, by pipework)
$ sudo ip netns exec 4068 ip addr
...
230: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
link/ether 66:cc:42:a8:8b:e7 brd ff:ff:ff:ff:ff:ff
inet 10.249.0.98/24 scope global eth1
valid_lft forever preferred_lft forever
(the arping proceeds as follows) $ sudo ip netns exec 4068 arping -c 1 -A -I eth1 10.249.0.98; echo rc: $? ARPING 10.249.0.98
--- 10.249.0.98 statistics --- 1 packets transmitted, 0 packets received, 100% unanswered (0 extra) rc: 1 =======8<========
when i assign an address to the bridge and arping it, i can't get a reply from it either with arping -A:
=======8<======== $ sudo ip netns exec 4068 arping -c 1 -A -I eth1 10.249.0.254; echo rc: $? ARPING 10.249.0.254
--- 10.249.0.254 statistics --- 1 packets transmitted, 0 packets received, 100% unanswered (0 extra) rc: 1 =======8<========
but when i remove the -A option i can get a reply from that bridge, and other hosts:
=======8<======== $ sudo ip netns exec 4068 arping -c 1 -I eth1 10.249.0.254; echo rc: $? ARPING 10.249.0.254 42 bytes from 22:76:9c:fd:4d:e0 (10.249.0.254): index=0 time=11.522 usec
--- 10.249.0.254 statistics --- 1 packets transmitted, 1 packets received, 0% unanswered (0 extra) rc: 0 =======8<========
.. but still not from the interface which is local to that namespace
=======8<======== $ sudo ip netns exec 4068 arping -c 1 -I eth1 10.249.0.98; echo rc: $? ARPING 10.249.0.98
--- 10.249.0.98 statistics --- 1 packets transmitted, 0 packets received, 100% unanswered (0 extra) rc: 1 =======8<========
i modify pipework with | /bin/true on this arping line so -e will not catch this always non-zero return code from the arping, and i can distinguish this failure from others when using it in scripts. i don't know what the intention was, but you might do the same if you don't care about the arping reply, which has presumably done its job per the code comments for having been sent ("# Give our ARP neighbors a nudge about the new interface"). hth
i have to learn not to hit that close c-c-c-combo button =/
I guess arping will just return an error if nobody replies (which could be the case if there is nobody on the container's network).
Anyway that was fixed in 4400d733da36facac2b160cf5a6064a8ad3fbf2a :-)
i've not found a situation where this arping won't cause the script run with -e to catch the non-zero return code from arping and exit with a non-zero code (i.e. pipework will always return 1 for me when it works):
ip netns exec $NSPID arping -c 1 -A -I $CONTAINER_IFNAME $IPADDR > /dev/null 2>&1
does it work differently / return 0 for you?