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

net: ip: igmp: add IGMPv3 support #65293

Merged
merged 3 commits into from Nov 21, 2023

Conversation

IVandeVeire
Copy link
Contributor

@IVandeVeire IVandeVeire commented Nov 16, 2023

Added IGMPv3 support by implementing the basics of RFC 3376. I used the already existing structure of IGMPv2 as reference without changing the existing IGMP api. IGMPv3 can be enabled by enabling CONFIG_NET_IPV4_IGMPV3.

@IVandeVeire IVandeVeire changed the title Add IGMPv3 support net: ip: igmp: add IGMPv3 support Nov 16, 2023
@IVandeVeire IVandeVeire force-pushed the add_igmpv3 branch 3 times, most recently from 7843a62 to f852baf Compare November 16, 2023 13:11
subsys/net/ip/igmp.c Show resolved Hide resolved
subsys/net/ip/igmp.c Outdated Show resolved Hide resolved
subsys/net/ip/igmp.c Outdated Show resolved Hide resolved
* @return Return 0 if joining was done, <0 otherwise.
*/
#if defined(CONFIG_NET_IPV4_IGMPV3)
int net_ipv4_igmpv3_join(struct net_if *iface, const struct in_addr *addr, bool include,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we need/want to have a separate API for IGMPv3? I'd rather see it in a way, that we have a single net_ipv4_igmp_join/leave() API, and with Kconfig you select whether it should send IGMPv2 or IGMPv3 queries.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I created a separate API because IGMPv3 has some additional arguments/functionality. How would you add the filter groups to a request if the API remains unchanged? For leaving a group, Kconfig should do the job indeed.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not saying the API has to remain unchanged, I just put under discussion whether it makes sense to have a separate API for IGMPv3 only. Right now it's a bit counter-intuitive for me, that even after enabling IGMPv3 most (if not all) of the networking components would still send IGMPv2 reports.

Just as an idea, net_ipv4_igmp_join() could accept an additional (optional) struct igmp_param * argument, with content dependent on the enabled IGMP version, with some reasonable fallback behavior if not provided (no filters for IGMPv3 if that makes sense). Net components that do not care about this additional functionality (is it just filtering or more?) could just skip the parameter.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

IGMPv3 does only support filters. I try your suggestion and see how that turns out.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree with @rlubos, the public APIs should not need to mention v2/v3 etc. but be generic as the caller does not need to care what IGMP version we are using.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I made the join/leave more generic. Now, the IGMP version is selected by the config. I added an optional param struct like @rlubos suggested.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I will add extra tests and needed documentation for the change of the public API once the changes are on point.

subsys/net/ip/igmp.c Outdated Show resolved Hide resolved
subsys/net/ip/igmp.c Outdated Show resolved Hide resolved
subsys/net/ip/igmp.c Outdated Show resolved Hide resolved
subsys/net/ip/net_private.h Outdated Show resolved Hide resolved
subsys/net/ip/utils.c Outdated Show resolved Hide resolved
* @return Return 0 if joining was done, <0 otherwise.
*/
#if defined(CONFIG_NET_IPV4_IGMPV3)
int net_ipv4_igmpv3_join(struct net_if *iface, const struct in_addr *addr, bool include,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree with @rlubos, the public APIs should not need to mention v2/v3 etc. but be generic as the caller does not need to care what IGMP version we are using.

@IVandeVeire IVandeVeire force-pushed the add_igmpv3 branch 4 times, most recently from d9b7053 to 5e0b19d Compare November 20, 2023 11:20
@IVandeVeire
Copy link
Contributor Author

I will add extra tests and needed documentation for the change of the public API once the changes are on point.

Added igmpv3 checksum function to make it possible to calculate the
checksum of a complete igmpv3 pkt at once.

Signed-off-by: Ibe Van de Veire <ibe.vandeveire@basalte.be>
@IVandeVeire IVandeVeire force-pushed the add_igmpv3 branch 2 times, most recently from 46e3c44 to 4fc5710 Compare November 20, 2023 15:12
Copy link
Contributor

@rlubos rlubos left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you for addressing the feedback so far. Spotted a few more nits, but otherwise looks pretty good to me.

include/zephyr/net/igmp.h Outdated Show resolved Hide resolved
include/zephyr/net/igmp.h Outdated Show resolved Hide resolved
include/zephyr/net/net_if.h Outdated Show resolved Hide resolved
subsys/net/ip/igmp.c Outdated Show resolved Hide resolved
@IVandeVeire IVandeVeire force-pushed the add_igmpv3 branch 3 times, most recently from 4fab65d to 2dd7704 Compare November 20, 2023 16:45
Copy link
Member

@jukkar jukkar left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good, I found couple of minor nits that we could change.

include/zephyr/net/net_if.h Outdated Show resolved Hide resolved
include/zephyr/net/igmp.h Outdated Show resolved Hide resolved
subsys/net/ip/igmp.c Outdated Show resolved Hide resolved
subsys/net/ip/igmp.c Outdated Show resolved Hide resolved
subsys/net/ip/igmp.c Outdated Show resolved Hide resolved
subsys/net/ip/igmp.c Outdated Show resolved Hide resolved
@zephyrbot zephyrbot added the Release Notes To be mentioned in the release notes label Nov 21, 2023
subsys/net/ip/igmp.c Outdated Show resolved Hide resolved
subsys/net/ip/igmp.c Outdated Show resolved Hide resolved
subsys/net/ip/igmp.c Outdated Show resolved Hide resolved
Added igmpv3 support based on the already existing structure for igmpv2.
The already existing api is not modified to prevent breaking exisiting
applications.

Signed-off-by: Ibe Van de Veire <ibe.vandeveire@basalte.be>
Added note about the migration steps needed to support the new IGMP api.
The api now expects an additional argument used for joining an IGMPv3
group.

Signed-off-by: Ibe Van de Veire <ibe.vandeveire@basalte.be>
Copy link
Member

@jukkar jukkar left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@IVandeVeire Thanks for the support, much appreciated!

Copy link
Contributor

@rlubos rlubos left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@carlescufi carlescufi merged commit a43e516 into zephyrproject-rtos:main Nov 21, 2023
19 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area: Networking Release Notes To be mentioned in the release notes
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants