Firstly, *keep no change* for `hash_get()` with NULL
`alloc_func`.
Only focus on cases with non-NULL `alloc_func` of
`hash_get()`.
Since `hash_get()` with non-NULL `alloc_func` parameter
shall not fail, just ignore the returned value of it.
The returned value must not be NULL.
So in this case, remove the unnecessary checking NULL
or not for the returned value and add `void` in front
of it.
Importantly, also *keep no change* for the two cases with
non-NULL `alloc_func` -
1) Use `assert(<returned_data> == <searching_data>)` to
ensure it is a created node, not a found node.
Refer to `isis_vertex_queue_insert()` of isisd, there
are many examples of this case in isid.
2) Use `<returned_data> != <searching_data>` to judge it
is a found node, then free <searching_data>.
Refer to `aspath_intern()` of bgpd, there are many
examples of this case in bgpd.
Here, <returned_data> is the returned value from `hash_get()`,
and <searching_data> is the data, which is to be put into
hash table.
Signed-off-by: anlan_cs <vic.lan@pica8.com>
A router has some static routes and redistributes turned on.
"clear ipv6 ospf process" command is applied. Then static routes
are deleted. In 1 in 5 runs, AS-External LSAs are not getting removed
from the neighbors even though it gets removed from its own LSDB.
Because of the clear process command, MAX_AGE LSAs are advertised and
fresh LSAs are installed in the LSDB. When the MAX_LSAs are advertised
back to the same router as part of the flooding process, it gets added
to the LSUpdate list even though it comes inside the MinLSArrival time.
When the static routes get deleted, it removed the LSA from the
LSRetrans list but not from LSUpdate list. The LSAs present in the
LSUpdate list gets advertised when sending LS Updates.
When an old copy of an LSA is more recent than the new LSA, check if it
has come inside the MinLSArrival time before adding to the LSUpdate
list.
Signed-off-by: Yash Ranjan <ranjany@vmware.com>
ospf6_routemap_rule_match_interface uses route->ospf6 field for matching
so we must fill the field in our temporary variable.
Fixes#10911.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
When an area-range command is applied in an ABR, the more specific prefixes
need to be removed.
r2# sh ipv6 ospf database
AS Scoped Link State Database
Type LSId AdvRouter Age SeqNum Payload
ASE 0.0.0.1 10.254.254.2 53 80000001 ::
ASE 0.0.0.2 10.254.254.2 51 80000001 2001:db8:1::/64
ASE 0.0.0.3 10.254.254.2 51 80000001 2001:db8:3::/64
ASE 0.0.0.4 10.254.254.2 51 80000001 2001:db8:2::/64
ASE 0.0.0.5 10.254.254.2 46 80000001 2001:db8:1::/64
ASE 0.0.0.6 10.254.254.2 46 80000001 2001:db8:3::/64
ASE 0.0.0.7 10.254.254.2 46 80000001 2001:db8:2::/64
ASE 0.0.0.8 10.254.254.2 41 80000001 2001:db8:3::/64
ASE 0.0.0.9 10.254.254.2 41 80000001 2001:db8:1000::1/128 <-- **
ASE 0.0.0.10 10.254.254.2 41 80000001 2001:db8:1000::2/128 <-- **
ASE 0.0.0.12 10.254.254.2 24 80000001 2001:db8:1000::/64
ASE 0.0.0.1 10.254.254.3 52 80000001 2001:db8:2::/64
Signed-off-by: ckishimo <carles.kishimoto@gmail.com>
Problem:
ospf6d crash is observed when lsack is received from the neighbour for
AS External LSA.
RCA:
The crash is observed in ospf6_decrement_retrans_count while decrementing
retransmit counter for the LSA when lsack is recived. This is because in
ospf6_flood_interace when new LSA is being added to the neighbour's list
the incrementing is happening on the received LSA instead of the already
present LSA in scope DB which is already carrying counters.
when this new LSA replaces the old one, the already present counters are
not copied on the new LSA this creates counter mismatch which results in
a crash when lsack is recevied due to counter going to negative.
Fix:
The fix involves following changes.
1. In ospf6_flood_interace when LSA is being added to retrans list
check if there is alreday lsa in the scoped db and increment
the counter on that if present.
2. In ospf6_lsdb_add copy the retrans counter from old to new lsa
when its being replaced.
Signed-off-by: Manoj Naragund <mnaragund@vmware.com>
Currently the nexthop tracking code is only sending to the requestor
what it was requested to match against. When the nexthop tracking
code was simplified to not need an import check and a nexthop check
in b8210849b8 for bgpd. It was not
noticed that a longer prefix could match but it would be seen
as a match because FRR was not sending up both the resolved
route prefix and the route FRR was asked to match against.
This code change causes the nexthop tracking code to pass
back up the matched requested route (so that the calling
protocol can figure out which one it is being told about )
as well as the actual prefix that was matched to.
Fixes: #10766
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Problem Statement:
=================
The feature is not enabled, needs to be enabled by doing required
initialization.
RCA:
====
Changes to support the feature is present, but the feature macro
needs to be enabled.
Fix:
====
This commit has changes to enable the code.
Risk:
=====
Medium
Need to ensure all existing ospf6 related topotests pass. to ensure
packet processing is not impacted.
Tests Executed:
===============
Have tested the functionality with enabling openssl and also disabling
openssl.
Signed-off-by: Abhinay Ramesh <rabhinay@vmware.com>
Problem Statement:
==================
RFC 7166 support for OSPF6 in FRR code.
RCA:
====
This feature is newly supported in FRR
Fix:
====
Core functionality implemented in previous commit is
stitched with rest of ospf6 code as part of this commit.
Risk:
=====
Low risk
Tests Executed:
===============
Have executed the combination of commands.
Signed-off-by: Abhinay Ramesh <rabhinay@vmware.com>
Problem Statement:
==================
Implement RFC 7166 support for OSPF6 in FRR code.
RCA:
====
This feature is newly supported in FRR.
Fix:
====
Changes are done to implement ospf6 ingress and egress
packet processing.
This commit has the core functionality.
It supports below debugability commands:
---------------------------------------
debug ospf6 authentication [<tx|rx>]
It supports below clear command:
--------------------------------
clear ipv6 ospf6 auth-counters interface [IFNAME]
It supports below show commands:
--------------------------------
frr# show ipv6 ospf6 interface ens192
ens192 is up, type BROADCAST
Interface ID: 5
Number of I/F scoped LSAs is 2
0 Pending LSAs for LSUpdate in Time 00:00:00 [thread off]
0 Pending LSAs for LSAck in Time 00:00:00 [thread off]
Authentication trailer is enabled with manual key ==> new info added
Packet drop Tx 0, Packet drop Rx 0 ==> drop counters
frr# show ipv6 ospf6 neighbor 2.2.2.2 detail
Neighbor 2.2.2.2%ens192
Area 1 via interface ens192 (ifindex 3)
0 Pending LSAs for LSUpdate in Time 00:00:00 [thread off]
0 Pending LSAs for LSAck in Time 00:00:00 [thread off]
Authentication header present ==> new info added
hello DBDesc LSReq LSUpd LSAck
Higher sequence no 0x0 0x0 0x0 0x0 0x0
Lower sequence no 0x242E 0x1DC4 0x1DC3 0x23CC 0x1DDA
frr# show ipv6 ospf6
OSPFv3 Routing Process (0) with Router-ID 2.2.2.2
Number of areas in this router is 1
Authentication Sequence number info ==> new info added
Higher sequence no 3, Lower sequence no 1656
Risk:
=====
Low risk
Tests Executed:
===============
Have executed the combination of commands.
Signed-off-by: Abhinay Ramesh <rabhinay@vmware.com>
Problem Statement:
==================
RFC 7166 support for OSPF6 in FRR code.
RCA:
====
This feature is newly supported in FRR
Fix:
====
Changes are done to add support for two new CLIs to configure
ospf6 authentication trailer feature.
One CLI is to support manual key configuration.
Other CLI is to configure key using keychain.
below CLIs are implemented as part of this commit. this configuration
is applied on interface level.
Without openssl:
ipv6 ospf6 authentication key-id (1-65535) hash-algo <md5|hmac-sha-256> key WORD
With openssl:
ipv6 ospf6 authentication key-id (1-65535) hash-algo <md5|hmac-sha-256|hmac-sha-1|hmac-sha-384|hmac-sha-512> key WORD
With keychain support:
ipv6 ospf6 authentication keychain KEYCHAIN_NAME
Running config for these command:
frr# show running-config
Building configuration...
Current configuration:
!
interface ens192
ipv6 address 2001:DB8:1::2/64
ipv6 ospf6 authentication key-id 10 hash-algo hmac-sha-256 key abhinay
!
interface ens224
ipv6 address 2001:DB8:2::2/64
ipv6 ospf6 authentication keychain abhinay
!
Risk:
=====
Low risk
Tests Executed:
===============
Have executed the combination of commands.
Signed-off-by: Abhinay Ramesh <rabhinay@vmware.com>
Problem Statement:
==================
As of now there is no support for ospf6 authentication.
To support ospf6 authentication need to have keychain support for
managing the auth key.
RCA:
====
New support
Fix:
====
Enabling keychain for ospf6 authentication feature.
Risk:
=====
Low risk
Tests Executed:
===============
Have verified the support for ospf6 auth trailer feature.
Signed-off-by: Abhinay Ramesh <rabhinay@vmware.com>
if r1 has a route received from a neighbor and the same route
configured as static, the administrative distance will determine
which route to use
r1(config)# ipv6 route 1:1::1/128 Null0 70
r1# sh ipv6 route
Codes: K - kernel route, C - connected, S - static, R - RIPng,
O - OSPFv3, I - IS-IS, B - BGP, N - NHRP, T - Table,
v - VNC, V - VNC-Direct, A - Babel, F - PBR,
f - OpenFabric,
> - selected route, * - FIB route, q - queued, r - rejected, b - backup
t - trapped, o - offload failure
S>* 1:1::1/128 [70/0] unreachable (blackhole), weight 1, 00:00:12
O 1:1::1/128 [110/20] via fe80::1833:c9ff:fe7b:3e43, r1-r2-eth0, weight 1, 00:00:49
The static route is selected. If we now change the administrative distance
in ospf6, the OSPF route should be selected
r1(config)# router ospf6
r1(config-ospf6)# distance 50
r1# sh ipv6 route
Codes: K - kernel route, C - connected, S - static, R - RIPng,
O - OSPFv3, I - IS-IS, B - BGP, N - NHRP, T - Table,
v - VNC, V - VNC-Direct, A - Babel, F - PBR,
f - OpenFabric,
> - selected route, * - FIB route, q - queued, r - rejected, b - backup
t - trapped, o - offload failure
S>* 1:1::1/128 [70/0] unreachable (blackhole), weight 1, 00:00:39
O 1:1::1/128 [110/20] via fe80::1833:c9ff:fe7b:3e43, r1-r2-eth0, weight 1, 00:01:16
However the distance is not applied as there are no changes in the routing table
This commit will force the update of the routing table with the new configured distance
r1# sh ipv6 route
Codes: K - kernel route, C - connected, S - static, R - RIPng,
O - OSPFv3, I - IS-IS, B - BGP, N - NHRP, T - Table,
v - VNC, V - VNC-Direct, A - Babel, F - PBR,
f - OpenFabric,
> - selected route, * - FIB route, q - queued, r - rejected, b - backup
t - trapped, o - offload failure
O>* 1:1::1/128 [50/20] via fe80::8cb7:e6ff:fef5:2344, r1-r2-eth0, weight 1, 00:00:03
S 1:1::1/128 [70/0] unreachable (blackhole), weight 1, 00:00:19
Signed-off-by: ckishimo <carles.kishimoto@gmail.com>
This PR will include if the area is NSSA in the output of "show ipv6 ospf"
r2# show ipv6 ospf
...
Area 0.0.0.0
Number of Area scoped LSAs is 8
Interface attached to this area: r2-eth1
SPF last executed 20.46717s ago
Area 0.0.0.1[Stub]
Number of Area scoped LSAs is 9
Interface attached to this area: r2-eth0
SPF last executed 20.46911s ago
Area 0.0.0.2[NSSA]
Number of Area scoped LSAs is 14
Interface attached to this area: r2-eth2
SPF last executed 20.46801s ago
Signed-off-by: ckishimo <carles.kishimoto@gmail.com>
Opaque data takes up a lot of memory when there are a lot of routes on
the box. Given that this is just a cosmetic info, I propose to disable
it by default to not shock people who start using FRR for the first time
or upgrades from an old version.
Fixes#10101.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
VRF name should not be printed in the config since 574445ec. The update
was done for NB config output but I missed it for regular vty output.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
Fixes#9720. When updating an ECMP inter-area route, we compute
a new route and check whether that already exists. If so, we keep the old
route and only update its nexthops. Previously, we merged the new route's
nexthops into the old one's, but this way, it's impossible to remove
nexthops from the old route, resulting in stale nexthops.
This commit fixes this by first removing all nexthops from the old route and
then copying all nexthops from the new route into it. If the new route has
fewer nexthops, the old one will have as well afterwards.
Signed-off-by: Martin Buck <mb-tmp-tvguho.pbz@gromit.dyndns.org>
Update ospfd and ospf6d to send opaque route attributes to
zebra. Those attributes are stored in the RIB and can be viewed
using the "show ip[v6] route" commands (other than that, they are
completely ignored by zebra).
Example:
```
debian# show ip route 192.168.1.0/24
Routing entry for 192.168.1.0/24
Known via "ospf", distance 110, metric 20, best
Last update 01:57:08 ago
* 10.0.1.2, via eth-rt2, weight 1
OSPF path type : External-2
OSPF tag : 0
debian#
debian# show ip route 192.168.1.0/24 json
{
"192.168.1.0\/24":[
{
"prefix":"192.168.1.0\/24",
"prefixLen":24,
"protocol":"ospf",
"vrfId":0,
"vrfName":"default",
"selected":true,
[snip]
"ospfPathType":"External-2",
"ospfTag":"0"
}
]
}
```
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
Currently the ospf6d's commands with non-exist vrfs can't give the error
informations to users.
This commit adds a macro "OSPF6_CMD_CHECK_VRF" to give error information
if with non-exist vrfs. As usual, skip the checking process in the case
of json.
So one command can call this macro to do the checking process in its
end. At that time it need know json style or not, so add "json" parameter for
several related functions.
BTW, suppress the build warning of the macro `OSPF6_FIND_VRF_ARGS`:
"Macros starting with if should be enclosed by a do - while loop to avoid
possible if/else logic defects."
Signed-off-by: anlan_cs <anlan_cs@tom.com>
Comparison of the two pointer is confusing, they have no relevance
except the time both of them are empty.
Additionly modify one variable name and correct some comment words, they
are same in both ospfd and ospf6d.
Signed-off-by: anlan_cs <anlan_cs@tom.com>
The OSPF6_LSA_UNAPPROVED flag is set in the function above
ospf6_lsa_translated_nssa_new, so there is no need to set
the flag again
Signed-off-by: ckishimo <carles.kishimoto@gmail.com>
When running topotest ospf6_topo2 we can see a log message with wrong lsa id
2021/12/20 23:14:40.330 OSPF6: [V8P0C-HB5Z2] ASBR[default:Status:3]: Update
2021/12/20 23:14:40.330 OSPF6: [Z489N-JAJ6P] ASBR[default:Status:3]: Already ASBR
2021/12/20 23:14:40.330 OSPF6: [Z9D0B-12SBJ] Redistribute 2001:db8:2::/64 (connected)
2021/12/20 23:14:40.330 OSPF6: [N66XP-ANN4G] Advertise as AS-External Id:8.70.41.177 prefix 2001:db8:2::/64 metric 2 (**)
2021/12/20 23:14:40.330 OSPF6: [K4Y9R-C22T6] Advertise new AS-External Id:0.0.0.3 prefix 2001:db8:2::/64 metric 2
2021/12/20 23:14:40.330 OSPF6: [PKX0N-KNRQR] Originate AS-External-LSA for 2001:db8:2::/64
This PR removes the log (instead of fixing it) as same information is printed
in the following entry
Signed-off-by: ckishimo <carles.kishimoto@gmail.com>
Since ospf6Enabled and attachedToArea are denoting the same thing.
It is decided to remove ospf6Enabled from json output to make
CLI and json output similar.
Fixes: #9286
Signed-off-by: Mobashshera Rasool <mrasool@vmware.com>
With the current code, in a topology like this:
r1 ---- 0.0.0.0 ---- r2(ABR) ---- 1.1.1.1 -----r3(ASBR)
NSSA
where r3 is redistributing statics within the NSSA area, the ABR (r2)
is translating type-7 lsa to type-5.
Everytime the function ospf6_abr_nssa_task() is executed all translated
type-5 are aged out and refreshed for no reason. So for instance having 3
lsas already advertised:
r1# sh ipv6 os database
AS Scoped Link State Database
Type LSId AdvRouter Age SeqNum Payload
ASE 0.0.0.1 2.2.2.2 39 80000001 3:3::3/128
ASE 0.0.0.2 2.2.2.2 39 80000001 4:4::4/128
ASE 0.0.0.3 2.2.2.2 39 80000001 5:5::5/128
Adversting a new route from r3:
r3(config)# ipv6 route 6:6::6/128 Null0
r1# sh ipv6 os database
AS Scoped Link State Database
Type LSId AdvRouter Age SeqNum Payload
ASE 0.0.0.1 2.2.2.2 124 80000001 3:3::3/128
ASE 0.0.0.2 2.2.2.2 124 80000001 4:4::4/128
ASE 0.0.0.3 2.2.2.2 124 80000001 5:5::5/128
ASE 0.0.0.4 2.2.2.2 8 80000001 6:6::6/128
That seems okay, however a few seconds later we see all prefixes refreshed
r1# sh ipv6 os database
AS Scoped Link State Database
Type LSId AdvRouter Age SeqNum Payload
ASE 0.0.0.1 2.2.2.2 3600 80000001 3:3::3/128
ASE 0.0.0.2 2.2.2.2 3600 80000001 4:4::4/128
ASE 0.0.0.3 2.2.2.2 3600 80000001 5:5::5/128
ASE 0.0.0.4 2.2.2.2 3600 80000001 6:6::6/128
ASE 0.0.0.5 2.2.2.2 3 80000001 3:3::3/128
ASE 0.0.0.6 2.2.2.2 3 80000001 4:4::4/128
ASE 0.0.0.7 2.2.2.2 3 80000001 5:5::5/128
ASE 0.0.0.8 2.2.2.2 3 80000001 6:6::6/128
This PR prevents the LSA of being refreshed by unsetting the OSPF6_LSA_UNAPPROVED
flag so advertising the last prefix will not refresh all of them:
r1# sh ipv6 os database
AS Scoped Link State Database
Type LSId AdvRouter Age SeqNum Payload
ASE 0.0.0.1 2.2.2.2 90 80000001 3:3::3/128
ASE 0.0.0.2 2.2.2.2 47 80000001 4:4::4/128
ASE 0.0.0.3 2.2.2.2 35 80000001 5:5::5/128
ASE 0.0.0.4 2.2.2.2 7 80000001 6:6::6/128
Signed-off-by: ckishimo <carles.kishimoto@gmail.com>
Currently, it is possible to rename the default VRF either by passing
`-o` option to zebra or by creating a file in `/var/run/netns` and
binding it to `/proc/self/ns/net`.
In both cases, only zebra knows about the rename and other daemons learn
about it only after they connect to zebra. This is a problem, because
daemons may read their config before they connect to zebra. To handle
this rename after the config is read, we have some special code in every
single daemon, which is not very bad but not desirable in my opinion.
But things are getting worse when we need to handle this in northbound
layer as we have to manually rewrite the config nodes. This approach is
already hacky, but still works as every daemon handles its own NB
structures. But it is completely incompatible with the central
management daemon architecture we are aiming for, as mgmtd doesn't even
have a connection with zebra to learn from it. And it shouldn't have it,
because operational state changes should never affect configuration.
To solve the problem and simplify the code, I propose to expand the `-o`
option to all daemons. By using the startup option, we let daemons know
about the rename before they read their configs so we don't need any
special code to deal with it. There's an easy way to pass the option to
all daemons by using `frr_global_options` variable.
Unfortunately, the second way of renaming by creating a file in
`/var/run/netns` is incompatible with the new mgmtd architecture.
Theoretically, we could force daemons to read their configs only after
they connect to zebra, but it means adding even more code to handle a
very specific use-case. And anyway this won't work for mgmtd as it
doesn't have a connection with zebra. So I had to remove this option.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
RFC 3101 states both E-bit and N-bit need to be checked when receiving a Hello packet.
"To support the NSSA option an additional check must be made in the function
that handles the receiving of the Hello packet to verify that both the N-bit
and the E-bit found in the Hello packet's option field match the area type and
ExternalRoutingCapability of the area of the receiving interface."
This PR adds the check for the N-bit
Signed-off-by: ckishimo <carles.kishimoto@gmail.com>
The external_id_table was only ever used to store pointers to data
and was never used for lookup during the course of normal operations.
However it did lead to crashes because somewhere along the way
external routes stored in the external_table never had their
id associated into the external_id_table and we would assert
on the node lookup failing.
Since this code was never used for anything other than
storing data and it was never retrieved for anything useful
let's just remove it from ospf6d.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Since f60a1188 we store a pointer to the VRF in the interface structure.
There's no need anymore to store a separate vrf_id field.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
In a topology like:
r1(ASBR) ---- 0.0.0.0 ---- r2(ABR) ---- 1.1.1.1 -----r3
where r1 is redistributing statics and area 1.1.1.1 is NSSA, the ABR r2 should
not originate type-4 LSA into the NSSA area. From RFC 3101: "NSSA border routers
should not originate Type-4 summary-LSAs into their NSSAs."
This PR prevents the above LSA of being originated by the ABR r2
Signed-off-by: ckishimo <carles.kishimoto@gmail.com>
In a topology like:
r1 ---- 0.0.0.0 ---- r2(ABR) ---- 1.1.1.1 -----r3(ASBR)
where r3 is redistributing statics and area 1.1.1.1 is NSSA, the ABR r2 should
not originate type-4 LSA, according to RFC 3101, section 1.3:
"also an NSSA's border routers never originate Type-4 summary-LSAs for the
NSSA's AS boundary routers, since Type-7 AS-external-LSAs are never flooded
beyond the NSSA's border"
r1# sh ipv6 os database inter-router
Area Scoped Link State Database (Area 0.0.0.0)
Type LSId AdvRouter Age SeqNum Payload
IAR 3.3.3.3 2.2.2.2 49 80000001 3.3.3.3
This PR prevents the above LSA of being originated by the ABR r2
Signed-off-by: ckishimo <carles.kishimoto@gmail.com>
We should always treat the VRF interface as a loopback. Currently, this
is not the case, because in some old pre-VRF code we use if_is_loopback
instead of if_is_loopback_or_vrf. To avoid any future problems, the
proposal is to rename if_is_loopback_or_vrf to if_is_loopback and use it
everywhere. if_is_loopback is renamed to if_is_loopback_exact in case
it's ever needed, but currently it's not used anywhere.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
Using memcmp with complex structures like prefix or ospf6_ls_origin is
not correct, because even two structures with same values in all fields
may have different values in padding bytes and comparison will fail.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
As part of the check, it memcompares two structs ospf6_path. This struct
has a pointer field nh_list which is allocated every time a new path is
created, which means it can never be the same for two different paths.
Therefore this check is always false and can be completely removed.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
The adj_ok thread event is being added but not killed
when the underlying interface is deleted. I am seeing
this crash:
OSPF6: Received signal 11 at 1636142186 (si_addr 0x0, PC 0x561d7fc42285); aborting...
OSPF6: zlog_signal+0x18c 7f227e93519a 7ffdae024590 /lib/libfrr.so.0 (mapped at 0x7f227e884000)
OSPF6: core_handler+0xe3 7f227e97305e 7ffdae0246b0 /lib/libfrr.so.0 (mapped at 0x7f227e884000)
OSPF6: funlockfile+0x50 7f227e863140 7ffdae024800 /lib/x86_64-linux-gnu/libpthread.so.0 (mapped at 0x7f227e84f000)
OSPF6: ---- signal ----
OSPF6: need_adjacency+0x10 561d7fc42285 7ffdae024db0 /usr/lib/frr/ospf6d (mapped at 0x561d7fbc6000)
OSPF6: adj_ok+0x180 561d7fc42f0b 7ffdae024dc0 /usr/lib/frr/ospf6d (mapped at 0x561d7fbc6000)
OSPF6: thread_call+0xc2 7f227e989e32 7ffdae024e00 /lib/libfrr.so.0 (mapped at 0x7f227e884000)
OSPF6: frr_run+0x217 7f227e92a7f3 7ffdae024ec0 /lib/libfrr.so.0 (mapped at 0x7f227e884000)
OSPF6: main+0xf3 561d7fc0f573 7ffdae024fd0 /usr/lib/frr/ospf6d (mapped at 0x561d7fbc6000)
OSPF6: __libc_start_main+0xea 7f227e6b0d0a 7ffdae025010 /lib/x86_64-linux-gnu/libc.so.6 (mapped at 0x7f227e68a000)
OSPF6: _start+0x2a 561d7fc0f06a 7ffdae0250e0 /usr/lib/frr/ospf6d (mapped at 0x561d7fbc6000)
OSPF6: in thread adj_ok scheduled from ospf6d/ospf6_interface.c:678 dr_election()
The crash is in the on->ospf6_if pointer is NULL. The only way this could
happen from what I can tell is that the event is added to the system
and then we immediately delete the interface, removing the memory
but not freeing up the adj_ok thread event.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
I am seeing a crash of ospf6d with this stack trace:
OSPF6: Received signal 11 at 1636042827 (si_addr 0x0, PC 0x55efc2d09ec2); aborting...
OSPF6: zlog_signal+0x18c 7fe20c8ca19a 7ffd08035590 /lib/libfrr.so.0 (mapped at 0x7fe20c819000)
OSPF6: core_handler+0xe3 7fe20c90805e 7ffd080356b0 /lib/libfrr.so.0 (mapped at 0x7fe20c819000)
OSPF6: funlockfile+0x50 7fe20c7f8140 7ffd08035800 /lib/x86_64-linux-gnu/libpthread.so.0 (mapped at 0x7fe20c7e4000)
OSPF6: ---- signal ----
OSPF6: ospf6_neighbor_state_change+0xdc 55efc2d09ec2 7ffd08035d90 /usr/lib/frr/ospf6d (mapped at 0x55efc2c8e000)
OSPF6: exchange_done+0x15c 55efc2d0ab4a 7ffd08035dc0 /usr/lib/frr/ospf6d (mapped at 0x55efc2c8e000)
OSPF6: thread_call+0xc2 7fe20c91ee32 7ffd08035df0 /lib/libfrr.so.0 (mapped at 0x7fe20c819000)
OSPF6: frr_run+0x217 7fe20c8bf7f3 7ffd08035eb0 /lib/libfrr.so.0 (mapped at 0x7fe20c819000)
OSPF6: main+0xf3 55efc2cd7573 7ffd08035fc0 /usr/lib/frr/ospf6d (mapped at 0x55efc2c8e000)
OSPF6: __libc_start_main+0xea 7fe20c645d0a 7ffd08036000 /lib/x86_64-linux-gnu/libc.so.6 (mapped at 0x7fe20c61f000)
OSPF6: _start+0x2a 55efc2cd706a 7ffd080360d0 /usr/lib/frr/ospf6d (mapped at 0x55efc2c8e000)
OSPF6: in thread exchange_done scheduled from ospf6d/ospf6_message.c:2264 ospf6_dbdesc_send_newone()
The stack trace when decoded is:
(gdb) l *(ospf6_neighbor_state_change+0xdc)
0x7bec2 is in ospf6_neighbor_state_change (ospf6d/ospf6_neighbor.c:200).
warning: Source file is more recent than executable.
195 on->name, ospf6_neighbor_state_str[prev_state],
196 ospf6_neighbor_state_str[next_state],
197 ospf6_neighbor_event_string(event));
198 }
199
200 /* Optionally notify about adjacency changes */
201 if (CHECK_FLAG(on->ospf6_if->area->ospf6->config_flags,
202 OSPF6_LOG_ADJACENCY_CHANGES)
203 && (CHECK_FLAG(on->ospf6_if->area->ospf6->config_flags,
204 OSPF6_LOG_ADJACENCY_DETAIL)
OSPFv3 is creating the event without a managing thread and as such
if the event is not run before a deletion event comes in memory
will be freed up and we'll start trying to access memory we should
not. Modify ospfv3 to track the thread and appropriately stop
it when the memory is deleted or it is no longer need to run
that bit of code.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
in show: 'show ipv6 ospf6' handler command, the reason of SPF
executation is looked up and displayed. At startup, SPF has been
started, but shows no specific reason. Instead of dumping non
initialised string context, reset the string context.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Description:
Addressed the following TAINTED_SCALAR issue which can possibly
leads to memory currption.
1. *** CID 1506514: Insecure data handling (TAINTED_SddddddCALAR)
/ospf6d/ospf6_gr_helper.c: 1222 in ospf6_grace_lsa_show_info()
2. *** CID 1506513: Insecure data handling (TAINTED_SCALAR)
/ospf6d/ospf6_gr_helper.c: 160 in ospf6_extract_grace_lsa_fields()
Signed-off-by: Rajesh Girada <rgirada@vmware.com>
if_lookup_by_index_all_vrf doesn't work correctly with netns VRF backend
as the same index may be used in multiple netns simultaneously.
We always know the OSPF6 instance we work with, so use its VRF id for
the interface lookup.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
Description:
code changes involve removal of increment and decrement operators
during function calls. These expressions make code less readable.
Signed-off-by: Manoj Naragund <mnaragund@vmware.com>
