Wifi keeps mobile device awake? [keepalive packets]

rs77 · Tue Jan 08, 2013 2:04 am

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?

TrollMan · Fri Jan 11, 2013 1:42 pm

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

rs77 · Fri Jan 11, 2013 3:54 pm

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

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.

calipso · Sun May 26, 2013 5:59 pm

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

remics · Tue Jun 18, 2013 10:17 am

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.

cejko · Wed Dec 25, 2013 3:10 pm

Same problem here on 6.7.

Is there anybody who has solved this problem ?

Fri Dec 27, 2013 11:53 am

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.

rs77 · Tue Dec 31, 2013 4:47 pm

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."

cejko · Sat Jan 11, 2014 3:00 pm

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.

Zavi · Tue Jan 14, 2014 1:26 pm

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.

Smog · Thu Feb 19, 2015 9:50 pm

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

calipso · Sun Mar 29, 2015 11:00 pm

Any news?

RB951G2HnD · Mon Apr 06, 2015 10:51 am

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.

rs77 · Mon Apr 06, 2015 11:05 am

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?

CyberTod · Mon Apr 06, 2015 12:06 pm

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.

xavierbt · Mon Apr 06, 2015 5:25 pm

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 ?

RB951G2HnD · Tue Apr 07, 2015 10:12 am

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.

Duduhandelman · Tue Apr 14, 2015 7:54 am

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?

xavierbt · Tue Jun 09, 2015 1:15 pm

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

Tue Jun 09, 2015 5:46 pm

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

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

Tue Jun 09, 2015 8:58 pm

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.

you are very lucky

personally i dont know any smartphone who can stay alive 2 days without charging if using wifi, even on standby

rs77 · Wed Jun 10, 2015 12:10 am

personally i dont know any smartphone who can stay alive 2 days without charging if using wifi, even on standby

My Samsung Galaxy S5 gets 2-3 days on normal usage (3-4 hours screen time) when connected to other Wifi networks.
This is reduced to 1-2 days and 2-3 hours screen time when connected to a Mikrotik Wifi network.

I experience 30% faster battery drain on Mikrotik networks.

calipso · Thu Jul 09, 2015 3:46 pm

What's new in 6.30 (2015-Jul-08 09:07):

*) wireless - added WMM power save suport for mobile devices;
*) firewall - sip helper improved, large packets no longer dropped;
*) fixed encryption 'out of order' problem on SMP systems;
*) email - fix sending multiple consecutive emails;
*) fixed router lockup on leap seconds with installed ntp package;
*) ccr - made hardware watchdog work again (was broken since v6.26);
*) console - allow users with 'policy' policy to change script owner;
*) icmp - use receive interface address when responding with icmp errors;
*) ipsec - fail ph2 negitioation when initiator proposed key length
does not match proposal configuration;
*) timezone - updated timezone information to 2015e release;
*) ssh - added option '/ip ssh stong-crypto'
*) wireless - improve ac radio coexistence with other wireless clients, optimized
transmit times to not interfere with other devices;
*) console - values of $".id", $".nextid" and $".dead" are avaliable for
use in 'print where' expressions;
*) console - ':execute' command now accepts script source in "{}" braces,
like '/system scripts add source=' does;
*) console - ':execute' command now returns internal number of running job,
that can be used to check and stop execution. For example:
:local j [:execute {/interface print follow where [:log info "$name"]}]
:delay 10s
:do { /system script job remove $j } on-error={}
*) console - firewall 'print' commands now show all entries including
dynamic, 'all' argument now has no effect;
*) ipsec - increase replay window to 128;
*) fixed file transfer on devices with large RAM memory;
*) pptp - fixed "encryption got out of sync" problem;
*) ppp - disable vj tcp header compression;
*) api - reduce api tcp connection keepalive delay to 30 seconds,
will timeout idle connections in about 5 minutes;
*) pptp & l2tp & sstp client: support the case were server issues its tunnel
ip address the same as its public one;
*) removed wireless package from routeros bundle package,
new wireless-fp is left in place and wireless-cm2 added as option;
*) pptp & l2tp client: when adding default route, add special exception route for
a tunnel itself (no need to add it manually anymore);
*) improved connection list: added connection packet/byte counters,
added separate counters for fasttrack, added current rate display,
added flag wheather connection is fasttracked/srcnated/dstnated,
removed 2048 connection entry limit;
*) tunnels - eoip, eoipv6, gre,gre6, ipip, ipipv6, 6to4 tunnels
have new property - ipsec-secret - for easy setup of ipsec
encryption and authentication;
*) firewall - added ipsec-policy matcher to check wheather packet
was/will be ipsec processed or not;
*) possibility to disable route cache - improves DDOS attack
handling performance up to 2x (note that ipv4 fastpath depends on route cache);
*) fasttrack - added dummy firewall rule in filter and mangle tables
to show packets/bytes that get processed in fasttrack and bypass firewall;
*) fastpath - vlan interfaces support fastpath;
*) fastpath - partial support for bonding interfaces (rx only);
*) fastpath - vrrp interfaces support fastpath;
*) fixed memory leak on CCR devices (introduced in 6.28);
*) lte - improved modem identification to better support multiple identical modems;
*) snmp - fix system scripts table;

