Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

PIM crashes when receiving an ssm and asm joins for the same group on the same interface #15630

Open
2 tasks done
Jafaral opened this issue Mar 27, 2024 · 0 comments · May be fixed by #16115
Open
2 tasks done

PIM crashes when receiving an ssm and asm joins for the same group on the same interface #15630

Jafaral opened this issue Mar 27, 2024 · 0 comments · May be fixed by #16115
Labels
pim triage Needs further investigation

Comments

@Jafaral
Copy link
Member

Jafaral commented Mar 27, 2024

Description

Filing this to keep track of the issue:

2024/03/27 21:40:22 PIM: [QZ7CA-ASJZG] eth2: NOCACHE for (192.168.1.2,239.1.2.3), MFC entry disappeared - reinstalling
2024/03/27 21:40:29 PIM: [GH8RT-48SNC] igmp_source_forward_start: (S,G)=(192.168.1.2,239.1.2.3) ASM range having source address, not allowed to create PIM state
PIM: Received signal 11 at 1711575656 (si_addr 0x0, PC 0x7fd07abb144d); aborting...
PIM: /usr/lib/x86_64-linux-gnu/frr/libfrr.so.0(zlog_backtrace_sigsafe+0x71) [0x7fd07ab70eb1]
PIM: /usr/lib/x86_64-linux-gnu/frr/libfrr.so.0(zlog_signal+0xf5) [0x7fd07ab710b5]
PIM: /usr/lib/x86_64-linux-gnu/frr/libfrr.so.0(+0xe54d5) [0x7fd07aba54d5]
PIM: /lib/x86_64-linux-gnu/libc.so.6(+0x42520) [0x7fd07a8be520]
PIM: /usr/lib/x86_64-linux-gnu/frr/libfrr.so.0(typed_rb_remove+0xbd) [0x7fd07abb144d]
PIM: /usr/lib/frr/pimd(pim_channel_oil_del+0xb9) [0x562421604a39]
PIM: /usr/lib/frr/pimd(tib_sg_gm_prune+0x77) [0x562421607a07]
PIM: /usr/lib/frr/pimd(igmp_source_forward_stop+0x65) [0x56242162b475]
PIM: /usr/lib/frr/pimd(igmp_get_source_by_addr+0x6c) [0x56242162e8cc]
PIM: /usr/lib/frr/pimd(+0xab024) [0x562421634024]
PIM: /usr/lib/frr/pimd(igmp_v3_recv_report+0x585) [0x5624216324f5]
PIM: /usr/lib/frr/pimd(pim_igmp_packet+0x3da) [0x562421632daa]
PIM: /usr/lib/frr/pimd(+0x7753e) [0x56242160053e]
PIM: /usr/lib/frr/pimd(+0x7768d) [0x56242160068d]
PIM: /usr/lib/x86_64-linux-gnu/frr/libfrr.so.0(event_call+0x84) [0x7fd07abba744]
PIM: /usr/lib/x86_64-linux-gnu/frr/libfrr.so.0(frr_run+0xd8) [0x7fd07ab6a818]
PIM: /usr/lib/frr/pimd(main+0xf6) [0x5624215dfcd6]
PIM: /lib/x86_64-linux-gnu/libc.so.6(+0x29d90) [0x7fd07a8a5d90]
PIM: /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0x80) [0x7fd07a8a5e40]
PIM: /usr/lib/frr/pimd(_start+0x25) [0x5624215dff65]

Version

9.1

How to reproduce

send two igmp joins on the same interface one ssm and one asm.

Expected behavior

no crash

Actual behavior

crash

Additional context

No response

Checklist

  • I have searched the open issues for this bug.
  • I have not included sensitive information in this report.
@Jafaral Jafaral added triage Needs further investigation pim labels Mar 27, 2024
Jafaral added a commit to Jafaral/frr that referenced this issue May 30, 2024
…terface

Fixes: FRRouting#15630

Signed-off-by: Jafar Al-Gharaibeh <jafar@atcorp.com>
@Jafaral Jafaral linked a pull request May 30, 2024 that will close this issue
Jafaral added a commit to Jafaral/frr that referenced this issue May 31, 2024
…terface

There is no reason to call `igmp_anysource_forward_stop()` inside a call to
`igmp_get_source_by_addr()`; not only it is not expected for a "get" function
to perform such an action, but also the decision to start/stop forwarding is
already handled correctly by pim outside `igmp_get_source_by_addr()`.
That call was left there from the days pim was initially imported into the sources.

The problem/crash was happening because `igmp_find_source_by_addr()` would fail to
find the group/source combo when mixing `(*, G)` and `(S, G)`. When having an existing
flow `(*, G)`, and a new `(S, G)` igmp is received, a new entry is correctly created.
`igmp_anysource_forward_stop(group)` always stops and eventually frees `(*, G)`, even
when the new igmp is `(S, G)`, leaving a bad state. I.e, the new entry for `(S, G)`
causes `(*, G)` to be deleted.

Tested the fix with multiple receivers on the same interface with several ssm and
any source senders and receivers with various combination of start/stop orders and
they all worked correctly.

Fixes: FRRouting#15630

Signed-off-by: Jafar Al-Gharaibeh <jafar@atcorp.com>
Jafaral added a commit to Jafaral/frr that referenced this issue May 31, 2024
There is no reason to call `igmp_anysource_forward_stop()` inside a call to
`igmp_get_source_by_addr()`; not only it is not expected for a "get" function
to perform such an action, but also the decision to start/stop forwarding is
already handled correctly by pim outside `igmp_get_source_by_addr()`.
That call was left there from the days pim was initially imported into the sources.

The problem/crash was happening because `igmp_find_source_by_addr()` would fail to
find the group/source combo when mixing `(*, G)` and `(S, G)`. When having an existing
flow `(*, G)`, and a new `(S, G)` igmp is received, a new entry is correctly created.
`igmp_anysource_forward_stop(group)` always stops and eventually frees `(*, G)`, even
when the new igmp is `(S, G)`, leaving a bad state. I.e, the new entry for `(S, G)`
causes `(*, G)` to be deleted.

Tested the fix with multiple receivers on the same interface with several ssm and
any source senders and receivers with various combination of start/stop orders and
they all worked correctly.

Fixes: FRRouting#15630

Signed-off-by: Jafar Al-Gharaibeh <jafar@atcorp.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
pim triage Needs further investigation
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant