arping fails to set correct broadcast address (it's not working at all)

[Kasper F. Brandt]

Binary package hint: iputils-arping

This bug prevents the arping utility from iputils-arping from detecting any host as online due to the broadcast ARP requests being sent to an invalid address. There is currently no feasable work-around for the users, as the iputils-arping package is required by network-manager and so installing the arping package would break network managers dependencies.

This is a regression in Ubuntu 10.10 from Ubuntu 10.04.

TEST CASE: arping any online and reachable host in the local subnet, that is not currently in the arp cache. You should receive arp replies.
TEST CASE: arp -d IP; arping -b IP

This bug has been fixed upstream in [1] and in Natty (3:20100418-3ubuntu1).

The bug reported here http://kerneltrap.org/mailarchive/linux-netdev/2010/8/13/6282972 is present in the current version of iputils-arping in 10.10 (iputils-sss20100418).

The bug occured on ubuntu 10.10:
poizan@poilap:~$ apt-cache policy iputils-arping
iputils-arping:
  Installed: 3:20100418-2ubuntu1
  Candidate: 3:20100418-2ubuntu1
  Version table:
 *** 3:20100418-2ubuntu1 0
        500 http://dk.archive.ubuntu.com/ubuntu/ maverick/main i386 Packages
        100 /var/lib/dpkg/status

poizan@poilap:~$ (sudo arping 10.10.100.164 &); sudo tcpdump -i eth0 ether proto \\arp and src host 10.10.100.164
ARPING 10.10.100.164 from 10.10.100.164 eth0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
22:54:48.299544 ARP, Request who-has poilap (ff:1f:ff:22:00:a4 (oui Unknown)) tell poilap, length 28
22:54:48.415587 ARP, Request who-has poilap (ff:1f:ff:22:00:a4 (oui Unknown)) tell poilap, length 28
22:54:48.415698 ARP, Request who-has poilap (ff:1f:ff:22:00:a4 (oui Unknown)) tell poilap, length 28
22:54:48.415887 ARP, Request who-has poilap (ff:1f:ff:22:00:a4 (oui Unknown)) tell poilap, length 28

I expected to see ff:ff:ff:ff:ff:ff / Broadcast instead of ff:1f:ff:22:00:a4 as the destination for the arp requests.

[1] http://www.linux-ipv6.org/gitweb/gitweb.cgi?p=gitroot/iputils.git;a=commitdiff;h=c5ccadd1f5251400d7f8382cd39f45e68940033c"

[Vincent Law (vincentlaw)]

Hi,
I was wondering if someone had tested the arping tool with the given patch on kernel trap mailing list ?
Is this patch corrects the indicated bug ?
If so, is it planned for the iputils maverick package to be updated soon ?

Thank you

[Vincent Law (vincentlaw)]

Ok, I answer to myself :-)
I've just downloaded, compiled and tested the latest iputils sources from http://www.skbuff.net/iputils/
I can confirm that the patched version of arping works better than the one provided in maverick release

[Timur Irmatov (irmatov)]

Yes, I also confirm that arping from iputils-s20101006.tar.bz2 works while included with maverick doesn't.

[Alexandr Zvezdin (alexandrzvezdin)]

00:e0:4c:86:08:10 - this is my hwaddr
ff:e0:ff:86:00:10 - this is broadcast address, assigned by arping

Something wrong with bit masking I guess.

tcpdump :

14:25:08.580648 00:e0:4c:86:08:10 > ff:e0:ff:86:00:10, ethertype ARP (0x0806), length 42: Request who-has 192.168.184.1 (ff:e0:ff:86:00:10) tell 192.168.184.146, length 28
 0x0000: ffe0 ff86 0010 00e0 4c86 0810 0806 0001
 0x0010: 0800 0604 0001 00e0 4c86 0810 c0a8 b892
 0x0020: ffe0 ff86 0010 c0a8 b801

[AZ (m-dev)]

The attached patch fixes the problem. Somehow the loop copying the broadcast address has its counters incremented twice: ch +=3 and used *3, p++ is in the for loop and in the assignment.

To use this patch, do the following:

apt-get source iputils-arping
apt-get build-dep iputils-arping
cd iputils-20100418
patch < fix-wrong-broadcast.diff
dpkg-buildpackage -a
dpkg -i ../iputils-arping*.deb

[AZ (m-dev)]

This has been fixed upstream in commit "arping: Set correct broadcast address.", c5ccadd1f5251400d7f8382cd39f45e68940033c.

http://www.linux-ipv6.org/gitweb/gitweb.cgi?p=gitroot/iputils.git;a=commitdiff;h=c5ccadd1f5251400d7f8382cd39f45e68940033c"

[Mathieu Trudel-Lapierre (cyphermox)]

Thank you for taking the time to report this bug and helping to make Ubuntu better. However, I am closing it because the bug has been fixed in the latest development version of Ubuntu - Natty Narwhal.

This is a significant bug in Ubuntu. If you need a fix for the bug in previous versions of Ubuntu, please do steps 1 and 2 of the SRU Procedure [1] to bring the need to a developer's attention.

[1]: https://wiki.ubuntu.com/StableReleaseUpdates#Procedure

I've also marked this as 'patch-accepted-upstream' since the patch made it there.

[AZ (m-dev)]

for SRU:
* impact of this bug: arping is unusable, it reports all hosts as offline.
* it has been adressed by fixing the copy procedure for destination (broadcast) mac
* the attached patch is minimal

There is no workaround for users as the arping package conflicts iputils-arping, which is required by network manager and in the end required by ubuntu-desktop.

[AZ (m-dev)]

I've verified that the current ubuntu 10.10 iputils-arping package with the patch attched fixes the problem.

[AZ (m-dev)]

I've verified this can be fixed by installing natty iputils-arping package in maverick.

[Mathieu Trudel-Lapierre (cyphermox)]

Wow, awesome work there AZ.

I'll put together an updated package to SRU now.

[Mathieu Trudel-Lapierre (cyphermox)]

Noticed though that you did create a package to test the patch with, so I should give you the opportunity to contribute your work directly to Ubuntu.

Do you want to work on updating the packaging yourself? It should be pretty easy if you take the lp:ubuntu/iputils-arping branch and add the patch there, or using "apt-get source iputils-arping" and applying the patch (though then we would need a debdiff).

Please just let me know how you want to proceed there, and don't hesitate to ask me on IRC for help if needed.

[AZ (m-dev)]

Hi,

I used edit-patch from ubuntu-dev-tools to add a patch "fix-broadcast" that does exactly this one line change and then build the package using dpkg-buildpackage -S . The resulting source package has been built using pbuilder and installed, I've verified that the new package fixes the issue, so I've added a Closes: #664165 tag to the changelog.

I hope the debdiff is fine this way.

[AZ (m-dev)]

fix the ## comments in the patch file.

[Mathieu Trudel-Lapierre (cyphermox)]

It looks perfect to me. The only issue is that it should be a (LP: #664165) rather than (Closes: 664165) for Ubuntu. The DEP-3 patch tags don't need to be commented when using quilt, but I wouldn't block the patch for that.

Nominating this bug for Maverick, and subscribing ubuntu-sru.

As there's already a debdiff ready for upload, I'm also subscribing ubuntu-sponsors (I can't sponsor this patch myself).

[AZ (m-dev)]

address Closes: versus LP: issue