Hello Martin

Le jeu. 26 nov. 2020 à 14:27, Martin Pieuchot <[email protected]> a écrit :
>
> >
> > $ doas route -T1 add 192.0.2.2/32 -link -iface vlan12
>
> I wonder if the problem isn't in the validation of these parameters.
>
> Should we accept a L2 (-link) entry on a routing table which isn't the
> routing domain?  If so why does the entry persist in the ARP cache?

Which arp entry are you referring to? The one from the route I added?

> Can you reproduce the problem if you don't specify T1?

No. The routes are correctly removed when the interface is destroyed.
It only crashes when the routes are added to another (non-empty if
that matters) rdomain, but again, this was a silly mistake on my side.

I reported it as it might be of interest to fix this for the sake of
it, but it causes almost no harm.

PS: I've managed to crash my first router just by waiting a few
seconds - no need to remove the route - same thing as the second
router:
ddb> show panic
kernel diagnostic assertion "ifp != NULL" failed: file "/usr/src/sys/netinet/if
_ether.c", line 718

ddb> trace
db_enter() at db_enter+0x10
panic(ffffffff81dc761f) at panic+0x12a
__assert(ffffffff81e321c2,ffffffff81db9f2b,2ce,ffffffff81d9e429) at __assert+0x
2b
arp_rtrequest(fffffd800baa10a8,fffffd800baa10a8,fffffd801aa63dc0) at arp_rtrequ
est
arptimer(ffffffff8216a090) at arptimer+0x67
softclock_thread(ffff8000ffffea40) at softclock_thread+0x13f
end trace frame: 0x0, count: -6

Reply via email to