I believe coverity can't tell the length of the return value from strftime based
on the format string (like we can), so it allows `n` to be larger than it could
be which then allows `sz - n` to be negative which is size_t positive and very
large so it thinks an overrun is possible.
CID#1563211
Signed-off-by: Christian Hopps <chopps@labn.net>
Looks like people don't find what does it mean (Policy) at first shot, let's
try giving more hints here.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
There might be a time element(s) from
temporary list are removed more than once
which leads to valueError in certain python3
version.
commit-id 1543f58b5 did not handle valueError
properly. This caused regression where
prefix-list config leads to delete followed
by add.
The new fix should just pass the exception as
value removal from list_to_add or list_to_del
is best effort.
This allows prefix-list config has no change
then removes the lines from lines_to_del and
lines_to_add properly.
Ticket:#3490252
Testing:
Configure prefix-list in frr.conf and perform
multiple frr-reload. After first reload operatoin
subsequent ones should not result in delete followed
by add of the prefix-list but rather no-op operation.
(Pdb) lines_to_add
[(('ip prefix-list FOO permit 10.2.1.0/24',), None)]
(Pdb) lines_to_del
[(('ip prefix-list FOO seq 5 permit 10.2.1.0/24',), None),
(('ip prefix-list FOO seq 10 permit 10.2.1.0/24',), None)]
(Pdb) lines_to_del_to_del
[(('ip prefix-list FOO seq 5 permit 10.2.1.0/24',), None),
(('ip prefix-list FOO seq 10 permit 10.2.1.0/24',), None)]
(Pdb) lines_to_add_to_del
[(('ip prefix-list FOO permit 10.2.1.0/24',), None),
(('ip prefix-list FOO permit 10.2.1.0/24',), None)]
(Pdb) c
> /usr/lib/frr/frr-reload.py(1562)ignore_delete_re_add_lines()
-> return (lines_to_add, lines_to_del)
(Pdb) lines_to_add
[]
(Pdb) lines_to_del
[]
Signed-off-by: Chirag Shah <chirag@nvidia.com>
- make sure we close and remove all handlers for named logs on each reuse.
- test module level exec.log no longer truncated to last test case output
- cleanup the log names, and make sure they are present in all exec logs
- keep separate exec logs for each pytest worker when running in distributed mode
- disabled code due to CI infra can't handle it: add per test case exec logs
Signed-off-by: Christian Hopps <chopps@labn.net>
The only places entry->any could ever be set to true was
when str was NULL. Unfortunately with the way our CLI works
str is impossible to be NonNULL. The entry->any value *used*
to work prior to commit e961923c72
but it was changed back in 2016 and no-one has noticed the changed
ability.
Let's just admit that there are no users of this and remove this
dead code.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Since the test was not named test_bgp_gr_functionality_topo3.py
pytest was not picking it up to run. Let's run it.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Receiver---LHR---RP
Problem:
In LHR, ipv6 pim state remains after MLD prune received.
Root Cause:
When LHR receives join, it creates (*,G) channel oil with
oil_ref_count = 2. The channel_oil is used by gm_sg sg->oil
and upstream->channel_oil.
When LHR receives prune, currently upstream->channel_oil is
deleted and gm_sg sg->oil still present. Due to this channel_oil
is still present with oil_ref_count = 1
Fix:
When LHR receives prune, upstream->channel_oil and pim_sg sg->oil
needs to be deleted.
Issue: #11249
Signed-off-by: Sarita Patra <saritap@vmware.com>
Code is no longer using a global FE "client context", and instead
creates client objects, rename the structure and it's uses to reflect this.
Remove an obfuscating abstraction layer whose existence was entirely
based on using a uintptr_t rather than a pointer to an declared-only struct.
Change multi-duty "params" structure into a single duty callbacks one.
Remove unsupported API code.
Signed-off-by: Christian Hopps <chopps@labn.net>
Remove an obfuscating abstraction layer whose existence was entirely
based on using a uintptr_t rather than a pointer to an declared-only struct.
As the code is no longer using a global FE "client context", and instead
create client objects, rename the structure and it's uses to reflect this.
Change init "params" structure into a single use callbacks one.
Signed-off-by: Christian Hopps <chopps@labn.net>
Consider the scenario of evpn, the box has some type-5 ECMP routes.
After one of its remote peers is removed ( or down ), `show evpn rmac vni all`
kept no change **sometimes**, it means the rmac of the removed peer maybe is
still in this box, and the traffic will be wrongly forwarded to the removed
peer.
The root cause is that the best path selection for type-5 routes maybe
keep no change and the best path is not routed to the removed peer, so `bgpd`
wrongly doesn't tell `zebra` to remove ( withdraw ) the type-5 routes owned
by the removed peer.
So, add a new flag to force the deletion.
Signed-off-by: anlan_cs <vic.lan@pica8.com>
When a state machine transition fails, bgpd would output
data about what happened, but not necessarily give the
reason why. Add that data to the output.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Currently, in PIM Northbound, when a path to RP is not found during config apply, we are treating this as a NB_ERR_INCONSISTENCY.
However, there are two issues with this approach:
When OSPF or IGP convergence is completed, it is possible that the RPF check will succeed.
If we have multiple groups and RPs (e.g. 50 RPs), we will receive 50 logs with inconsistency errors.
example:
2023/05/27 22:57:45 PIM: [G822R-SBMNH] config-from-file# ip pim rp 192.168.100.1 239.100.0.0/28 2023/05/27 22:57:45
PIM: [VAKV3-NMY7B][EC 100663337] error processing configuration change: error [internal inconsistency] event [apply]
operation [create] xpath [/frr-routing:routing/control-plane-protocols/control-plane-protocol[type='frr-pim:pimd']
[name='pim'][vrf='default']/frr-pim:pim/address-family[address-family='frr-routing:ipv4']/frr-pim-rp:rp/static-rp/rp-list
[rp-address='192.168.100.1']/group-list[.='239.100.0.0/28']] message: No Path to RP address specified: 192.168.100.1
Issue: #13620
Signed-off-by: Rajesh Varatharaj <rvaratharaj@nvidia.com>
