in Wireless

STA go to sleep and the AP tracking it, or not?

Recently my colleague asked me to join with a so called wireless problem involving a mac client, because I was a mac user and he was not.


At the crime scene I observed a loading icon on the MacBook and I see his teams and outlook session disconnecting. The user tolt me he then click to on the SSID again and the problem wil solve after a few seconds. Interesting… So lets do a packet capture on the channel (64) he was connected to. Below is the pcap I filled in the comments to make it readable. In ISE we saw no reauthenticaton of what so ever.

But whats interesting you see the Null Data Frame ( a control frame).  It is only transmitted by a STA (wireless client). Access points do not transmit these frames. It carry’s no data payload. In fact, the only purpose of this frame (by standard) is to carry the power management bit in the frame controlled field. The power management bit will be either “0” zero or “1” one. 

When the STA sends a power management bit of “1” to the access point in which it is associated to. This is informing the access point that the STA is going offline and any frames that come into the access point for this STA should be buffered at the access point till the STA returns and sends a NULL frame of “0”, active state.

So the flag off (1) means I go to sleep, save the packets into your buffer please for when I am awake
(0) means I’m awake.

I not go to deep into the Power Save Modes, but basically, the client does this when he wants to roam to another channel or to save battery and turn off the NIC radio. The total time was 0.161ms before the client say i;m back! so nothing strange there, also we do not cause any video/audio from being interrupted..

But look at the retry rate, on the packet where the PS flag is 0, the AP doesn’t respond to it.
And with the PS flag on 1 the AP responds, and both are sent on the lowest MBR possible, which is 12Mbit in this case. So why the AP doesn’t respond? Its a Cisco 2700i AP that’s already EOL so not much support from Cisco there, but wait everything is controlled by the controller right? So is there maybe a feature involved that causes this issue? Till today I still don’t know what caused this AP not to respond when the PS but is set to 0, we also observed 1 more client where the AP did not send a response back on the PS 0 null data frame. Or did the AP doesn’t see the client? But why send an ack back when the PS bit is set to 1 ? Wouldn’t we expect also a trey there then?

I Still need to figure out the answers, but the evidence we have.


I saw the BSS Max Idle Period in the WLAN was not enabled but after reading about it will only keep the clients in sleep mode for a longer duration without transmitting the keepalive messages often. This in turn contributes to saving battery power.

So what about power save polling (PSP) ?


If a Wi-Fi access point (AP) or broadband Wi-Fi router does not support the feature:
    •    Intermittent loss of Wi-Fi connection
    •    Inability to initiate a Wi-Fi connection
    •    Poor Wi-Fi connection data performance

Using battery power can reveal these symptoms.

power save polling (PSP) feature on


U-APSD will be utilized when WMM is enabled on the Access Point. When on call U-APSD, PS-POLL. Wmm is on

So what about the Delivery Traffic Indicator Message (DTIM): For optimal battery life and performance, we recommend setting the DTIM period to 2 with a beacon period of 100 ms.

The DTIM period is a tradeoff between battery life and multicast performance. Broadcast and multicast traffic will be queued until the DTIM period when there are power save-enabled clients associated to the access point, so DTIM will determine how quickly these packets can be delivered to the client. If using multicast applications, a shorter DTIM period can be used. If multiple multicast streams exist on the wireless LAN frequently, then it is recommended to set the DTIM period to 1. The DTIM is set to 1 in this case. So to be continued.

Write a Comment

Comment