rtlwifi/rtl8192cu AP mode broken with PS STA

rtlwifi/rtl8192cu AP mode broken with PS STA

[Maciej S. Szmigiero]

Hi,

It looks like rtlwifi/rtl8192cu AP mode is broken when a STA is using PS,
since the driver does not update its beacon to account for TIM changes,
so a station that is sleeping will never learn that it has packets
buffered at the AP.

Looking at the code, the rtl8192cu driver implements neither the set_tim()
callback, nor does it explicitly update beacon data periodically, so it
has no way to learn that it had changed.

This results in the AP mode being virtually unusable with STAs that do
PS and don't allow for it to be disabled (IoT devices, mobile phones,
etc.).

I think the easiest fix here would be to implement set_tim() for example
the way rt2x00 driver does: queue a work or schedule a tasklet to update
the beacon data on the device.

Thanks,
Maciej

Re: rtlwifi/rtl8192cu AP mode broken with PS STA

[Maciej S. Szmigiero]

On 29.03.2021 00:54, Maciej S. Szmigiero wrote:
> Hi,
> 
> It looks like rtlwifi/rtl8192cu AP mode is broken when a STA is using PS,
> since the driver does not update its beacon to account for TIM changes,
> so a station that is sleeping will never learn that it has packets
> buffered at the AP.
> 
> Looking at the code, the rtl8192cu driver implements neither the set_tim()
> callback, nor does it explicitly update beacon data periodically, so it
> has no way to learn that it had changed.
> 
> This results in the AP mode being virtually unusable with STAs that do
> PS and don't allow for it to be disabled (IoT devices, mobile phones,
> etc.).
> 
> I think the easiest fix here would be to implement set_tim() for example
> the way rt2x00 driver does: queue a work or schedule a tasklet to update
> the beacon data on the device.

Are there any plans to fix this?
The driver is listed as maintained by Ping-Ke.

Thanks,
Maciej

Re: rtlwifi/rtl8192cu AP mode broken with PS STA

[Kalle Valo]

"Maciej S. Szmigiero" <mail@maciej.szmigiero.name> writes:

> On 29.03.2021 00:54, Maciej S. Szmigiero wrote:
>> Hi,
>>
>> It looks like rtlwifi/rtl8192cu AP mode is broken when a STA is using PS,
>> since the driver does not update its beacon to account for TIM changes,
>> so a station that is sleeping will never learn that it has packets
>> buffered at the AP.
>>
>> Looking at the code, the rtl8192cu driver implements neither the set_tim()
>> callback, nor does it explicitly update beacon data periodically, so it
>> has no way to learn that it had changed.
>>
>> This results in the AP mode being virtually unusable with STAs that do
>> PS and don't allow for it to be disabled (IoT devices, mobile phones,
>> etc.).
>>
>> I think the easiest fix here would be to implement set_tim() for example
>> the way rt2x00 driver does: queue a work or schedule a tasklet to update
>> the beacon data on the device.
>
> Are there any plans to fix this?
> The driver is listed as maintained by Ping-Ke.

Yeah, power save is hard and I'm not surprised that there are drivers
with broken power save mode support. If there's no fix available we
should stop supporting AP mode in the driver.

-- 
https://patchwork.kernel.org/project/linux-wireless/list/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

Re: rtlwifi/rtl8192cu AP mode broken with PS STA

[Maciej S. Szmigiero]

On 06.04.2021 12:00, Kalle Valo wrote:
> "Maciej S. Szmigiero" <mail@maciej.szmigiero.name> writes:
> 
>> On 29.03.2021 00:54, Maciej S. Szmigiero wrote:
>>> Hi,
>>>
>>> It looks like rtlwifi/rtl8192cu AP mode is broken when a STA is using PS,
>>> since the driver does not update its beacon to account for TIM changes,
>>> so a station that is sleeping will never learn that it has packets
>>> buffered at the AP.
>>>
>>> Looking at the code, the rtl8192cu driver implements neither the set_tim()
>>> callback, nor does it explicitly update beacon data periodically, so it
>>> has no way to learn that it had changed.
>>>
>>> This results in the AP mode being virtually unusable with STAs that do
>>> PS and don't allow for it to be disabled (IoT devices, mobile phones,
>>> etc.).
>>>
>>> I think the easiest fix here would be to implement set_tim() for example
>>> the way rt2x00 driver does: queue a work or schedule a tasklet to update
>>> the beacon data on the device.
>>
>> Are there any plans to fix this?
>> The driver is listed as maintained by Ping-Ke.
> 
> Yeah, power save is hard and I'm not surprised that there are drivers
> with broken power save mode support. If there's no fix available we
> should stop supporting AP mode in the driver.
> 

https://wireless.wiki.kernel.org/en/developers/documentation/mac80211/api
clearly documents that "For AP mode, it must (...) react to the set_tim()
callback or fetch each beacon from mac80211".

The driver isn't doing either so no wonder the beacon it is sending
isn't getting updated.

As I have said above, it seems to me that all that needs to be done here
is to queue a work in a set_tim() callback, then call
send_beacon_frame() from rtlwifi/core.c from this work.

But I don't know the exact device semantics, maybe it needs some other
notification that the beacon has changed, too, or even tries to
manage the TIM bitmap by itself.

It would be a shame to lose the AP mode for such minor thing, though.

I would play with this myself, but unfortunately I don't have time
to work on this right now.

That's where my question to Realtek comes: are there plans to actually
fix this?

Maciej

Re: rtlwifi/rtl8192cu AP mode broken with PS STA

[Larry Finger]