kurtkraut · Sun Jul 19, 2015 11:07 pm

What setting I must turn on to get this power saving feature working?

JB172 · Fri Jul 24, 2015 3:17 pm

What setting I must turn on to get this power saving feature working?

In Interfaces -> Wireless in Advanced Mode, you will find the choice of VMM Support

fposavec · Fri Jul 24, 2015 3:57 pm

How about via CAPsMAN?

On every device turn this option?

juanvi · Tue Jul 28, 2015 4:51 pm

Ok. It is ready but, how to enable it for CAPsMAN CAP's?

What's new in 6.31rc10 (2015-Jul-28 08:59):
*) wireless - improved WMM-PowerSave support in wireless-cm2 package;

fposavec · Tue Jul 28, 2015 4:55 pm

 /interface wireless set 0 wmm-support=enabled

juanvi · Tue Jul 28, 2015 5:17 pm

 /interface wireless set 0 wmm-support=enabled

Does not work. No wireless interfaces in my CAPsMAN (CCR).

juanvi · Wed Jul 29, 2015 11:07 am

Wed Jul 29, 2015 1:48 pm

CAPsMAN doesn't support all the features. We will see if we can add it later. Currently only on AP itself.

fposavec · Wed Jul 29, 2015 1:53 pm

CAPsMAN doesn't support all the features. We will see if we can add it later. Currently only on AP itself.

if I enable wwm on AP, then add to CAPsMAN, will be feature enabled?

Wed Jul 29, 2015 2:35 pm

