Valgrind is reporting this:
==22220== Invalid read of size 4
==22220== at 0x11DC2B: pim_if_delete (pim_iface.c:215)
==22220== by 0x11DD71: pim_if_terminate (pim_iface.c:76)
==22220== by 0x128E03: pim_instance_terminate (pim_instance.c:66)
==22220== by 0x128E03: pim_vrf_delete (pim_instance.c:159)
==22220== by 0x48E0010: vrf_delete (vrf.c:251)
==22220== by 0x48E0010: vrf_delete (vrf.c:225)
==22220== by 0x48E02FE: vrf_terminate (vrf.c:551)
==22220== by 0x149495: pim_terminate (pimd.c:142)
==22220== by 0x13C61B: pim_sigint (pim_signals.c:44)
==22220== by 0x48CF862: quagga_sigevent_process (sigevent.c:103)
==22220== by 0x48DD324: thread_fetch (thread.c:1404)
==22220== by 0x48A926A: frr_run (libfrr.c:1122)
==22220== by 0x11B85E: main (pim_main.c:167)
==22220== Address 0x5912160 is 1,200 bytes inside a block of size 1,624 free'd
==22220== at 0x48369AB: free (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==22220== by 0x128E52: pim_instance_terminate (pim_instance.c:74)
==22220== by 0x128E52: pim_vrf_delete (pim_instance.c:159)
==22220== by 0x48E0010: vrf_delete (vrf.c:251)
==22220== by 0x48E0010: vrf_delete (vrf.c:225)
==22220== by 0x48F1353: zclient_vrf_delete (zclient.c:1896)
==22220== by 0x48F1353: zclient_read (zclient.c:3511)
==22220== by 0x48DD826: thread_call (thread.c:1585)
==22220== by 0x48A925F: frr_run (libfrr.c:1123)
==22220== by 0x11B85E: main (pim_main.c:167)
==22220== Block was alloc'd at
==22220== at 0x4837B65: calloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==22220== by 0x48ADA4F: qcalloc (memory.c:110)
==22220== by 0x128B9B: pim_instance_init (pim_instance.c:82)
==22220== by 0x128B9B: pim_vrf_new (pim_instance.c:142)
==22220== by 0x48E0C5A: vrf_get (vrf.c:217)
==22220== by 0x48F13C9: zclient_vrf_add (zclient.c:1863)
==22220== by 0x48F13C9: zclient_read (zclient.c:3508)
==22220== by 0x48DD826: thread_call (thread.c:1585)
==22220== by 0x48A925F: frr_run (libfrr.c:1123)
==22220== by 0x11B85E: main (pim_main.c:167)
On pim vrf deletion, ensure that the vrf->info pointers are NULL as well
as the free'd pim pointer for ->vrf is NULL as well.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Issue: #7892 has a startup config where only igmp
interfaces are created and a igmp report comes in.
Effectively we are not creating the regiface device unless
we do a `ip pim`. This is incorrect we should always create
the regiface.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
1. As per RFC 4601 Sec 4.5.7:
* JoinDesired(S,G) -> False, set SPTbit to false.
2. Change the debug type.
Signed-off-by: Mobashshera Rasool <mrasool@vmware.com>
This command has been added in the context of
PIM BSM functionality. This command will clear the
data structs having bsr information.
Co-authored-by: Sarita Patra <saritap@vmware.com>
Signed-off-by: vishaldhingra <vdhingra@vmware.com>
Test case 5.10 sends leave message to unicast address, the leave
packet is accepted and a query message is sent in response to this.
No validation for address is present in the function
Add check for addresses as per RFC. Leave messages are allowed only
sent to either ALL-ROUTERS (224.0.0.2) or group address.
Signed-off-by: Mobashshera Rasool <mrasool@vmware.com>
1. When a node changes from non-DR to DR in the given topology,
the node was receiving both PIM Join as well as IGMP join.
Since it was already receiving PIM Join previously, ifchannel was
already present. Hence when it becomes DR, the IGMP source flag is not
set due to issue in the code. Hence it never creates S,G entry thinking
that it is not DR.
2. When pim join expires, the pim flag is not reset when ifchannel is not
deleted.
Issue: #7752
Signed-off-by: Mobashshera Rasool <mrasool@vmware.com>
The flag "R" in below display description denotes the
SGRpt Pruned but the description shows something else
hence correcting the definition.
R2(config)# do show ip mroute
IP Multicast Routing Table
Flags: S- Sparse, C - Connected, P - Pruned
R - RP-bit set, F - Register flag
Signed-off-by: Mobashshera Rasool <mrasool@vmware.com>
Issue:
Configure msdp mesh mg1 for 2 groups.
ip msdp mesh-group mg1 member 1.1.1.1
ip msdp mesh-group mg1 member 1.1.1.2
Remove mg1 for 1.1.1.1
no ip msdp mesh-group mg1 member 1.1.1.1
mg1 for 1.1.1.1 still present. This is fixed.
Signed-off-by: Sarita Patra <saritap@vmware.com>
Issue:
Configure RP.
ip pim rp 20.0.0.1 239.1.1.1/32
ip pim rp 20.0.0.1 239.1.1.2/32
Remove RP.
no ip pim rp 20.0.0.1 239.1.1.1/32
Rp is not removed. This is fixed now.
Signed-off-by: Sarita Patra <saritap@vmware.com>
The pim_version.[c|h] files are never used and we are getting
warnings about PIM_VERSION changing pointer sizes from
newer versions of the compiler. I see no reason to keep this
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
pim is enabled internally/implicitly on the vxlan termination device
and displaying that can confuse the admin and tools (such as
frr-reload).
Ticket: CM-30180
Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
If we screw up and don't have the right flags we'll print
out garbage. At the very least just print out nothing.
Signed-off-by: Donald Sharp <sharp@nvidia.com>
Issue: When an IGMPv2 leave packet is received, it did not validate
the checksum and hence the packet is accepted and group specific
query is sent out in response to this.
Due to this IGMP conformance test case 6.1 failed.
https://github.com/FRRouting/frr/issues/6868
Fix: Validate the checksum for all IGMP packets
Signed-off-by: Mobashshera Rasool <mrasool@vmware.com>
The `enum zclient_send_status` enum needs to be extended
throughout the code base to use the new states and
to fix up places where we tested against the return
value being non zero.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
problem :
=========
When (*,G) prune received where we have SGRpt state,
ifchannel goes to NO_INFO state and doesn't get removed.
Root cause :
============
During the processing of (*,G) prune, we are not removing the
ifchannel on PruneTmp or PrunePendingTmp state.
Fix :
=====
In that scenario, stop joinExpiry timer and delete the ifchannel.
issue #7347
Co-authored-by: Saravanan K <saravanank@vmware.com>
Signed-off-by: vishaldhingra <vdhingra@vmware.com>