On 4/6/21 7:06 AM, Maciej S. Szmigiero wrote:
> On 06.04.2021 12:00, Kalle Valo wrote:
>> "Maciej S. Szmigiero" <mail@maciej.szmigiero.name> writes:
>>
>>> On 29.03.2021 00:54, Maciej S. Szmigiero wrote:
>>>> Hi,
>>>>
>>>> It looks like rtlwifi/rtl8192cu AP mode is broken when a STA is using PS,
>>>> since the driver does not update its beacon to account for TIM changes,
>>>> so a station that is sleeping will never learn that it has packets
>>>> buffered at the AP.
>>>>
>>>> Looking at the code, the rtl8192cu driver implements neither the set_tim()
>>>> callback, nor does it explicitly update beacon data periodically, so it
>>>> has no way to learn that it had changed.
>>>>
>>>> This results in the AP mode being virtually unusable with STAs that do
>>>> PS and don't allow for it to be disabled (IoT devices, mobile phones,
>>>> etc.).
>>>>
>>>> I think the easiest fix here would be to implement set_tim() for example
>>>> the way rt2x00 driver does: queue a work or schedule a tasklet to update
>>>> the beacon data on the device.
>>>
>>> Are there any plans to fix this?
>>> The driver is listed as maintained by Ping-Ke.
>>
>> Yeah, power save is hard and I'm not surprised that there are drivers
>> with broken power save mode support. If there's no fix available we
>> should stop supporting AP mode in the driver.
>>
> 
> https://wireless.wiki.kernel.org/en/developers/documentation/mac80211/api
> clearly documents that "For AP mode, it must (...) react to the set_tim()
> callback or fetch each beacon from mac80211".
> 
> The driver isn't doing either so no wonder the beacon it is sending
> isn't getting updated.
> 
> As I have said above, it seems to me that all that needs to be done here
> is to queue a work in a set_tim() callback, then call
> send_beacon_frame() from rtlwifi/core.c from this work.
> 
> But I don't know the exact device semantics, maybe it needs some other
> notification that the beacon has changed, too, or even tries to
> manage the TIM bitmap by itself.
> 
> It would be a shame to lose the AP mode for such minor thing, though.
> 
> I would play with this myself, but unfortunately I don't have time
> to work on this right now.
> 
> That's where my question to Realtek comes: are there plans to actually
> fix this?

Yes, I am working on this. My only question is "if you are such an expert on the 
problem, why do you not fix it?"

The example in rx200 is not particularly useful, and I have not found any other 
examples.

Larry

Re: rtlwifi/rtl8192cu AP mode broken with PS STA

[Maciej S. Szmigiero]

On 06.04.2021 18:25, Larry Finger wrote:
> On 4/6/21 7:06 AM, Maciej S. Szmigiero wrote:
>> On 06.04.2021 12:00, Kalle Valo wrote:
>>> "Maciej S. Szmigiero" <mail@maciej.szmigiero.name> writes:
>>>
>>>> On 29.03.2021 00:54, Maciej S. Szmigiero wrote:
>>>>> Hi,
>>>>>
>>>>> It looks like rtlwifi/rtl8192cu AP mode is broken when a STA is using PS,
>>>>> since the driver does not update its beacon to account for TIM changes,
>>>>> so a station that is sleeping will never learn that it has packets
>>>>> buffered at the AP.
>>>>>
>>>>> Looking at the code, the rtl8192cu driver implements neither the set_tim()
>>>>> callback, nor does it explicitly update beacon data periodically, so it
>>>>> has no way to learn that it had changed.
>>>>>
>>>>> This results in the AP mode being virtually unusable with STAs that do
>>>>> PS and don't allow for it to be disabled (IoT devices, mobile phones,
>>>>> etc.).
>>>>>
>>>>> I think the easiest fix here would be to implement set_tim() for example
>>>>> the way rt2x00 driver does: queue a work or schedule a tasklet to update
>>>>> the beacon data on the device.
>>>>
>>>> Are there any plans to fix this?
>>>> The driver is listed as maintained by Ping-Ke.
>>>
>>> Yeah, power save is hard and I'm not surprised that there are drivers
>>> with broken power save mode support. If there's no fix available we
>>> should stop supporting AP mode in the driver.
>>>
>>
>> https://wireless.wiki.kernel.org/en/developers/documentation/mac80211/api
>> clearly documents that "For AP mode, it must (...) react to the set_tim()
>> callback or fetch each beacon from mac80211".
>>
>> The driver isn't doing either so no wonder the beacon it is sending
>> isn't getting updated.
>>
>> As I have said above, it seems to me that all that needs to be done here
>> is to queue a work in a set_tim() callback, then call
>> send_beacon_frame() from rtlwifi/core.c from this work.
>>
>> But I don't know the exact device semantics, maybe it needs some other
>> notification that the beacon has changed, too, or even tries to
>> manage the TIM bitmap by itself.
>>
>> It would be a shame to lose the AP mode for such minor thing, though.
>>
>> I would play with this myself, but unfortunately I don't have time
>> to work on this right now.
>>
>> That's where my question to Realtek comes: are there plans to actually
>> fix this?
> 
> Yes, I am working on this. My only question is "if you are such an expert on the problem, why do you not fix it?"

I don't think I am an expert here - I've tried to use a rtl8192cu USB
dongle in AP mode but its STAs would become unreachable or disconnect
after a short while, so I have started investigating the reason for such
problems.
Ultimately, I have traced it to DTIM in beacons not indicating there are
frames buffered for connected stations.

Then I've looked how the beacon that is broadcast is supposed to get
updated when it changes and seen there seems to be no existing mechanism
for this in rtl8192cu driver.
However, I had to stop at this point and post my findings as I could not
commit more time to this issue due to other workload.

> The example in rx200 is not particularly useful, and I have not found any other examples.

That's why I thought it would be best if somebody from Realtek, with
deep knowledge of both the driver and the hardware, could voice their
opinion here.

As I have stated earlier, just uploading new beacon to the hardware
might not be enough for it to be (safely) updated.

> Larry
> 

Thanks,
Maciej

Re: rtlwifi/rtl8192cu AP mode broken with PS STA

[Pkshih]

[-- Attachment #1: Type: text/plain, Size: 3068 bytes --]

On Tue, 2021-04-06 at 11:25 -0500, Larry Finger wrote:
> On 4/6/21 7:06 AM, Maciej S. Szmigiero wrote:
> > On 06.04.2021 12:00, Kalle Valo wrote:
> >> "Maciej S. Szmigiero" <mail@maciej.szmigiero.name> writes:
> >>
> >>> On 29.03.2021 00:54, Maciej S. Szmigiero wrote:
> >>>> Hi,
> >>>>
> >>>> It looks like rtlwifi/rtl8192cu AP mode is broken when a STA is using PS,
> >>>> since the driver does not update its beacon to account for TIM changes,
> >>>> so a station that is sleeping will never learn that it has packets
> >>>> buffered at the AP.
> >>>>
> >>>> Looking at the code, the rtl8192cu driver implements neither the set_tim()
> >>>> callback, nor does it explicitly update beacon data periodically, so it
> >>>> has no way to learn that it had changed.
> >>>>
> >>>> This results in the AP mode being virtually unusable with STAs that do
> >>>> PS and don't allow for it to be disabled (IoT devices, mobile phones,
> >>>> etc.).
> >>>>
> >>>> I think the easiest fix here would be to implement set_tim() for example
> >>>> the way rt2x00 driver does: queue a work or schedule a tasklet to update
> >>>> the beacon data on the device.
> >>>
> >>> Are there any plans to fix this?
> >>> The driver is listed as maintained by Ping-Ke.
> >>
> >> Yeah, power save is hard and I'm not surprised that there are drivers
> >> with broken power save mode support. If there's no fix available we
> >> should stop supporting AP mode in the driver.
> >>
> > 
> > https://wireless.wiki.kernel.org/en/developers/documentation/mac80211/api
> > clearly documents that "For AP mode, it must (...) react to the set_tim()
> > callback or fetch each beacon from mac80211".
> > 
> > The driver isn't doing either so no wonder the beacon it is sending
> > isn't getting updated.
> > 
> > As I have said above, it seems to me that all that needs to be done here
> > is to queue a work in a set_tim() callback, then call
> > send_beacon_frame() from rtlwifi/core.c from this work.
> > 
> > But I don't know the exact device semantics, maybe it needs some other
> > notification that the beacon has changed, too, or even tries to
> > manage the TIM bitmap by itself.
> > 
> > It would be a shame to lose the AP mode for such minor thing, though.
> > 
> > I would play with this myself, but unfortunately I don't have time
> > to work on this right now.
> > 
> > That's where my question to Realtek comes: are there plans to actually
> > fix this?
> 
> Yes, I am working on this. My only question is "if you are such an expert on the 
> problem, why do you not fix it?"
> 
> The example in rx200 is not particularly useful, and I have not found any other 
> examples.
> 

