On 4/6/21 7:06 AM, Maciej S. Szmigiero wrote:
> On 06.04.2021 12:00, Kalle Valo wrote:
>> "Maciej S. Szmigiero" <[email protected]> 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
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" <[email protected]> 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
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" <[email protected]> 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
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" <[email protected]> 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
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" <[email protected]> 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
> -----Original Message-----
> From: Maciej S. Szmigiero [mailto:[email protected]]
> Sent: Thursday, April 08, 2021 4:53 AM
> To: Larry Finger; Pkshih
> Cc: [email protected]; [email protected]; [email protected];
> [email protected]; [email protected]
> 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" <[email protected]> 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
On 08.04.2021 06:42, Pkshih wrote:
>> -----Original Message-----
>> From: Maciej S. Szmigiero [mailto:[email protected]]
>> Sent: Thursday, April 08, 2021 4:53 AM
>> To: Larry Finger; Pkshih
>> Cc: [email protected]; [email protected]; [email protected];
>> [email protected]; [email protected]
>> 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
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:[email protected]]
>>> Sent: Thursday, April 08, 2021 4:53 AM
>>> To: Larry Finger; Pkshih
>>> Cc: [email protected]; [email protected]; [email protected];
>>> [email protected]; [email protected]
>>> 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
> -----Original Message-----
> From: Maciej S. Szmigiero [mailto:[email protected]]
> Sent: Sunday, April 18, 2021 2:08 AM
> To: Pkshih
> Cc: [email protected]; [email protected]; [email protected];
> [email protected]; [email protected]; 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:[email protected]]
> >>> Sent: Thursday, April 08, 2021 4:53 AM
> >>> To: Larry Finger; Pkshih
> >>> Cc: [email protected]; [email protected]; [email protected];
> >>> [email protected]; [email protected]
> >>> 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
On 4/18/21 7:32 PM, Pkshih wrote:
>
>> -----Original Message-----
>> From: Maciej S. Szmigiero [mailto:[email protected]]
>> Sent: Sunday, April 18, 2021 2:08 AM
>> To: Pkshih
>> Cc: [email protected]; [email protected]; [email protected];
>> [email protected]; [email protected]; 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:[email protected]]
>>>>> Sent: Thursday, April 08, 2021 4:53 AM
>>>>> To: Larry Finger; Pkshih
>>>>> Cc: [email protected]; [email protected]; [email protected];
>>>>> [email protected]; [email protected]
>>>>> 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
> -----Original Message-----
> From: Larry Finger [mailto:[email protected]] On Behalf Of Larry Finger
> Sent: Monday, April 19, 2021 9:23 AM
> To: Pkshih; Maciej S. Szmigiero
> Cc: [email protected]; [email protected]; [email protected];
> [email protected]; [email protected]
> 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:[email protected]]
> >> Sent: Sunday, April 18, 2021 2:08 AM
> >> To: Pkshih
> >> Cc: [email protected]; [email protected]; [email protected];
> >> [email protected]; [email protected]; 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:[email protected]]
> >>>>> Sent: Thursday, April 08, 2021 4:53 AM
> >>>>> To: Larry Finger; Pkshih
> >>>>> Cc: [email protected]; [email protected]; [email protected];
> >>>>> [email protected]; [email protected]
> >>>>> 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/[email protected]/T/#u
--
Ping-Ke