Wifi keeps mobile device awake? [keepalive packets]

RouterOS Wireless Networking
1

Hello, I have been experiencing strange behaviour with wireless connections to Mikrotik RB751G-2HnD, v5.22.

When devices are connected to the Mikrotik AP we experience quick battery drain, where the devices have very high wake time and problems entering deep sleep.

I ran tcpdump on a Android device and can see that every 20-30 seconds there are “empty” packets sent from the Mikrotik to the device and cause wakelocks. The only information in these IPv4 packets seems to be source and destination MAC address.

Constant packets. Mikrotik MAC = d4:ca:, device MAC = 88:30:.

Full info of packet:




When running the tool “Packet sniffer” inside WinBox simultaneously on the wifi interface these packets are not recorded.

Note that there are 5 seconds offset.




What are these packets? Some kind of keepalive? Can I disable them to stop my devices from draining battery?

I have run tcpdump on other vendor APs but have not seen this elsewhere.

Things I have done and verified:

  • Tests were done on a completely silent network with one single device.
  • No neighbor APs transmitting on adjacent channels.
  • Disabled STP, CDP/MNDP.
  • Isolated Wifi interface to separate bridge.
  • Set device ARP static in Mikrotik.
> interface wireless advanced print 
 0    name="wlan1" mtu=1500 mac-address=D4:CA:6D:21:4E:05 arp=enabled 
      disable-running-check=no interface-type=Atheros 11N 
      radio-name="D4CA6D214E05" mode=ap-bridge ssid="DegFi" area="" 
      frequency-mode=manual-txpower country=sweden antenna-gain=0 
      frequency=2422 band=2ghz-onlyg channel-width=20mhz scan-list=default 
      wireless-protocol=802.11 rate-set=default 
      supported-rates-b=1Mbps,2Mbps,5.5Mbps,11Mbps 
      supported-rates-a/g=6Mbps,9Mbps,12Mbps,18Mbps,24Mbps,36Mbps,48Mbps,
                    54Mbps 
      basic-rates-b=1Mbps basic-rates-a/g=6Mbps max-station-count=2007 
      distance=indoors tx-power-mode=default noise-floor-threshold=default 
      nv2-noise-floor-offset=default periodic-calibration=default 
      periodic-calibration-interval=60 dfs-mode=none antenna-mode=ant-a 
      wds-mode=disabled wds-default-bridge=none wds-default-cost=100 
      wds-cost-range=50-150 wds-ignore-ssid=no update-stats-interval=disabled 
      bridge-mode=disabled default-authentication=yes default-forwarding=no 
      default-ap-tx-limit=0 default-client-tx-limit=0 
      proprietary-extensions=post-2.9.25 wmm-support=disabled hide-ssid=no 
      security-profile=wifi disconnect-timeout=3s on-fail-retry-time=100ms 
      preamble-mode=both compression=no allow-sharedkey=no 
      station-bridge-clone-mac=00:00:00:00:00:00 ht-ampdu-priorities=0 
      ht-guard-interval=any 
      ht-supported-mcs=mcs-0,mcs-1,mcs-2,mcs-3,mcs-4,mcs-5,mcs-6,mcs-7,mcs-8,
                 mcs-9,mcs-10,mcs-11,mcs-12,mcs-13,mcs-14,mcs-15,mcs-16,mcs-17,
                 mcs-18,mcs-19,mcs-20,mcs-21,mcs-22,mcs-23 
      ht-basic-mcs=mcs-0,mcs-1,mcs-2,mcs-3,mcs-4,mcs-5,mcs-6,mcs-7 
      ht-txchains=1 ht-rxchains=1 ht-amsdu-limit=8192 ht-amsdu-threshold=8192 
      tdma-period-size=2 nv2-queue-count=2 nv2-qos=default nv2-cell-radius=30 
      nv2-security=disabled nv2-preshared-key="" hw-retries=7 
      frame-lifetime=0 adaptive-noise-immunity=none 
      hw-fragmentation-threshold=disabled hw-protection-mode=none 
      hw-protection-threshold=0 frequency-offset=0 rate-selection=advanced 
      multicast-helper=default 

