Wireless – Multicast update on wifi network

It appears your network isn't running IPv6 -- no RAs are seen in the capture -- which may be a big part of the problem. Otherwise, it looks like the standard effects of a bunch of windows machines joining the network. Couple that with the simple fact that 99.999% of APs (wifi in general) don't handle multicast worth a damn, and you have the perfect recipe for a meltdown.

[** Multicast is just broadcast to most gear. In the wifi world, broadcast is handled at the "basic rate" which could be as low as 1Mbps. I've tested several APs (linksys, cisco, ...) with an HDHR as the source: it'll unicast two full video stream (39m) QAMs without a single error, but switch to multicast and even a 3M Standard Definition video sub-stream will kill wireless. (disclaimer) I've not done that with a Unifi.]

Alternate Option
1) Disable 802.11b -- use G only, or G/N only.
2) Change the basic-rate selection(s) on the APs. This will significantly reduce the range of each AP. And could cause some clients problems. But, it will increase the bandwidth for broadcast traffic.

(Have you talked to UBNT about your issues with IPv6? They may have nothing for you, but pinging them doesn't cost anything.)

Lets test this out then. If we send multicast packets to multiple devices connected to a WiFi access point at a constant rate, then the access point should report the same amount of traffic.

To run this test, I'm sending packets from a wired PC to an an android tablet and a raspberry pi. Don't have any iOS devices. The network testing tool iperf can easily be used to send and receive these packets with the following settings:

Server (Devices on WiFI): iperf -s -u -B 230.5.5.82

Client (Wired PC): iperf -u -c 230.5.5.82 -t 60 -b 1M

With these settings we're sending multicast packets at 1Mbps for a minute. Running this test and looking at the wireless traffic on the access point shows it is consistently about 1Mbps so it must be doing true multicast. The other notable thing from the results is that the packet loss is really bad at well over 50%. This is likely because multicast packets are getting sent at the lowest possible speed so lets force the access point to only run in the fastest speed. I'm using a WRT54GL running dd-wrt where the setting is called "Transmission Fixed Rate". Running the same tests again after setting this to the fastest speed gives a much more acceptable packet loss of less than 5%.

To actually answer the questions:

1. Get the fastest access point that allows you to fix the transmission rate and that supports multicast. There are definitely access points that do automatically convert multicast packets to unicast. For the speed issue, it isn't enough to just use a wide 5GHz channel since there are a number of different speeds that clients can actually communicate at.

2. Can't imagine things would work differently on iOS devices since the main determining factor would be the access point.

3. See 1 as it depends on the access point.

Edit: After testing things out more and on some ac APs, it turns out the important thing for mulitcast is being able to set the available rates. Multicast still uses g speeds so the available physical rates are 6, 9, 12, 18, 24, 36, 48 and 54Mbps. Most APs are going to default to the slower speeds so being able to disable them to force it to use the higher rates will give a huge speed up. Being able to set this is probably the most important criterion for a multicast AP. As an example, in modern versions of DD-WRT, this can be set using the "wl rateset" command on the command line. It sure is well hidden and most firmware doesn't allow this to be set.