for CAPsMAN managed CAPs, wmm power save is enabled by default (can't turn off)

you need v6.31rc11 and wireless-cm2

there is no status, you just have to believe my words

CyberTod · Wed Jul 29, 2015 4:47 pm

Why are these improvements made only for wireless-cm2? I need this for my home router, actually I have two for roaming, but i don't need capsman so I'm using the wireless-fp package.

juanvi · Wed Jul 29, 2015 5:00 pm

edit: http://forum.mikrotik.com/viewtopic.php?f=21&t=98525

Have installed rc11with cm2 from rc10 and all my capsman config has disappeared!!!

No provision rules, no configs, no datapaths... !!! Nothing!!! Empty winbox tabs under capsman. New terminal export hangs!

EVERYTHING RETURNED WITH RC10... UFFF! Do not make this things to my heart or it will break young...

Please take a look. We need WMM power save.

for CAPsMAN managed CAPs, wmm power save is enabled by default (can't turn off)

you need v6.31rc11 and wireless-cm2

there is no status, you just have to believe my words

bajodel · Sat Aug 01, 2015 8:08 pm

edit: http://forum.mikrotik.com/viewtopic.php?f=21&t=98525
Have installed rc11with cm2 from rc10 and all my capsman config has disappeared!!!
No provision rules, no configs, no datapaths... !!! Nothing!!! Empty winbox tabs under capsman. New terminal export hangs!
EVERYTHING RETURNED WITH RC10... UFFF! Do not make this things to my heart or it will break young...
Please take a look. We need WMM power save.

Maybe you had jumped from capsman to capsman2 ? (fp ..to ..cm2 package)

bajodel · Sun Aug 02, 2015 11:43 am

for CAPsMAN managed CAPs, wmm power save is enabled by default (can't turn off)
you need v6.31rc11 and wireless-cm2
there is no status, you just have to believe my words

We believe your words, but I need some clarifications:

- untill 6.28 only legacy mode power saving (wmm)
- from 6.29 to 6.30.2 "new" wmm power saving is available (but silently disabled on caps/capsman)
- from 6.31rc11 "newer" wmm power (improved..??..no more infos) and default enabled on caps/capsman

Since I had some little wifi connections problems with "new" wmm on 6.30.x (my cell wifi connects only after many tries ..and it seems to prefer low signal diferent ap on other room) I really need to know exactly how to handle this.
In 2/3 days I'm going to setup a warehouse with 10 ap using capsman2 (now I'm on 6.30.2 here) and I already know I'll have to fight against some wifi motorola bar code reader. So I really need to know how to enable/disable this wmm power saving feature.

juanvi · Tue Aug 04, 2015 1:54 pm

Always used capsman v2. Reported to MK and waiting for reply. Thanks for your interest.

bajodel · Wed Aug 05, 2015 12:14 am

Always used capsman v2. Reported to MK and waiting for reply. Thanks for your interest.

Please, keep the topic update with mt news ..tnx

bajodel · Sat Aug 08, 2015 8:22 am

for CAPsMAN managed CAPs, wmm power save is enabled by default (can't turn off)
you need v6.31rc11 and wireless-cm2
there is no status, you just have to believe my words
We believe your words, but I need some clarifications:

- untill 6.28 only legacy mode power saving (wmm)
- from 6.29 to 6.30.2 "new" wmm power saving is available (but silently disabled on caps/capsman)
- from 6.31rc11 "newer" wmm power (improved..??..no more infos) and default enabled on caps/capsman

Since I had some little wifi connections problems with "new" wmm on 6.30.x (my cell wifi connects only after many tries ..and it seems to prefer low signal diferent ap on other room) I really need to know exactly how to handle this.
In 2/3 days I'm going to setup a warehouse with 10 ap using capsman2 (now I'm on 6.30.2 here) and I already know I'll have to fight against some wifi motorola bar code reader. So I really need to know how to enable/disable this wmm power saving feature.

Normis/mt .. probably on holidays ?

imho · Thu Aug 27, 2015 8:49 am

When i'am add VirtualAP (also set WMM Support: enabled for it and for Master Interface) the problem come back, disable VirtualAP — all ok. v6.31.

bajodel · Fri Aug 28, 2015 6:07 am

for CAPsMAN managed CAPs, wmm power save is enabled by default (can't turn off)
you need v6.31rc11 and wireless-cm2
there is no status, you just have to believe my words
We believe your words, but I need some clarifications:

- untill 6.28 only legacy mode power saving (wmm)
- from 6.29 to 6.30.4 "new" wmm power saving is available (but silently disabled on caps/capsman)
- from 6.31rc11+ "newer" wmm power (improved..??..no more infos) and default enabled on caps/capsman

Since I had some little wifi connections problems with "new" wmm on 6.30.x (my cell wifi connects only after many tries ..and it seems to prefer low signal diferent ap on other room) I really need to know exactly how to handle this.
In 2/3 days I'm going to setup a warehouse with 10 ap using capsman2 (now I'm on 6.30.2 here) and I already know I'll have to fight against some wifi motorola bar code reader. So I really need to know how to enable/disable this wmm power saving feature.

mt/normis ..any comments? Please..

bajodel · Mon Aug 31, 2015 8:16 pm

Ok, I must give up!

dboreham · Mon Nov 30, 2015 3:35 am

Any news on this? I came on this thread after spending many days tracking down the reason for "push fail" on iOS devices using our WiFi network. Since I'm running 6.33.1 presumably I'm affected by the "fix wasn't implemented for virtual APs" issue.

Mon Nov 30, 2015 10:03 am

Any news on this? I came on this thread after spending many days tracking down the reason for "push fail" on iOS devices using our WiFi network. Since I'm running 6.33.1 presumably I'm affected by the "fix wasn't implemented for virtual APs" issue.

Please tell us exactly what isn't working for your Virtual AP? What setup you have? Are you using CAPsMAN or regular AP mode? Explain how to reproduce this problem.

dboreham · Mon Nov 30, 2015 5:51 pm

Any news on this? I came on this thread after spending many days tracking down the reason for "push fail" on iOS devices using our WiFi network. Since I'm running 6.33.1 presumably I'm affected by the "fix wasn't implemented for virtual APs" issue.
Please tell us exactly what isn't working for your Virtual AP? What setup you have? Are you using CAPsMAN or regular AP mode? Explain how to reproduce this problem.

Sure. Somehow I thought this was a known issue given the posts in this thread. Anyway, here's my reproduction scenario:

Using an RB912UAG-2HPnD with a second AR9300 card installed for 5GHz (the devices pretty much don't use 5GHz so afaik the problem exists with the bare RB912 @ 2.4GHz). Running 6.33.1 with the stock configuration (wireless-fp is enabled, wireless-cm2 is not).

I have the "base" AP (non virtual) configured with an unused SSID, all traffic is on virtual APs. There are several virtual APs defined (for regular traffic, for guests, for traffic that gets tunneled to another site). In this test I'm using the regular traffic virtual AP. WMM is enabled on both the base interface and the virtual AP.

The device I'm using to reproduce is an iPhone 6s Plus. I've seen varying behavior with other Apple devices (ranging from the same behavior, to similar but less frequently observed, through "works just fine"). It seems that the newer the device, the more problematic it is, conversely the older the device the more likely it is to work ok.

Reproduce as follows:

0. Obtain a test device, ideally iPhone 6s running the latest iOS9, configured with some background push service. The easiest to use is the iCloud email service that comes with the Apple ID configured on the device.
1. Connect device to the virtual AP, verify connectivity and association at the AP. I add the devices to the "Access List" so they can be easily identified in Winbox.
2. Disable cellular data on the device to force its traffic through WiFi always (otherwise it will just use 3G/4G and the problem will not be observable).
3. Leave device for a while (an hour or so is usually enough). It can be plugged into a charger, or not -- doesn't matter.
4. Observe that a) the device is no longer associated to the AP and b) push services no longer work.

The last thing I see in the log on the AP is :

"data from unknown device <MAC>, sent deauth"

I started investigating this problem originally because we run a push email service, so I also have access to the server side of the connection and can see the time of last contact etc, but since you don't have that capability use iCloud or GMail or some other service that does push to test.

I confirmed that Mikrotik AP is the cause by associating the device with an Apple AP (I bought an Airport 802.11n AP specifically to do this test). Device will be observed to stay connected to push services for days without disconnecting.

RB951G2HnD · Tue Dec 01, 2015 8:20 am

The problem here because of the 'group-key-update' value - this interval is too short. 1 day will be better to have than 1 hour as it is now. It seems that MikroTik Team didn't pay attention to my previous post. In general WMM is working fine as expected.

Tue Dec 01, 2015 8:41 am

The maximal value is 1h but what is worse the default value is 5min. Setting it to 1h will help significantly. 1day maximal value or even not to apply such small limits at all would be very helpful together with new default value much bigger than 5min.

dboreham · Tue Dec 01, 2015 8:12 pm

The problem here because of the 'group-key-update' value - this interval is too short. 1 day will be better to have than 1 hour as it is now. It seems that MikroTik Team didn't pay attention to my previous post. In general WMM is working fine as expected.

I'm not an 802.11 expert, but this sounds like a poor solution. Surely WMM power saving mode and WPA key rotation are able to work together? No AP that I'm aware of allows a key update interval longer than 1h to be configured (presumably because the risk of key recovery by an eavesdropper rises considerably with a longer interval).

fwiw I did try a 1h key update interval with no success (iPhone still disconnects after a while).

robertkjonesjr · Thu Dec 03, 2015 2:47 am

No AP that I'm aware of allows a key update interval longer than 1h to be configured

Cisco WLC controllers allow 86400sec as group key update - which is one day. In older versions of software it is CLI configured, but in newer versions it is available through the GUI. Cisco has a large market share, and many consider it a standard. You may not.

Other vendors allow adjustment past 1hr as well. In fact, for those vendors that allow adjustment, one hour is rather short in my experience. Not all vendors allow adjustment, so they must fix in code.

dboreham · Thu Dec 03, 2015 3:08 am

No AP that I'm aware of allows a key update interval longer than 1h to be configured
Cisco WLC controllers allow 86400sec as group key update - which is one day. In older versions of software it is CLI configured, but in newer versions it is available through the GUI. Cisco has a large market share, and many consider it a standard. You may not.

Other vendors allow adjustment past 1hr as well. In fact, for those vendors that allow adjustment, one hour is rather short in my experience. Not all vendors allow adjustment, so they must fix in code.

Are you saying that an 802.11 deployment has to pick one of a) working power saving mode or b) resistance to key recovery attacks?? Surely that's wrong.

