Solved: Run-By Capture Challenge - Something Strange with Multicast

This packet challenge has concluded!

Read on for the solution, or check out the original challenge below!

The Solution

A few folks spotted the issue with multicast packets #4 and #6. Normally, IP layer multicast packets also use a layer 2 multicast destination MAC address. But the multicast packets in this capture are using a unicast destination address.

What is going on here?

It turns out that this capture was generated in a wireless network. The packets originate from a wireless router that is unicasting the IP multicast packets. This technique is called multicast-to-unicast by some wireless vendors and it is used to improve the reliability of multicast in a wireless network. Normally, an 802.11 network will not acknowledge multicast 802.11 frames. But unicast frames are acknowledged.

Ruckus Wireless patented this feature a few years back and you can read more about it here.

http://www.ruckuswireless.com/press/releases/20091207-multicast-patent

The Challenge

Greetings packet geeks,

We come across a lot of weird things when testing broadband customer premises equipment (CPE) with CloudShark’s sister product, CDRouter. Here’s one that baffled us for a moment until we looked deeper. We noticed something unusual (to us anyways) with the following captured packets. Specifically, there is something unexpected in the multicast data packets #4 and #6. Do you see it?

https://www.cloudshark.org/captures/43e4e554c591

Tell us the problem and we’ll send you a CloudShark t-shirt. If you can do some additional research outside of the capture and find out the source of this particular problem, we’ll send you a CloudShark P-CAP hat!