On 15/09/16(Thu) 13:27, Visa Hankala wrote: > On Thu, Sep 15, 2016 at 12:52:09PM +0200, Francisco Gaitan wrote: > > >Synopsis: I can't set permanent arp entries in the ERL router > > >Category: system > > >Environment: > > System : OpenBSD 6.0 > > Details : OpenBSD 6.0-current (GENERIC) #27: Mon Sep 12 > > 00:55:34 UTC 2016 > > > > visa@octeon:/usr/src/sys/arch/octeon/compile/GENERIC > > > > Architecture: OpenBSD.octeon > > Machine : octeon > > >Description: > > > > Hello. I'm trying to set permament arp entries in my router. > > This happens in OpenBSD 6.0-release. I have installed -current > > and the problem is still happening. > > > > I have tried this in my amd64 machine and all works fine there, > > so I suppose this is a bug (I also asked in #openbsd first) > > > > This is a fresh -current installation. It happened exactly > > the same in my previous 6.0-release installation. > > > > mac adddresses are spoofed for privacy. > > > > >How-To-Repeat: > > > > # arp -Fs 192.168.1.50 00:25:90:a2:aa:91 > > 192.168.1.50 (192.168.1.50) deleted > > arp: writing to routing socket: File exists > > > > # arp -a > > Host Ethernet Address Netif Expire > > Flags > > 192.168.1.1 44:d9:e7:9f:0d:1b cnmac1 permanent l > > 192.168.1.50 00:25:90:a2:aa:91 cnmac1 20m0s > > Does it help if you set the arp entry while the interface is still down? > As a workaround, you could also try redirecting arp's output to > /dev/null when setting the static entry: > > # arp -Fs 192.168.1.50 00:25:90:a2:aa:91 > /dev/null > > When replacing an arp entry, the replacement is done in two steps. The > old entry is deleted first, and then the new one is added. As these > steps do not happen in a single transaction, it is possible that > 'well-timed' network traffic makes the kernel re-resolve the old entry > just before the static entry gets added.
But even in this case a RTF_CLONED entry should be overwritten by a RTF_STATIC entry. That's the logic of net/route.c:1083.
