CC3351: WOWLAN wake up system unexpected

Hello,

Are you able to use a sniffer capture and see which packets are turning on your system?

Yes, I am able to capture WiFi packets. I will try to capture the packets that trigger the wakeup.

Hello,

Are you using dedicated GPIO IRQ to wake your MPU?

Separately, which filters have you tried? Can you try 'iw phy0 wowlan enable any' and then send ping to the device? Does this work?

We are using HOST_IRQ_WL to wake up the system. I tried using iw phy0 wowlan enable any, and the system did wake up when I sent a ping to the device. The same thing happened when I set iw phy0 wowlan enable patterns 00:44:44:44:44:44:-:-:-:-:-:-:08:00:45:-:-:-:-:-:-:-:-:06:-:-:-:-:-:-:c0:a8:01:04:13:89.

I captured packets addressed to the device's MAC address, and this is what I found:

00:25:92:33:44:55 (GuangzhouS:33:44:55) is the MAC address of my device. Please see the attached Excel file for details.Capture 2.csv 

Hello,

I brought up wowlan on my system as well and also noticed some issues. For me the system came back online after a few seconds, even without the wake up or magic packet. Is this the same behavior for you?

Yes, that’s exactly what I am seeing as well.

Okay, understood. Let me debug this internally and report to the team. I will provide an update by next week. 

That would be great.

Just following up to see if there’s been any progress.

hi Sabeeh Khan1 

I used the latest sdk test to find that when the wifi go sleep, it will automatically get up to scan test ssid after 8 seconds, and then the system will resume. As shown in the above picture.
Please confirm whether this behavior is reasonable. looking forward to your reply

hi Sabeeh Khan1 

I grabbed the log of wifi firmware and intercepted the log of abnormal wake-up, and helped to analyze what caused the abnormal wake-up.  I look forward to your reply.
Log is as follows：

Hi Sabeeh Khan1 
I’ve also run into the same issue—the system wakes up unexpectedly just a few seconds after suspend.

Besides, when I applied the packet filter and sent a WOL wake-up packet from my phone, the system did not wake up.

The filter set is as follows:

The content of the WOL packet is as follows:


dest mac address: 74:02:e1:20:ec:12

Hi Jihu,

Thank you for all of the details. It seems we certainly have a bug with the WoWLAN behavior. Let us investigate internally and I will report back when we have fixes planned and developed.

Hi Jihu,

I'm providing a FW that should have some fixes. Please use this firmware while doing the wowlan testing. Do note that this is strictly for testing purposes of the wowlan and should be not used in any production purposes.

SW_ver_1.7.96.323_wowlan.zip

Hi  Sabeeh,

I test the FW on my side, and  the system wakes up unexpectedly just a few seconds after suspend

it's wake up by some other packet 

 but Wake-on-LAN (WoL) packet can wake up system immediately，I test it multitime。

Hello,

Very glad to hear the WoL packet is working for you.

From the sniffer, the unexpected packet is actually expected. Just before the packet you have highlighted there is an Action frame packet from the AP. For action frames, the MPU must wake up in order to maintain stable connections. These action frames are required by the wpa_supplicant so these frames can not be filtered out. 

Most often, action frames are used by APs to set the block session and length with stations. You can probably decrease the number of block ack sessions by setting 'disable_max_amsdu' to '1' in the wpa_supplicant.conf file. I would recommend this for testing purposes. 

What is the make and model of the AP you are using?

AP model:TP LINK Archer AX55

HI Sabeeh Khan1 

We have completed further testing with the latest firmware using an ASUS RT-AX86U router. Here are our findings and a request for alternative configurations:

1. Observation: System Wake-up during Sleep

Scenario: The device enters sleep mode successfully via the command echo mem > /sys/power/state.

Issue: After a short period in sleep, the ASUS RT-AX86U router sends an ADDBA Request (Action Frame).

Result: This specific Action Frame triggers the Wi-Fi chip to wake up the host system prematurely.

2. Feedback regarding disable_max_amsdu

We attempted to implement your suggestion to set disable_max_amsdu=1 in the configuration, but encountered the following:

Error: Our current wpa_supplicant build does not recognize the disable_max_amsdu field, returning an "unknown network field" error.

Analysis: It appears this specific feature was not enabled during the cross-compilation of our wpa_supplicant.