Thu Dec 03, 2015 7:07 am

i think group update of 1hr is just fine, many vendors have this as a maximum, remember wireless is for mobile devices if you want more stability go for cable

dboreham · Thu Dec 03, 2015 5:11 pm

i think group update of 1hr is just fine, many vendors have this as a maximum, remember wireless is for mobile devices if you want more stability go for cable

Huh??? What on earth are you talking about?? Wireless is perfectly stable with non-Mikrotik access points and the devices in question don't have a cable connector.

Thu Dec 03, 2015 6:20 pm

i think (my personal opinion) in la LAN scenario wireless is not a reliable connectivity option, because the only think you need is a little amount of interference the lost performance and stability.

im not complaining about it

its logical, we have to sacrifice some to get the benefits of mobility, in LAN scenario wireless is not a replacement for wired connectivity is a complement

i repeat is my personal opinion

robertkjonesjr · Sat Dec 05, 2015 4:33 pm

Are you saying that an 802.11 deployment has to pick one of a) working power saving mode or b) resistance to key recovery attacks?? Surely that's wrong.

No, it's not obvious why I would have to choose. I can set GTK rekey interval from 2min to 1day on other platforms and have no trouble. The issue appears to be here with Mikrotik.

To your point b, have you analyzed the impact of GTK rekey time on your actual security by a simple time based trigger? How often does the PTK change? Most of the communication profiles I have to deal with are unicast at 802.11/layer 2 so the GTK does not even come into play very often. Only broadcast/multicast packets, sent from AP to clients, use this key. Some systems allow multicast-to-unicast conversion, so this key is used even less if this feature is enabled.

