Description of problem: It seems the arping utility is incorrectly returning -1 received packets when run on top of an infiniband interface. [root@flopteron iputils]# !./arping ./arping -c 2 -w 3 -D -I ib0 192.168.0.62 ARPING 192.168.0.62 from 0.0.0.0 ib0 Sent 2 probes (2 broadcast(s)) Received -1 response(s) This causes the ifup script to think the address is already in use on the network. Version-Release number of selected component (if applicable): iputils-20020927-19 How reproducible: always this patch seems to fix at least the negative return. --- arping.c.orig 2005-03-02 15:29:50.820076282 -0800 +++ arping.c 2005-03-02 15:52:36.613692634 -0800 @@ -56,7 +56,7 @@ struct timeval start, last; int sent, brd_sent; -int received, brd_recv, req_recv; +int received = 0, brd_recv, req_recv; #define MS_TDIFF(tv1,tv2) ( ((tv1).tv_sec-(tv2).tv_sec)*1000 + \ ((tv1).tv_usec-(tv2).tv_usec)/1000 ) Now, I get: [root@flopteron iputils]# ./arping -c 2 -w 3 -D -I ib0 192.168.0.62 ARPING 192.168.0.62 from 0.0.0.0 ib0 Sent 2 probes (2 broadcast(s)) Received 0 response(s) Which allows ifup to continue.
Created attachment 111603 [details] patch to initilize received to 0
I've included the patch in rawhide version of iputils.
The patch I sent was bogus. This bug stemmed from a buffer overflow that was seen using fortified builds. I have opened a new bug 163383 which has a patch that really fixes the problem seen here. Please backout this patch and close this bug as invalid (or dup). thanks
Ok, I will replace your patch. Thanks for your input cos I don't have infiniband interface to test those issues on ...