> interface bridge print 
 1  R name="wifi-bridge" mtu=1500 l2mtu=2290 arp=enabled 
      mac-address=D4:CA:6D:21:4E:05 protocol-mode=none priority=0x8000 
      auto-mac=yes admin-mac=00:00:00:00:00:00 max-message-age=40s 
      forward-delay=30s transmit-hold-count=6 ageing-time=5m

> interface wireless security-profiles print 
 1   name="wifi" mode=dynamic-keys authentication-types=wpa2-psk 
     unicast-ciphers=tkip group-ciphers=tkip wpa-pre-shared-key="***" 
     wpa2-pre-shared-key="***" supplicant-identity="" eap-methods="" 
     tls-mode=no-certificates tls-certificate=none static-algo-0=none 
     static-key-0="" static-algo-1=none static-key-1="" static-algo-2=none 
     static-key-2="" static-algo-3=none static-key-3="" 
     static-transmit-key=key-0 static-sta-private-algo=none 
     static-sta-private-key="" radius-mac-authentication=no 
     radius-mac-accounting=no radius-eap-accounting=no interim-update=0s 
     radius-mac-format=XX:XX:XX:XX:XX:XX radius-mac-mode=as-username 
     radius-mac-caching=disabled group-key-update=5m 
     management-protection=disabled management-protection-key=""

Is there any more info I can supply?

2

I think you need to enable WMM so that powersave can kick in

3

Hi TrollMan, thank you very much for the suggestion. However it did not make any difference, the packets are still sent every 20-30 seconds.

4

Any news? I have the same issue with Mikrotik RB951G-2HnD with ROS 6.0.

5

I have just set up an RB951G-2HnD ROS v6.1 and am experiencing same heavy battery drain on mobile devices overnight.
This is in direct contrast to the Asus RT N13U that I was using up until deploying the MikroTik.

On top of what has been investigated above I have also tried with multicast helper full, disabled, all to no avail.

Attached screenshot of my quick capture.
Capture.png

6

Same problem here on 6.7.

Is there anybody who has solved this problem ?

7

Currently it is not possible to disable those packets.
Also currently we support only legacy power-saving and WMM Powersaving support will be added some time later.

8

I got this information from Uldis also for those interested:

“… those are wireless keepalive messages and it is not possible to disable.”
“… we have added this feature in the to-do list, we will try to add in in one of the RouterOS releases as an option.”

9

Mikrotik you have a really a great product but this is a really big issue.

I have 9 wireless devices at home which last 4x less than before. My android phone at example usually lasted almost 2 days and now since I’ve upgraded my router it last for about 8 hours ??#
We have the same problem in our company where some of employees devices does not last even for the whole working day after the router upgrade.

The biggest issue is that most users are not even aware that their devices last so little because of your routers .. they certainly think that they have bad phones or worn-out batteries.
I’m not 100% sure that this packets are the main cause for the heavy battery consumption but after I’ve checked all the settings and read everything I could find on the net I could’t find any other possible reason.

Don’t you have the same problems yourselves ?

Does it exist at least a work in progress patch for this problem? Or do you have any other idea how to solve this.

We’re now in a mobile devices era and we really need to sort this out.

10

The battery drain can be stopped by enabling WiFi powersave mode in Android WiFi settings - but as this isn’t supported by ROS, you can expect troubles with push-mail or other things, that need to use WiFi when on powersave. I heard somewhere, that the missing WMM could be cause for problems with Apple devices too.
ANOTHER LOUD VOTE FOR THIS IN ROS! With tons of mobile devices everywhere it’s a must-have feature.

11