3. Questions & Requests regarding Protocol Offloading Since we cannot disable AMSDU via wpa_supplicant at this moment, could you please clarify the following firmware capabilities:

Firmware Offloading: Is it possible for the Wi-Fi firmware to autonomously handle (offload) ARP and ADDBA packets during sleep mode? We want to ensure that these routine protocol interactions are managed by the firmware to avoid unnecessary wake-up interrupts to the Linux kernel.

WoWLAN Configuration: Do you have recommended settings to enable ARP Offload and ADDBA Proxy specifically for this chipset during the suspend state?

Please prioritize this investigation, as the unintended wake-ups are impacting our power consumption validation for the trial production.

Hello,

wenrong xue said:

Firmware Offloading: Is it possible for the Wi-Fi firmware to autonomously handle (offload) ARP and ADDBA packets during sleep mode? We want to ensure that these routine protocol interactions are managed by the firmware to avoid unnecessary wake-up interrupts to the Linux kernel.

No, it is not possible. These packets must be handled by the network stack, which is a part of the linux kernel. So that is why we have to wake up the host MPU to send it these ARP and ADDBA packets.

wenrong xue said:

WoWLAN Configuration: Do you have recommended settings to enable ARP Offload and ADDBA Proxy specifically for this chipset during the suspend state?

We don't have any configurations to enable offloading of these packets. For now the best recommendation I have is to enable disable_max_amsdu in the wpa_supplicant which should disable ADDBA sessions with the AP.

hi Sabeeh Khan1 

I attempted to implement your suggestion to set disable_max_amsdu=1 in the configuration, but encountered the following:

Error: Our current wpa_supplicant build does not recognize the disable_max_amsdu field,
Line 3: unknown global field 'disable_max_amsdu=1'.
Line 3: Invalid configuration line 'disable_max_amsdu=1'.

Is it because some configuration options of wpa_supplicant are not turned on?

hi Sabeeh Khan1 
Is there any way to turn off wifi6(11ax) completely?

Hello,

Yes we do have the ability to turn off wifi 6. You can set it through the INI Composer tool and create a new cc33xx-conf.bin. We have a parameter called 'disable_wifi6'. 

Do note that the block ACK session and action frames are a part 802.11N, so you will still receive action frames even if wifi 6 is disabled. But you can give it a try anyways.

hi Sabeeh Khan1 

We have disabled WiFi 6 as advised (configured mac.he_enable = 0x01), but unfortunately, the frequent kernel wakeup issue persists.

After analyzing the sniffer logs, we observed the following sequence causing the wakeups:

1. Going to Sleep: When the kernel enters sleep mode, the WiFi firmware sends a DELBA (Delete Action) frame with the Power Management (PWR MGR) bit set to 1. This tells the router to delete the previous Block ACK (BA) link and indicates the device is going to sleep.

2. Unwanted Wakeup: About 10 seconds later, the router sends an ADDBA Request. Since the WiFi firmware cannot handle this packet while in its low-power state, the kernel is forced to wake up to process the ADDBA Request.

Further Testing: We performed a test by setting disable_ht = 1 in wpa_supplicant (which disables AMPDU). After disabling HT/AMPDU, the frequent kernel wakeup situation improved significantly.

my Question: Why does the WiFi firmware send a DELBA frame to tear down the BA link right before entering sleep? Could the firmware simply send a QoS Null Data packet with PM=1 to inform the router it is sleeping, without deleting the BA session? It seems that tearing down the session triggers the router to try and re-establish it (via ADDBA Request), which causes the wakeup.

Looking forward to your feedback.

AP model:ASUS  AX68U pro

wenrong xue said:

We have disabled WiFi 6 as advised (configured mac.he_enable = 0x01), but unfortunately, the frequent kernel wakeup issue persists.

Again, this is expected. Disabling wifi 6 will not have an effect on the behavior as BA sessions are a feature of wifi 4.

wenrong xue said:

my Question: Why does the WiFi firmware send a DELBA frame to tear down the BA link right before entering sleep? Could the firmware simply send a QoS Null Data packet with PM=1 to inform the router it is sleeping, without deleting the BA session? It seems that tearing down the session triggers the router to try and re-establish it (via ADDBA Request), which causes the wakeup.

