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.
Are you thinking something like this? diff --git a/proto/ospf/hello.c b/proto/ospf/hello.c index d094f934..dc3bc912 100644 --- a/proto/ospf/hello.c +++ b/proto/ospf/hello.c @@ -253,6 +253,10 @@ ospf_receive_hello(struct ospf_packet *pkt, struct ospf_iface *ifa, neighbors = ps->neighbors; neigh_count = (plen - sizeof(struct ospf_hello3_packet)) / sizeof(u32); + if (rcv_options & OPT_AT) + n->options |= OPT_AT; + else + n->options &= ~OPT_AT; } if (rcv_helloint != ifa->helloint)