Hi Larry,

I have a draft patch that forks a work to do send_beacon_frame(), whose
behavior like Maciej mentioned.
I did test on RTL8821AE; it works well. But, it seems already work well even
I don't apply this patch, and I'm still digging why.

I don't have a rtl8192cu dongle on hand, but I'll try to find one.

---
Ping-Ke


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-rtlwifi-implement-set_tim-by-update-beacon-content.patch --]
[-- Type: text/x-patch; name="0001-rtlwifi-implement-set_tim-by-update-beacon-content.patch", Size: 5209 bytes --]

From 44be80232aa49737c035ee4656d20a22f573d33e Mon Sep 17 00:00:00 2001
From: Ping-Ke Shih <pkshih@realtek.com>
Date: Tue, 6 Apr 2021 19:55:59 +0800
Subject: [PATCH] rtlwifi: implement set_tim by update beacon content

Once beacon content is changed, we update the content to wifi card by
send_beacon_frame().

Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
---
 drivers/net/wireless/realtek/rtlwifi/core.c | 30 +++++++++++++++++++++
 drivers/net/wireless/realtek/rtlwifi/core.h |  1 +
 drivers/net/wireless/realtek/rtlwifi/pci.c  |  3 +++
 drivers/net/wireless/realtek/rtlwifi/usb.c  |  3 +++
 drivers/net/wireless/realtek/rtlwifi/wifi.h |  1 +
 5 files changed, 38 insertions(+)

diff --git a/drivers/net/wireless/realtek/rtlwifi/core.c b/drivers/net/wireless/realtek/rtlwifi/core.c
index 965bd9589045..ca47a70d9a86 100644
--- a/drivers/net/wireless/realtek/rtlwifi/core.c
+++ b/drivers/net/wireless/realtek/rtlwifi/core.c
@@ -1018,6 +1018,25 @@ static void send_beacon_frame(struct ieee80211_hw *hw,
 	}
 }
 