dboreham · Mon Dec 07, 2015 6:12 pm

To your point b, have you analyzed the impact of GTK rekey time on your actual security by a simple time based trigger? How often does the PTK change? Most of the communication profiles I have to deal with are unicast at 802.11/layer 2 so the GTK does not even come into play very often. Only broadcast/multicast packets, sent from AP to clients, use this key. Some systems allow multicast-to-unicast conversion, so this key is used even less if this feature is enabled.

I have no clue. All I know is a) iPhones disconnect from the AP after some time, supposedly due to having the wrong key, because it has been changed in the meantime and b) there is no known Mikrotik config setting that will make an iPhone happy and not do this.

Since having iPhones stay connected to the AP long term is something that I (and I think any iPhone user) regard as "mission critical", and iPhones are quite common these days, it means that Mikrotik APs are not usable.

robertkjonesjr · Tue Dec 08, 2015 12:43 am

Since having iPhones stay connected to the AP long term is something that I (and I think any iPhone user) regard as "mission critical", and iPhones are quite common these days, it means that Mikrotik APs are not usable.

On this we agree. It's a showstopper. I will not deploy Mikrotik wireless beyond the lab for this very reason.

dboreham · Thu Dec 10, 2015 8:23 pm

btw based on my testing the theory that the problem is now (in the latest update) only present with virtual APs is false.
I see the problem (iPhone 6s disconnects from AP when sleeping) with both virtual and non-virtual AP configurations.

