Please note: This project is no longer active. The website is kept online for historic purposes only.
If you´re looking for a Linux driver for your Atheros WLAN device, you should continue here .

Ticket #1911 (new defect)

Opened 14 years ago

Last modified 13 years ago

madwifi problems with power saving STAs

Reported by: igor@thinkpads.net Assigned to:
Priority: major Milestone:
Component: madwifi: driver Version: trunk
Keywords: power saving Cc:
Patch is attached: 0 Pending: 0

Description (Last modified by mrenzmann)

Hardware: Asus WL-500g Premium with TP-Link TL-WN560G card, laptop with Intel 3945 card, Nokia N810. Software: OpenWrt trunk with 2.6 kernel and MadWifi driver in AP mode, bridged to local network.

After changing wireless card in my Asus router from broadcom to atheros I started to see a problems with my Nokia N810 device. It frequently diassociates from AP, but didn't notice that, also stopes answer to pings, but can answer after a series of pings requests. I started to investigate this situation.

Facts:

  1. N810 disconnects from AP by inact timeout with: 
    Apr 27 17:03:51 OpenWrt user.debug kernel: wifi0/ath0[06:19:e0:8c:09:29]: 00:1d:6e:d5:7c:7e probe station due to inactivity
Apr 27 17:06:21 OpenWrt user.debug kernel: wifi0/ath0[06:19:e0:8c:09:29]: 00:1d:6e:d5:7c:7e probe station due to inactivity
Apr 27 17:06:36 OpenWrt user.debug kernel: wifi0/ath0[06:19:e0:8c:09:29]: 00:1d:6e:d5:7c:7e probe station due to inactivity
Apr 27 17:06:51 OpenWrt user.debug kernel: wifi0/ath0[06:19:e0:8c:09:29]: 00:1d:6e:d5:7c:7e station timed out due to inactivity (refcnt 9)
Apr 27 17:06:51 OpenWrt user.debug kernel: wifi0/ath0[06:19:e0:8c:09:29]: 00:1d:6e:d5:7c:7e send station deauthenticate (reason 2)
Apr 27 17:06:51 OpenWrt user.debug kernel: wifi0/ath0[06:19:e0:8c:09:29]: 00:1d:6e:d5:7c:7e station with aid 1 leaves (refcnt 13)
Apr 27 17:06:51 OpenWrt user.debug kernel: wifi0/ath0[06:19:e0:8c:09:29]: 00:1d:6e:d5:7c:7e node_cleanup_debug (ieee80211_node_leave2316): power save mode off, 0 STAs in PS mode
  1. N810 always answer to pings and other packets if it transmits data out through AP;
  1. N810 works excellent if it has disabled Power Saving mode;
    After that I start running tcpdump on both ends (AP and N810):
  1. when N810 in PS, it often didn't recieve arp broadcast from network, and don't answer to arp requests for it;
  1. nothing changes after iwpriv ath0 uapsd 0, iwpriv ath0 wmm 0, and encryption set to none;
    Then I put my laptop in Power Saving mode:
  1. with laptop I see exactly the same situation with arp requests;
  1. laptop didn't deassociate from AP, because of frequent changes in PS mode and resetting timeout: 
    Apr 27 17:11:52 OpenWrt user.debug kernel: wifi0/ath0[06:19:e0:8c:09:29]: 00:18:de:b8:be:7b power save mode on, 1 STAs in PS mode
Apr 27 17:11:53 OpenWrt user.debug kernel: wifi0/ath0[06:19:e0:8c:09:29]: 00:18:de:b8:be:7b power save mode off, 0 STAs in PS mode
Apr 27 17:11:53 OpenWrt user.debug kernel: wifi0/ath0[06:19:e0:8c:09:29]: 00:18:de:b8:be:7b power save mode on, 1 STAs in PS mode
Apr 27 17:11:54 OpenWrt user.debug kernel: wifi0/ath0[06:19:e0:8c:09:29]: 00:18:de:b8:be:7b power save mode off, 0 STAs in PS mode
Apr 27 17:11:54 OpenWrt user.debug kernel: wifi0/ath0[06:19:e0:8c:09:29]: 00:18:de:b8:be:7b power save mode on, 1 STAs in PS mode
  1. laptop also works excellent with disabled Power Saving;

To fix arp problem I added mac address to arp table of desktop computer in lan with permanent state. And it helps - madwifi always sends packet with direct address to PS STAs: 

