Re: rtlwifi/rtl8192cu AP mode broken with PS STA
On 19.04.2021 09:04, Pkshih wrote: -Original Message- From: Larry Finger [mailto:larry.fin...@gmail.com] On Behalf Of Larry Finger Sent: Monday, April 19, 2021 9:23 AM To: Pkshih; Maciej S. Szmigiero Cc: linux-wirel...@vger.kernel.org; net...@vger.kernel.org; linux-kernel@vger.kernel.org; johan...@sipsolutions.net; kv...@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:m...@maciej.szmigiero.name] Sent: Sunday, April 18, 2021 2:08 AM To: Pkshih Cc: linux-wirel...@vger.kernel.org; net...@vger.kernel.org; linux-kernel@vger.kernel.org; johan...@sipsolutions.net; kv...@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:m...@maciej.szmigiero.name] Sent: Thursday, April 08, 2021 4:53 AM To: Larry Finger; Pkshih Cc: linux-wirel...@vger.kernel.org; net...@vger.kernel.org; linux-kernel@vger.kernel.org; johan...@sipsolutions.net; kv...@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-pks...@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
RE: rtlwifi/rtl8192cu AP mode broken with PS STA
> -Original Message- > From: Larry Finger [mailto:larry.fin...@gmail.com] On Behalf Of Larry Finger > Sent: Monday, April 19, 2021 9:23 AM > To: Pkshih; Maciej S. Szmigiero > Cc: linux-wirel...@vger.kernel.org; net...@vger.kernel.org; > linux-kernel@vger.kernel.org; > johan...@sipsolutions.net; kv...@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:m...@maciej.szmigiero.name] > >> Sent: Sunday, April 18, 2021 2:08 AM > >> To: Pkshih > >> Cc: linux-wirel...@vger.kernel.org; net...@vger.kernel.org; > >> linux-kernel@vger.kernel.org; > >> johan...@sipsolutions.net; kv...@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:m...@maciej.szmigiero.name] > >>>>> Sent: Thursday, April 08, 2021 4:53 AM > >>>>> To: Larry Finger; Pkshih > >>>>> Cc: linux-wirel...@vger.kernel.org; net...@vger.kernel.org; > >>>>> linux-kernel@vger.kernel.org; > >>>>> johan...@sipsolutions.net; kv...@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-pks...@realtek.com/T/#u -- Ping-Ke
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:m...@maciej.szmigiero.name] Sent: Sunday, April 18, 2021 2:08 AM To: Pkshih Cc: linux-wirel...@vger.kernel.org; net...@vger.kernel.org; linux-kernel@vger.kernel.org; johan...@sipsolutions.net; kv...@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:m...@maciej.szmigiero.name] Sent: Thursday, April 08, 2021 4:53 AM To: Larry Finger; Pkshih Cc: linux-wirel...@vger.kernel.org; net...@vger.kernel.org; linux-kernel@vger.kernel.org; johan...@sipsolutions.net; kv...@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
> -Original Message- > From: Maciej S. Szmigiero [mailto:m...@maciej.szmigiero.name] > Sent: Sunday, April 18, 2021 2:08 AM > To: Pkshih > Cc: linux-wirel...@vger.kernel.org; net...@vger.kernel.org; > linux-kernel@vger.kernel.org; > johan...@sipsolutions.net; kv...@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:m...@maciej.szmigiero.name] > >>> Sent: Thursday, April 08, 2021 4:53 AM > >>> To: Larry Finger; Pkshih > >>> Cc: linux-wirel...@vger.kernel.org; net...@vger.kernel.org; > >>> linux-kernel@vger.kernel.org; > >>> johan...@sipsolutions.net; kv...@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
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:m...@maciej.szmigiero.name] Sent: Thursday, April 08, 2021 4:53 AM To: Larry Finger; Pkshih Cc: linux-wirel...@vger.kernel.org; net...@vger.kernel.org; linux-kernel@vger.kernel.org; johan...@sipsolutions.net; kv...@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
On 08.04.2021 06:42, Pkshih wrote: -Original Message- From: Maciej S. Szmigiero [mailto:m...@maciej.szmigiero.name] Sent: Thursday, April 08, 2021 4:53 AM To: Larry Finger; Pkshih Cc: linux-wirel...@vger.kernel.org; net...@vger.kernel.org; linux-kernel@vger.kernel.org; johan...@sipsolutions.net; kv...@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
> -Original Message- > From: Maciej S. Szmigiero [mailto:m...@maciej.szmigiero.name] > Sent: Thursday, April 08, 2021 4:53 AM > To: Larry Finger; Pkshih > Cc: linux-wirel...@vger.kernel.org; net...@vger.kernel.org; > linux-kernel@vger.kernel.org; > johan...@sipsolutions.net; kv...@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" 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 lo
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" 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
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" 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
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" 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 From 44be80232aa49737c035ee4656d20a22f573d33e Mon Sep 17 00:00:00 2001 From: Ping-Ke Shih 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 --- 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:
Re: rtlwifi/rtl8192cu AP mode broken with PS STA
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" 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
On 4/6/21 7:06 AM, Maciej S. Szmigiero wrote: On 06.04.2021 12:00, Kalle Valo wrote: "Maciej S. Szmigiero" 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
On 06.04.2021 12:00, Kalle Valo wrote: "Maciej S. Szmigiero" 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
"Maciej S. Szmigiero" 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
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
rtlwifi/rtl8192cu AP mode broken with PS STA
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