Both net/ipv4/arp.c and net/arm/clip.c create neighbour tables with family == AF_INET. For most purposes this is fine, since the two modules each hold a pointer to their table and pass it into the neigh_* functions.
A problem arises in neigh_add, which is called by the rtnetlink code and which iterates through all the neighbour tables looking for the first one with the correct family. Since there are two different tables with family == AF_INET, sometimes it picks the wrong one. This leads to the situation where sending a RTM_NEWNEIGH message via netlink can generate an ignored and useless entry in the clip table, whilst the not affecting another entry in the ARP table, both entries for the same IP. Viz: sid:~# ip neigh 192.168.3.40 dev eth0 lladdr 52:54:00:12:34:59 REACHABLE 192.168.3.40 dev eth0 FAILED It's not immediately obvious how to fix this in a conceptually clean manner: neighbour tables are not associated with single netdevices, and they don't carry an address-type field. Given a {IP,lladdr,device} triple, its easy to determine if the device is ether-like or CLIP, but then the update call would have to go via the ARP and CLIP modules, instead of direct to the neighbour module in an address independent way. New address types would need further additions to the netlink/neighbour code. OTOH there are several obvious hacks that will fix the immediate problem. I'm happy to provide a patch implementing one if that's desired. Looking again, I think this is also a security hole, since the CLIP code keeps a whole struct including pointers in the neighbour table entry where ARP has the MAC address. So this might provide a way to poke arbitrary pointers into the kernel via RTM_NEWNEIGH. Only for root, though. Cheers, Simon. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html