Apr 27 17:17:42 OpenWrt user.debug kernel: wifi0/ath0[06:19:e0:8c:09:29]: 00:1d:6e:d5:7c:7e save frame, 1 now queued
Apr 27 17:17:42 OpenWrt user.debug kernel: wifi0/ath0[06:19:e0:8c:09:29]: 06:19:e0:8c:09:29 ieee80211_beacon_update: TIM updated, pending 1, off 0, len 1
Apr 27 17:17:42 OpenWrt user.debug kernel: wifi0/ath0[06:19:e0:8c:09:29]: 00:1d:6e:d5:7c:7e recv ps-poll, send packet, queue empty
Apr 27 17:17:42 OpenWrt user.debug kernel: wifi0/ath0[06:19:e0:8c:09:29]: 00:1d:6e:d5:7c:7e power save mode off, 0 STAs in PS mode
Apr 27 17:17:42 OpenWrt user.debug kernel: wifi0/ath0[06:19:e0:8c:09:29]: 06:19:e0:8c:09:29 ieee80211_beacon_update: TIM updated, pending 0, off 0, len 1
Apr 27 17:17:42 OpenWrt user.debug kernel: wifi0/ath0[06:19:e0:8c:09:29]: 00:1d:6e:d5:7c:7e power save mode on, 1 STAs in PS mode

I try different versions of madwifi:

  1. r3314 with openwrt patches;
  2. r3314 without openwrt patches;
  3. r3480 without openwrt patches.

All works the same. I can't at the moment try latest trunk because of ticket 1910, but I think that it also has this problem.

I can give any logs and debugging testing if you say what you want to see.

Change History

04/27/08 21:57:47 changed by foodoc

sounds like the broadcast TIM bit isn't set, or your N810 ignores the bit... mentor?

04/27/08 23:15:15 changed by igor@thinkpads.net

It's not N810 issue. My laptop with Intel 3945 card shows the same problem with broadcast arp when Power Saving. Also both of them works perfectly in Power Saving with Broadcom BCM4318, BCM4320 wireless and Broadcom proprietary driver 4.80.53.0.

N810 specific issue - diassociate from AP after inact timeout. And this is also shoudn't be - with Broadcom driver N810 correctly passing inact timeout and associate for several days until you manually do diassociation. So with broadcom driver N810 seems to acks probe requests.

Also you could look into this thread: http :// lists.shmoo.com/pipermail/hostap/2008-February/017373.html

People has the same symptoms, but says that disabled WMM helps them. In my tests it isn't helping at all.

04/28/08 00:37:46 changed by foodoc

no. no. I have a Intel Card too and let me explain who I see it.

the basics: see 802.11-2007.pdf when a station _goes_ into powersaving... It will only wake up now and then listen to the beacons. And then it'll powerdown again UNTIL "one" beacon comes in, that contains a TIM where the Station's AID or broadcast-bit is set... Then the Station will wake up and tell the AP about it.

So, and what does the Intel do? It bursts out a huge number of NULL-Funcs without waiting for any beacon... Just to generate traffic and tell the AP that it was _active_. This is a known workaround for all APs with a broken powersaving feature, because noone got it right.

04/28/08 06:22:35 changed by mrenzmann

  • description changed.

04/28/08 09:32:07 changed by igor@thinkpads.net

Oh, yes, you are right.

I see this NULL-Funcs via tcpdump, it comes every second to AP. And this is what I see under clause 7.

Also earlier I tested laptop with 'arping -c 1', that was a bad idea. I'm testing with 'arping -c 3' now and laptop always answer at least for 1 request. So, we shoudn't taking it into consideration anymore and think only about N810.

N810 comes with Conexant cx3110x wireless, firmware version 2.13.0.0.a.22.8 and driver version 2.0.15. And it seems that it working though closed source wi-fi stack in module umac.ko.

04/28/08 10:26:13 changed by foodoc

hmm, isn't the cx3110x more or less a stripped-down version of the PrismGT Softmac chip? Maybe it's already supported by the "in-kernel" p54 softmac driver. Johannes Berg should know more about this topic, since he has a N810 too...

04/28/08 10:49:04 changed by igor@thinkpads.net

In dmesg it says: 

cx3110x: chip variant STLC4550

Also I found this thread via google:

https :// garage.maemo.org/pipermail/cx3110x-devel/2007-November/000001.html

04/29/08 00:07:05 changed by igor@thinkpads.net

BTW, should Intel 3945 recieve all broadcast from AP even with their workaround?

04/30/08 16:24:42 changed by foodoc

The Intel card never disable the RX completely... (whereas the STLC4550 shuts down, between the beacon). So Intel always sees all frames!

