Did anybody ever notice this?

I'm quite sure it didn't happen with 1.2...

Pinging a broadcast address on the local ethernet confuses arp:

---8<------8<------8<------8<------8<------8<------8<------8<------8<---
[/tmp] root@rumolt > ping -c 1 194.77.123.128
PING 194.77.123.128 (194.77.123.128): 56 data bytes
64 bytes from 194.77.123.129: icmp_seq=0 ttl=255 time=1.209 ms

--- 194.77.123.128 ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max = 1.209/1.209/1.209 ms
[/tmp] root@rumolt > ping -c 1 194.77.123.143
PING 194.77.123.143 (194.77.123.143): 56 data bytes
64 bytes from 194.77.123.129: icmp_seq=0 ttl=255 time=1.030 ms

--- 194.77.123.143 ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max = 1.030/1.030/1.030 ms
[/tmp] root@rumolt > arp -a
? (194.77.123.128) at (incomplete)
? (194.77.123.143) at (incomplete)
[/tmp] root@rumolt > ifconfig ed0
ed0: flags=9863<UP,BROADCAST,NOTRAILERS,RUNNING,SIMPLEX,LINK0,MULTICAST>
        inet 194.77.123.129 netmask 0xfffffff0 broadcast 194.77.123.143
---8<------8<------8<------8<------8<------8<------8<------8<------8<---

This doesn't hurt, but at least looks ugly ;-)
I would call it a bug. Does it make sense to enter this types of addresses
(which could never be assigned to a correctly configured device) into the
arp cache?

The same things happen with standard class C networks, so its not a question
of my unusual (is it?) netmask/broadcast address.


Martin