kernel/2179: inconsistent behaviour in arp reply of a bridge

[gwyllion@ace.ulyssis.org]

>Number:         2179
>Category:       kernel
>Synopsis:       inconsistent behaviour in arp reply of a bridge
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    bugs
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Thu Nov 15 04:10:01 MST 2001
>Last-Modified:
>Originator:     Dries Schellekens
>Organization:
net
>Release:        OpenBSD-current
>Environment:
	
	System      : OpenBSD 3.0
	Architecture: OpenBSD.alpha
	Machine     : alpha
>Description:
	
I have a really simple bridge set up on:
* interface ne3 has a dhcp IP (10.0.33.50) and MAC address 00:50:bf:58:04:96
* interface dc0 has no IP (just up) and MAC address 08:00:2b:86:3e:9d
* ne3 and dc0 make bridge0

A second machine is connected to dc0 (using cross cable) and everything
works (of course). But the log of that second machine get the following
entries:
arp: 10.0.33.50 moved from 08:00:2b:86:3e:9d to 00:50:bf:58:04:96 on vr0
arp: 10.0.33.50 moved from 00:50:bf:58:04:96 to 08:00:2b:86:3e:9d on vr0
arp: 10.0.33.50 moved from 08:00:2b:86:3e:9d to 00:50:bf:58:04:96 on vr0

An other demostration of this inconsistent behaviour (using
/usr/ports/net/arping):

ARPING 10.0.33.50
60 bytes from 08:00:2b:86:3e:9d (10.0.33.50): index=0
60 bytes from 08:00:2b:86:3e:9d (10.0.33.50): index=1
--- 10.0.33.50 statistics ---
2 packets transmitted, 2 packets received,   0% unanswered

ARPING 08:00:2b:86:3e:9d
--- 08:00:2b:86:3e:9d statistics ---
2 packets transmitted, 0 packets received, 100% unanswered

ARPING 00:50:bf:58:04:96
60 bytes from 10.0.33.50 (00:50:bf:58:04:96): icmp_seq=0
60 bytes from 10.0.33.50 (00:50:bf:58:04:96): icmp_seq=1
--- 00:50:bf:58:04:96 statistics ---
2 packets transmitted, 2 packets received,   0% unanswered


>How-To-Repeat:
	
Set up the same configuration: bridge with 2 interface, only 1 having an IP.
Use arping like I describe. 

>Fix:
	
NetBSD and FreeBSD have fix this problem, as far as I can see.
So I guess this can be solved by looking at what they did.
e.g. http://cvsweb.netbsd.org/bsdweb.cgi/syssrc/sys/netinet/if_arp.c.diff?r1=1.76&r2=1.78

>Audit-Trail:
>Unformatted: