Neither tabs nor newlines are acceptable in syslog messages. They also
break line-based parsing of file logs.
Signed-off-by: David Lamparter <equinox@diac24.net>
Issue: When a path in the inter area ecmp route is deleted, the route is removed
Fix: The fix is to remove the specific path from the inter area route using
ospf6_abr_old_route_remove() when abr route entry is not found.
In the function ospf6_abr_old_route_remove() the path to be removed needs
to match adv router and link state ID
Fixed memory leak in ospf6_intra_prefix_update_route_origin() caused by
route node lock not getting released.
Signed-off-by: kssoman <somanks@gmail.com>
Valgrind reports:
2437395-==2437395== Invalid read of size 8
2437395:==2437395== at 0x40B610: ospf6_asbr_update_route_ecmp_path (ospf6_asbr.c:327)
2437395-==2437395== by 0x40BC7C: ospf6_asbr_lsa_add (ospf6_asbr.c:544)
2437395-==2437395== by 0x40C5DF: ospf6_asbr_lsentry_add (ospf6_asbr.c:829)
2437395-==2437395== by 0x42D88D: ospf6_top_brouter_hook_add (ospf6_top.c:185)
2437395-==2437395== by 0x4188E3: ospf6_intra_brouter_calculation (ospf6_intra.c:2320)
2437395-==2437395== by 0x42C624: ospf6_spf_calculation_thread (ospf6_spf.c:638)
2437395-==2437395== by 0x4904B7E: thread_call (thread.c:1681)
2437395-==2437395== by 0x48CAA27: frr_run (libfrr.c:1126)
2437395-==2437395== by 0x40AF43: main (ospf6_main.c:232)
2437395-==2437395== Address 0x5c668a8 is 24 bytes inside a block of size 256 free'd
2437395:==2437395== at 0x48399AB: free (vg_replace_malloc.c:538)
2437395-==2437395== by 0x429027: ospf6_route_delete (ospf6_route.c:419)
2437395-==2437395== by 0x429027: ospf6_route_unlock (ospf6_route.c:460)
2437395-==2437395== by 0x429027: ospf6_route_remove (ospf6_route.c:887)
2437395-==2437395== by 0x40B343: ospf6_asbr_update_route_ecmp_path (ospf6_asbr.c:318)
2437395-==2437395== by 0x40BC7C: ospf6_asbr_lsa_add (ospf6_asbr.c:544)
2437395-==2437395== by 0x40C5DF: ospf6_asbr_lsentry_add (ospf6_asbr.c:829)
2437395-==2437395== by 0x42D88D: ospf6_top_brouter_hook_add (ospf6_top.c:185)
2437395-==2437395== by 0x4188E3: ospf6_intra_brouter_calculation (ospf6_intra.c:2320)
2437395-==2437395== by 0x42C624: ospf6_spf_calculation_thread (ospf6_spf.c:638)
2437395-==2437395== by 0x4904B7E: thread_call (thread.c:1681)
2437395-==2437395== by 0x48CAA27: frr_run (libfrr.c:1126)
2437395-==2437395== by 0x40AF43: main (ospf6_main.c:232)
2437395-==2437395== Block was alloc'd at
2437395:==2437395== at 0x483AB65: calloc (vg_replace_malloc.c:760)
2437395-==2437395== by 0x48D2A32: qcalloc (memory.c:115)
2437395-==2437395== by 0x427CE4: ospf6_route_create (ospf6_route.c:402)
2437395-==2437395== by 0x40BA8A: ospf6_asbr_lsa_add (ospf6_asbr.c:490)
2437395-==2437395== by 0x40C5DF: ospf6_asbr_lsentry_add (ospf6_asbr.c:829)
2437395-==2437395== by 0x42D88D: ospf6_top_brouter_hook_add (ospf6_top.c:185)
2437395-==2437395== by 0x4188E3: ospf6_intra_brouter_calculation (ospf6_intra.c:2320)
2437395-==2437395== by 0x42C624: ospf6_spf_calculation_thread (ospf6_spf.c:638)
2437395-==2437395== by 0x4904B7E: thread_call (thread.c:1681)
2437395-==2437395== by 0x48CAA27: frr_run (libfrr.c:1126)
2437395-==2437395== by 0x40AF43: main (ospf6_main.c:232)
ospfv3 loops through the ecmp routes to decide what to clean up. In some
situations the code free's up an existing route at the head of the list.
Cleaning the pointers in the list but never touching the original pointer.
In that case notice and update the old pointer.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Make return values for lh_get_prefix_str LSA handlers consistent, i.e.
return NULL in case of error without having written to the passed buffer
and non-NULL (address of buffer) if a string was written to the buffer.
Previously, it was possible in certain cases (bogus LSAs) to not initialize
(and 0-terminate) the buffer but still return non-NULL, causing the caller
to print random junk.
Signed-off-by: Martin Buck <mb-tmp-tvguho.pbz@gromit.dyndns.org>
Check whether full struct ospf6_router_lsdesc/ospf6_prefix is accessible
before accessing its contents. Previously, we only checked for the first
byte in ospf6_router_lsa_get_nbr_id() or not even that (due to an additional
off-by-one error) in ospf6_link_lsa_get_prefix_str() and
ospf6_intra_prefix_lsa_get_prefix_str().
Also check *before* accessing the first prefix instead of starting the
checks only at the 2nd prefix.
The previous code could cause out-of-bounds accesses with valid LSAs in case
of ospf6_link_lsa_get_prefix_str() and
ospf6_intra_prefix_lsa_get_prefix_str() and with specially crafted LSAs
(bad length field) in case of ospf6_router_lsa_get_nbr_id().
Signed-off-by: Martin Buck <mb-tmp-tvguho.pbz@gromit.dyndns.org>
Modify code to add JSON format output in show command
"show ipv6 ospf6 interface prefix" with proper formating
Signed-off-by: Yash Ranjan <ranjany@vmware.com>
Modify code to add JSON format output in show command
"show ipv6 ospf6 route [<intra-area|inter-area|external-1|
external-2|X:X::X:X|X:X::X:X/M|detail|summary>]"
with proper formating
Signed-off-by: Yash Ranjan <ranjany@vmware.com>
When removing ospfv3 from an interface that has been previously
put into wait state, there is a possible use after free of the
oi because the wait_timer could have been started for the interface.
This is because the wait_timer was not tracked by the interface
and we just created a thread for it without storing the thread
pointer.
Issue: #7932
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
When redistributing multiple route types into ospfv3
the code must create a new array per route type into
the the json code.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
When the ospfv3 interface is disabled by the command "no interface <eth> area <area-id>
the linked interface prefixes does not get flushed
Signed-off-by: Yash Ranjan <ranjany@vmware.com>
Some prefixes were not shown in the link database
show command, due to issues with pointer calculation.
Signed-off-by: Yash Ranjan <ranjany@vmware.com>
Some prefixes were not shown in the intra-prefix database
show command, due to issues with pointer calculation.
Signed-off-by: Yash Ranjan <ranjany@vmware.com>
1. Created new ospf6_redist structure.
2. Moved the 'route_map' structure from structure 'ospf6' to
structure 'ospf6_redist'.
3. Added new message type OSPF6_REDISTRIBUTE.
4. Added the placeholder for metric option in structure ospf6_redist
for redistribute.
5. Added few API's for route redistribute lookup, add & del.
Signed-off-by: Kaushik <kaushik@niralnetworks.com>
Compare the neighbour id string from the arguments to the router_id of
the neighbor. If equal then call the show function.
Signed-off-by: Yash Ranjan <ranjany@vmware.com>
Apparently the person who wrote this code was big into
cut-n-paste. Commit 710a61d57c
found the first instance, but upon code inspection this morning
it became evident that 2 other functions had the exact same
problem.
Fix. Note I have not cleaned up the cut-n-paste code for
two reasons: a) I'm chasing something else b) this code
has been fairly un-maintained for a very long time. No
need to start up now.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Modify code to add JSON format output in show command
"show ipv6 ospf6 interface" with proper formating
Signed-off-by: Yash Ranjan <ranjany@vmware.com>
Modify code to add JSON format output in show command
"show ipv6 ospf6 interface traffic" with proper formating
Signed-off-by: Yash Ranjan <ranjany@vmware.com>
Modify code to add JSON format output in show command
"show ipv6 ospf6 redistribute" with proper formating
Signed-off-by: Yash Ranjan <ranjany@vmware.com>
Add a `enum zclient_send_status` for appropriate handling
of return codes from zclient_send_message. Touch all the places
where we handle this.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
The route_map_object_t was being used to track what protocol we were
being called against. But each protocol was only ever calling itself.
So we had a variable that was only ever being passed in from route_map_apply
that had to be carried against and everyone was testing if that variable
was for their own stack.
Clean up this route_map_object_t from the entire system. We should
speed some stuff up. Yes I know not a bunch but this will add up.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
