Consider testing for IGMP Membership Reports

[duncangreene]

What is the problem your feature is trying to solve?
IGMP Snooping is a feature on many managed network switches to allow L3 multicast traffic to be propagated as L2 unicast (instead of L2 broadcast). Any end devices that use L3 multicast as part of their functionality should send/respond with IGMP Membership Reports to indicate membership to certain multicast groups.

By way of an example, one of the current tests in Testrun (dns.mdns) listens for mDNS traffic. If a device did indeed implement mDNS, it also ought to send IGMP Membership Reports to indicate to the network switch its need to receive multicast traffic to 224.0.0251.

Describe the solution you think would solve the problem
Implement IGMP Membership Report or Join detection/querying for informational purposes only, with membership reports included in a separate section in the report (much like the detail for NTP and DNS probes, etc.).

Testing could either be done by passive listening for an IGMP join message on DUT start up, or by sending query using something similar to the below nmap command.

nmap --script broadcast-igmp-discovery --script-args 'broadcast-igmp-discovery.version=all'

Additional context
Not all devices implement IGMP, and so in some cases the network administrators have no choice to but to disable IGMP Snooping on their network switches, leading to a more inefficient network.

There are a number of (smart building) protocols that utilise IP multicast, KNXnet/IP Routing being one of the most popular.

More info on multicast and IGMP Snooping here.

[jboddey]

This is out of scope for our testing within Testrun at this stage and so we will not implement it ourselves. We encourage open source contributions and would accept this into the code base provided that a new test module is added and a new test pack is added.