Candela Technologies Logo
Network Testing and Emulation Solutions

Powersave Test Cases

Goal: Test and verify powersave mode on a station using various methods.

DTIM multicast testing:

This pcap file from a station on a mtk7921k radio shows proper unicast behavior. This is using the packet filter: wlan.addr == a8:93:4a:9d:47:a3 || wlan.addr == 04:f0:21:9a:64:65

This pcap file shows bad broadcast Powersave behavior. Frame 157 TIM field should indicate Multicast and the broadcast frame 158 should be immediately after frame 157 instead of being 65ms later.

TIM unicast testing (with APs set up for multicast → unicast behaviour):




For the ASUS capture above, use this filter for ax200: wlan.addr == 50:e0:85:8a:0a:f2 || wlan.addr == F0:2F:74:7C:A3:B0, for ax200 to LANforge VAP use: wlan.addr == 50:e0:85:8a:0a:f2 || wlan.addr == wlan.addr == 04:f0:21:9a:64:65 and for the mtk to LANforge VAP, use: wlan.addr == a8:93:4a:9d:47:a3 || wlan.addr == 04:f0:21:9a:64:65

The ax200 capture shows buggy behaviour on the ASUS: ASUS does not ack frames well so ax200 sends lots of retries. The ASUS is doing multicast to unicast behaviour, so the ‘multicast’ frames are sent as directed unicast frames directly to the station.

Wake/Sleep testing in upload direction

The following capture: shows power-save-mtk7921k-sta-mtk7915-lanforge-vap-unicast-upload.pcapng capture shows mtk7921k station talking to a LANforge mtk7915 VAP. The capture filter is: wlan.addr == a8:93:4a:9d:47:a3 || == 00:0A:52:46:8D:4. The capture starts with the TCP traffic idle and the station in sleep mode. The STA then wakes up in frame 884 and it starts sending TCP traffic in frame 888. The TCP traffic has then quiesced for a bit in frame 996 and STA goes back to sleep.

Wake/Sleep testing in download direction

Packet Capture Analysis of Ucast to Mcast Capture with Buggy AP with Bad Ack on Frames

See ‘power-save-ax200-asus.pcapng’ file linked above. The captures ‘power-save-ax200-sta-9984-lanforge-vap-unicast.pcapng’ and ‘power-save-mtk7921k-sta-9984-lanforge-vap-unicast.pcapng’ show similar behaviour, but without the buggy lack of ACKs from the AP since a different AP (LANforge on QCA 9984 chipset) was used.

Starting with frame 227, a beacon frame, the AP indicates in the TIM IE that (unicast) data is waiting for the station with Association ID (AID) 0x8. This is the LANforge station in question, where it's AID is seen in the 'Probe' text dump in LANforge. This can also be seen by looking at the association frames, though this is not part of the capture. The TIM does not set the Multicast bit since this AP is converting multicast to unicast.

Frame 228 is from the station. It will always wake up to receive the beacon so that it can check the TIM element to see if it needs to stay awake and tell AP it needs to receive frames. Frame 228 is a few micro-seconds after the beacon, and STA tells the AP that is is waking up (because the AID was set in the TIM), and so AP can send traffic to it:

The multicast frames (converted to unicast in this case) are sent very soon after the STA wakes, see frames 232, 236 - 240. After the burst of multicast frames, the traffic goes quite. The station decides to go back to sleep at frame 259. Notice the interval between frames, and that it has been idle for a bit...

Packet Capture Analysis of Multicast Capture with Powersave

See file ‘power-save-mtk7921k-sta-9984-lanforge-vap.pcapng’, using filter: wlan.addr == a8:93:4a:9d:47:a3 || wlan.addr == 04:f0:21:9a:64:65

The AP in this setup is LANforge using QCA 9984 chipset radio. The AP is not set to convert multicast to unicast, so we get to inspect how multicast traffic is queued and sent to sleeping stations.

In frame 269, the station goes to sleep.  It does not wake up again, at least not often, but it does wake up to hear beacons and pay attention to the DTIM so it can stay awake to receive multicast frames when needed. This was verified by ensuring that the multicast receiver endpoint on the station shows proper amount of received traffic.

Frame 364 shows DTIM with no multicast bit set, indicating no mcast frames are queued.  And, DTIM count is 1, which means that stations do not need to wake now, but do need to wake for next DTIM period.

Frame 365 is next beacon, and it shows mcast frames are queued, and the DTIM count indicates that stations should wake NOW to receive the queued frames.

And right after the beacon, the mcast frame is sent, as expected. Later, if station needs to send a frame, it would send a Null-Func frame with the ‘STA is awake’ flag set, and if AP needed to send a unicast frame, the AID of the STA would be added to the TIM element and so STA would wake for that as well….

Packet capture for buggy broadcast power-save behavior:

See file linked near the top: bad-bcast-powersave.pcapng

LANforge is configured to generate slow broadcast traffic in downstream direction using LANforge-Eth layer-3 connection type, with Dest Mac specified as all FFs, and 'b' side as un-managed. This causes A side to blindly send out these frames, the B side does not actually attempt to receive it.

This AP is not buffering broadcast packets and sending them after the beacon like it is supposed to. Frame 157 (beacon) does not have Multicast bit set in its TIM:

Frame 158 (broadcast frame) arrives 65ms after the beacon, indicating that the AP did not buffer the frame properly.

Packet capture for Wake/Sleep testing in upload direction:

See file ‘power-save-mtk7921k-sta-mtk7915-lanforge-vap-unicast-upload.pcapng’ This capture shows mtk7921k station talking to LANforge mtk7915 VAP. The capture filter is: wlan.addr == a8:93:4a:9d:47:a3 || == 00:0A:52:46:8D:4. The capture starts with the TCP traffic idle and the station in sleep mode. Frame 884 is STA waking up, and it starts sending TCP traffic frame 888.

At frame 996, the TCP traffic has quiesced for a bit, and STA goes back to sleep.

Candela  Technologies, 2417 Main Street, Suite 201, Ferndale, WA 98248, USA | | +1.360.380.1618
Facebook | LinkedIn | Blog