[PATCH] net: Broadcast ARP packets on link local addresses

[PATCH] net: Broadcast ARP packets on link local addresses

[David Daney]

From: David Daney

Greetings,

When an internet host joins a network where there is no DHCP server,
it may auto-allocate an IP address by the method described in RFC
3927.  There are several user space daemons available that implement
most of the protocol (zcip, busybox, ...).  The kernel's APR driver
should function in the normal manner except that it is required to
broadcast all ARP packets that it originates in the link local address
space (169.254.0.0/16).  RFC 3927 section 2.5 explains the requirement.

The current ARP code is non-compliant because it does not broadcast
some ARP packets as required by RFC 3927.

This patch to net/ipv4/arp.c checks the source address of all ARP
packets and if the fall in 169.254.0.0/16, they are broadcast instead
of unicast.  I would like to thank Freek Dijkstra wrote the first
version of the patch.  He was kind enough to sign off on it in his
(off-list) e-mail to me:

>David Daney wrote:
>
>
>> For the linux kernel the requirements for contributing are quite easy.
>> All people who wrote the patch simply affirm that they are have the
>> right to contribute and that they are doing so.  See section 11 of
>> Documentation/SubmittingPatches in the kernel source tree.
>
>
> Just read. (a) and (d) apply (I wrote it, and I'm fine that you use it):
> Signed-off-by: Freek Dijkstra <freek@macfreek.nl>
>
.
.
.
>
> I hereby release the above patch in the public domain.
> (You may credit me or not, I don't think it's needed).
>
> Have fun.
> Freek

This patch is against 2.6.16.1 

Signed-off-by: David Daney <ddaney@avtrex.com>

---

--- net/ipv4/arp.c.orig	2006-03-31 13:44:50.000000000 -0800
+++ net/ipv4/arp.c	2006-03-31 13:48:26.000000000 -0800
@@ -682,6 +682,7 @@ void arp_send(int type, int ptype, u32 d
 	      unsigned char *target_hw)
 {
 	struct sk_buff *skb;
+	int lla;
 
 	/*
 	 *	No arp on this interface.
@@ -690,8 +691,13 @@ void arp_send(int type, int ptype, u32 d
 	if (dev->flags&IFF_NOARP)
 		return;
 
+	/* If link local address (169.254.0.0/16) we must broadcast
+         * the ARP packet.  See RFC 3927 section 2.5 for details.
+	 */
+	lla = (dest_ip & htonl(0xFFFF0000UL)) == htonl(0xA9FE0000UL);
+
 	skb = arp_create(type, ptype, dest_ip, dev, src_ip,
-			 dest_hw, src_hw, target_hw);
+			 lla ? NULL : dest_hw, src_hw, target_hw);
 	if (skb == NULL) {
 		return;
 	}

Re: [PATCH] net: Broadcast ARP packets on link local addresses

[Anand Kumria]

On Fri, 31 Mar 2006 15:26:00 -0800, David Daney wrote:

> From: David Daney
> 
> Greetings,
> 
> When an internet host joins a network where there is no DHCP server,
> it may auto-allocate an IP address by the method described in RFC
> 3927.  There are several user space daemons available that implement
> most of the protocol (zcip, busybox, ...).  The kernel's APR driver
> should function in the normal manner except that it is required to
> broadcast all ARP packets that it originates in the link local address
> space (169.254.0.0/16).  RFC 3927 section 2.5 explains the requirement.
> 
> The current ARP code is non-compliant because it does not broadcast
> some ARP packets as required by RFC 3927.

I haven't seem anyone comment on this, but it would be useful to see this
integrated.

If you have a bunch of Linux machines and two machines have the same
address allocated (not so impossible) they won't notice until they start
communicating with each other.

A third machine attempting to communicate with either party won't be able
to do so.  With this patch in place, overlapping assignments are noticed
much faster due to the broadcast.

Something else I've noticed while I've been implementing my zeroconf
daemon is that the kernel returns link-scoped primary addresses first to
'ifconfig'.  Unfortunately quite a lot of user-space programs parse its
output and interpret the address it presents as the primary for the
specified interface.

Is that a case of user-space breakage that the kernel team would
ordinarily worry about?

Thanks,
Anand

Re: [PATCH] net: Broadcast ARP packets on link local addresses

[jamal]

On Fri, 2006-07-04 at 17:20 +1000, Anand Kumria wrote:
> On Fri, 31 Mar 2006 15:26:00 -0800, David Daney wrote:
> 
> > From: David Daney
> > 
> > Greetings,
> > 
> > When an internet host joins a network where there is no DHCP server,
> > it may auto-allocate an IP address by the method described in RFC
> > 3927.  There are several user space daemons available that implement
> > most of the protocol (zcip, busybox, ...).  The kernel's APR driver
> > should function in the normal manner except that it is required to
> > broadcast all ARP packets that it originates in the link local address
> > space (169.254.0.0/16).  RFC 3927 section 2.5 explains the requirement.
> > 
> > The current ARP code is non-compliant because it does not broadcast
> > some ARP packets as required by RFC 3927.
> 
> I haven't seem anyone comment on this, 

Theres a lot of comments - check the archives of netdev on the thread
as well as a newer thread under "Broadcast ARP packets on link local
addresses (Version2)"

> but it would be useful to see this
> integrated.

IMO not the way it is defined right now in that patch. 
As suggested in the thread, best way is for the kernel to check
if it is link local and do the advert in broadcast instead of unicast.

> 
> Something else I've noticed while I've been implementing my zeroconf
> daemon is that the kernel returns link-scoped primary addresses first to
> 'ifconfig'.  Unfortunately quite a lot of user-space programs parse its
> output and interpret the address it presents as the primary for the
> specified interface.
> 

Not sure i followed.

> Is that a case of user-space breakage that the kernel team would
> ordinarily worry about?

I think user space setting the attribute of the address to be link local
would be a sufficient hint to the kernel to broadcast the arps.

cheers,
jamal