04/30/08 16:54:35 changed by igor@thinkpads.net

As I thought. But in my tests it recieves 1-3 broadcast of 3, i.e. not always all. So, even Intel 3945 works strange with my atheros AP. Also I tryed with Ubiquiti SR2 instead of TP-Link card, and all the same (only few specific differences).

04/30/08 18:28:18 changed by foodoc

hmm.. as I said. noone got it right... However until someone checks if the stack sets the broadcast bit in the TIM IE correctly, or not. We are groping in the dark with this issue.

05/15/08 03:30:53 changed by mentor

  • priority changed from critical to major.

11/06/08 09:17:40 changed by marpros@gmail.com

I can confirm same behavior on Nokia E51 with openwrt madwifi r3314, with PS phone doesn't respond to ARP queries from madwifi-driven card w/o PS works OK, but.. symbian's energy profiler says that avg. power usage in standby growed from 0.02W to 0.8W ... :(

11/06/08 09:20:06 changed by marpros

additional info, phone w/PS works correctly with another access points, two linksys tested

11/29/08 23:25:31 changed by ftx

I am experiencing the same problem with a nokia n800. Is their any workaround, except disabling power saving mode ?

(follow-up: ↓ 23 ) 01/05/09 09:31:20 changed by camh

I have hit this issue too. I have a nokia n800 and I'm using an Atheros AR5212 minipci card in a Debian testing box using kernel 2.7.27.10 and the debian madwifi-source package, version 1:0.9.4+r3772.20080716-1.

I have tested two scenarios - AP without encryption and AP with WPA-PSK TKIP. I see slightly different behaviour for each.

If I run the AP without encryption, the TIM bitmap is set properly to wake up the n800 when it has data for it. However if you flush the ARP cache, the ARP broadcasts are not received by the n800 as the mcast bit in the TIM parameter is not set. Debug messages always say "Updating beacon - mcast pending=0.".

If I run the AP with WPA-PSK TKIP (using hostapd 0.5.10) the behaviour is a little different. The n800 goes into power save mode just after completing DHCP. The linux network stack seems to do an ARP probe just after where it sends a number of ARP requests directly to the n800 (unicast MAC address, not broadcast). The n800 does not receive these because the TIM bit for its AID is not sent in any beacons. Broadcast packets behave the same as the non-encrypted case.

I can provide pcap files from another station in monitor mode if needed.

(follow-up: ↓ 18 ) 02/09/09 14:54:02 changed by iseeyou@nic.fi

What driver DD-WRT firmware uses? It works fine with power saving enabled.

(in reply to: ↑ 17 ) 02/10/09 12:06:31 changed by mrenzmann

  • pending changed.

Replying to iseeyou@nic.fi:

What driver DD-WRT firmware uses? It works fine with power saving enabled.

Afaik they use a modified version of MadWifi. Their modifications may make the difference here.

03/15/09 20:09:10 changed by anonymous

Does this affect ath5k?

03/15/09 20:10:40 changed by iseeyou@nic.fi

This was tested on Fon2200.

(follow-up: ↓ 22 ) 04/19/09 12:22:58 changed by simon-madwifi@imaginator.com

Just a "me too" on this one. As a work-around I'm running the nokia without the wlan powersaving. It works, but kills the battery.

(in reply to: ↑ 21 ) 04/19/09 14:06:13 changed by anonymous

Replying to simon-madwifi@imaginator.com:

Just a "me too" on this one. As a work-around I'm running the nokia without the wlan powersaving. It works, but kills the battery.

more information:

works fine without encryption on KAMIKAZE (8.09, r14511). Turning on WPA gets the Nokia E71 very upset and it looses it's connection and all ARP madness ensues.

(in reply to: ↑ 16 ) 04/26/09 11:09:35 changed by camh

Replying to camh:

I have hit this issue too. I have a nokia n800 and I'm using an Atheros AR5212 minipci card in a Debian testing box using kernel 2.7.27.10 and the debian madwifi-source package, version 1:0.9.4+r3772.20080716-1.

I have just retested with kernel wireless-testing/master (91e2d84) with madwifi trunk r4011 using hostapd 0.6.9 and everything works now. I can use my nokia n800 in power saving mode and it has worked for the last few hours, using WPA.

My previous test that did not work was with 2.6.29.1, madwifi-free branch r3952 with hostapt 0.6.9. So it is some recent change that has got this going for me.

04/26/09 19:10:19 changed by anonymous

I don't know how difficult to fix this. All other wireless access point I know are working even DD-WRT. Why don't ask DD-WRT fixes?