djdrastic · Wed Feb 10, 2016 11:42 am

Have run into this exact problem with some fruit equipment losing connection to the network after entering sleep mode giving me the dreaded "data from unknown device <MAC>, sent deauth" message.
MTK guys any idea if this will get attention ? Whether a higher GTK timer or just having a way to disable powersave mode on Capsman would suffice.

I understand this is not quite your fault , but the damn fruit things are unfortunately everywhere.

dave864 · Sat Mar 26, 2016 12:24 pm

On my edimax pro, mine were defaulted to 300s. We have no issues with android gear and have no apple stuff yet. But I can change it to 65535s max. I chose 12h.

On the edimax the setting, if the same, is called station idle time out.

I've already ordered a couple of mikrotik APs to test. So I hope this issue gets fixed.

Jan89 · Sun Apr 24, 2016 5:23 pm

Hi,

I also had a problem with disconnects iphone from network, but my network setup looks as follows:
Internet -> Routerboard 850gx2 -> Wifi AP Cisco Aironet 2702.
My iphone was disconnecting from wifi every 10 minutes. The problem was with default settings of dhcp server in Mikrotik. Lease time was set to 10 minutes. When I changed it to 24h my iphone stays connected to the network

btw. when I was using Mikrotik as AP, I also observed waking up mobile devices every 20s, it was killing battery. For this reason I'm not using Mikrotik for wireless with mobile devices

Regards.

nvassilev · Fri Oct 14, 2016 7:53 pm

Guys, in versions 6.37 and 6.37.1 wifi is causing a big battery drain on mobile devices. My phone is Nexus 5X with latest android 7 OTA and battery fully drains in less than a day on wifi, while it was lasting 3 days before. I switched WMM on and keepalive off, but this didn't helped. The problem was finally fixed when I reverted to version 6.34.6. It's possible the problem to be appearing in earlier versions - I just noticed it in 6.37. Please check this issue.

drees · Fri Oct 14, 2016 10:53 pm

Interesting, I also have a 5X running Nougat and a RB951G-2HnD as an AP/router, but no battery life issues here when I was running 6.37.1 (now running latest 6.38rc).

I don't get 3 days out of it, but that's because I use it too much, the screen drains most of the battery. When the phone is not used and sitting still, it uses very little battery.

Edit: I read the thread - will turn on WMM and lengthen the group key update to see if it improves battery life or not. It does appear that you can set the group key update beyond an hour now. I was able to set a value of 30d without issue, at least.

Ronce · Sun Oct 16, 2016 6:35 pm

