Ticket #1218 (new defect)

Opened 5 years ago

Last modified 5 years ago

Error in Power-Save mode handling when in AP mode

Reported by: joerg.straube@iaeth.ch Assigned to:
Priority: major Milestone:
Component: madwifi: other Version: v0.9.2
Keywords: power save handling AP Cc:
Patch is attached: 0 Pending:

Description (Last modified by mentor)

History:
I built a base station (AP) based on madwifi
The wireless client (STA) runs on Windows XP (Intel PRO/Wirless 3945ABG)

Symptom:
ping from STA to AP has high packet loss (upto 100%) when STA uses PS-Poll (Power-Save Polling)
ping is okay when STA uses CAM (Constantly Awake Mode)

Configuration:
AP HW: Intel Mac Mini, Atheros 5424
AP SW: madwifi-source 1:0.9.2+r1842, Debian etch, Kernel 2.6.18-4
AP initialization (/etc/network/interfaces)

  auto ath0
  iface ath0 inet static
        address 10.0.3.1
        netmask 255.255.255.0
        madwifi-base wifi0
        madwifi-mode ap
        wireless-key 1122-3344-55
        wireless-channel 9
        wireless-essid StraubeNet
        wireless-rate 54M
        wireless-txpower 50mW

When I change the STA as Intel suggests it works
http://support.intel.com/support/wireless/wlan/pro3945abg/index.htm

But as I never had to change the power setting under XP for other APs I think there is an error in madwifi...

Tickets #417, #480 sound quite similar.

Attachments

madwifi_packetloss.txt (7.4 kB) - added by joerg.straube@iaeth.ch on 03/24/07 08:35:33.
Trace with 100% packet loss
madwifi_pingokay.txt (2.7 kB) - added by joerg.straube@iaeth.ch on 03/24/07 08:36:43.
Trace without packetloss
wireshark_ath1.pcap (8.3 kB) - added by Jörg Straube <joerg.straube@iaeth.ch> on 04/12/07 09:30:08.
Trace taken on the AP (ath1=monitor mode)
tcpdump_ath0.txt (1.2 kB) - added by Jörg Straube <joerg.straube@iaeth.ch> on 04/12/07 09:31:13.
Trace taken on the AP (ath0=ap mode)

Change History

03/23/07 10:00:25 changed by mrenzmann

  • description changed.

03/24/07 02:02:00 changed by mentor

  • description changed.
  • summary changed from Error in power safe handling when in AP mode to Error in Power-Save mode handling when in AP mode.

03/24/07 02:09:36 changed by mentor

I think the best thing for you to do would be to get a packet capture from the AP and/or debugging log (turn on debugging using 80211debug and look in syslog), whilst the STA is pinging the AP.

03/24/07 02:10:54 changed by mentor

  • keywords changed from power safe handling AP to power save handling AP.
  • priority changed from critical to major.

03/24/07 08:35:33 changed by joerg.straube@iaeth.ch

  • attachment madwifi_packetloss.txt added.

Trace with 100% packet loss

03/24/07 08:36:43 changed by joerg.straube@iaeth.ch

  • attachment madwifi_pingokay.txt added.

Trace without packetloss

03/24/07 08:48:56 changed by joerg.straube@iaeth.ch

mentor,

I pinged the AP and attached the two traces: once with power management set to PSP (100% packet loss), once with power management set to CAM (all pings okay).

Remark: you will find in the traces a second SSID "StraubeNet (chan 4)". Before doing the pings, I switched to the other AP/SSID, set the power management to PSP or CAM, checked functionality with that other AP (an old Apple Airport, both cases okay!) and then switched back to the madwifi AP.

03/24/07 09:09:13 changed by joerg.straube@iaeth.ch

To clarify the involved MAC addresses:

AP 0:16:cb:08:f6:f6 (madwifi AP of interest)
STA 0:18:de:1c:b4:7c (client of interest)
STA 0:14:51:ed:5a:97 (other client but connected to other AP/SSID)

03/26/07 15:24:34 changed by Jörg Straube <joerg.straube@iaeth.ch>

I analysed the error further by using Wireshark and a VAP in monitor mode.

To save battery, the Windows XP driver periodically does the following: 

    STA                                      AP
        --- QoS Null (will stay up) ------->
        10 ms
        --- QoS Null (will go to sleep) --->
        200 ms
        --- QoS Null (will stay up) ------->
        10 ms
        --- QoS Null (will go to sleep) --->
        :
        :

It seems that in CAM mode, the Windows XP driver delays the (go to sleep) message after the ping request. I don't know the exact timing but we have a high probability for this successful message flow: 

    STA                                      AP
        --- ping request ------------------>
        <-- ping answer --------------------
        --- QoS Null (will go to sleep) --->

But in PSP mode, the Windows XP driver sends the (go to sleep) rather often. So, we will end up in the following unsuccessful message flow: 

    STA                                      AP
        --- ping request ------------------>
        --- QoS Null (will go to sleep) --->
        <-- ping answer --------------------

The answer from the AP gets lost as the STA sleeps. Madwifi AP is expected to buffer the ping answer until the STA is ready again!

03/29/07 04:06:34 changed by mentor

MadWiFi does buffer the traffic for a STA in PS mode.

Could you try a debug log with: 

80211debug +input +node +assoc +output +state +power +inact

04/03/07 08:43:57 changed by Jörg Straube <joerg.straube@iaeth.ch>

The two traces formerly attached were captured with 

80211debug 0xffffffff

04/06/07 19:41:54 changed by mentor

Duplicate frames for some reason...

I'm going to need a packet dump, I think; just with PS mode anabled should be fine.

04/12/07 09:30:08 changed by Jörg Straube <joerg.straube@iaeth.ch>

  • attachment wireshark_ath1.pcap added.

Trace taken on the AP (ath1=monitor mode)

04/12/07 09:31:13 changed by Jörg Straube <joerg.straube@iaeth.ch>

  • attachment tcpdump_ath0.txt added.

Trace taken on the AP (ath0=ap mode)

04/12/07 09:44:29 changed by Jörg Straube <joerg.straube@iaeth.ch>

To see what's going on, I did the following:
1) I created ath1 in addition to ath0 (wlanconfig ath1 create wlandev wifi0 wlanmode monitor -bssid)
2) I activated wireshark on ath1
3) and in parallel I did a "tcpdump -i ath0" on the standard base station interface

On the Windows client I did: 

C:\>ping 10.0.3.1

Pinging 10.0.3.1 with 32 bytes of data:

Reply from 10.0.3.1: bytes=32 time=3ms TTL=64
Request timed out
Request timed out
Reply from 10.0.3.1: bytes=32 time=9ms TTL=64

Ping statistics for 10.0.3.1:
    Packets: Sent = 4, Received = 2, Lost = 2 (50% loss)

If you look at the attached traces, you'll find that all four pings are in the air (trace on ath1) but only two reached the kernel (trace on ath0)

05/18/07 11:32:34 changed by joerg.straube@iaeth.ch

Yesterday, I disabled two madwifi default values 

iwpriv ath0 wmm 0
iwpriv ath0 bgscan 0

My STA <--> AP connection is stable now!

If I re-enable "wmm", the packet losses appear again. If I have some spare time, I will investigate further what is going on. But for the time being the error is closed, ehm, suppressed ;-)

05/24/07 20:02:40 changed by mentor

Hum... I don't see the Madwifi AP actually sending any beacons here. I see beacons from 00:0a:95:f8:a4:32, but that doesn't appear to be related...

Add/Change #1218 (Error in Power-Save mode handling when in AP mode)