Hello!
We use RTL8822CS modules in our devices and we switched to rtw88 from an
external driver by Realtek. Suddenly we discovered that the AP mode
(hotspot) stopped working. The hotspot is set up, but it does not
authorize client connections.
In attacments log and config files.
client - notebook with iwlwifi 0000:00:14.3: Detected Killer(R) Wi-Fi 6E
AX1675i 160MHz Wireless Network Adapter (211NGW), REV=0x370
hotspot:
JetHub D1+ (arm64, debian 12) with RTL8822CS (SDIO module),
NetworkManager disabled for wifi.
# uname -a
Linux ha.test 6.6.6-edge-meson64 #1 SMP PREEMPT Mon Dec 11 09:40:17 UTC
2023 aarch64 GNU/Linux
--
Viacheslav Bocharov
> -----Original Message-----
> From: Viacheslav <[email protected]>
> Sent: Wednesday, January 10, 2024 3:07 PM
> To: [email protected]
> Cc: Ping-Ke Shih <[email protected]>; Jernej Škrabec <[email protected]>; Martin Blumenstingl
> <[email protected]>
> Subject: rtw88: rtl8822cs AP mode not working
>
> Hello!
>
> We use RTL8822CS modules in our devices and we switched to rtw88 from an
> external driver by Realtek. Suddenly we discovered that the AP mode
> (hotspot) stopped working. The hotspot is set up, but it does not
> authorize client connections.
>
> In attacments log and config files.
>
> client - notebook with iwlwifi 0000:00:14.3: Detected Killer(R) Wi-Fi 6E
> AX1675i 160MHz Wireless Network Adapter (211NGW), REV=0x370
>
It is probably because RTL8822CS doesn't issue beacon properly. Trying to
capture air packets will be helpful to clarify the problem.
Jan 10 09:45:57 adeepn wpa_supplicant[3326]: wlo1: Associated with 5c:c5:63:2a:70:7a
Jan 10 09:45:58 adeepn wpa_supplicant[3326]: wlo1: CTRL-EVENT-BEACON-LOSS
Jan 10 09:45:58 adeepn wpa_supplicant[3326]: wlo1: CTRL-EVENT-BEACON-LOSS
Jan 10 09:45:58 adeepn wpa_supplicant[3326]: wlo1: CTRL-EVENT-BEACON-LOSS
Jan 10 09:45:58 adeepn wpa_supplicant[3326]: wlo1: CTRL-EVENT-BEACON-LOSS
Jan 10 09:45:59 adeepn wpa_supplicant[3326]: wlo1: CTRL-EVENT-BEACON-LOSS
Jan 10 09:45:59 adeepn wpa_supplicant[3326]: wlo1: CTRL-EVENT-DISCONNECTED bssid=5c:c5:63:2a:70:7a reason=4 locally_generated=1
Hi!
10/01/2024 12.15, Ping-Ke Shih wrote:
>
>
>> -----Original Message-----
>> From: Viacheslav <[email protected]>
>> Sent: Wednesday, January 10, 2024 3:07 PM
>> To: [email protected]
>> Cc: Ping-Ke Shih <[email protected]>; Jernej Škrabec <[email protected]>; Martin Blumenstingl
>> <[email protected]>
>> Subject: rtw88: rtl8822cs AP mode not working
>>
>> Hello!
>>
>> We use RTL8822CS modules in our devices and we switched to rtw88 from an
>> external driver by Realtek. Suddenly we discovered that the AP mode
>> (hotspot) stopped working. The hotspot is set up, but it does not
>> authorize client connections.
>>
>> In attacments log and config files.
>>
>> client - notebook with iwlwifi 0000:00:14.3: Detected Killer(R) Wi-Fi 6E
>> AX1675i 160MHz Wireless Network Adapter (211NGW), REV=0x370
>>
>
> It is probably because RTL8822CS doesn't issue beacon properly. Trying to
> capture air packets will be helpful to clarify the problem.
airdump-ng result in attachment.
I don't see any captured beacon packets.
BSSID 5C:C5:63:2A:70:7A
PWR -126
RXQ 100
Beacons 0
#Data 0
#/s 0
CH 6
MB 54
ENC WPA2
CIPHER CCMP
AUTH PSK
ESSID Hostspot
BSSID 5C:C5:63:2A:70:7A
STATION 5C:C5:63:2A:6F:45
PWR -38
Rate 0-1
Lost 0
Frames 7
>
> Jan 10 09:45:57 adeepn wpa_supplicant[3326]: wlo1: Associated with 5c:c5:63:2a:70:7a
> Jan 10 09:45:58 adeepn wpa_supplicant[3326]: wlo1: CTRL-EVENT-BEACON-LOSS
> Jan 10 09:45:58 adeepn wpa_supplicant[3326]: wlo1: CTRL-EVENT-BEACON-LOSS
> Jan 10 09:45:58 adeepn wpa_supplicant[3326]: wlo1: CTRL-EVENT-BEACON-LOSS
> Jan 10 09:45:58 adeepn wpa_supplicant[3326]: wlo1: CTRL-EVENT-BEACON-LOSS
> Jan 10 09:45:59 adeepn wpa_supplicant[3326]: wlo1: CTRL-EVENT-BEACON-LOSS
> Jan 10 09:45:59 adeepn wpa_supplicant[3326]: wlo1: CTRL-EVENT-DISCONNECTED bssid=5c:c5:63:2a:70:7a reason=4 locally_generated=1
>
>
> -----Original Message-----
> From: Viacheslav <[email protected]>
> Sent: Wednesday, January 10, 2024 7:05 PM
> To: Ping-Ke Shih <[email protected]>; [email protected]
> Cc: Jernej Škrabec <[email protected]>; Martin Blumenstingl <[email protected]>
> Subject: Re: rtw88: rtl8822cs AP mode not working
>
> Hi!
>
> 10/01/2024 12.15, Ping-Ke Shih wrote:
> >
> >
> >> -----Original Message-----
> >> From: Viacheslav <[email protected]>
> >> Sent: Wednesday, January 10, 2024 3:07 PM
> >> To: [email protected]
> >> Cc: Ping-Ke Shih <[email protected]>; Jernej Škrabec <[email protected]>; Martin Blumenstingl
> >> <[email protected]>
> >> Subject: rtw88: rtl8822cs AP mode not working
> >>
> >> Hello!
> >>
> >> We use RTL8822CS modules in our devices and we switched to rtw88 from an
> >> external driver by Realtek. Suddenly we discovered that the AP mode
> >> (hotspot) stopped working. The hotspot is set up, but it does not
> >> authorize client connections.
> >>
> >> In attacments log and config files.
> >>
> >> client - notebook with iwlwifi 0000:00:14.3: Detected Killer(R) Wi-Fi 6E
> >> AX1675i 160MHz Wireless Network Adapter (211NGW), REV=0x370
> >>
> >
> > It is probably because RTL8822CS doesn't issue beacon properly. Trying to
> > capture air packets will be helpful to clarify the problem.
>
> airdump-ng result in attachment.
> I don't see any captured beacon packets.
So, that is the problem. Did you see any weird messages in kernel log when
you were starting hostapd?
11/01/2024 03.42, Ping-Ke Shih пишет:
>
>
>> -----Original Message-----
>> From: Viacheslav <[email protected]>
>> Sent: Wednesday, January 10, 2024 7:05 PM
>> To: Ping-Ke Shih <[email protected]>; [email protected]
>> Cc: Jernej Škrabec <[email protected]>; Martin Blumenstingl <[email protected]>
>> Subject: Re: rtw88: rtl8822cs AP mode not working
>>
>> Hi!
>>
>> 10/01/2024 12.15, Ping-Ke Shih wrote:
>>>
>>>
>>>> -----Original Message-----
>>>> From: Viacheslav <[email protected]>
>>>> Sent: Wednesday, January 10, 2024 3:07 PM
>>>> To: [email protected]
>>>> Cc: Ping-Ke Shih <[email protected]>; Jernej Škrabec <[email protected]>; Martin Blumenstingl
>>>> <[email protected]>
>>>> Subject: rtw88: rtl8822cs AP mode not working
>>>>
>>>> Hello!
>>>>
>>>> We use RTL8822CS modules in our devices and we switched to rtw88 from an
>>>> external driver by Realtek. Suddenly we discovered that the AP mode
>>>> (hotspot) stopped working. The hotspot is set up, but it does not
>>>> authorize client connections.
>>>>
>>>> In attacments log and config files.
>>>>
>>>> client - notebook with iwlwifi 0000:00:14.3: Detected Killer(R) Wi-Fi 6E
>>>> AX1675i 160MHz Wireless Network Adapter (211NGW), REV=0x370
>>>>
>>>
>>> It is probably because RTL8822CS doesn't issue beacon properly. Trying to
>>> capture air packets will be helpful to clarify the problem.
>>
>> airdump-ng result in attachment.
>> I don't see any captured beacon packets.
>
> So, that is the problem. Did you see any weird messages in kernel log when
> you were starting hostapd?
>
>
dmesg/journalctl is clean. No messages related to wifi.
dmesg before start hostapd:
[ 1.045856] mmc0: new high speed SDIO card at address 0001
[ 6.003887] Loaded X.509 cert 'sforshee: 00b28ddf47aef9cea7'
[ 6.146318] rtw_8822cs mmc0:0001:1: WOW Firmware version 9.9.4, H2C
version 15
[ 6.147548] rtw_8822cs mmc0:0001:1: Firmware version 9.9.15, H2C
version 15
In attach the log of hostapd with -dd options.
--
Viacheslav Bocharov
Hi Martin,
> -----Original Message-----
> From: Viacheslav <[email protected]>
> Sent: Thursday, January 11, 2024 2:19 PM
> To: Ping-Ke Shih <[email protected]>; [email protected]
> Cc: Jernej Škrabec <[email protected]>; Martin Blumenstingl <[email protected]>
> Subject: Re: rtw88: rtl8822cs AP mode not working
>
> 11/01/2024 03.42, Ping-Ke Shih пишет:
> >
> >
> >> -----Original Message-----
> >> From: Viacheslav <[email protected]>
> >> Sent: Wednesday, January 10, 2024 7:05 PM
> >> To: Ping-Ke Shih <[email protected]>; [email protected]
> >> Cc: Jernej Škrabec <[email protected]>; Martin Blumenstingl
> <[email protected]>
> >> Subject: Re: rtw88: rtl8822cs AP mode not working
> >>
> >> Hi!
> >>
> >> 10/01/2024 12.15, Ping-Ke Shih wrote:
> >>>
> >>>
> >>>> -----Original Message-----
> >>>> From: Viacheslav <[email protected]>
> >>>> Sent: Wednesday, January 10, 2024 3:07 PM
> >>>> To: [email protected]
> >>>> Cc: Ping-Ke Shih <[email protected]>; Jernej Škrabec <[email protected]>; Martin Blumenstingl
> >>>> <[email protected]>
> >>>> Subject: rtw88: rtl8822cs AP mode not working
> >>>>
> >>>> Hello!
> >>>>
> >>>> We use RTL8822CS modules in our devices and we switched to rtw88 from an
> >>>> external driver by Realtek. Suddenly we discovered that the AP mode
> >>>> (hotspot) stopped working. The hotspot is set up, but it does not
> >>>> authorize client connections.
> >>>>
> >>>> In attacments log and config files.
> >>>>
> >>>> client - notebook with iwlwifi 0000:00:14.3: Detected Killer(R) Wi-Fi 6E
> >>>> AX1675i 160MHz Wireless Network Adapter (211NGW), REV=0x370
> >>>>
> >>>
> >>> It is probably because RTL8822CS doesn't issue beacon properly. Trying to
> >>> capture air packets will be helpful to clarify the problem.
> >>
> >> airdump-ng result in attachment.
> >> I don't see any captured beacon packets.
> >
> > So, that is the problem. Did you see any weird messages in kernel log when
> > you were starting hostapd?
> >
> >
> dmesg/journalctl is clean. No messages related to wifi.
>
Have you ever tried AP mode on SDIO interface wifi cards, like RTL8822CS?
It seems no beacon issues properly, but no obvious errors during starting
AP mode.
I don't have this kind of wifi cards, could you help to check if AP mode
works in your side?
Thank you
Ping-Ke
Hi Ping-Ke,
On Fri, Jan 12, 2024 at 1:40 AM Ping-Ke Shih <[email protected]> wrote:
[...]
> > dmesg/journalctl is clean. No messages related to wifi.
> >
>
> Have you ever tried AP mode on SDIO interface wifi cards, like RTL8822CS?
> It seems no beacon issues properly, but no obvious errors during starting
> AP mode.
I haven't tried AP mode before (and I think* that Jernej also hasn't tried it).
> I don't have this kind of wifi cards, could you help to check if AP mode
> works in your side?
I'll check that in the next few days.
Also I'm wondering where code enables beacons (is it
rtw_core_enable_beacon() or is there another relevant function?).
Knowing that would be helpful to analyze this further.
Thank you,
Martin
> -----Original Message-----
> From: Martin Blumenstingl <[email protected]>
> Sent: Sunday, January 14, 2024 6:50 AM
> To: Ping-Ke Shih <[email protected]>
> Cc: Viacheslav <[email protected]>; [email protected]; Jernej Škrabec
> <[email protected]>
> Subject: Re: rtw88: rtl8822cs AP mode not working
>
> Hi Ping-Ke,
>
> On Fri, Jan 12, 2024 at 1:40 AM Ping-Ke Shih <[email protected]> wrote:
> [...]
> > > dmesg/journalctl is clean. No messages related to wifi.
> > >
> >
> > Have you ever tried AP mode on SDIO interface wifi cards, like RTL8822CS?
> > It seems no beacon issues properly, but no obvious errors during starting
> > AP mode.
> I haven't tried AP mode before (and I think* that Jernej also hasn't tried it).
>
> > I don't have this kind of wifi cards, could you help to check if AP mode
> > works in your side?
> I'll check that in the next few days.
> Also I'm wondering where code enables beacons (is it
> rtw_core_enable_beacon() or is there another relevant function?).
> Knowing that would be helpful to analyze this further.
>
The main function to get and set beacon template to firmware is
rtw_fw_download_rsvd_page(). The basic concept is to put beacon frame via
qsel=BCN to a special TX FIFO area called "reserve page", and then
hardware/firmware will send beacon in interval of 100ms.
The TX FIFO look like
+---------+
| | ^
| | |
| | |
| | | normal TX FIFO page
| | |
| | |
| | v
+---------+ <----------- BCN_HEAD
| | ^
| | | reserve page
| | v
+---------+
The initial pages of reserve page is to store beacon, but latter one could be
PS null frame that firmware uses it to notify AP.
Ping-Ke
Hi Ping-Ke and Viacheslav,
On Mon, Jan 15, 2024 at 3:17 AM Ping-Ke Shih <[email protected]> wrote:
[...]
> > > I don't have this kind of wifi cards, could you help to check if AP mode
> > > works in your side?
> > I'll check that in the next few days.
AP mode is also not working for me, I get the same problem as
Viacheslav reported.
> > Also I'm wondering where code enables beacons (is it
> > rtw_core_enable_beacon() or is there another relevant function?).
> > Knowing that would be helpful to analyze this further.
>
> The main function to get and set beacon template to firmware is
> rtw_fw_download_rsvd_page(). The basic concept is to put beacon frame via
> qsel=BCN to a special TX FIFO area called "reserve page", and then
> hardware/firmware will send beacon in interval of 100ms.
Thanks for the explanation - that helped me find a better starting point!
I didn't have much time in the past few days, but I have some findings
and questions:
1) I found the following comment/code in the downstream driver [0]:
/*
* Disable Hw protection for a time which revserd for Hw sending beacon.
* Fix download reserved page packet fail that access collision with
the protection time.
*/
val8 = rtw_read8(adapter, REG_BCN_CTRL_8822C);
restore[1] = val8;
val8 &= ~BIT_EN_BCN_FUNCTION_8822C;
val8 |= BIT_DIS_TSF_UDT_8822C;
rtw_write8(adapter, REG_BCN_CTRL_8822C, val8);
This is not part of the upstream rtw88 driver, so I made a patch and
attached it.
Unfortunately it doesn't fix the problem.
2) PCI is the only HCI which does not need the checksum in the
pkt_Info (USB and SDIO need the checksum).
The checksum is added by rtw_tx_fill_txdesc_checksum() which is only
called in usb.c and sdio.c.
My understanding is that for reserved pages we can have more than one
pkt_info in the buffer (my starting point for this thought is
rtw_fill_rsvd_page_desc() from fw.c).
In usb.c and sdio.c we're only calculating the checksum for the very
first pkt_info, not for any subsequent ones (I didn't even know that
it's possible to have more than one pkt_Info outside of RX and TX
aggregation).
However, it seems that the downstream code calculates the TX checksum
for *all* pkt_info in the buffer, see [1]
This code is missing from rtw88 at the moment. Since I didn't have
time I did not try to implement this yet.
3) Has anybody tried AP mode with rtw88 on a (supported) USB chipset?
If my thought (from #2) is correct then AP mode would show the same
problems there.
4) Viacheslav, I think you previously mentioned that you did a bit of
work with the downstream driver.
It would be awesome if you could also take a look at the rtw88 and
downstream driver code and start comparing them (logic that's
different or completely missing from rtw88 is suspicious).
Best regards,
Martin
[0] https://github.com/chewitt/RTL8822CS/blob/60cd82134d63aa9436b43c42933a86d6e5a191ba/hal/rtl8822c/rtl8822c_ops.c#L1885-L1893
[1] https://github.com/chewitt/RTL8822CS/blob/main/hal/rtl8822c/sdio/rtl8822cs_xmit.c#L311-L312
+ Sascha for question 3)
(no other comments for now)
> -----Original Message-----
> From: Martin Blumenstingl <[email protected]>
> Sent: Wednesday, January 17, 2024 6:07 AM
> To: Ping-Ke Shih <[email protected]>; Viacheslav <[email protected]>
> Cc: [email protected]; Jernej Škrabec <[email protected]>
> Subject: Re: rtw88: rtl8822cs AP mode not working
>
> Hi Ping-Ke and Viacheslav,
>
> On Mon, Jan 15, 2024 at 3:17 AM Ping-Ke Shih <[email protected]> wrote:
> [...]
> > > > I don't have this kind of wifi cards, could you help to check if AP mode
> > > > works in your side?
> > > I'll check that in the next few days.
> AP mode is also not working for me, I get the same problem as
> Viacheslav reported.
>
> > > Also I'm wondering where code enables beacons (is it
> > > rtw_core_enable_beacon() or is there another relevant function?).
> > > Knowing that would be helpful to analyze this further.
> >
> > The main function to get and set beacon template to firmware is
> > rtw_fw_download_rsvd_page(). The basic concept is to put beacon frame via
> > qsel=BCN to a special TX FIFO area called "reserve page", and then
> > hardware/firmware will send beacon in interval of 100ms.
> Thanks for the explanation - that helped me find a better starting point!
>
> I didn't have much time in the past few days, but I have some findings
> and questions:
> 1) I found the following comment/code in the downstream driver [0]:
> /*
> * Disable Hw protection for a time which revserd for Hw sending beacon.
> * Fix download reserved page packet fail that access collision with
> the protection time.
> */
> val8 = rtw_read8(adapter, REG_BCN_CTRL_8822C);
> restore[1] = val8;
> val8 &= ~BIT_EN_BCN_FUNCTION_8822C;
> val8 |= BIT_DIS_TSF_UDT_8822C;
> rtw_write8(adapter, REG_BCN_CTRL_8822C, val8);
>
> This is not part of the upstream rtw88 driver, so I made a patch and
> attached it.
> Unfortunately it doesn't fix the problem.
>
> 2) PCI is the only HCI which does not need the checksum in the
> pkt_Info (USB and SDIO need the checksum).
> The checksum is added by rtw_tx_fill_txdesc_checksum() which is only
> called in usb.c and sdio.c.
> My understanding is that for reserved pages we can have more than one
> pkt_info in the buffer (my starting point for this thought is
> rtw_fill_rsvd_page_desc() from fw.c).
> In usb.c and sdio.c we're only calculating the checksum for the very
> first pkt_info, not for any subsequent ones (I didn't even know that
> it's possible to have more than one pkt_Info outside of RX and TX
> aggregation).
> However, it seems that the downstream code calculates the TX checksum
> for *all* pkt_info in the buffer, see [1]
> This code is missing from rtw88 at the moment. Since I didn't have
> time I did not try to implement this yet.
>
> 3) Has anybody tried AP mode with rtw88 on a (supported) USB chipset?
> If my thought (from #2) is correct then AP mode would show the same
> problems there.
>
> 4) Viacheslav, I think you previously mentioned that you did a bit of
> work with the downstream driver.
> It would be awesome if you could also take a look at the rtw88 and
> downstream driver code and start comparing them (logic that's
> different or completely missing from rtw88 is suspicious).
>
>
> Best regards,
> Martin
>
>
> [0]
> https://github.com/chewitt/RTL8822CS/blob/60cd82134d63aa9436b43c42933a86d6e5a191ba/hal/rtl8822c/rtl882
> 2c_ops.c#L1885-L1893
> [1] https://github.com/chewitt/RTL8822CS/blob/main/hal/rtl8822c/sdio/rtl8822cs_xmit.c#L311-L312
On Wed, Jan 17, 2024 at 12:35:42AM +0000, Ping-Ke Shih wrote:
> + Sascha for question 3)
>
> (no other comments for now)
>
> > -----Original Message-----
> > From: Martin Blumenstingl <[email protected]>
> > Sent: Wednesday, January 17, 2024 6:07 AM
> > To: Ping-Ke Shih <[email protected]>; Viacheslav <[email protected]>
> > Cc: [email protected]; Jernej Škrabec <[email protected]>
> > Subject: Re: rtw88: rtl8822cs AP mode not working
> >
> > Hi Ping-Ke and Viacheslav,
> >
> > On Mon, Jan 15, 2024 at 3:17 AM Ping-Ke Shih <[email protected]> wrote:
> > [...]
> > > > > I don't have this kind of wifi cards, could you help to check if AP mode
> > > > > works in your side?
> > > > I'll check that in the next few days.
> > AP mode is also not working for me, I get the same problem as
> > Viacheslav reported.
> >
> > > > Also I'm wondering where code enables beacons (is it
> > > > rtw_core_enable_beacon() or is there another relevant function?).
> > > > Knowing that would be helpful to analyze this further.
> > >
> > > The main function to get and set beacon template to firmware is
> > > rtw_fw_download_rsvd_page(). The basic concept is to put beacon frame via
> > > qsel=BCN to a special TX FIFO area called "reserve page", and then
> > > hardware/firmware will send beacon in interval of 100ms.
> > Thanks for the explanation - that helped me find a better starting point!
> >
> > I didn't have much time in the past few days, but I have some findings
> > and questions:
> > 1) I found the following comment/code in the downstream driver [0]:
> > /*
> > * Disable Hw protection for a time which revserd for Hw sending beacon.
> > * Fix download reserved page packet fail that access collision with
> > the protection time.
> > */
> > val8 = rtw_read8(adapter, REG_BCN_CTRL_8822C);
> > restore[1] = val8;
> > val8 &= ~BIT_EN_BCN_FUNCTION_8822C;
> > val8 |= BIT_DIS_TSF_UDT_8822C;
> > rtw_write8(adapter, REG_BCN_CTRL_8822C, val8);
> >
> > This is not part of the upstream rtw88 driver, so I made a patch and
> > attached it.
> > Unfortunately it doesn't fix the problem.
> >
> > 2) PCI is the only HCI which does not need the checksum in the
> > pkt_Info (USB and SDIO need the checksum).
> > The checksum is added by rtw_tx_fill_txdesc_checksum() which is only
> > called in usb.c and sdio.c.
> > My understanding is that for reserved pages we can have more than one
> > pkt_info in the buffer (my starting point for this thought is
> > rtw_fill_rsvd_page_desc() from fw.c).
> > In usb.c and sdio.c we're only calculating the checksum for the very
> > first pkt_info, not for any subsequent ones (I didn't even know that
> > it's possible to have more than one pkt_Info outside of RX and TX
> > aggregation).
> > However, it seems that the downstream code calculates the TX checksum
> > for *all* pkt_info in the buffer, see [1]
> > This code is missing from rtw88 at the moment. Since I didn't have
> > time I did not try to implement this yet.
> >
> > 3) Has anybody tried AP mode with rtw88 on a (supported) USB chipset?
> > If my thought (from #2) is correct then AP mode would show the same
> > problems there.
I haven't tried AP mode with the rtw88 driver. Shame on me, but I didn't
want to open that can of worms at that time.
Regards,
Sascha
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
Hi!
17/01/2024 01.07, Martin Blumenstingl wrote:
> Hi Ping-Ke and Viacheslav,
>
> On Mon, Jan 15, 2024 at 3:17 AM Ping-Ke Shih <[email protected]> wrote:
> [...]
>>>> I don't have this kind of wifi cards, could you help to check if AP mode
>>>> works in your side?
>>> I'll check that in the next few days.
> AP mode is also not working for me, I get the same problem as
> Viacheslav reported.
>
>>> Also I'm wondering where code enables beacons (is it
>>> rtw_core_enable_beacon() or is there another relevant function?).
>>> Knowing that would be helpful to analyze this further.
>>
>> The main function to get and set beacon template to firmware is
>> rtw_fw_download_rsvd_page(). The basic concept is to put beacon frame via
>> qsel=BCN to a special TX FIFO area called "reserve page", and then
>> hardware/firmware will send beacon in interval of 100ms.
> Thanks for the explanation - that helped me find a better starting point!
>
> I didn't have much time in the past few days, but I have some findings
> and questions:
> 1) I found the following comment/code in the downstream driver [0]:
> /*
> * Disable Hw protection for a time which revserd for Hw sending beacon.
> * Fix download reserved page packet fail that access collision with
> the protection time.
> */
> val8 = rtw_read8(adapter, REG_BCN_CTRL_8822C);
> restore[1] = val8;
> val8 &= ~BIT_EN_BCN_FUNCTION_8822C;
> val8 |= BIT_DIS_TSF_UDT_8822C;
> rtw_write8(adapter, REG_BCN_CTRL_8822C, val8);
>
> This is not part of the upstream rtw88 driver, so I made a patch and
> attached it.
> Unfortunately it doesn't fix the problem.
>
> 2) PCI is the only HCI which does not need the checksum in the
> pkt_Info (USB and SDIO need the checksum).
> The checksum is added by rtw_tx_fill_txdesc_checksum() which is only
> called in usb.c and sdio.c.
> My understanding is that for reserved pages we can have more than one
> pkt_info in the buffer (my starting point for this thought is
> rtw_fill_rsvd_page_desc() from fw.c).
> In usb.c and sdio.c we're only calculating the checksum for the very
> first pkt_info, not for any subsequent ones (I didn't even know that
> it's possible to have more than one pkt_Info outside of RX and TX
> aggregation).
> However, it seems that the downstream code calculates the TX checksum
> for *all* pkt_info in the buffer, see [1]
> This code is missing from rtw88 at the moment. Since I didn't have
> time I did not try to implement this yet.
>
> 3) Has anybody tried AP mode with rtw88 on a (supported) USB chipset?
> If my thought (from #2) is correct then AP mode would show the same
> problems there.
I have USB RTL8821CU. It works in AP mode:
[511809.841083] usb 1-1.4: New USB device found, idVendor=0bda,
idProduct=c820, bcdDevice= 2.00
[511809.841111] usb 1-1.4: New USB device strings: Mfr=1, Product=2,
SerialNumber=3
[511809.841118] usb 1-1.4: Product: 802.11ac NIC
[511809.841124] usb 1-1.4: Manufacturer: Realtek
[511809.841130] usb 1-1.4: SerialNumber: 123456
[511809.973789] usbcore: registered new interface driver btusb
[511810.432057] usbcore: registered new interface driver rtl8821cu
client log:
Jan 17 12:35:02 adeepn wpa_supplicant[1868]: wlo1: SME: Trying to
authenticate with 00:13:ef:5f:22:2f (SSID='Hostspot' freq=2437 MHz)
Jan 17 12:35:03 adeepn kernel: wlo1: authenticate with 00:13:ef:5f:22:2f
Jan 17 12:35:03 adeepn kernel: wlo1: 80 MHz not supported, disabling VHT
Jan 17 12:35:03 adeepn kernel: wlo1: send auth to 00:13:ef:5f:22:2f (try
1/3)
Jan 17 12:35:03 adeepn kernel: wlo1: authenticated
Jan 17 12:35:03 adeepn kernel: iwlwifi 0000:00:14.3 wlo1: disabling
HT/VHT/HE as WMM/QoS is not supported by the AP
Jan 17 12:35:03 adeepn kernel: wlo1: associate with 00:13:ef:5f:22:2f
(try 1/3)
Jan 17 12:35:03 adeepn kernel: wlo1: RX AssocResp from 00:13:ef:5f:22:2f
(capab=0x1411 status=0 aid=1)
Jan 17 12:35:03 adeepn kernel: wlo1: associated
Jan 17 12:35:02 adeepn wpa_supplicant[1868]: wlo1: Trying to associate
with 00:13:ef:5f:22:2f (SSID='Hostspot' freq=2437 MHz)
Jan 17 12:35:02 adeepn wpa_supplicant[1868]: wlo1: Associated with
00:13:ef:5f:22:2f
Jan 17 12:35:02 adeepn wpa_supplicant[1868]: wlo1:
CTRL-EVENT-SUBNET-STATUS-UPDATE status=0
Jan 17 12:35:02 adeepn wpa_supplicant[1868]: wlo1: WPA: Key negotiation
completed with 00:13:ef:5f:22:2f [PTK=CCMP GTK=CCMP]
Jan 17 12:35:02 adeepn wpa_supplicant[1868]: wlo1: CTRL-EVENT-CONNECTED
- Connection to 00:13:ef:5f:22:2f completed [id=0 id_str=]
Jan 17 12:35:02 adeepn wpa_supplicant[1868]: wlo1:
CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-47 noise=9999 txrate=1000
Jan 17 12:35:02 adeepn NetworkManager[1827]: <info> [1705484102.2430]
device (wlo1): Activation: (wifi) Stage 2 of 5 (Device Configure)
successful. Connected to wireless network "Hostspot"
Log from hostapd in attachment.
> 4) Viacheslav, I think you previously mentioned that you did a bit of
> work with the downstream driver.
> It would be awesome if you could also take a look at the rtw88 and
> downstream driver code and start comparing them (logic that's
> different or completely missing from rtw88 is suspicious).
>
I made some minor fixes to restore functionality after kernel updates.
But in this case, I will need help to understand where and how to start
figuring this out.
Moreover, we've encountered another problem: after two or three days the
client WiFi connection stops working, the network interface loses its
DHCP address, and consequently nothing else works.
>
> Best regards,
> Martin
>
>
> [0] https://github.com/chewitt/RTL8822CS/blob/60cd82134d63aa9436b43c42933a86d6e5a191ba/hal/rtl8822c/rtl8822c_ops.c#L1885-L1893
> [1] https://github.com/chewitt/RTL8822CS/blob/main/hal/rtl8822c/sdio/rtl8822cs_xmit.c#L311-L312
Hi Viacheslav,
On Wed, Jan 17, 2024 at 10:48 AM Viacheslav <[email protected]> wrote:
[...]
> > 3) Has anybody tried AP mode with rtw88 on a (supported) USB chipset?
> > If my thought (from #2) is correct then AP mode would show the same
> > problems there.
>
> I have USB RTL8821CU. It works in AP mode:
Thank you - this helps a lot as it narrows down the problem a lot!
If RTL8821CU works in AP mode the problem must be one of:
- a bug in sdio.c (in my opinion this is the most likely cause -
starting point: rtw_sdio_write_data_rsvd_page())
- some missing bits that are only SDIO relevant (in other words: code
that hasn't made it from the downstream driver into rtw88 yet)
- chipset specific differences (RTL8821C vs RTL8822C)
- a bug in the existing code that only affects SDIO cards (but doesn't
affect PCI / USB chips)
- a combination of any of those issues
I won't have time to look into this any further before the weekend.
Once I have more findings I'll let you know.
[...]
> > 4) Viacheslav, I think you previously mentioned that you did a bit of
> > work with the downstream driver.
> > It would be awesome if you could also take a look at the rtw88 and
> > downstream driver code and start comparing them (logic that's
> > different or completely missing from rtw88 is suspicious).
> >
>
> I made some minor fixes to restore functionality after kernel updates.
> But in this case, I will need help to understand where and how to start
> figuring this out.
The last rtw88 sdio bug fixes also only required changing only a few lines each.
As always: the tricky part is finding out what to change (without
breaking something else) :-)
> Moreover, we've encountered another problem: after two or three days the
> client WiFi connection stops working, the network interface loses its
> DHCP address, and consequently nothing else works.
Can you please confirm (to avoid any misunderstanding) that:
- this is in STA mode (meaning: RTL8822CS is connected to another AP)
- "loses it's DHCP address" means traffic stops flowing, even DHCP
renew is not working anymore
- (does restarting the interface: ip link set down ...; ip link set up
... work?)
Best regards,
Martin
@ Viacheslav:
Can you please tell me which repo did you use when your run USB 8821cu
successfully in AP mode ?
From your log bellow it seems that is not the mainline driver rtw88_8821cu.
On Wed, Jan 17, 2024 at 10:49 AM Viacheslav <[email protected]> wrote:
> I have USB RTL8821CU. It works in AP mode:
>
> [511809.841083] usb 1-1.4: New USB device found, idVendor=0bda,
> idProduct=c820, bcdDevice= 2.00
> [511809.841111] usb 1-1.4: New USB device strings: Mfr=1, Product=2,
> SerialNumber=3
> [511809.841118] usb 1-1.4: Product: 802.11ac NIC
> [511809.841124] usb 1-1.4: Manufacturer: Realtek
> [511809.841130] usb 1-1.4: SerialNumber: 123456
> [511809.973789] usbcore: registered new interface driver btusb
> [511810.432057] usbcore: registered new interface driver rtl8821cu
18/04/2024 09.58, Gabriel Tisan wrote:
> @ Viacheslav:
> Can you please tell me which repo did you use when your run USB 8821cu
> successfully in AP mode ?
> From your log bellow it seems that is not the mainline driver rtw88_8821cu.
>
> On Wed, Jan 17, 2024 at 10:49 AM Viacheslav <[email protected]> wrote:
>> I have USB RTL8821CU. It works in AP mode:
>>
>> [511809.841083] usb 1-1.4: New USB device found, idVendor=0bda,
>> idProduct=c820, bcdDevice= 2.00
>> [511809.841111] usb 1-1.4: New USB device strings: Mfr=1, Product=2,
>> SerialNumber=3
>> [511809.841118] usb 1-1.4: Product: 802.11ac NIC
>> [511809.841124] usb 1-1.4: Manufacturer: Realtek
>> [511809.841130] usb 1-1.4: SerialNumber: 123456
>> [511809.973789] usbcore: registered new interface driver btusb
>> [511810.432057] usbcore: registered new interface driver rtl8821cu
Damn, I thought the rtw88 driver had been picked up, but now I see that
it hasn't. I will test again and report back with the results.
I tested again and I could confirm that rtw88 does not send any beacon
in AP mode.
Once again, maybe you could tell me which repo of the driver rtl8821cu
you tested successfully in AP mode.
On Thu, Apr 18, 2024 at 12:55 PM Viacheslav <[email protected]> wrote:
>
>
>
> 18/04/2024 09.58, Gabriel Tisan wrote:
> > @ Viacheslav:
> > Can you please tell me which repo did you use when your run USB 8821cu
> > successfully in AP mode ?
> > From your log bellow it seems that is not the mainline driver rtw88_8821cu.
> >
> > On Wed, Jan 17, 2024 at 10:49 AM Viacheslav <[email protected]> wrote:
> >> I have USB RTL8821CU. It works in AP mode:
> >>
> >> [511809.841083] usb 1-1.4: New USB device found, idVendor=0bda,
> >> idProduct=c820, bcdDevice= 2.00
> >> [511809.841111] usb 1-1.4: New USB device strings: Mfr=1, Product=2,
> >> SerialNumber=3
> >> [511809.841118] usb 1-1.4: Product: 802.11ac NIC
> >> [511809.841124] usb 1-1.4: Manufacturer: Realtek
> >> [511809.841130] usb 1-1.4: SerialNumber: 123456
> >> [511809.973789] usbcore: registered new interface driver btusb
> >> [511810.432057] usbcore: registered new interface driver rtl8821cu
>
> Damn, I thought the rtw88 driver had been picked up, but now I see that
> it hasn't. I will test again and report back with the results.
Seems that was github morrownr/8821cu-20210916 repo.
see
https://github.com/armbian/build/blob/2c0fef166f78962500fecfb6a2208550cc897fb5/lib/functions/compilation/patch/drivers_network.sh#L257
06/05/2024 12.38, Gabriel Tisan wrote:
> I tested again and I could confirm that rtw88 does not send any beacon
> in AP mode.
> Once again, maybe you could tell me which repo of the driver rtl8821cu
> you tested successfully in AP mode.
>
> On Thu, Apr 18, 2024 at 12:55 PM Viacheslav <[email protected]> wrote:
>>
>>
>>
>> 18/04/2024 09.58, Gabriel Tisan wrote:
>>> @ Viacheslav:
>>> Can you please tell me which repo did you use when your run USB 8821cu
>>> successfully in AP mode ?
>>> From your log bellow it seems that is not the mainline driver rtw88_8821cu.
>>>
>>> On Wed, Jan 17, 2024 at 10:49 AM Viacheslav <[email protected]> wrote:
>>>> I have USB RTL8821CU. It works in AP mode:
>>>>
>>>> [511809.841083] usb 1-1.4: New USB device found, idVendor=0bda,
>>>> idProduct=c820, bcdDevice= 2.00
>>>> [511809.841111] usb 1-1.4: New USB device strings: Mfr=1, Product=2,
>>>> SerialNumber=3
>>>> [511809.841118] usb 1-1.4: Product: 802.11ac NIC
>>>> [511809.841124] usb 1-1.4: Manufacturer: Realtek
>>>> [511809.841130] usb 1-1.4: SerialNumber: 123456
>>>> [511809.973789] usbcore: registered new interface driver btusb
>>>> [511810.432057] usbcore: registered new interface driver rtl8821cu
>>
>> Damn, I thought the rtw88 driver had been picked up, but now I see that
>> it hasn't. I will test again and report back with the results.