Guys, in versions 6.37 and 6.37.1 wifi is causing a big battery drain on mobile devices. My phone is Nexus 5X with latest android 7 OTA and battery fully drains in less than a day on wifi, while it was lasting 3 days before. I switched WMM on and keepalive off, but this didn't helped. The problem was finally fixed when I reverted to version 6.34.6. It's possible the problem to be appearing in earlier versions - I just noticed it in 6.37. Please check this issue.

Hi.
I have same problem with nexus 5x and rb951g-2hnd, battery drain very fast on wifi ,
ROS 6.37.1 or 6.38
but no drain with ROS 6.34.6
on ROS 6.37.1 router non stop sending packets to phone.

QuesT · Wed Oct 26, 2016 5:00 pm

Hi.
I have same problem with nexus 5x and rb2011, battery drain very fast on wifi no Deepsleep since 7.0, i on the 6.38 Rc15. On a TP-Link AP no Probs .

drees · Wed Oct 26, 2016 5:55 pm

No noticeable difference after turning WMM on and increasing group key update to 1 hour on my RB951G using 6.38rc15.

Have a few Nexus 5x phones, and a few other phones, all good battery life and no excessive battery drain on any.

Thu Oct 27, 2016 9:07 am

And what about to use battery defender application?

laca77 · Wed Nov 02, 2016 5:47 pm

Hi

I have the some problem with my Oneplus 3. If i connect to any MT device (HAP Lite) with 6.37.1, the phone never goes to deepsleep if I use CM13 or CM14 roms. But sleep on every non MT device.

I will try older MT images too and come back with the results if it interesting for the MT engineers...

Siona · Wed Nov 02, 2016 10:40 pm

Hi

I have the some problem with my Oneplus 3. If i connect to any MT device (HAP Lite) with 6.37.1, the phone never goes to deepsleep if I use CM13 or CM14 roms. But sleep on every non MT device.

I will try older MT images too and come back with the results if it interesting for the MT engineers...

I have op3 with oxygen os. Working fine with hap ac, rb433gl, 493g, 433ah - all with 6.37.1. Sleeps as it should.

R1CH · Fri Nov 04, 2016 12:38 am

I've used monitor mode (watching all radio traffic) to confirm there are no spurious packets in the air when using mostly default settings. Enabling WMM and setting group key interval to 1 hour should be enough, the rest is up to the device itself.

laca77 · Fri Nov 04, 2016 11:41 am

Hi

I have the some problem with my Oneplus 3. If i connect to any MT device (HAP Lite) with 6.37.1, the phone never goes to deepsleep if I use CM13 or CM14 roms. But sleep on every non MT device.

I will try older MT images too and come back with the results if it interesting for the MT engineers...
I have op3 with oxygen os. Working fine with hap ac, rb433gl, 493g, 433ah - all with 6.37.1. Sleeps as it should.

Yes, the official OOS can sleep. But not the CM13. May be it is a CM bug.. but here are different phones with different OS with the same error.

Just an info: The CM14 affected too IF i just install it standalone. If i install before CM14 the OOS 3.5.5 modem and firmware too, the CM14 can sleep to. This trick not working on CM13, because the CM13 can sleep with 3.2.7 Modem and Firmware, but the Home button is not working. But this is an another thread...

ether1 · Wed Nov 16, 2016 4:11 pm

Hello!
Just registered to report.
I have the same problem with nexus 5x and 951G-2HnD with rb 3.37 and 3.38.
Can't downgrade to 3.34 to confirm that it is working, sorry. WMM is enabled, second WiFi ap is disabled. Group key upgrade is set to 01:00:00.

First I thought the problem is in Android. It is not. I disabled all stock app, rebooted into safe mode. The problem is still there, reverted to stock, same problem.
Installed firewall on the phone and disabled all app WiFi and Network activities. The problem is still there.
No problem when the phone is on LTE or Dlink wifi.
What can I do?
Thanks

agrisvv · Mon Nov 21, 2016 11:29 am

