On Mon, 2021-03-15 at 15:59 +0100, Ondrej Zajicek wrote: > On Mon, Mar 15, 2021 at 02:25:18PM +0000, Kenth Eriksson wrote: > > I believe the "options" of the neighbor object is only updated as a > > result of NEIGHBOR_EXSTART. If the authentication is enabled after > > unauthenticated neighbor adjacency, then this does not result in a new > > NEIGHBOR_EXSTART. Thus the options of the neighbor object is stuck 0x113, > > and not the updated to 0x513 (i.e. OPT_AT) resulting in that OSPF packets > > are becoming dropped in procedure ospf_pkt_checkauth3 since auth_present > > is zero. > > Yes, you are right. If iface is configured to not use auth, adjacency is > established (n->options are set to not include OPT_AT) and then > reconfigured to use auth, adjacency is kept (because Hello packets > are authenticated) but LSUpd and others are ignored (because there > is no OPT_AT flag in n->options). > > RFC 7166 is vague about updating OPT_AT flag, and basic OSPFv2/v3 RFC > just describing setting n->options from DBDes during NEIGHBOR_EXSTART. > > > If I manually kick the FSM when authentication is changed by > > doing ISM_DOWN-> ISM_UP then this works as expected (see pseudo code > > below). I believe there is some logic missing when changing the autype? > > Can this be done in some more fine granular way? > > I think that the best solution would be to update OPT_AT flag in > n->options based on received Hello packets. Will make a patch.
What about IPv4? Does it also need some tweaking is this case? Jocke