Repository navigation
Conversation
Scapy 2.8 aliases contrib IGMPv3mr to IGMPv3_MR, which already includes the IGMP header, and IGMPv3() with no bytes was built as an IGMPv1/v2 query. The old stack therefore sends an invalid report: a Membership Query with a second report glued on. Receivers such as FRR pimd treat the packet as a query and install no group. Drop the bare header when it is stacked with a complete v3 message. This broke FRR's IGMPv3 fragmentation topotest: FRRouting/frr#23533 Signed-off-by: Jafar Al-Gharaibeh <jafar@atcorp.com>
Jafaral
changed the title
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Scapy 2.8 broke existing applications that still use the old API,
IGMPv3() / IGMPv3mr(...).The compatibility aliases are wrong.
IGMPv3mrpoints atIGMPv3_MR, which already includes the IGMP header, and a bareIGMPv3()is built as an IGMPv1/v2 Membership Query. That stack sends an invalid report: a query with a second report glued on. On 2.7 the same call was one Membership Report (type0x22).FRR pimd reads the first IGMP type, treats the packet as a query, and installs no group. That broke FRR's IGMPv3 fragmentation topotest: FRRouting/frr#23533
A bare
IGMPv3stacked with a complete v3 message now keeps that message, so the old API builds one report again.IGMPv3_MQandIGMPv3_MRare unchanged. Covered intest/scapy/layers/igmp.uts.