I don't think this is the Wi-Fi firmware, but it is the linux kernel ending the connection before the kernel/MPU goes to sleep. And yes, the router retries the connection.

hi  Sabeeh Khan1 

Thanks for the previous feedback.

Following your suggestion, we investigated the mac80211 behavior and successfully applied a kernel patch(

From a60e1442ba0356780a9da9cf266fd7eeb906e1de Mon Sep 17 00:00:00 2001
From: xue yunfei <xueyunfei@cvte.com>
Date: Tue, 30 Dec 2025 20:02:59 +0800
Subject: [PATCH] debug ampdu sleep

---
 net/mac80211/agg-rx.c | 72 ++++++++++++++++++++++++++++++++++++++-----
 net/mac80211/util.c   | 24 +++++++++++++++
 2 files changed, 88 insertions(+), 8 deletions(-)

diff --git a/net/mac80211/agg-rx.c b/net/mac80211/agg-rx.c
index 49ec9bfb6..dd64652b9 100644
--- a/net/mac80211/agg-rx.c
+++ b/net/mac80211/agg-rx.c
@@ -74,34 +74,87 @@ void ___ieee80211_stop_rx_ba_session(struct sta_info *sta, u16 tid,
 	tid_rx = rcu_dereference_protected(sta->ampdu_mlme.tid_rx[tid],
 					lockdep_is_held(&sta->ampdu_mlme.mtx));
 
-	if (!test_bit(tid, sta->ampdu_mlme.agg_session_valid))
+	printk(KERN_INFO "mac80211: Rx BA session stop requested for %pM tid %u %s reason: %d tx: %d\n",
+	       sta->sta.addr, tid,
+	       initiator == WLAN_BACK_RECIPIENT ? "recipient" : "initiator",
+	       (int)reason, tx);
+
+	if (!test_bit(tid, sta->ampdu_mlme.agg_session_valid)) {
+		printk(KERN_INFO "mac80211: Rx BA session for %pM tid %u is not valid, skip\n",
+		       sta->sta.addr, tid);
 		return;
+	}
 
 	RCU_INIT_POINTER(sta->ampdu_mlme.tid_rx[tid], NULL);
 	__clear_bit(tid, sta->ampdu_mlme.agg_session_valid);
 
-	ht_dbg(sta->sdata,
-	       "Rx BA session stop requested for %pM tid %u %s reason: %d\n",
-	       sta->sta.addr, tid,
-	       initiator == WLAN_BACK_RECIPIENT ? "recipient" : "initiator",
-	       (int)reason);
+	printk(KERN_INFO "mac80211: Rx BA session cleared for %pM tid %u, tid_rx: %p\n",
+	       sta->sta.addr, tid, tid_rx);
 
+#if 0
+	/* Don't stop hardware RX BA during suspend, stop it in reconfig instead */
+	/* Check WLAN_STA_BLOCK_BA flag which is set during suspend */
+	if (!test_sta_flag(sta, WLAN_STA_BLOCK_BA)) {
+		printk(KERN_INFO "mac80211: Stopping hardware RX BA for %pM tid %u\n",
+		       sta->sta.addr, tid);
+		if (drv_ampdu_action(local, sta->sdata, &params))
+			sdata_info(sta->sdata,
+				   "HW problem - can not stop rx aggregation for %pM tid %d\n",
+				   sta->sta.addr, tid);
+		else
+			printk(KERN_INFO "mac80211: Hardware RX BA stopped successfully for %pM tid %u\n",
+			       sta->sta.addr, tid);
+	} else {
+		printk(KERN_INFO "mac80211: Skipping hardware RX BA stop for %pM tid %u (WLAN_STA_BLOCK_BA set)\n",
+		       sta->sta.addr, tid);
+	}
+#else
+	printk(KERN_INFO "mac80211: Stopping hardware RX BA for %pM tid %u\n",
+	       sta->sta.addr, tid);
 	if (drv_ampdu_action(local, sta->sdata, &params))
 		sdata_info(sta->sdata,
 			   "HW problem - can not stop rx aggregation for %pM tid %d\n",
 			   sta->sta.addr, tid);
+	else
+		printk(KERN_INFO "mac80211: Hardware RX BA stopped successfully for %pM tid %u\n",
+		       sta->sta.addr, tid);
+#endif
 
 	/* check if this is a self generated aggregation halt */
-	if (initiator == WLAN_BACK_RECIPIENT && tx)
+#if 1
+	/* Don't send DELBA during suspend/resume to keep BA sessions alive */
+	/* Check WLAN_STA_BLOCK_BA flag which is set during suspend */
+	if (initiator == WLAN_BACK_RECIPIENT && tx &&
+	    !test_sta_flag(sta, WLAN_STA_BLOCK_BA)) {
+		printk(KERN_INFO "mac80211: Sending DELBA for %pM tid %u reason: %d\n",
+		       sta->sta.addr, tid, reason);
+		ieee80211_send_delba(sta->sdata, sta->sta.addr,
+				     tid, WLAN_BACK_RECIPIENT, reason);
+	} else if (initiator == WLAN_BACK_RECIPIENT && tx) {
+		printk(KERN_INFO "mac80211: Skipping DELBA for %pM tid %u (WLAN_STA_BLOCK_BA set)\n",
+		       sta->sta.addr, tid);
+	}
+#else
+	if (initiator == WLAN_BACK_RECIPIENT && tx) {
+		printk(KERN_INFO "mac80211: Sending DELBA for %pM tid %u reason: %d\n",
+		       sta->sta.addr, tid, reason);
 		ieee80211_send_delba(sta->sdata, sta->sta.addr,
 				     tid, WLAN_BACK_RECIPIENT, reason);
+	}
+#endif
 
 	/*
 	 * return here in case tid_rx is not assigned - which will happen if
 	 * IEEE80211_HW_SUPPORTS_REORDERING_BUFFER is set.
 	 */
-	if (!tid_rx)
+	if (!tid_rx) {
+		printk(KERN_INFO "mac80211: Rx BA session stop complete for %pM tid %u (no tid_rx, hardware managed)\n",
+		       sta->sta.addr, tid);
 		return;
+	}
+
+	printk(KERN_INFO "mac80211: Cleaning up software RX BA resources for %pM tid %u\n",
+	       sta->sta.addr, tid);
 
 	del_timer_sync(&tid_rx->session_timer);
 
@@ -112,6 +165,9 @@ void ___ieee80211_stop_rx_ba_session(struct sta_info *sta, u16 tid,
 	del_timer_sync(&tid_rx->reorder_timer);
 
 	call_rcu(&tid_rx->rcu_head, ieee80211_free_tid_rx);
+
+	printk(KERN_INFO "mac80211: Rx BA session stop complete for %pM tid %u\n",
+	       sta->sta.addr, tid);
 }
 
 void __ieee80211_stop_rx_ba_session(struct sta_info *sta, u16 tid,
diff --git a/net/mac80211/util.c b/net/mac80211/util.c
index 6223af1c3..349979a13 100644
--- a/net/mac80211/util.c
+++ b/net/mac80211/util.c
@@ -2537,6 +2537,30 @@ int ieee80211_reconfig(struct ieee80211_local *local)
 			ieee80211_sta_restart(sdata);
 	}
 
+#if 0
+	/* After full recovery, tear down all BA sessions completely */
+	if (ieee80211_hw_check(hw, AMPDU_AGGREGATION) && suspended) {
+		printk(KERN_INFO "mac80211: After full recovery, tearing down all BA sessions completely\n");
+		mutex_lock(&local->sta_mtx);
+		list_for_each_entry(sta, &local->sta_list, list) {
+			/* Completely tear down all BA sessions after recovery */
+			printk(KERN_INFO "mac80211: Tearing down all BA sessions for STA %pM\n",
+			       sta->sta.addr);
+			ieee80211_sta_tear_down_BA_sessions(sta,
+							     AGG_STOP_LOCAL_REQUEST);
+			printk(KERN_INFO "mac80211: BA sessions torn down for STA %pM\n",
+			       sta->sta.addr);
+		}
+		mutex_unlock(&local->sta_mtx);
+		printk(KERN_INFO "mac80211: All BA sessions torn down after recovery\n");
+	} else {
+		if (!ieee80211_hw_check(hw, AMPDU_AGGREGATION))
+			printk(KERN_INFO "mac80211: Skipping BA teardown (AMPDU_AGGREGATION not supported)\n");
+		if (!suspended)
+			printk(KERN_INFO "mac80211: Skipping BA teardown (not from suspend recovery)\n");
+	}
+#endif
+
 	mod_timer(&local->sta_cleanup, jiffies + 1);
 #else
 	WARN_ON(1);
-- 
2.43.0

However, the system still wakes up abnormally. We have isolated the root cause to the Firmware's handling of Block ACK (BA) sessions specifically for IGMP traffic.

Scenario A (Current Issue):

• The router sends IGMP Multicast packets (likely converted to Unicast by AP).

• The WiFi Firmware replies with a Block ACK (BA).

• Result: This BA interaction triggers an interrupt that wakes up the Linux Kernel.

Scenario B (Control Test - Works Correctly):

• We configured disable_ht = 1 in wpa_supplicant (disabling AMPDU/BA).

• The router sends the same IGMP packets.

• The WiFi Firmware replies with a standard ACK.

• Result: The Linux Kernel stays asleep.

Our Request: Could you provide a firmware optimization or configuration to solve this? We need the firmware to handle these BA sessions (for background traffic like IGMP,ARP....) silently during sleep, similar to how it handles standard ACKs, without triggering a linux Wakeup.

Please let us know if there is a specific FW flag or update available.

Hello,

Can you please help to clarify: do you require a firmware optimization with the solution described in Scenario B? Or are you saying that the Firmware must handle all action and management frames such that the linux kernel will always stay asleep unless the wake word is provided?

hi Sabeeh Khan1 

1. Clarification on "Scenario B" (Block ACK Handling) Scenario B (disabling HT) is NOT our solution. We need HT/AMPDU enabled for performance. Our requirement is: The Firmware must handle Block ACK (BA) generation silently.

Logic: If an incoming packet (e.g., multicast IGMP) does not match the Wake Pattern and is filtered by the FW, the FW should still send the required Block ACK to the router to maintain the link, but it MUST NOT wake up the linux

The act of sending a BA should not be a wakeup event if the payload itself is ignored.

2. Requirement for ARP Offload In addition to the above, does the current firmware support ARP Offload?

Issue: We observe that ARP broadcast requests are also a frequent source of wakeups.

Requirement: The Firmware should automatically reply to ARP Requests (for its own IP) without waking up the Linux Kernel.

If this is already supported, please let us know the correct configuration (INI parameter or feature flag) to enable it.

Hello,

Thank you for clarifying the requirements. As I have mentioned before, we do not have the capability in our FW to handle these packets, as our FW assumes these packets need to be handled by the linux kernel. If it is a hard requirement for your product, then we need to discuss how we can add this feature in. This is not a simple feature to add in because we need to pull in much of the linux TCP/IP stack into the FW.

Hello Sabeeh,

      Reguarding this topic, we had discussed with our customer, and they are very concerned about standby power consumption. If we don't find a feasible solution, our product can't be released.

Hello,

Let's please discuss this soon, as it will require significant development time (more than just a few days) to enable such a feature.

Hi Jihu SI  Xing SU  wenrong xue 

Our current plan to handle the BlockACK session requests while the host MPU is asleep is decline these packets. 

With this solution, during WoWLAN, the AP retries ADDBA requests with exponential backoff and does not disconnect. Firmware responds with proper ADDBA_RESPONSE status DECLINE.

After wake, ADDBA requests arrive shortly and are immediately accepted by the host, and the BA session re-establishes normally. There will be no impact on the packet filter, and this solution will also speed up our development time.

I would to confirm with you if this solution is acceptable for BSH's application.

hi Sabeeh Khan1 

Yes, the solution to DECLINE the ADDBA requests during the host MPU sleep state is totally acceptable for our application and safe approach to keep the host asleep without dropping the connection.

We would like to confirm if the CC33xx firmware fully supports them concurrently during WoWLAN:

1. ARP Offload: Before the host enters deep sleep, we will push the device's IP address to the firmware. We expect the firmware to autonomously catch ARP requests and reply with ARP responses without waking up the host.

2. Multicast Filtering & Power Save State Maintenance: We expect the firmware to autonomously handle or filter specific multicast traffic (e.g., mDNS, SSDP, or general multicast drops) to prevent false wakeups. 

BSH provides a detailed list of popular AP/ router models in the market. You can get these router models, and do tests after the functions are developed to verify the feasibility of the functions.
xing su