My company has a large opportunity to deploy a Mikrotik network to deliver multicast traffic to iPhones and other smartphones.

During testing, we found that the iPhones lost nearly 90% of packets sent by MT AP's. However, packet loss was less than 5% when the test iPhones were associated with AP's from Cisco/Linksys, Apple, Belkin, D-link, and Netgear.

The tests were replicated in 3 different labs using ROS 4.11 through 5.14. The MT devices used RB411 and RB433 and a mix of radios from Mikrotik and Ubiquiti.

The test environment was a single ethernet LAN with a single unix machine sending multicast traffic to the AP under test, which was serving a single iPhone client. No routing was needed, just bridging from ethernet to AP.

To find the difference between the MT products and all the rest, I used Wireshark (v1.6.5) to capture packets over the air using a separate machine (an iMac), not on the physical LAN, to listen for the multicast packets over the air.

After two weeks of comparing packet traces under all sorts of conditions, the only difference I could find was that the MT beacon frames contained zeros where the sequence number should be. All other brands of AP incremented the sequence number in each successive beacon.

Because the iPhone OS is proprietary, I have no way to prove that the absence of beacon sequence numbers is the cause of this problem. The evidence is circumstantial, but I can find no other differences. The actual multicast data frames are identical except for the SSID and Frame Check Sequence. All FCS values are reported as correct by Wireshark.

Can anyone comment on the lack of sequence numbers in beacons? Has anyone else noticed this? Can any Mikrotik folks shed some light on this? Is there a way to have the MT AP generate proper beacon sequence numbers?

If I can't get this to work, this opportunity is a nonstarter.

edit: Updated to show test results are current through v5.14.

there is obviously some problem with your configuration, as iPhones work fine for everybody else. Need more information about config.

I would be thrilled if you could find some configuration problem that I could easily fix. I'm not in the lab now, but I'm arranging for remote access so I can upload the (very simple) configuration in my next post.

In the meantime, perhaps Normis, you could address the issue of zero sequence numbers in the beacons?

I suppose I would have attributed these problems to an "obvious" configuration error if someone came to me with this situation. Of course we all know that iPhones work just fine for everybody else, except that what we think we know would be incorrect in this case.

As far as I have been able to determine, no one is using iPhones for receiving multicast packets from MT AP's. All of the iPhone traffic, including on my network, is unicast. There are a few multicast applications for iPhone, but I don't think any of them are being served by MT equipment. I previously posted a query on this board on January 18 about wifi multicast to iPhones and there were no responses.

Here are some other configuration details, while I'm waiting for remote access to the RB411 in my lab:

The LAN subnet is 192.168.1.0/24 . The DHCP server for this subnet is a RB493H, which is also the gateway to the Internet. This RB493 has no radios and is not participating in the testing, other than to supply IP addresses via DHCP to the transmitter host and the iPhone.

We tested with two different transmitters, written by two different people, in two different languages, running on two different machines.

The first transmitter was written by a consultant who wrote an application for MAC using objective C.
The second transmitter was written by me and runs on Linux, using C.

The Mac version uses the high-level API provided by Apple to generate multicast UDP packets.
The Linux version uses the low-level BSD socket interface.

Both transmitters generate the same packets. The destination IP is 224.0.0.1, port 50000. UDP packet size is 1000 bytes. Data rates are variable and testing was performed from 1 packet per second ( 8 kbits/sec) up to 100 packets/second (800 Kbits/second).


We tested two different receiver app's on the iPhone.
The consultant wrote an app using the latest apple high level network interface.
I wrote an app using BSD sockets, which is supported on the iPhone.

Both apps bind to port 50000 and listen for packets. As packets are received, they are counted and sequence numbers in the data portion of the packets (inserted by the transmitter) are checked to see if any packets were dropped.

Test results are consistent for both transmitters and both receivers in all three locations across the various MT and non-MT AP's.

Yes, I sure would suspect that I messed up the MT configuration, but how? It's so simple.
There is one bridge, with two ports: ether1 and AP.
I know the bridge is working because the iPhone's DHCP request is bridged back to the DHCP server and gets an IP address.

I believe the AP configuration is correct because unicast packets, like web browsing and email collection, work fine from the iPhone. Only multicast fails with just a few packets trickling in.

I will post the full configuration shortly.

Here is the configuration from a RB433 that was among 4 used for the testing:
edit: Used export compact to save space

I'm surprised no one seems concerned over the issue of beacons that are not in compliance with 802.11 standards. While I can't prove that this is the cause of the iPhone problems, it still is a compliance issue. I'm going to post the Wireshark trace here from Mikrotik AP's and Cisco AP's so everyone can see what I'm referring to.

Also my business client was able to reach someone in Apple's networking group and Apple has requested the Wireshark traces also.

I have over a hundred Mikrotik nodes in 3 states so I would love to find out that this is my error.

Normis, you asked for more information about my config, which I posted last week. Would you prefer that I submit a support ticket and take this discussion off the forum?

We also have had problems with iPhones connecting to MT but only iPhone 3, 3G, 3GS and gen2 ipod touch. All newer devices and ipads work perfectly.

