CloudShark Blog

Training, webinars, and resources for network analysis

October 7, 2013

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

Written By
October 7, 2013

Posted to:
Capture Challenge
Multicast Wifi

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.

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?

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!

About Us

CloudShark is made by QA Cafe, a technology company based in Portsmouth, NH. Our passion for packet captures has grown out of our other product CDRouter.

Get in touch via our Contact us page or by following us on your favorite service: