|
||
| Network Testing and Emulation Solutions |
|
|
||
| Network Testing and Emulation Solutions |
Set up mcast traffic between upstream port sending to station with parameters of 9kbps Min Speed, 128 Kbps Max Speed and Default Pkt Size using the following cookbook link: http://www.candelatech.com/cookbook.php?vol=wifire&book=WiFi+Station+Multicast .
Double-click on the created station in the Port Mgr tab. Enable Powersave on LANforge station (in the Misc Configuration tab)
Configure station for something easy to sniff (20Mhz a/b/g/n) by clicking the Disable HT40 button in the Standard Configuration tab. Then click Apply and OK to close the Configure Settings window for the station.
Start sniffer with optional filter to see all frames from AP BSSID or STA BSSID.
Investigate packet capture:
The beacon right before the mcast frame should have the TIM Multicast flag set.
Beacon without mcast frame soon after should NOT have the Multicast flag set.
DTIM count counts down to zero, only at zero can mcast frames be transmitted.
DTIM count should count down, with maximum value being DTIM Period - 1.
If AP can change DTIM period, test with multiple DTIM periods.
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.
Set up download unicast TCP traffic between upstream port and station. Set the Min Speed as 9 Kbps, Max Speed 128 Kbps, and 1400 as the Pkt Size.
Double-click on the created station in the Port Mgr tab. Enable Powersave on LANforge station (in the Misc Configuration tab)
Configure station for something easy to sniff (20Mhz a/b/g/n) by clicking the Disable HT40 button in the Standard Configuration tab. Then click Apply and OK to close the Configure Settings window for the station.
Start sniffer, with optional filter to see all frames from AP BSSID or STA BSSID.
Investigate packet capture:
The beacon should indicate that AID has traffic waiting (and Multicast flag would not be set).
STA should send wake-up null-func frame very soon after the beacon is seen (regardless of DTIM count/period, which is not pertinent for unicast frames).
AP acks that and proceeds to send queued traffic to STA.
STA goes back to sleep after a short period (around 100ms)
Average latency for the TCP download frames is around 100ms since frames are held on the AP until the next beacon so that STA can know to wake.
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.
Set bursty traffic, min of zero, max of 128kbps, in upload direction.
Double-click on the created station in the Port Mgr tab. Enable Powersave on LANforge station (in the Misc Configuration tab)
Configure station for something easy to sniff (20Mhz a/b/g/n) by clicking the Disable HT40 button in the Standard Configuration tab. Then click Apply and OK to close the Configure Settings window for the station.
Start sniffer, with optional filter to see all frames from AP BSSID or STA BSSID.
Watch for packets from STA indicating it is going awake or asleep (Frame Control Field → Flags → PWR MGT)
STA should :
indicate it is awake before transmitting frames.
go to sleep after a period of idle time (about 100ms, I think, but it may depend on the station).
not transmit while asleep
STA may receive multicast packets while ‘asleep’ using the DTIM logic described above.
AP should not transmit unicast frames to STA while STA is asleep.
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 ||wlan.sa == 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.
Configure AP for bridge mode so that NAT is not an issue. Follow the following cookbook link to configure the AP in bridge mode: http://www.candelatech.com/cookbook.php?vol=wifire&book=wifi+VAP+bridge
Double-click on the created station in the Port Mgr tab. Enable Powersave on LANforge station (in the Misc Configuration tab)
Configure station for something easy to sniff (20Mhz a/b/g/n) by clicking the Disable HT40 button in the Standard Configuration tab. Then click Apply and OK to close the Configure Settings window for the station.
Start sniffer, with optional filter to see all frames from AP BSSID or STA BSSID.
Ping from upstream to STA, one packet per second.
Ping latency should vary from near zero to the beacon interval since AP will store packets between when STA sleeps and wakes again. STA will wake after seeing indication in DTIM that it needs to receive (non multicast) frames.
Packet loss should not be very high, this indicates AP is storing frames properly and that STA is waking properly.
Ping from STA to upstream should not have much latency, because STA should wake each time it wants to send ICMP request, and stay awake long enough to receive the response before going back to sleep.
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...
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….
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.
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 || wlan.sa == 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.