This but is not solved yet((( My phone start to work 3 times less. Is there any perspective to solve this bug?

12

Any news?

13

I think that due to Mikrotik supports only legacy power-saving and WMM power saving is not yet supported is the reason why too much new mobiles devices based on Android or iOS operating systems are losing WiFi connection.

I made a following test with the mobile phone based on Android OS. Start ping from PC to mobile device. When the screen is switching off on the phone then its going to WMM power saving mode automatically but Mikrotik router didn’t understand that and we can see that pings are dropped. If the screen will be switched of for a 5 minutes then Mikrotik router sends deauthentication message. To connect phone back to the wireless network you need to disable WiFi then enable it again.

When Mikrotik are going to solve this issue approximately? Thank you.

14

Hundreds of thousands or millions mobile devices are connected Mikrotik APs and experience this battery drain and cannot figure out why. It is not only us in this thread that has pinpointed the issue that has problems.

Mikrotik, it has been over two years since this “feature” was reported. Do you have plans to fix it at all? :angry:

15

I want to know more about that too. Some timeframe about fix ?
At home when connected to my 951ui with 6.27 my phone has no battery at all by evening even if the phone just sits idle on the table without me even touching it. In another network with a simple tp-link router after 2 full days with this same usage I have more than 30% battery remaining.

16

Recently, I have incorporated to my home wifi network an 951G-2HnD with RouterOS 6.27. I use iOS devices only and I haven’t detected any battery drain issue. Happens to all MikroTik wifi hardware allways ? Or is this problem related to some router settings, wifi hardware pairing , or any other condition ?

17

I believe that if Mikrotik will implement WMM power saving in the future versions of code it will not affect your battery power drain because anyway your mobile devises are goin into power save mode automatically when the screen is switched off.

The problem here is that all traffic between the mobile device and the router are dropped when the screen is switched off because the router don’t understand that your wireless device went to WMM power saving mode as it’s not supported in the code yet. After that when The Group Key is expired (by default this is 5 minutes) the router thinks that the wireless device is disappeared and sending deauthentication message. Then for example in 20 minutes you wish to check your incoming messages in IM application and you will find that the WiFi connection on your device is in active state but in reality it is not because the router has dropped your session already.

The Group Key (Group Transient Key) is a shared key among all Supplicants connected to the same AP and is used to secure multicast/broadcast traffic. It is not used for normal unicast traffic. A Pairwise Transient Key secures the unicast traffic. Group Key Renewal controls how often the Group Transient Key is changed. The Group Key Renewal does not control the update period for the Pairwise Transient Key. The Pairwise Transient Key is changed each time the Supplicant authenticates or re-authenticates.

The workaround for this scenario is to use longer Group Key update interval then 5 minutes. In my case the value for group-key-update is set to maximum - 1 hour (not enough). The reason to rekey the Group Key is one of policy not key space exhaustion. If a system leaves the wireless it still has the current group key and can capture all broadcast/multicast traffic (including network neighborhood stuff). If you have complete control over all the wireless devices on your AP you could set this at once a week. With PSK there is NO justification to make it less than 1 hour. For 802.1X with many ‘guests’ a shorter time can be good policy.

In conclusion it will be great if Mikrotik Team will expand range for a group-key-update interval to 1 week. It might be a temporary workaround solution when wireless devices with the WMM power saving mode are disconnecting (where it can’t be disabled manually). But later too much clients in the world will be happy to see the fully supported WMM power saving on their routers. I hope that Mikrotik Team will take this notes for consolidation.

18

I’m using capsman with a lot of caps and I thought it beacuse of the roaimg between caps.
Now I can see the packets that prevent the device going to sleep.
Too bad it like this the capsman and caps are so great.

Any Idea on how to solve this?

19

Are any news about this ? I’m experiencing abnormal battery draining, so we are taking off Mikrotik testing routers of our wifi network.

20

i have tested on rb951 Ui on 6.29.1 without the packets showing on capture, no battery life problem