+void rtl_update_beacon_work_callback(struct work_struct *work)
+{
+	struct rtl_works *rtlworks =
+	    container_of(work, struct rtl_works, update_beacon_work);
+	struct ieee80211_hw *hw = rtlworks->hw;
+	struct rtl_priv *rtlpriv = rtl_priv(hw);
+	struct ieee80211_vif *vif = rtlpriv->mac80211.vif;
+
+	if (!vif) {
+		WARN_ONCE(true, "no vif to update beacon\n");
+		return;
+	}
+
+	mutex_lock(&rtlpriv->locks.conf_mutex);
+	send_beacon_frame(hw, vif);
+	mutex_unlock(&rtlpriv->locks.conf_mutex);
+}
+EXPORT_SYMBOL_GPL(rtl_update_beacon_work_callback);
+
 static void rtl_op_bss_info_changed(struct ieee80211_hw *hw,
 				    struct ieee80211_vif *vif,
 				    struct ieee80211_bss_conf *bss_conf,
@@ -1747,6 +1766,16 @@ static void rtl_op_flush(struct ieee80211_hw *hw,
 		rtlpriv->intf_ops->flush(hw, queues, drop);
 }
 
+static int rtl_op_set_tim(struct ieee80211_hw *hw, struct ieee80211_sta *sta,
+			  bool set)
+{
+	struct rtl_priv *rtlpriv = rtl_priv(hw);
+
+	schedule_work(&rtlpriv->works.update_beacon_work);
+
+	return 0;
+}
+
 /*	Description:
  *		This routine deals with the Power Configuration CMD
  *		 parsing for RTL8723/RTL8188E Series IC.
@@ -1903,6 +1932,7 @@ const struct ieee80211_ops rtl_ops = {
 	.sta_add = rtl_op_sta_add,
 	.sta_remove = rtl_op_sta_remove,
 	.flush = rtl_op_flush,
+	.set_tim = rtl_op_set_tim,
 };
 EXPORT_SYMBOL_GPL(rtl_ops);
 
diff --git a/drivers/net/wireless/realtek/rtlwifi/core.h b/drivers/net/wireless/realtek/rtlwifi/core.h
index 7447ff456710..345161b47442 100644
--- a/drivers/net/wireless/realtek/rtlwifi/core.h
+++ b/drivers/net/wireless/realtek/rtlwifi/core.h
@@ -60,5 +60,6 @@ void rtl_bb_delay(struct ieee80211_hw *hw, u32 addr, u32 data);
 bool rtl_cmd_send_packet(struct ieee80211_hw *hw, struct sk_buff *skb);
 bool rtl_btc_status_false(void);
 void rtl_dm_diginit(struct ieee80211_hw *hw, u32 cur_igval);
+void rtl_update_beacon_work_callback(struct work_struct *work);
 
 #endif
diff --git a/drivers/net/wireless/realtek/rtlwifi/pci.c b/drivers/net/wireless/realtek/rtlwifi/pci.c
index 3776495fd9d0..c7365354737e 100644
--- a/drivers/net/wireless/realtek/rtlwifi/pci.c
+++ b/drivers/net/wireless/realtek/rtlwifi/pci.c
@@ -1200,6 +1200,8 @@ static void _rtl_pci_init_struct(struct ieee80211_hw *hw,
 		     _rtl_pci_prepare_bcn_tasklet);
 	INIT_WORK(&rtlpriv->works.lps_change_work,
 		  rtl_lps_change_work_callback);
+	INIT_WORK(&rtlpriv->works.update_beacon_work,
+		  rtl_update_beacon_work_callback);
 }
 
 static int _rtl_pci_init_tx_ring(struct ieee80211_hw *hw,
@@ -1742,6 +1744,7 @@ static void rtl_pci_deinit(struct ieee80211_hw *hw)
 	synchronize_irq(rtlpci->pdev->irq);
 	tasklet_kill(&rtlpriv->works.irq_tasklet);
 	cancel_work_sync(&rtlpriv->works.lps_change_work);
+	cancel_work_sync(&rtlpriv->works.update_beacon_work);
 
 	flush_workqueue(rtlpriv->works.rtl_wq);
 	destroy_workqueue(rtlpriv->works.rtl_wq);
diff --git a/drivers/net/wireless/realtek/rtlwifi/usb.c b/drivers/net/wireless/realtek/rtlwifi/usb.c
index 6c5e242b1bc5..b5e1f9403949 100644
--- a/drivers/net/wireless/realtek/rtlwifi/usb.c
+++ b/drivers/net/wireless/realtek/rtlwifi/usb.c
@@ -805,6 +805,7 @@ static void rtl_usb_stop(struct ieee80211_hw *hw)
 
 	tasklet_kill(&rtlusb->rx_work_tasklet);
 	cancel_work_sync(&rtlpriv->works.lps_change_work);
+	cancel_work_sync(&rtlpriv->works.update_beacon_work);
 
 	flush_workqueue(rtlpriv->works.rtl_wq);
 
@@ -1031,6 +1032,8 @@ int rtl_usb_probe(struct usb_interface *intf,
 		  rtl_fill_h2c_cmd_work_callback);
 	INIT_WORK(&rtlpriv->works.lps_change_work,
 		  rtl_lps_change_work_callback);
+	INIT_WORK(&rtlpriv->works.update_beacon_work,
+		  rtl_update_beacon_work_callback);
 
 	rtlpriv->usb_data_index = 0;
 	init_completion(&rtlpriv->firmware_loading_complete);
diff --git a/drivers/net/wireless/realtek/rtlwifi/wifi.h b/drivers/net/wireless/realtek/rtlwifi/wifi.h
index fdccfd29fd61..8152117c03ee 100644
--- a/drivers/net/wireless/realtek/rtlwifi/wifi.h
+++ b/drivers/net/wireless/realtek/rtlwifi/wifi.h
@@ -2487,6 +2487,7 @@ struct rtl_works {
 
 	struct work_struct lps_change_work;
 	struct work_struct fill_h2c_cmd;
+	struct work_struct update_beacon_work;
 };
 
 struct rtl_debug {
-- 
2.21.0

Re: rtlwifi/rtl8192cu AP mode broken with PS STA

[Larry Finger]

On 4/6/21 9:48 PM, Pkshih wrote:
> On Tue, 2021-04-06 at 11:25 -0500, Larry Finger wrote:
>> On 4/6/21 7:06 AM, Maciej S. Szmigiero wrote:
>>> On 06.04.2021 12:00, Kalle Valo wrote:
>>>> "Maciej S. Szmigiero" <mail@maciej.szmigiero.name> writes:
>>>>
>>>>> On 29.03.2021 00:54, Maciej S. Szmigiero wrote:
>>>>>> Hi,
>>>>>>
>>>>>> It looks like rtlwifi/rtl8192cu AP mode is broken when a STA is using PS,
>>>>>> since the driver does not update its beacon to account for TIM changes,
>>>>>> so a station that is sleeping will never learn that it has packets
>>>>>> buffered at the AP.
>>>>>>
>>>>>> Looking at the code, the rtl8192cu driver implements neither the set_tim()
>>>>>> callback, nor does it explicitly update beacon data periodically, so it
>>>>>> has no way to learn that it had changed.
>>>>>>
>>>>>> This results in the AP mode being virtually unusable with STAs that do
>>>>>> PS and don't allow for it to be disabled (IoT devices, mobile phones,
>>>>>> etc.).
>>>>>>
>>>>>> I think the easiest fix here would be to implement set_tim() for example
>>>>>> the way rt2x00 driver does: queue a work or schedule a tasklet to update
>>>>>> the beacon data on the device.
>>>>>
>>>>> Are there any plans to fix this?
>>>>> The driver is listed as maintained by Ping-Ke.
>>>>
>>>> Yeah, power save is hard and I'm not surprised that there are drivers
>>>> with broken power save mode support. If there's no fix available we
>>>> should stop supporting AP mode in the driver.
>>>>
>>>   
>>> https://wireless.wiki.kernel.org/en/developers/documentation/mac80211/api
>>> clearly documents that "For AP mode, it must (...) react to the set_tim()
>>> callback or fetch each beacon from mac80211".
>>>   
>>> The driver isn't doing either so no wonder the beacon it is sending
>>> isn't getting updated.
>>>   
>>> As I have said above, it seems to me that all that needs to be done here
>>> is to queue a work in a set_tim() callback, then call
>>> send_beacon_frame() from rtlwifi/core.c from this work.
>>>   
>>> But I don't know the exact device semantics, maybe it needs some other
>>> notification that the beacon has changed, too, or even tries to
>>> manage the TIM bitmap by itself.
>>>   
>>> It would be a shame to lose the AP mode for such minor thing, though.
>>>   
>>> I would play with this myself, but unfortunately I don't have time
>>> to work on this right now.
>>>   
>>> That's where my question to Realtek comes: are there plans to actually
>>> fix this?
>>
>> Yes, I am working on this. My only question is "if you are such an expert on the
>> problem, why do you not fix it?"
>>
>> The example in rx200 is not particularly useful, and I have not found any other
>> examples.
>>
> 
> Hi Larry,
> 
> I have a draft patch that forks a work to do send_beacon_frame(), whose
> behavior like Maciej mentioned.
> I did test on RTL8821AE; it works well. But, it seems already work well even
> I don't apply this patch, and I'm still digging why.
> 
> I don't have a rtl8192cu dongle on hand, but I'll try to find one.

Maceij,

Does this patch fix the problem?

Larry

Re: rtlwifi/rtl8192cu AP mode broken with PS STA

[Maciej S. Szmigiero]

On 07.04.2021 06:21, Larry Finger wrote:
> On 4/6/21 9:48 PM, Pkshih wrote:
>> On Tue, 2021-04-06 at 11:25 -0500, Larry Finger wrote:
>>> On 4/6/21 7:06 AM, Maciej S. Szmigiero wrote:
>>>> On 06.04.2021 12:00, Kalle Valo wrote:
>>>>> "Maciej S. Szmigiero" <mail@maciej.szmigiero.name> writes:
>>>>>
>>>>>> On 29.03.2021 00:54, Maciej S. Szmigiero wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> It looks like rtlwifi/rtl8192cu AP mode is broken when a STA is using PS,
>>>>>>> since the driver does not update its beacon to account for TIM changes,
>>>>>>> so a station that is sleeping will never learn that it has packets
>>>>>>> buffered at the AP.
>>>>>>>
>>>>>>> Looking at the code, the rtl8192cu driver implements neither the set_tim()
>>>>>>> callback, nor does it explicitly update beacon data periodically, so it
>>>>>>> has no way to learn that it had changed.
>>>>>>>
>>>>>>> This results in the AP mode being virtually unusable with STAs that do
>>>>>>> PS and don't allow for it to be disabled (IoT devices, mobile phones,
>>>>>>> etc.).
>>>>>>>
>>>>>>> I think the easiest fix here would be to implement set_tim() for example
>>>>>>> the way rt2x00 driver does: queue a work or schedule a tasklet to update
>>>>>>> the beacon data on the device.
>>>>>>
>>>>>> Are there any plans to fix this?
>>>>>> The driver is listed as maintained by Ping-Ke.
>>>>>
>>>>> Yeah, power save is hard and I'm not surprised that there are drivers
>>>>> with broken power save mode support. If there's no fix available we
>>>>> should stop supporting AP mode in the driver.
>>>>>
>>>> https://wireless.wiki.kernel.org/en/developers/documentation/mac80211/api
>>>> clearly documents that "For AP mode, it must (...) react to the set_tim()
>>>> callback or fetch each beacon from mac80211".
>>>> The driver isn't doing either so no wonder the beacon it is sending
>>>> isn't getting updated.
>>>> As I have said above, it seems to me that all that needs to be done here
>>>> is to queue a work in a set_tim() callback, then call
>>>> send_beacon_frame() from rtlwifi/core.c from this work.
>>>> But I don't know the exact device semantics, maybe it needs some other
>>>> notification that the beacon has changed, too, or even tries to
>>>> manage the TIM bitmap by itself.
>>>> It would be a shame to lose the AP mode for such minor thing, though.
>>>> I would play with this myself, but unfortunately I don't have time
>>>> to work on this right now.
>>>> That's where my question to Realtek comes: are there plans to actually
>>>> fix this?
>>>
>>> Yes, I am working on this. My only question is "if you are such an expert on the
>>> problem, why do you not fix it?"
>>>
>>> The example in rx200 is not particularly useful, and I have not found any other
>>> examples.
>>>
>>
>> Hi Larry,
>>
>> I have a draft patch that forks a work to do send_beacon_frame(), whose
>> behavior like Maciej mentioned.

That's great, thanks!

>> I did test on RTL8821AE; it works well. But, it seems already work well even
>> I don't apply this patch, and I'm still digging why.

It looks like PCI rtlwifi hardware uses a tasklet (specifically,
_rtl_pci_prepare_bcn_tasklet() in pci.c) to periodically transfer the
current beacon to the NIC.

This tasklet is scheduled on a RTL_IMR_BCNINT interrupt, which sounds
like a beacon interval interrupt.

>> I don't have a rtl8192cu dongle on hand, but I'll try to find one.
> 
> Maceij,
> 
> Does this patch fix the problem?

The beacon seems to be updating now and STAs no longer get stuck in PS
mode.
Although sometimes (every 2-3 minutes with continuous 1s interval pings)
there is around 5s delay in updating the transmitted beacon - don't know
why, maybe the NIC hardware still has the old version in queue?

I doubt, however that this set_tim() callback should be added for every
rtlwifi device type.

As I have said above, PCI devices seem to already have a mechanism in
place to update their beacon each beacon interval.
Your test that RTL8821AE works without this patch confirms that (at
least for the rtl8821ae driver).

It seems this callback is only necessarily for USB rtlwifi devices.
Which currently means rtl8192cu only.

Thanks,
Maciej

RE: rtlwifi/rtl8192cu AP mode broken with PS STA

[Pkshih]

> -----Original Message-----
> From: Maciej S. Szmigiero [mailto:mail@maciej.szmigiero.name]
> Sent: Thursday, April 08, 2021 4:53 AM
> To: Larry Finger; Pkshih
> Cc: linux-wireless@vger.kernel.org; netdev@vger.kernel.org; linux-kernel@vger.kernel.org;
> johannes@sipsolutions.net; kvalo@codeaurora.org
> Subject: Re: rtlwifi/rtl8192cu AP mode broken with PS STA
> 
> On 07.04.2021 06:21, Larry Finger wrote:
> > On 4/6/21 9:48 PM, Pkshih wrote:
> >> On Tue, 2021-04-06 at 11:25 -0500, Larry Finger wrote:
> >>> On 4/6/21 7:06 AM, Maciej S. Szmigiero wrote:
> >>>> On 06.04.2021 12:00, Kalle Valo wrote:
> >>>>> "Maciej S. Szmigiero" <mail@maciej.szmigiero.name> writes:
> >>>>>
> >>>>>> On 29.03.2021 00:54, Maciej S. Szmigiero wrote:
> >>>>>>> Hi,
> >>>>>>>
> >>>>>>> It looks like rtlwifi/rtl8192cu AP mode is broken when a STA is using PS,
> >>>>>>> since the driver does not update its beacon to account for TIM changes,
> >>>>>>> so a station that is sleeping will never learn that it has packets
> >>>>>>> buffered at the AP.
> >>>>>>>
> >>>>>>> Looking at the code, the rtl8192cu driver implements neither the set_tim()
> >>>>>>> callback, nor does it explicitly update beacon data periodically, so it
> >>>>>>> has no way to learn that it had changed.
> >>>>>>>
> >>>>>>> This results in the AP mode being virtually unusable with STAs that do
> >>>>>>> PS and don't allow for it to be disabled (IoT devices, mobile phones,
> >>>>>>> etc.).
> >>>>>>>
> >>>>>>> I think the easiest fix here would be to implement set_tim() for example
> >>>>>>> the way rt2x00 driver does: queue a work or schedule a tasklet to update
> >>>>>>> the beacon data on the device.
> >>>>>>
> >>>>>> Are there any plans to fix this?
> >>>>>> The driver is listed as maintained by Ping-Ke.
> >>>>>
> >>>>> Yeah, power save is hard and I'm not surprised that there are drivers
> >>>>> with broken power save mode support. If there's no fix available we
> >>>>> should stop supporting AP mode in the driver.
> >>>>>
> >>>> https://wireless.wiki.kernel.org/en/developers/documentation/mac80211/api
> >>>> clearly documents that "For AP mode, it must (...) react to the set_tim()
> >>>> callback or fetch each beacon from mac80211".
> >>>> The driver isn't doing either so no wonder the beacon it is sending
> >>>> isn't getting updated.
> >>>> As I have said above, it seems to me that all that needs to be done here
> >>>> is to queue a work in a set_tim() callback, then call
> >>>> send_beacon_frame() from rtlwifi/core.c from this work.
> >>>> But I don't know the exact device semantics, maybe it needs some other
> >>>> notification that the beacon has changed, too, or even tries to
> >>>> manage the TIM bitmap by itself.
> >>>> It would be a shame to lose the AP mode for such minor thing, though.
> >>>> I would play with this myself, but unfortunately I don't have time
> >>>> to work on this right now.
> >>>> That's where my question to Realtek comes: are there plans to actually
> >>>> fix this?
> >>>
> >>> Yes, I am working on this. My only question is "if you are such an expert on the
> >>> problem, why do you not fix it?"
> >>>
> >>> The example in rx200 is not particularly useful, and I have not found any other
> >>> examples.
> >>>
> >>
> >> Hi Larry,
> >>
> >> I have a draft patch that forks a work to do send_beacon_frame(), whose
> >> behavior like Maciej mentioned.
> 
> That's great, thanks!
> 
> >> I did test on RTL8821AE; it works well. But, it seems already work well even
> >> I don't apply this patch, and I'm still digging why.
> 
> It looks like PCI rtlwifi hardware uses a tasklet (specifically,
> _rtl_pci_prepare_bcn_tasklet() in pci.c) to periodically transfer the
> current beacon to the NIC.

Got it.

> 
> This tasklet is scheduled on a RTL_IMR_BCNINT interrupt, which sounds
> like a beacon interval interrupt.
> 

Yes, PCI series update every beacon, so TIM and DTIM count maintained by
mac80211 work properly.

> >> I don't have a rtl8192cu dongle on hand, but I'll try to find one.
> >
> > Maceij,
> >
> > Does this patch fix the problem?
> 
> The beacon seems to be updating now and STAs no longer get stuck in PS
> mode.
> Although sometimes (every 2-3 minutes with continuous 1s interval pings)
> there is around 5s delay in updating the transmitted beacon - don't know
> why, maybe the NIC hardware still has the old version in queue?

Since USB device doesn't update every beacon, dtim_count isn't updated neither.
It leads STA doesn't awake properly. Please try to fix dtim_period=1 in
hostapd.conf, which tells STA awakes every beacon interval.

> 
> I doubt, however that this set_tim() callback should be added for every
> rtlwifi device type.
> 
> As I have said above, PCI devices seem to already have a mechanism in
> place to update their beacon each beacon interval.
> Your test that RTL8821AE works without this patch confirms that (at
> least for the rtl8821ae driver).
> 
> It seems this callback is only necessarily for USB rtlwifi devices.
> Which currently means rtl8192cu only.
> 

I agree with you.

--
Ping-Ke

Re: rtlwifi/rtl8192cu AP mode broken with PS STA

[Maciej S. Szmigiero]

On 08.04.2021 06:42, Pkshih wrote:
>> -----Original Message-----
>> From: Maciej S. Szmigiero [mailto:mail@maciej.szmigiero.name]
>> Sent: Thursday, April 08, 2021 4:53 AM
>> To: Larry Finger; Pkshih
>> Cc: linux-wireless@vger.kernel.org; netdev@vger.kernel.org; linux-kernel@vger.kernel.org;
>> johannes@sipsolutions.net; kvalo@codeaurora.org
>> Subject: Re: rtlwifi/rtl8192cu AP mode broken with PS STA
>>
(...)
>>> Maceij,
>>>
>>> Does this patch fix the problem?
>>
>> The beacon seems to be updating now and STAs no longer get stuck in PS
>> mode.
>> Although sometimes (every 2-3 minutes with continuous 1s interval pings)
>> there is around 5s delay in updating the transmitted beacon - don't know
>> why, maybe the NIC hardware still has the old version in queue?
> 
> Since USB device doesn't update every beacon, dtim_count isn't updated neither.
> It leads STA doesn't awake properly. Please try to fix dtim_period=1 in
> hostapd.conf, which tells STA awakes every beacon interval.

The situation is the same with dtim_period=1.

When I look at a packet trace (captured from a different NIC running in
monitor mode) it's obvious that the pinged STA wakes up almost
immediately once it sees its DTIM bit set in a beacon.

But many beacons pass (the network has beacon interval of 0.1s) between
where a ping request (ICMP echo request) is buffered on the AP and where
the transmitted beacon actually starts to have DTIM bit set.

I am observing delays up to 9 seconds, which means a delay up to 90
beacons between when DTIM bit should be set and when it actually gets
set.

As I said above, this happens only sometimes (every 2-3 minutes with
continuous 1s interval pings) but there is definitely something wrong
here.

My wild guess would be that if the NIC is prevented from sending a beacon
due to, for example, its radio channel being busy it keeps that beacon
in queue for the next transmission attempt and only then sends it and
removes from that queue.
Even thought there might be newer beacon data already available for
transmission.

And then these "unsent" beacons pile up in queue and the delays I am
observing are simply old queued beacons (that don't have the DTIM bit
set yet) being transmitted.

But that's just my hypothesis - I don't know how rtl8192cu hardware
actually works.

> --
> Ping-Ke

Thanks,
Maciej

Re: rtlwifi/rtl8192cu AP mode broken with PS STA

[Maciej S. Szmigiero]

On 08.04.2021 21:04, Maciej S. Szmigiero wrote:
> On 08.04.2021 06:42, Pkshih wrote:
>>> -----Original Message-----
>>> From: Maciej S. Szmigiero [mailto:mail@maciej.szmigiero.name]
>>> Sent: Thursday, April 08, 2021 4:53 AM
>>> To: Larry Finger; Pkshih
>>> Cc: linux-wireless@vger.kernel.org; netdev@vger.kernel.org; linux-kernel@vger.kernel.org;
>>> johannes@sipsolutions.net; kvalo@codeaurora.org
>>> Subject: Re: rtlwifi/rtl8192cu AP mode broken with PS STA
>>>
> (...)
>>>> Maceij,
>>>>
>>>> Does this patch fix the problem?
>>>
>>> The beacon seems to be updating now and STAs no longer get stuck in PS
>>> mode.
>>> Although sometimes (every 2-3 minutes with continuous 1s interval pings)
>>> there is around 5s delay in updating the transmitted beacon - don't know
>>> why, maybe the NIC hardware still has the old version in queue?
>>
>> Since USB device doesn't update every beacon, dtim_count isn't updated neither.
>> It leads STA doesn't awake properly. Please try to fix dtim_period=1 in
>> hostapd.conf, which tells STA awakes every beacon interval.
> 
> The situation is the same with dtim_period=1.
> 
(...)

Ping-Ke,
are you going to submit your set_tim() patch so at least the AP mode is
usable with PS STAs or are you waiting for a solution to the delayed
beacon update issue?

Thanks,
Maciej

RE: rtlwifi/rtl8192cu AP mode broken with PS STA

[Pkshih]

> -----Original Message-----
> From: Maciej S. Szmigiero [mailto:mail@maciej.szmigiero.name]
> Sent: Sunday, April 18, 2021 2:08 AM
> To: Pkshih
> Cc: linux-wireless@vger.kernel.org; netdev@vger.kernel.org; linux-kernel@vger.kernel.org;
> johannes@sipsolutions.net; kvalo@codeaurora.org; Larry Finger
> Subject: Re: rtlwifi/rtl8192cu AP mode broken with PS STA
> 
> On 08.04.2021 21:04, Maciej S. Szmigiero wrote:
> > On 08.04.2021 06:42, Pkshih wrote:
> >>> -----Original Message-----
> >>> From: Maciej S. Szmigiero [mailto:mail@maciej.szmigiero.name]
> >>> Sent: Thursday, April 08, 2021 4:53 AM
> >>> To: Larry Finger; Pkshih
> >>> Cc: linux-wireless@vger.kernel.org; netdev@vger.kernel.org; linux-kernel@vger.kernel.org;
> >>> johannes@sipsolutions.net; kvalo@codeaurora.org
> >>> Subject: Re: rtlwifi/rtl8192cu AP mode broken with PS STA
> >>>
> > (...)
> >>>> Maceij,
> >>>>
> >>>> Does this patch fix the problem?
> >>>
> >>> The beacon seems to be updating now and STAs no longer get stuck in PS
> >>> mode.
> >>> Although sometimes (every 2-3 minutes with continuous 1s interval pings)
> >>> there is around 5s delay in updating the transmitted beacon - don't know
> >>> why, maybe the NIC hardware still has the old version in queue?
> >>
> >> Since USB device doesn't update every beacon, dtim_count isn't updated neither.
> >> It leads STA doesn't awake properly. Please try to fix dtim_period=1 in
> >> hostapd.conf, which tells STA awakes every beacon interval.
> >
> > The situation is the same with dtim_period=1.
> >
> (...)
> 
> Ping-Ke,
> are you going to submit your set_tim() patch so at least the AP mode is
> usable with PS STAs or are you waiting for a solution to the delayed
> beacon update issue?
> 

I'm still trying to get a 8192cu, and then I can reproduce the symptom you
met. However, I'm busy now; maybe I have free time two weeks later.

Do you think I submit the set_tim() patch with your Reported-by and Tested-by first?

Thanks 
Ping-Ke

Re: rtlwifi/rtl8192cu AP mode broken with PS STA

[Larry Finger]

On 4/18/21 7:32 PM, Pkshih wrote:
> 
>> -----Original Message-----
>> From: Maciej S. Szmigiero [mailto:mail@maciej.szmigiero.name]
>> Sent: Sunday, April 18, 2021 2:08 AM
>> To: Pkshih
>> Cc: linux-wireless@vger.kernel.org; netdev@vger.kernel.org; linux-kernel@vger.kernel.org;
>> johannes@sipsolutions.net; kvalo@codeaurora.org; Larry Finger
>> Subject: Re: rtlwifi/rtl8192cu AP mode broken with PS STA
>>
>> On 08.04.2021 21:04, Maciej S. Szmigiero wrote:
>>> On 08.04.2021 06:42, Pkshih wrote:
>>>>> -----Original Message-----
>>>>> From: Maciej S. Szmigiero [mailto:mail@maciej.szmigiero.name]
>>>>> Sent: Thursday, April 08, 2021 4:53 AM
>>>>> To: Larry Finger; Pkshih
>>>>> Cc: linux-wireless@vger.kernel.org; netdev@vger.kernel.org; linux-kernel@vger.kernel.org;
>>>>> johannes@sipsolutions.net; kvalo@codeaurora.org
>>>>> Subject: Re: rtlwifi/rtl8192cu AP mode broken with PS STA
>>>>>
>>> (...)
>>>>>> Maceij,
>>>>>>
>>>>>> Does this patch fix the problem?
>>>>>
>>>>> The beacon seems to be updating now and STAs no longer get stuck in PS
>>>>> mode.
>>>>> Although sometimes (every 2-3 minutes with continuous 1s interval pings)
>>>>> there is around 5s delay in updating the transmitted beacon - don't know
>>>>> why, maybe the NIC hardware still has the old version in queue?
>>>>
>>>> Since USB device doesn't update every beacon, dtim_count isn't updated neither.
>>>> It leads STA doesn't awake properly. Please try to fix dtim_period=1 in
>>>> hostapd.conf, which tells STA awakes every beacon interval.
>>>
>>> The situation is the same with dtim_period=1.
>>>
>> (...)
>>
>> Ping-Ke,
>> are you going to submit your set_tim() patch so at least the AP mode is
>> usable with PS STAs or are you waiting for a solution to the delayed
>> beacon update issue?
>>
> 
> I'm still trying to get a 8192cu, and then I can reproduce the symptom you
> met. However, I'm busy now; maybe I have free time two weeks later.
> 
> Do you think I submit the set_tim() patch with your Reported-by and Tested-by first?

PK,

I would say yes. Get the fix in as soon as possible.

Larry

RE: rtlwifi/rtl8192cu AP mode broken with PS STA

[Pkshih]

> -----Original Message-----
> From: Larry Finger [mailto:larry.finger@gmail.com] On Behalf Of Larry Finger
> Sent: Monday, April 19, 2021 9:23 AM
> To: Pkshih; Maciej S. Szmigiero
> Cc: linux-wireless@vger.kernel.org; netdev@vger.kernel.org; linux-kernel@vger.kernel.org;
> johannes@sipsolutions.net; kvalo@codeaurora.org
> Subject: Re: rtlwifi/rtl8192cu AP mode broken with PS STA
> 
> On 4/18/21 7:32 PM, Pkshih wrote:
> >
> >> -----Original Message-----
> >> From: Maciej S. Szmigiero [mailto:mail@maciej.szmigiero.name]
> >> Sent: Sunday, April 18, 2021 2:08 AM
> >> To: Pkshih
> >> Cc: linux-wireless@vger.kernel.org; netdev@vger.kernel.org; linux-kernel@vger.kernel.org;
> >> johannes@sipsolutions.net; kvalo@codeaurora.org; Larry Finger
> >> Subject: Re: rtlwifi/rtl8192cu AP mode broken with PS STA
> >>
> >> On 08.04.2021 21:04, Maciej S. Szmigiero wrote:
> >>> On 08.04.2021 06:42, Pkshih wrote:
> >>>>> -----Original Message-----
> >>>>> From: Maciej S. Szmigiero [mailto:mail@maciej.szmigiero.name]
> >>>>> Sent: Thursday, April 08, 2021 4:53 AM
> >>>>> To: Larry Finger; Pkshih
> >>>>> Cc: linux-wireless@vger.kernel.org; netdev@vger.kernel.org; linux-kernel@vger.kernel.org;
> >>>>> johannes@sipsolutions.net; kvalo@codeaurora.org
> >>>>> Subject: Re: rtlwifi/rtl8192cu AP mode broken with PS STA
> >>>>>
> >>> (...)
> >>>>>> Maceij,
> >>>>>>
> >>>>>> Does this patch fix the problem?
> >>>>>
> >>>>> The beacon seems to be updating now and STAs no longer get stuck in PS
> >>>>> mode.
> >>>>> Although sometimes (every 2-3 minutes with continuous 1s interval pings)
> >>>>> there is around 5s delay in updating the transmitted beacon - don't know
> >>>>> why, maybe the NIC hardware still has the old version in queue?
> >>>>
> >>>> Since USB device doesn't update every beacon, dtim_count isn't updated neither.
> >>>> It leads STA doesn't awake properly. Please try to fix dtim_period=1 in
> >>>> hostapd.conf, which tells STA awakes every beacon interval.
> >>>
> >>> The situation is the same with dtim_period=1.
> >>>
> >> (...)
> >>
> >> Ping-Ke,
> >> are you going to submit your set_tim() patch so at least the AP mode is
> >> usable with PS STAs or are you waiting for a solution to the delayed
> >> beacon update issue?
> >>
> >
> > I'm still trying to get a 8192cu, and then I can reproduce the symptom you
> > met. However, I'm busy now; maybe I have free time two weeks later.
> >
> > Do you think I submit the set_tim() patch with your Reported-by and Tested-by first?
> 
> PK,
> 
> I would say yes. Get the fix in as soon as possible.
> 

I have sent a patch that only 8192cu, which is the only one USB device supported by rtlwifi,
schedules a work to update beacon content to wifi card.

https://lore.kernel.org/linux-wireless/20210419065956.6085-1-pkshih@realtek.com/T/#u

--
Ping-Ke

Re: rtlwifi/rtl8192cu AP mode broken with PS STA

[Maciej S. Szmigiero]

On 19.04.2021 09:04, Pkshih wrote:
> 
>> -----Original Message-----
>> From: Larry Finger [mailto:larry.finger@gmail.com] On Behalf Of Larry Finger
>> Sent: Monday, April 19, 2021 9:23 AM
>> To: Pkshih; Maciej S. Szmigiero
>> Cc: linux-wireless@vger.kernel.org; netdev@vger.kernel.org; linux-kernel@vger.kernel.org;
>> johannes@sipsolutions.net; kvalo@codeaurora.org
>> Subject: Re: rtlwifi/rtl8192cu AP mode broken with PS STA
>>
>> On 4/18/21 7:32 PM, Pkshih wrote:
>>>
>>>> -----Original Message-----
>>>> From: Maciej S. Szmigiero [mailto:mail@maciej.szmigiero.name]
>>>> Sent: Sunday, April 18, 2021 2:08 AM
>>>> To: Pkshih
>>>> Cc: linux-wireless@vger.kernel.org; netdev@vger.kernel.org; linux-kernel@vger.kernel.org;
>>>> johannes@sipsolutions.net; kvalo@codeaurora.org; Larry Finger
>>>> Subject: Re: rtlwifi/rtl8192cu AP mode broken with PS STA
>>>>
>>>> On 08.04.2021 21:04, Maciej S. Szmigiero wrote:
>>>>> On 08.04.2021 06:42, Pkshih wrote:
>>>>>>> -----Original Message-----
>>>>>>> From: Maciej S. Szmigiero [mailto:mail@maciej.szmigiero.name]
>>>>>>> Sent: Thursday, April 08, 2021 4:53 AM
>>>>>>> To: Larry Finger; Pkshih
>>>>>>> Cc: linux-wireless@vger.kernel.org; netdev@vger.kernel.org; linux-kernel@vger.kernel.org;
>>>>>>> johannes@sipsolutions.net; kvalo@codeaurora.org
>>>>>>> Subject: Re: rtlwifi/rtl8192cu AP mode broken with PS STA
>>>>>>>
>>>>> (...)
>>>>>>>> Maceij,
>>>>>>>>
>>>>>>>> Does this patch fix the problem?
>>>>>>>
>>>>>>> The beacon seems to be updating now and STAs no longer get stuck in PS
>>>>>>> mode.
>>>>>>> Although sometimes (every 2-3 minutes with continuous 1s interval pings)
>>>>>>> there is around 5s delay in updating the transmitted beacon - don't know
>>>>>>> why, maybe the NIC hardware still has the old version in queue?
>>>>>>
>>>>>> Since USB device doesn't update every beacon, dtim_count isn't updated neither.
>>>>>> It leads STA doesn't awake properly. Please try to fix dtim_period=1 in
>>>>>> hostapd.conf, which tells STA awakes every beacon interval.
>>>>>
>>>>> The situation is the same with dtim_period=1.
>>>>>
>>>> (...)
>>>>
>>>> Ping-Ke,
>>>> are you going to submit your set_tim() patch so at least the AP mode is
>>>> usable with PS STAs or are you waiting for a solution to the delayed
>>>> beacon update issue?
>>>>
>>>
>>> I'm still trying to get a 8192cu, and then I can reproduce the symptom you
>>> met. However, I'm busy now; maybe I have free time two weeks later.
>>>
>>> Do you think I submit the set_tim() patch with your Reported-by and Tested-by first?
>>
>> PK,
>>
>> I would say yes. Get the fix in as soon as possible.
>>
> 
> I have sent a patch that only 8192cu, which is the only one USB device supported by rtlwifi,
> schedules a work to update beacon content to wifi card.
> 
> https://lore.kernel.org/linux-wireless/20210419065956.6085-1-pkshih@realtek.com/T/#u

Thanks, I have tested the patch and it seems to work as good as the previous one.
It definitely improves things.

However, it would be great to eventually fix the update delay issue, too.
It looks to me like possibly just a missing beacon queue flush.

> --
> Ping-Ke
> 

Maciej