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. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: [email protected]) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."
