-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
Comments
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
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
Description
Filing this to keep track of the issue:
Version
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
The text was updated successfully, but these errors were encountered: