Devices are not reliably responding to ARP requests / Wifi Power Saving

I have observed that some devices using WiFi Power Saving features are not reliably responding to ARP. This is affecting an ESP8266, a Huawei P30 and a Samsung Galaxy S9. I am using a hAP AC and have the issue on version 6.44.6 and 6.46

I have configured an un-encrypted wireless network for the purpose of easily sniffing the traffic on another device in monitor mode, and I can see the affected clients notify the AP that they’re going to sleep. The ARP request is then sent whilst they’re sleeping, and when they notify the AP they’re now awake the ARP request is not re-transmitted, so it appears like the Mikrotik AP is not buffering these broadcast packets when the end device is asleep. As a result the end device doesn’t receive the ARP request to reply to.

Has anyone else observed this behaviour? To test you can install nping and run the command below against a device using power saving (Mobile Phone etc). If you network is affected you should see a high number of missing replies :

sudo nping --arp-type ARP (IP of Device) -c 60

Thanks

Is WMM enabled? This is a pre-requisite for a lot of power saving features, though Mikrotik’s proprietary wireless drivers are missing a lot of functionality in this area.

I have tried with

wmm-support

enabled and disabled and unfortunately the behaviour doesn’t change.

Try setting Multicast Helper to Full. This will turn broadcasts into unicasts and do a better job of getting your ARP message through. I always turn it on to Full now as a default. I have had Epson wireless printers respond much better to print and scan requests once this was turned on. And definitely leave WMM on.

Some discussion here: https://wiki.mikrotik.com/wiki/Manual:Multicast_detailed_example#Multicast_and_Wireless

And also see the multicast-helper details here: https://wiki.mikrotik.com/wiki/Manual:Interface/Wireless#General_interface_properties

Try setting Multicast Helper to Full.

It’s a bodge / work around. It does work, but Mikrotik should identify / fix the underlying issue.

How it it a bodge? It works! What more can you ask for? It’s a better kind of best effort! If your device is asleep or suspended during a broadcast and misses it what are you going to do? You also absolutely need it as well if you start mapping VLANs to SSIDs and/or Wifi MACs to VLANs.

It’s not uncommon - Cisco call it Unicast mode as documented here: https://www.cisco.com/c/en/us/support/docs/wireless-mobility/wireless-lan-wlan/81671-multicast-wlc-lap.html

It works! What more can you ask for? It’s a better kind of best effort!

It’s concealing a potential issue with Mikrotik Access Points that isn’t observed on other vendors.


If your device is asleep or suspended during a broadcast and misses it what are you going to do?

The Client announces to the AP it’s going to sleep. The AP should then buffer traffic. The Client then announces it’s awake, and the AP re-transmits the buffered packets - this is how Wireless Power Save works.

I wonder how this affects performance when a lot of clients are idling/sending on the AP.

It’s concealing a potential issue with Mikrotik Access Points that isn’t observed on other vendors.

Really? Do the other vendors quietly enable the equivalent of multicast helper known as MC2UC? It’s not even an option to en/disable in many consumer devices. How do you know your device in question is doing the right things anyway with regards to WMM or that it can receive a broadcast reliably?

The Client announces to the AP it’s going to sleep. The AP should then buffer traffic. The Client then announces it’s awake, and the AP re-transmits the buffered packets - this is how Wireless Power Save works.

Your assertion seems to me that you think that the broad/multicast frame should be cached along with the device specific traffic until the device wakes up. I don’t think this is so.

Have a read of this Wikipedia article:
https://en.wikipedia.org/wiki/IEEE_802.11e-2005#Automatic_power_save_delivery
It refers to the detailed article:
https://community.arubanetworks.com/aruba/attachments/aruba/tkb@tkb/37/1/U-APSD%20explained%20and%20debugged_i62_R2.pdf
Section 4.2 of this article strongly implies even in power saving mode all broadcasts and multicasts happen after the regular DTIM. The buffering you refer to is the collection of all network broad/multicasts that occurred while the devices were asleep and the AP sends all of these collected casts to all devices in one hit. After this time the devices can poll and collect any buffered non-broadcast and non-multicast frames for it. So it doesn’t look like WMM buffers broadcasts per device in power save mode and your problem with your device might have to do with errors being received with the broadcast or that it’s not awake at the right time.

Even the IETF has seen fit to address the problem of multicast in Wifi. It’s a very good and detailed article and gets updated monthly:
https://tools.ietf.org/id/draft-ietf-mboned-ieee802-mcast-problems-11.html
Have a read of section " 3.1.4. Power-save Effects on Multicast" - there is a point there:

  • “Multicast traffic is delayed in a wireless network if any of the STAs in that network are power savers. All STAs associated to the AP have to be awake at a known time to receive multicast traffic.”
    Have a read of section " 4.3. Buffering to Improve Battery Life " - It doesn’t seem to me that WMM caches broadcast traffic for sleeping stations per station - it does it for all stations and then transmits the cached broad/multicasts at once. Your device has to be awake at the right time and receive the broadcast flawlessly.

Meraki say quite clearly here they turn on MC2UC by default:
https://documentation.meraki.com/MR/Other_Topics/Multicast-Unicast_Conversion

Rukus turn it on by default as well (and explains that it drains the battery faster):
https://support.ruckuswireless.com/articles/000003400

It looks like TP-Link enable it by default too:
https://community.tp-link.com/en/business/forum/topic/81122

These articles explain the problem nicely and how UBNT solves it which also involves MC2UC as well as just reducing the propagation of MC and BC traffic on the network.
https://help.ubnt.com/hc/en-us/articles/115001529267-UniFi-Managing-Broadcast-Traffic
https://help.ubnt.com/hc/en-us/articles/115011813968-UniFi-airTime-What-s-Eating-your-Wi-Fi-Performance-

What I am getting at is that your problem can’t be so easily blamed on Mikrotik and using multicast helper in full mode solves your problem for all the reasons in the articles above.

What are your Wifi rates settings? Have you disabled any? Does this problem occur on 2.4GHz and/or 5GHz?


The ARP request is then sent whilst they’re sleeping, and when they notify the AP they’re now awake the ARP request is not re-transmitted, so it appears like the Mikrotik AP is not buffering these broadcast packets when the end device is asleep. As a result the end device doesn’t receive the ARP request to reply to.

Can you determine that the buffered broadcasts after the DTIM are or are not being really sent? Can you determine if they are being received without error? If they were received in error you wouldn’t see them versus them not being transmitted at all.

Really? Do the other vendors quietly enable the equivalent of multicast helper known as MC2UC?

That’s plausible, yes (and backed up by your other references). It still feels like a work around to me but as it’s common amongst vendors I guess I will eat humble pie and enable it.

Thanks for the detailed reply with the links, very useful.

That’s OK, I had to find and read all that first before I could address it properly. At the end of all that you could be onto something - maybe the Mikrotik doesn’t cache and transmit the multicasts properly - you wouldn’t really know unless you had a physical layer WiFi analyser or could see the frames as they come in after demodulation but before sanity and correctness checking.

The IETF article really shows what a mess multicasting is for Wifi. The only big downside of MC2UC is the extra drain on the battery on devices. My Android phone definitely drains quicker when connected to my Mikrotik Wifi which has MH on as Full. If you’re on mains it’s not such a problem.

As for the rates, I found some other Mikrotik based articles that discuss disabling the lower speed modulations to increase the overall throughput - see page 60 of this:
https://mum.mikrotik.com/presentations/EU18/presentation_5155_1523286214.pdf

This one suggest disabling the BPSK and QPSK MCS modes for HT and VHT but I found my Chromecast and printers would no longer connect - need to experiment a bit more:
https://itimagination.com/mikrotik-capsman-setup-access-rates-for-high-de1nsity-wireless/

@marrold - Has this solution been working for you? I’m having similar issues which lead me to this thread as well as similar issues described on github that I saw you talking about. Most of my tasmota support I get through discord channels but none of those guys seem to use MikroTik.