For consistency,
I'll follow a similar packet analysis process for all
IGMPv2 packets as I did for IGMPv1.
Let's begin with the membership query.
The source and destination addressing is unchanged from IGMPv1,
so I won't cover that again.
However, notice the word general in the packet description.
IGMPv2 introduces the concept of general and group-specific queries,
thanks to the leave capability.
Notice the IGMP type is 11 in hex or 17 in decimal, just like IGMPv1.
This packet was recycled between v1 and v2 because it was easily extensible.
Wireshark knows this is an IGMPv2 query because the code is non-zero.
The code carries the IGMP maximum response time,
which is an upper bound on how long the router is willing to
wait after asking who wants multicast.
The hex value of 19 represents the amount of time in tenths of seconds.
Nineteen in hex equal 25 in decimal, so 25 tenths of a second yields 2.5 seconds.
Wireshark graciously does this math for us.
Like IGMPv2,
the multicast group address carried in the general
query message is always set to 0,
since the message is only checking to see if
receivers want any kind of multicast.
IGMPv2 membership reports are almost identical to IVMPv1 membership reports.
The source and destination addressing is also unchanged,
so let's not dwell on it.
The IGMPv2 membership report uses type 16 in hex or 22 in decimal.
This is different than IGMPv1 despite the packets being almost identical.
This update allows a multicast router to differentiate
between v1 and v2 membership reports.
The maximum response time in membership reports is always 0 and is ignored.
Finally,
the packet carries the multicast group the client wishes to join
effectively answering the query's question of who wants multicast
with I want multicast on group 239.2 .2 .2.
This is similar to IGMPv1.
In the interest of time,
I'll skip the packet deep dive on the second membership
report because it's the same as this one, except that it joins group 239.1 .1 .1.