All of our tests were with iPhone 3GS hardware running iOS 5, which is the latest OS version. I'll find someone with
a new iPad and a new iPhone to test with.

When you were having these problems. was the traffic standard unicast traffic, rather than multicast?

As promised, here are the Wireshark packet captures for Cisco beacon frames and Mikrotik beacon frames.

The Beacon Frame sequence number is identified by "SN=" in the Wireshark capture.

Note that Cisco beacons (as well as Netgear, Airport, D-link, and Belkin) have sequence numbers as required by 802.11, while Mikrotik beacons(ROS 5.12 in this test) have zero where the sequence number should be.

This should be easy for others to reproduce. I can't prove (yet) that this is causing my problems with iPhone multicast reception, but it appears to be an 802.11 protocol violation. I would welcome the opinion of others and of course the test results of others.

Cisco: Mikrotik:

dsobin please reset your configuration and see if it works with blanc config, simple AP settings (enable ap-bridge and that's all!)

Would you prefer that I submit a support ticket and take this discussion off the forum?

yes, this is a user forum, if you want official mikrotik support, please email us! this would give faster response times.

I upgraded to ROS 5.13, reset the config, set the radio to AP-bridge, and bridged the radio to ether1. Same results. Many multicast packets dropped.

Also, the beacons continue to be broadcast without sequence numbers, in apparent violation of 802.11 protocol.

I will submit this directly to support, while continuing to post status on this thread for those who may have an interest in multicast over wifi.

in apparent violation of 802.11 protocol

I was not aware that it was mandatory for beacon Management Frames to have a valid incrementing sequence number. Only that it has one. Which it has, except that it does not increment. Have you got any reference material to show that a "genuine" incrementing sequence number is mandatory in 802.11? (Not saying you're wrong - just can't see where it says it!)

I know that Mikrotik have been sending Beacons like this for a long time, so it's not unique to v5.12.

The other thing I have noticed from your config is that you've put the interfaces AP and ether1 ports into a bridge, but have assigned the IP to ether1. It should be assigned to bridge1. Ports should not have IPs, if they are a member of a bridge.

Per IEEE Standard 802.11-2007 (emphasis is mine)

7.1.3.4.1 Sequence Number field
The Sequence Number field is a 12-bit field indicating the sequence number of an MSDU or MMPDU. Each MSDU or MMPDU transmitted by a STA is assigned a sequence number. Sequence numbers are not assigned to control frames, as the Sequence Control field is not present.

Non-QoS STAs, as well as QoS STAs operating as non-QoS STAs because they are in a non-QoS BSS or non-QoS IBSS, assign sequence numbers, to management frames and data frames (QoS subfield of the Subtype field is set to 0),from a single modulo-4096 counter, starting at 0 and incrementing by 1 for each MSDU or MMPDU.

You're right about this not being unique to v5.12. As I mentioned in my initial post, I tested with versions from 4.11 through 5.12 (now 5.14). Interestingly, I observe that a very old ROS 3.30, which I can no longer access for testing, DOES have working sequence numbers, so the sequence number feature was lost somewhere between 3.30 and 4.11.

I assigned the IP address to the ethernet port instead of the bridge because the address was assigned to facilitate configuration before I created the bridge. In production systems, I always move the IP address to the bridge. In this test setup, the IP address isn't used at all. However, I appreciate your taking the time to read through all of that configuration data!

My current testing seems to now point to a problem with station power save mode. Wireshark packet captures show the Mikrotik AP failing to buffer multicast packets while the iPhone is "dozing" in power save mode between Beacon frames. All of the other brands of AP properly buffer the multicast packets and send them during the DTIM interval after an appropriate Beacon flag indicating that sleeping stations should stay awake for a multicast burst.

Note that I'm not using WMM power save mode, which is an extension to 802.11. I'm using the "legacy" power save mode, which has been around for a long time.

I've sent all of the supporting material to MT support and I'm waiting for a response. I'll post results here as they come in.

If anyone would like to peruse the wireshark capture file, let me know and I'll send it directly. The capture file is too big to attach here.

I just did a test using an old RB532 and ROS 2.9.50.

Beacon sequence numbers increment as they are supposed to.
Multicast packets are correctly indicated by setting the multicast bit in the TIM of the Beacon frame whenever there are clients that are in power save mode.

It appears that a bug was introduced between 3.30 and 4.11 that broke the Beacon sequence numbers.
Another bug (not necessarily related) was introduced between 2.9.50 and 4.11 that broke the transmission of multicast packets when there are one or more clients in power save mode.

I'm still waiting for an update from Mikrotik support. I've been sending all updates to them directly as well as posting here. I'm keeping this thread updated in case anyone out there is having the same problems with wifi multicast as I am.

Did you receive any updates from Mikrotik?

I bought an Apple TV this weekend, connected it to the ethernet and Airplay connections from my Wifi from/to it are not working most of the time. When I connect the clients to the ethernet it works fine (but that's not really possible for iphones/ipads).

I suspect the same multicast issue to be responsible for this.

I confirm this problem which is related to energy power saving in the WiFi network. I have a Nokia E71. If I turn on energy power saving in the advanced WiFi settings this problem does exist. Nokia connects to the Internet, but the device from the LAN (connected to the same Mikrotik WiFi AP) can't connect to the phone. Disabling power saving solves this problem, but the battery discharges quickly ...
Sorry for my english

If you are using a Mikrotik AP, you will not be able to use Apple's Airplay or any other multicast service via wifi on a handheld device that uses power save mode (which is pretty much all handheld devices).

Mikrotik has been working on this problem and I've received some updates for debugging. So far, the results are promising, but there are still a few issues to work out. Once we have converged on a solution that we are both satisfied with, Mikrotik will include it in the next v5 release.

However, it also seems that Apple has done some things to its multicast implementation that prevents packets from crossing between different subnets. This would be a bit unusual in a home situation.

If your ethernet and your wifi are both on the same subnet, then you are seeing the Mikrotik broken wifi multicast problem.

If the ethernet and wifi are on different subnets (e.g. ethernet is 192.168.1.x and wifi is 192.168.2.x), then you are experiencing an Apple-related problem. This is an unusual configuration, however.

In the unlikely event that you have different subnets for ethernet and wifi, even if you fixed this, Airplay still wouldn't work because of the current lack of ROS multicast support for wifi.

Sorry you're having this problem. Multicast over wifi is becoming increasingly popular, so I'm sure there are going to be many more people experiencing this problem. I'm hoping the final fix will be soon!

Thanks for the update and your efforts dsobin.. I'll just wait for the new release and use my old AP in the meantime..

Glad to have been some help!

Thank you for the update.

Do you happen to have any idea on a timescale for resolution - we've specced out a job to install circa 49 lodges with Mikrotik APs, as they will have an apple TV in each lodge and the core requirement is to be able to use AirPlay to stream from ipad to apple tv.

Kinda leaves me up sh*t creek without a paddle if this setup won't work as all pricing and project has been signed off by customer.

stream from ipad to apple tv

Did you mean that direction? If you mirror an iPad's screen on the Apple TV, I believe it uses unicast, not multicast. That should work fine.

If you want to watch content on the iPad that is AirPlay streamed from the Apple TV, that's multicast and you're out of luck until this is fixed.

The version I'm testing is v6.0alpha1, not for distribution. Once it's working, they will port it to the next release of v5.

On Friday, I sent them some supout.rif files which had occurrences of the AP freezing. They were closed from Friday to Monday for the holiday. I'm expecting to hear back soon, based on past performance. I don't know how long it will take after all the bugs are worked out to come out with a new v5 release.

I'm afraid I have no definitive answer to when they will have this fixed. They seem to be working hard on it. I hope they're reading this thread and see that there really is a need for wifi multicast besides my application.

Goodnews!

With 5.15, my computer is able to connect with Nokia which uses energy power saving and connects to the Mikrotik.

Unfortunately, energy power saving is not so good in comparison to the access points of other manufacturers. My mobile phone eats battery faster when connects with Mikrotik..

With the beta release of v5.15, the wifi multicast feature is back!

I've done extensive testing and it seems to be stable. Thanks to the folks at Mikrotik for working so diligently to get us new releases almost daily as our testing progressed.

The DTIM interval on Mikrotik is set to one and cannot be changed. This results in the highest battery drain on handheld devices, but better throughput.

An Apple Mac Mini, for example, defaults to a DTIM of 3. Handheld devices have longer battery life, but performance isn't as good.

Many AP's allow the user to change the DTIM interval. Mikrotik does not allow this.

Maybe this feature will show up in a future release.

Most importantly, we now have our wifi multicast back!

We still seem to have a problem with multicast on v5.15.

During multicast transmission, the AP sometimes will freeze. In this frozen mode, no data will be transmitted by the AP. Both unicast and multicast stop.

In order to get things going again, we are usually able to disable the AP, then enable again. On one occasion however, we had to reboot the router.

We've sent several supout files to Mikrotik and they are working on a solution.

We are unable to determine how to reproduce the freeze condition. It appear to be random.

CPU load never exceeds 10% and available memory stays at the value it had when the router was booted.

We sent v5.15 to our potential customer and they had one occurrence of the freeze.

I'll keep this thread updated if I get any new data.

a few more have the same issue you found
let's hope there's a fix for this problem

We still seem to have a problem with multicast on v5.15.

During multicast transmission, the AP sometimes will freeze. In this frozen mode, no data will be transmitted by the AP. Both unicast and multicast stop.

In order to get things going again, we are usually able to disable the AP, then enable again. On one occasion however, we had to reboot the router.

We've sent several supout files to Mikrotik and they are working on a solution.

We are unable to determine how to reproduce the freeze condition. It appear to be random.

CPU load never exceeds 10% and available memory stays at the value it had when the router was booted.

We sent v5.15 to our potential customer and they had one occurrence of the freeze.

I'll keep this thread updated if I get any new data.

I'm testing a beta release of 5.16 which Mikrotik says has fixed this problem. So far so good!

there's something new in the multicast thing.... 2 more choises..... default, full, disabled

I'm testing a beta release of 5.16 which Mikrotik says has fixed this problem. So far so good!