Same here nexus 5x. same for stock android 7 and 7.1. factory reseted. with 6.0.1 wasn't so extensive awake.

hAP lite and RB2011UiAS-2HnD-IN with last versions.
phone stay awake. no diference after change dhcp lease time, wmm or group key settings. Also reset to default.

No awake with such routers linskys e900 stock, Buffalo WHR-300HP DD-WRT, huawei-e5577-4g modem.

In AP Client statistic:
TX (packets,frames,hw frames) are send, but RX stay unchanged.
packed sniffer show nothing in packets monitor for TX.

Igorok · Sun Nov 27, 2016 10:28 pm

Can confirm with nexus 5x android 7.1 developer preview 2. RouterOS 6.37 and 6.38rc.

The wakelock is called "qcom_rx_wakelock".

agrisvv · Thu Dec 22, 2016 1:38 am

Android 7.1.1 repair bug with wifi keep awake. But as of topic start date 2013 wifiAP keep sending frames..

is better, but now cpu deep sleep(200mhz) vs next step(300mhz) = 50:50 at night.

But on screenshoot you can see diferent phones nexus 5x (android 7.x) ends with MAC 36 and other lumia windows phone.

last activity for nexus changes from 0.010 to 0.020 even after 2 min.
rx/tx rate mostly about 144 mbps
tx frames sending nowhere :/

wifi.png

agrisvv · Thu Dec 22, 2016 1:41 am

Can confirm with nexus 5x android 7.1 developer preview 2. RouterOS 6.37 and 6.38rc.

The wakelock is called "qcom_rx_wakelock".

no i think it wasn't because frenco kernel help mee to disable qcom_rx_wakelock. but this dose not help.. only now after 7.1.1 stable. battery drain to me are same as android 6/7

Ronce · Thu Dec 22, 2016 9:01 am

Android 7.1.1 repair bug with wifi keep awake. But as of topic start date 2013 wifiAP keep sending frames..

is better, but now cpu deep sleep(200mhz) vs next step(300mhz) = 50:50 at night.

But on screenshoot you can see diferent phones nexus 5x (android 7.x) ends with MAC 36 and other lumia windows phone.

last activity for nexus changes from 0.010 to 0.020 even after 2 min.
rx/tx rate mostly about 144 mbps
tx frames sending nowhere :/
wifi.png

i confirm, same problem nexus 5x android 7.1.1 mobile last activity max 0.2 sec, but with "router os 6.34.6 bug fix edition" wifi last activity reach 19sec and no prolbme with battery

drees · Thu Dec 22, 2016 5:51 pm

No problems here with 6.37.3 on a number of Android devices including two Nexus 5X phones with 7.0. Don't have 7.1 yet.

Last wireless activity resets at 20 seconds.

Last 6.38rc I tested was fine, too.

Ronce · Fri Dec 23, 2016 9:05 am

No problems here with 6.37.3 on a number of Android devices including two Nexus 5X phones with 7.0. Don't have 7.1 yet.

Last wireless activity resets at 20 seconds.

Last 6.38rc I tested was fine, too.

What your mikrotik hw?
My RB951G

i very sad, that mikrotik no reaction on this problem, next router will not mikrotik.

drees · Fri Dec 23, 2016 7:11 pm

951G-2HnD running firmware 3.33.

DanielJB · Thu Dec 29, 2016 4:23 am

I would say it's worthwhile trying to:
- disable STP on all bridges (and hardware switch chip STP if enabled on certain models)
- increase DHCP lease time to eg 4h
- ensure group-key-update is eg 1h
- disable keepalive-frames

It's just a pity we can't adjust beacon frequency and DTIM:
http://forum.mikrotik.com/viewtopic.php?f=1&t=116221

jagdpandora · Mon Feb 04, 2019 1:06 pm

hi,I have same problem with xiaomi redmi note 5
ROS 6.42.11 (Long-term)

Who is online