On 03/03/16(Thu) 13:39, Matthieu Herrb wrote:
> On Thu, Mar 03, 2016 at 01:30:10PM +0100, Martin Pieuchot wrote:
> > On 03/03/16(Thu) 09:32, Matthieu Herrb wrote:
> > > One more data point: I've checked with 5.8, the patch is not needed
> > > there. (the "route add .../32 -link -iface if" stays and renews the
> > > arp entry when needed).
> > 
> > Which route does that create?  I might not be obvious, but without
> > including your route table output, I don't have enough information
> > to figure out what's happening.
> > 
> > The route table output is like the dmesg for routing problems ;)
> 
> Here's the result for a 5.8 machine with /etc/hostname.bge0: 
> (I've removed the v6 bits)
> 
> 
>    inet 91.224.149.89/32
>    !route add 91.224.148.0/32 -link -iface bge0
> 
> and /etc/mygate:
> 
>     91.224.148.0
> 
> nowhere% route -n show -inet
> Routing tables
> 
> Internet:
> Destination        Gateway            Flags   Refs      Use   Mtu  Prio Iface
> default            91.224.148.0       UGS        3     9637     -     8 bge0 
> 91.224.148.0       bc:5f:f4:ee:0c:88  UHLS       1        0     -     8 bge0 
> 91.224.149.89      38:ea:a7:a6:cd:7d  UHLl       0        0     -     1 lo0  
> 91.224.149.89/32   91.224.149.89      UC         0        0     -     8 bge0 
> 127/8              127.0.0.1          UGRS       0        0 32768     8 lo0  
> 127.0.0.1          127.0.0.1          UHl        1   691790 32768     1 lo0  
> 224/4              127.0.0.1          URS        0        0 32768     8 lo0  
> 
> 
> and also 
> 
> nowhere% arp -an 
> Host                                 Ethernet Address   Netif Expire     Flags
> 91.224.148.0                         bc:5f:f4:ee:0c:88   bge0 5m47s      
> 91.224.149.89                        38:ea:a7:a6:cd:7d   bge0 permanent  l

So you found a regression due to a change in arptfree().  Previously the
function was looking as its reference counter to decide if it should
delete the route or not.  I changed that do stop look at the reference
because this behavior is racy and wont fly as soon as route lookups are
done without holding the KERNEL_LOCK.

But we could decide not to remove ARP entries with the RTF_STATIC bit
set.  The others will automatically be re-created by a cloning route.

Does the diff below restore the previous behavior for you?

Index: netinet/if_ether.c
===================================================================
RCS file: /cvs/src/sys/netinet/if_ether.c,v
retrieving revision 1.201
diff -u -p -r1.201 if_ether.c
--- netinet/if_ether.c  21 Jan 2016 03:34:05 -0000      1.201
+++ netinet/if_ether.c  3 Mar 2016 13:28:03 -0000
@@ -667,7 +667,8 @@ arptfree(struct rtentry *rt)
                la->la_asked = 0;
        }
 
-       rtdeletemsg(rt, ifp, ifp->if_rdomain);
+       if (!ISSET(rt->rt_flags, RTF_STATIC))
+               rtdeletemsg(rt, ifp, ifp->if_rdomain);
        if_put(ifp);
 }
 
Index: netinet6/nd6.c
===================================================================
RCS file: /cvs/src/sys/netinet6/nd6.c,v
retrieving revision 1.176
diff -u -p -r1.176 nd6.c
--- netinet6/nd6.c      3 Dec 2015 21:57:59 -0000       1.176
+++ netinet6/nd6.c      3 Mar 2016 13:28:02 -0000
@@ -833,7 +833,8 @@ nd6_free(struct rtentry *rt, int gc)
         * caches, and disable the route entry not to be used in already
         * cached routes.
         */
-       rtdeletemsg(rt, ifp, ifp->if_rdomain);
+       if (!ISSET(rt->rt_flags, RTF_STATIC))
+               rtdeletemsg(rt, ifp, ifp->if_rdomain);
        splx(s);
 
        if_put(ifp);

Reply via email to