On 10/04/20(Fri) 13:19, Claudio Jeker wrote: > On Fri, Apr 10, 2020 at 12:14:17PM +0200, Martin Pieuchot wrote: > > On 10/04/20(Fri) 11:18, Claudio Jeker wrote: > > > On Fri, Apr 10, 2020 at 10:47:53AM +0200, Martin Pieuchot wrote: > > > > On 09/04/20(Thu) 20:22, Laurent Salle wrote: > > > > > On 08/04/2020 06.52, Martin Pieuchot wrote: > > > > > > > > > > > It's the same bug as reported by sthen@. Two interfaces in the > > > > > > same subnet > > > > > > have two identical cloning routes: > > > > > > > > > > I've been able to reproduce systematically the problem with an OpenBSD > > > > > virtual machine running the latest snapshot and two vio interface with > > > > > different priority connected to the same lan with dhcp. > > > > > > > > Thanks for the report! Diff below seems to fix the issue here, could > > > > you try it? > > > > > > I'm not convinced that this is the right solution. In your diff you insert > > > the MAC received on one interface into the arp node of another interface. > > > This feels wrong, arp entries should never cross over interfaces. > > > For example if for some reasons the two interfaces have the same gateway > > > IP but use different MACs for that IP then this breaks. > > > > Makes sense. > > > > Well it looks like when the default route on if0 tries to use the L2 > > route underneath it, the ARP layer resolve the entry on if1 instead of > > on if0. > > > > The route on if0 is being used because it has higher priority, however > > the L2 entry on if1 has been inserted first. I haven't debugged > > further. > > Yes, this comes from the fact that rtalloc() will find the gw route of the > wrong interface and not clone a new entry from the other interface and so > the rt_gwroute cache is all messed up.
Do you know which particular rtalloc(9) we're talking about?
