netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH] wifi: rtl8xxxu: fix authentication timeout due to incorrect RCR value
@ 2023-04-27  2:05 Yun Lu
  2023-04-27 17:01 ` Bitterblue Smith
                   ` (2 more replies)
  0 siblings, 3 replies; 16+ messages in thread
From: Yun Lu @ 2023-04-27  2:05 UTC (permalink / raw)
  To: Jes.Sorensen; +Cc: kvalo, davem, edumazet, kuba, pabeni, linux-wireless, netdev

From: Yun Lu <luyun@kylinos.cn>

When using rtl8192cu with rtl8xxxu driver to connect wifi, there is a
probability of failure, which shows "authentication with ... timed out".
Through debugging, it was found that the RCR register has been inexplicably
modified to an incorrect value, resulting in the nic not being able to
receive authenticated frames.

To fix this problem, add regrcr in rtl8xxxu_priv struct, and store
the RCR value every time the register is writen, and use it the next
time the register need to be modified.

Signed-off-by: Yun Lu <luyun@kylinos.cn>
---
 drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h      | 1 +
 drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c | 4 +++-
 2 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h
index c8cee4a24755..4088aaa1c618 100644
--- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h
+++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h
@@ -1518,6 +1518,7 @@ struct rtl8xxxu_priv {
 	u32 rege9c;
 	u32 regeb4;
 	u32 regebc;
+	u32 regrcr;
 	int next_mbox;
 	int nr_out_eps;
 
diff --git a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
index 620a5cc2bfdd..2fe71933ba08 100644
--- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
+++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
@@ -4053,6 +4053,7 @@ static int rtl8xxxu_init_device(struct ieee80211_hw *hw)
 		RCR_ACCEPT_MGMT_FRAME | RCR_HTC_LOC_CTRL |
 		RCR_APPEND_PHYSTAT | RCR_APPEND_ICV | RCR_APPEND_MIC;
 	rtl8xxxu_write32(priv, REG_RCR, val32);
+	priv->regrcr = val32;
 
 	if (priv->rtl_chip == RTL8188F) {
 		/* Accept all data frames */
@@ -6273,7 +6274,7 @@ static void rtl8xxxu_configure_filter(struct ieee80211_hw *hw,
 				      unsigned int *total_flags, u64 multicast)
 {
 	struct rtl8xxxu_priv *priv = hw->priv;
-	u32 rcr = rtl8xxxu_read32(priv, REG_RCR);
+	u32 rcr = priv->regrcr;
 
 	dev_dbg(&priv->udev->dev, "%s: changed_flags %08x, total_flags %08x\n",
 		__func__, changed_flags, *total_flags);
@@ -6319,6 +6320,7 @@ static void rtl8xxxu_configure_filter(struct ieee80211_hw *hw,
 	 */
 
 	rtl8xxxu_write32(priv, REG_RCR, rcr);
+	priv->regrcr = rcr;
 
 	*total_flags &= (FIF_ALLMULTI | FIF_FCSFAIL | FIF_BCN_PRBRESP_PROMISC |
 			 FIF_CONTROL | FIF_OTHER_BSS | FIF_PSPOLL |
-- 
2.27.0


No virus found
		Checked by Hillstone Network AntiVirus


^ permalink raw reply related	[flat|nested] 16+ messages in thread

* Re: [PATCH] wifi: rtl8xxxu: fix authentication timeout due to incorrect RCR value
  2023-04-27  2:05 [PATCH] wifi: rtl8xxxu: fix authentication timeout due to incorrect RCR value Yun Lu
@ 2023-04-27 17:01 ` Bitterblue Smith
  2023-04-28  4:30   ` Yun Lu
  2023-04-27 18:01 ` Larry Finger
  2023-04-28  2:00 ` Larry Finger
  2 siblings, 1 reply; 16+ messages in thread
From: Bitterblue Smith @ 2023-04-27 17:01 UTC (permalink / raw)
  To: Yun Lu, Jes.Sorensen
  Cc: kvalo, davem, edumazet, kuba, pabeni, linux-wireless, netdev

On 27/04/2023 05:05, Yun Lu wrote:
> From: Yun Lu <luyun@kylinos.cn>
> 
> When using rtl8192cu with rtl8xxxu driver to connect wifi, there is a
> probability of failure, which shows "authentication with ... timed out".
> Through debugging, it was found that the RCR register has been inexplicably
> modified to an incorrect value, resulting in the nic not being able to
> receive authenticated frames.
> 
> To fix this problem, add regrcr in rtl8xxxu_priv struct, and store
> the RCR value every time the register is writen, and use it the next
> time the register need to be modified.
> 

Can this bug be reproduced easily? Is it always the same bits which
are mysteriously cleared from REG_RCR?

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [PATCH] wifi: rtl8xxxu: fix authentication timeout due to incorrect RCR value
  2023-04-27  2:05 [PATCH] wifi: rtl8xxxu: fix authentication timeout due to incorrect RCR value Yun Lu
  2023-04-27 17:01 ` Bitterblue Smith
@ 2023-04-27 18:01 ` Larry Finger
  2023-04-28  2:00 ` Larry Finger
  2 siblings, 0 replies; 16+ messages in thread
From: Larry Finger @ 2023-04-27 18:01 UTC (permalink / raw)
  To: Yun Lu, Jes.Sorensen
  Cc: kvalo, davem, edumazet, kuba, pabeni, linux-wireless, netdev

On 4/26/23 21:05, Yun Lu wrote:
> From: Yun Lu <luyun@kylinos.cn>
> 
> When using rtl8192cu with rtl8xxxu driver to connect wifi, there is a
> probability of failure, which shows "authentication with ... timed out".
> Through debugging, it was found that the RCR register has been inexplicably
> modified to an incorrect value, resulting in the nic not being able to
> receive authenticated frames.
> 
> To fix this problem, add regrcr in rtl8xxxu_priv struct, and store
> the RCR value every time the register is writen, and use it the next
> time the register need to be modified.
> 
> Signed-off-by: Yun Lu <luyun@kylinos.cn>
> ---
>   drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h      | 1 +
>   drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c | 4 +++-
>   2 files changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h
> index c8cee4a24755..4088aaa1c618 100644
> --- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h
> +++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h
> @@ -1518,6 +1518,7 @@ struct rtl8xxxu_priv {
>   	u32 rege9c;
>   	u32 regeb4;
>   	u32 regebc;
> +	u32 regrcr;
>   	int next_mbox;
>   	int nr_out_eps;
>   
> diff --git a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
> index 620a5cc2bfdd..2fe71933ba08 100644
> --- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
> +++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
> @@ -4053,6 +4053,7 @@ static int rtl8xxxu_init_device(struct ieee80211_hw *hw)
>   		RCR_ACCEPT_MGMT_FRAME | RCR_HTC_LOC_CTRL |
>   		RCR_APPEND_PHYSTAT | RCR_APPEND_ICV | RCR_APPEND_MIC;
>   	rtl8xxxu_write32(priv, REG_RCR, val32);
> +	priv->regrcr = val32;
>   
>   	if (priv->rtl_chip == RTL8188F) {
>   		/* Accept all data frames */
> @@ -6273,7 +6274,7 @@ static void rtl8xxxu_configure_filter(struct ieee80211_hw *hw,
>   				      unsigned int *total_flags, u64 multicast)
>   {
>   	struct rtl8xxxu_priv *priv = hw->priv;
> -	u32 rcr = rtl8xxxu_read32(priv, REG_RCR);
> +	u32 rcr = priv->regrcr;
>   
>   	dev_dbg(&priv->udev->dev, "%s: changed_flags %08x, total_flags %08x\n",
>   		__func__, changed_flags, *total_flags);
> @@ -6319,6 +6320,7 @@ static void rtl8xxxu_configure_filter(struct ieee80211_hw *hw,
>   	 */
>   
>   	rtl8xxxu_write32(priv, REG_RCR, rcr);
> +	priv->regrcr = rcr;
>   
>   	*total_flags &= (FIF_ALLMULTI | FIF_FCSFAIL | FIF_BCN_PRBRESP_PROMISC |
>   			 FIF_CONTROL | FIF_OTHER_BSS | FIF_PSPOLL |

Wouldn't it be better to find the location that is writing the incorrect value 
to RCR and fix that? It seems to me that you are applying a band-aid rather than 
fixing the problem.

Larry


^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [PATCH] wifi: rtl8xxxu: fix authentication timeout due to incorrect RCR value
  2023-04-27  2:05 [PATCH] wifi: rtl8xxxu: fix authentication timeout due to incorrect RCR value Yun Lu
  2023-04-27 17:01 ` Bitterblue Smith
  2023-04-27 18:01 ` Larry Finger
@ 2023-04-28  2:00 ` Larry Finger
  2023-04-28  4:25   ` wo
       [not found]   ` <76a784b2.2cb3.187c60f0f68.Coremail.luyun_611@163.com>
  2 siblings, 2 replies; 16+ messages in thread
From: Larry Finger @ 2023-04-28  2:00 UTC (permalink / raw)
  To: Yun Lu, Jes.Sorensen
  Cc: kvalo, davem, edumazet, kuba, pabeni, linux-wireless, netdev

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

On 4/26/23 21:05, Yun Lu wrote:
> From: Yun Lu <luyun@kylinos.cn>
> 
> When using rtl8192cu with rtl8xxxu driver to connect wifi, there is a
> probability of failure, which shows "authentication with ... timed out".
> Through debugging, it was found that the RCR register has been inexplicably
> modified to an incorrect value, resulting in the nic not being able to
> receive authenticated frames.
> 
> To fix this problem, add regrcr in rtl8xxxu_priv struct, and store
> the RCR value every time the register is writen, and use it the next
> time the register need to be modified.

I added the attached patch to see what was different between the two values in 
REG_RCR. To my surprise, nothing was logged.

Please add this one on top of you proposed patch, and send me the output from 
the log.

Thanks,

Larry


[-- Attachment #2: log_data.patch --]
[-- Type: text/x-patch, Size: 1443 bytes --]

diff --git a/Makefile b/Makefile
index f5543eef4f82..6d985a175d78 100644
--- a/Makefile
+++ b/Makefile
@@ -1,8 +1,8 @@
 # SPDX-License-Identifier: GPL-2.0
 VERSION = 6
-PATCHLEVEL = 3
+PATCHLEVEL = 4
 SUBLEVEL = 0
-EXTRAVERSION =
+EXTRAVERSION = -rc0
 NAME = Hurr durr I'ma ninja sloth
 
 # *DOCUMENTATION*
diff --git a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
index 831639d73657..b5212ceb4eb4 100644
--- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
+++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
@@ -6504,6 +6504,10 @@ static void rtl8xxxu_configure_filter(struct ieee80211_hw *hw,
 	struct rtl8xxxu_priv *priv = hw->priv;
 	u32 rcr = priv->regrcr;
 
+	if (rcr != rtl8xxxu_read32(priv, REG_RCR)) {
+		pr_info("BEFORE: REG_RCR differs from regrcr: 0x%x insted of 0x%x\n",
+			rtl8xxxu_read32(priv, REG_RCR), priv->regrcr);
+	}
 	dev_dbg(&priv->udev->dev, "%s: changed_flags %08x, total_flags %08x\n",
 		__func__, changed_flags, *total_flags);
 
@@ -6547,6 +6551,10 @@ static void rtl8xxxu_configure_filter(struct ieee80211_hw *hw,
 	 * FIF_PROBE_REQ ignored as probe requests always seem to be accepted
 	 */
 
+	if (rcr != rtl8xxxu_read32(priv, REG_RCR)) {
+		pr_info("AFTER: REG_RCR differs from regrcr: 0x%x insted of 0x%x\n",
+			rtl8xxxu_read32(priv, REG_RCR), priv->regrcr);
+	}
 	rtl8xxxu_write32(priv, REG_RCR, rcr);
 	priv->regrcr = rcr;
 

^ permalink raw reply related	[flat|nested] 16+ messages in thread

* Re:Re: [PATCH] wifi: rtl8xxxu: fix authentication timeout due to incorrect RCR value
  2023-04-28  2:00 ` Larry Finger
@ 2023-04-28  4:25   ` wo
  2023-04-28  8:25     ` Kalle Valo
       [not found]   ` <76a784b2.2cb3.187c60f0f68.Coremail.luyun_611@163.com>
  1 sibling, 1 reply; 16+ messages in thread
From: wo @ 2023-04-28  4:25 UTC (permalink / raw)
  To: Larry Finger
  Cc: Jes.Sorensen, kvalo, davem, edumazet, kuba, pabeni,
	linux-wireless, netdev

At 2023-04-28 10:00:28, "Larry Finger" <Larry.Finger@lwfinger.net> wrote:
>On 4/26/23 21:05, Yun Lu wrote:
>> From: Yun Lu <luyun@kylinos.cn>
>> 
>> When using rtl8192cu with rtl8xxxu driver to connect wifi, there is a
>> probability of failure, which shows "authentication with ... timed out".
>> Through debugging, it was found that the RCR register has been inexplicably
>> modified to an incorrect value, resulting in the nic not being able to
>> receive authenticated frames.
>> 
>> To fix this problem, add regrcr in rtl8xxxu_priv struct, and store
>> the RCR value every time the register is writen, and use it the next
>> time the register need to be modified.
>
>I added the attached patch to see what was different between the two values in 
>REG_RCR. To my surprise, nothing was logged.
>
>Please add this one on top of you proposed patch, and send me the output from 
>the log.
>
>Thanks,
>
>Larry
>
Larry:

Thanks  for providing the debugging patch.
The REG_RCR can only be writen in function rtl8xxxu_init_device or rtl8xxxu_configure_filter,
the init value is 0x7000600e, and may be modified to 0x700060ce or 0x7000604e when 
configure_filter. But on this device(EDIMAX EW-7822UAn) we used, the REG_RCR has indeed
been modified for unknown reason.

After applying your debugging patch, the log shows:
[   70.426757] [pid:217,cpu6,kworker/u16:3,3]AFTER: REG_RCR differs from regrcr: 0x7000600e insted of 0x7000600e
[   70.465881] [pid:1994,cpu6,wpa_supplicant,5]AFTER: REG_RCR differs from regrcr: 0x700060ce insted of 0x700060ce
[   71.803222] [pid:217,cpu7,kworker/u16:3,0]AFTER: REG_RCR differs from regrcr: 0x7000604e insted of 0x7000604e
[   71.805358] [pid:217,cpu7,kworker/u16:3,1]BEFORE: REG_RCR differs from regrcr: 0x70006009 insted of 0x700060ce
[   71.806854] [pid:217,cpu6,kworker/u16:3,2]AFTER: REG_RCR differs from regrcr: 0x390272a insted of 0x700060ce
[   98.894104] [pid:1994,cpu6,wpa_supplicant,9]AFTER: REG_RCR differs from regrcr: 0x700060ce insted of 0x700060ce
[  100.151824] [pid:1949,cpu7,NetworkManager,1]AFTER: REG_RCR differs from regrcr: 0x7000604e insted of 0x7000604e
[  100.830505] [pid:1994,cpu6,wpa_supplicant,5]AFTER: REG_RCR differs from regrcr: 0x700060ce insted of 0x700060ce
[  102.101806] [pid:7,cpu7,kworker/u16:0,9]AFTER: REG_RCR differs from regrcr: 0x7000604e insted of 0x7000604e
[  107.545440] [pid:1994,cpu7,wpa_supplicant,4]AFTER: REG_RCR differs from regrcr: 0x700060ce insted of 0x700060ce
[  108.878204] [pid:216,cpu1,kworker/u16:2,7]AFTER: REG_RCR differs from regrcr: 0x7000604e insted of 0x7000604e
[  126.028961] [pid:1994,cpu7,wpa_supplicant,5]AFTER: REG_RCR differs from regrcr: 0x700060ce insted of 0x700060ce
[  127.389801] [2023:04:28 11:11:45][pid:237,cpu7,kworker/u16:5,6]AFTER: REG_RCR differs from regrcr: 0x7000604e insted of 0x7000604e
[  137.119384] [pid:1994,cpu6,wpa_supplicant,3]AFTER: REG_RCR differs from regrcr: 0x700060ce insted of 0x700060ce
[  138.393005] [pid:237,cpu7,kworker/u16:5,5]AFTER: REG_RCR differs from regrcr: 0x7000604e insted of 0x7000604e
[  138.395996] [pid:1994,cpu7,wpa_supplicant,6]AFTER: REG_RCR differs from regrcr: 0x700060ce insted of 0x700060ce
[  138.436889] [pid:1994,cpu6,wpa_supplicant,9]AFTER: REG_RCR differs from regrcr: 0x7000604e insted of 0x7000604e
[  148.251800] [pid:1994,cpu6,wpa_supplicant,5]AFTER: REG_RCR differs from regrcr: 0x700060ce insted of 0x700060ce
[  149.538909] [2023:04:28 11:12:08][pid:216,cpu6,kworker/u16:2,6]AFTER: REG_RCR differs from regrcr: 0x7000604e insted of 0x7000604e
[  149.542419] [pid:1994,cpu6,wpa_supplicant,7]AFTER: REG_RCR differs from regrcr: 0x700060ce insted of 0x700060ce
[  149.595642] [pid:7,cpu6,kworker/u16:0,0]BEFORE: REG_RCR differs from regrcr: 0x1830613 insted of 0x7000604e
[  149.597778] [pid:1994,cpu6,wpa_supplicant,1]AFTER: REG_RCR differs from regrcr: 0x7000604e insted of 0x7000604e
[  159.384613] [pid:1994,cpu7,wpa_supplicant,7]AFTER: REG_RCR differs from regrcr: 0x700060ce insted of 0x700060ce
[  160.673583] [pid:237,cpu4,kworker/u16:5,1]AFTER: REG_RCR differs from regrcr: 0x7000604e insted of 0x7000604e
[  160.676422] [pid:237,cpu6,kworker/u16:5,3]BEFORE: REG_RCR differs from regrcr: 0x70006009 insted of 0x700060ce
[  170.521148] [pid:1994,cpu7,wpa_supplicant,8]AFTER: REG_RCR differs from regrcr: 0x700060ce insted of 0x700060ce
[  171.845764] [pid:237,cpu6,kworker/u16:5,0]AFTER: REG_RCR differs from regrcr: 0x7000604e insted of 0x7000604e
[  171.850830] [pid:1994,cpu6,wpa_supplicant,1]AFTER: REG_RCR differs from regrcr: 0x700060ce insted of 0x700060ce
[  171.897125] [pid:1994,cpu7,wpa_supplicant,4]AFTER: REG_RCR differs from regrcr: 0x7000604e insted of 0x7000604e
[  173.092742] [2023:04:28 11:12:31][pid:1994,cpu6,wpa_supplicant,0]AFTER: REG_RCR differs from regrcr: 0x700060ce insted of 0x700060ce
[  174.369445] [pid:237,cpu6,kworker/u16:5,2]AFTER: REG_RCR differs from regrcr: 0x7000604e insted of 0x7000604e
[  176.070007] [2023:04:28 11:12:34][pid:1994,cpu7,wpa_supplicant,8]AFTER: REG_RCR differs from regrcr: 0x700060ce insted of 0x700060ce
[  177.354827] [2023:04:28 11:12:35][pid:216,cpu6,kworker/u16:2,9]AFTER: REG_RCR differs from regrcr: 0x7000604e insted of 0x7000604e
[  181.610473] [pid:1994,cpu7,wpa_supplicant,4]AFTER: REG_RCR differs from regrcr: 0x700060ce insted of 0x700060ce
[  182.904541] [pid:7,cpu7,kworker/u16:0,6]AFTER: REG_RCR differs from regrcr: 0x7000604e insted of 0x7000604e
[  188.618011] [2023:04:28 11:12:47][pid:1994,cpu7,wpa_supplicant,3]AFTER: REG_RCR differs from regrcr: 0x700060ce insted of 0x700060ce
[  189.923339] [2023:04:28 11:12:48][pid:7,cpu7,kworker/u16:0,4]AFTER: REG_RCR differs from regrcr: 0x7000604e insted of 0x7000604e
[  192.706268] [pid:1994,cpu6,wpa_supplicant,8]AFTER: REG_RCR differs from regrcr: 0x700060ce insted of 0x700060ce
[  194.026855] [pid:7,cpu6,kworker/u16:0,1]AFTER: REG_RCR differs from regrcr: 0x7000604e insted of 0x7000604e
[  196.727020] [pid:1994,cpu6,wpa_supplicant,8]AFTER: REG_RCR differs from regrcr: 0x700060ce insted of 0x700060ce
[  196.753326] [pid:216,cpu7,kworker/u16:2,9]AFTER: REG_RCR differs from regrcr: 0x7000604e insted of 0x7000604e
[  203.798675] [pid:1994,cpu7,wpa_supplicant,4]AFTER: REG_RCR differs from regrcr: 0x700060ce insted of 0x700060ce
[  205.088653] [2023:04:28 11:13:03][pid:216,cpu6,kworker/u16:2,5]AFTER: REG_RCR differs from regrcr: 0x7000604e insted of 0x7000604e
[  214.879211] [pid:1994,cpu7,wpa_supplicant,7]AFTER: REG_RCR differs from regrcr: 0x700060ce insted of 0x700060ce
[  216.193817] [2023:04:28 11:13:14][pid:216,cpu7,kworker/u16:2,8]AFTER: REG_RCR differs from regrcr: 0x7000604e insted of 0x7000604e
[  221.726043] [pid:1994,cpu6,wpa_supplicant,2]AFTER: REG_RCR differs from regrcr: 0x700060ce insted of 0x700060ce
[  223.019012] [pid:95,cpu6,kworker/u16:1,4]AFTER: REG_RCR differs from regrcr: 0x7000604e insted of 0x7000604e
[  225.984741] [pid:1994,cpu7,wpa_supplicant,2]AFTER: REG_RCR differs from regrcr: 0x700060ce insted of 0x700060ce
[  227.272735] [pid:95,cpu6,kworker/u16:1,4]AFTER: REG_RCR differs from regrcr: 0x7000604e insted of 0x7000604e
[  233.242523] [2023:04:28 11:13:31][pid:1994,cpu7,wpa_supplicant,6]AFTER: REG_RCR differs from regrcr: 0x700060ce insted of 0x700060ce
[  234.541503] [pid:237,cpu7,kworker/u16:5,9]AFTER: REG_RCR differs from regrcr: 0x7000604e insted of 0x7000604e
[  237.070556] [pid:1994,cpu6,wpa_supplicant,7]AFTER: REG_RCR differs from regrcr: 0x700060ce insted of 0x700060ce
[  238.388366] [2023:04:28 11:13:36][pid:237,cpu4,kworker/u16:5,8]AFTER: REG_RCR differs from regrcr: 0x7000604e insted of 0x7000604e
[  246.725952] [pid:1994,cpu7,wpa_supplicant,3]AFTER: REG_RCR differs from regrcr: 0x700060ce insted of 0x700060ce
[  247.046478] [pid:216,cpu6,kworker/u16:2,4]BEFORE: REG_RCR differs from regrcr: 0x7000604e insted of 0x7000604e
[  247.079742] [pid:76395,cpu6,ifconfig,5]AFTER: REG_RCR differs from regrcr: 0x7000604e insted of 0x7000604e
[  248.217987] [pid:1994,cpu6,wpa_supplicant,9]AFTER: REG_RCR differs from regrcr: 0x700060ce insted of 0x700060ce
[  249.530578] [2023:04:28 11:13:48][pid:237,cpu6,kworker/u16:5,1]AFTER: REG_RCR differs from regrcr: 0x7000604e insted of 0x7000604e
[  249.533721] [pid:1994,cpu7,wpa_supplicant,2]AFTER: REG_RCR differs from regrcr: 0x700060ce insted of 0x700060ce
[  249.579711] [pid:237,cpu6,kworker/u16:5,5]BEFORE: REG_RCR differs from regrcr: 0x1832e13 insted of 0x7000604e
[  249.582946] [pid:1994,cpu7,wpa_supplicant,6]AFTER: REG_RCR differs from regrcr: 0x7000604e insted of 0x7000604e
[  259.287170] [pid:1994,cpu7,wpa_supplicant,7]AFTER: REG_RCR differs from regrcr: 0x700060ce insted of 0x700060ce
[  260.566009] [pid:237,cpu6,kworker/u16:5,9]AFTER: REG_RCR differs from regrcr: 0x7000604e insted of 0x7000604e
[  270.383453] [pid:1994,cpu6,wpa_supplicant,0]AFTER: REG_RCR differs from regrcr: 0x700060ce insted of 0x700060ce
[  271.678924] [2023:04:28 11:14:10][pid:7,cpu6,kworker/u16:0,1]AFTER: REG_RCR differs from regrcr: 0x7000604e insted of 0x7000604e
[  281.472015] [pid:1994,cpu6,wpa_supplicant,3]AFTER: REG_RCR differs from regrcr: 0x700060ce insted of 0x700060ce
[  282.743103] [pid:237,cpu7,kworker/u16:5,5]AFTER: REG_RCR differs from regrcr: 0x7000604e insted of 0x7000604e
[  283.654632] [2023:04:28 11:14:22][pid:1994,cpu7,wpa_supplicant,6]AFTER: REG_RCR differs from regrcr: 0x700060ce insted of 0x700060ce
[  284.942474] [pid:217,cpu6,kworker/u16:3,8]AFTER: REG_RCR differs from regrcr: 0x7000604e insted of 0x7000604e
[  292.564056] [pid:1994,cpu6,wpa_supplicant,8]AFTER: REG_RCR differs from regrcr: 0x700060ce insted of 0x700060ce
[  293.845397] [2023:04:28 11:14:32][pid:217,cpu7,kworker/u16:3,9]AFTER: REG_RCR differs from regrcr: 0x7000604e insted of 0x7000604e
[  299.727813] [pid:1994,cpu6,wpa_supplicant,3]AFTER: REG_RCR differs from regrcr: 0x700060ce insted of 0x700060ce
[  301.002807] [pid:217,cpu7,kworker/u16:3,6]AFTER: REG_RCR differs from regrcr: 0x7000604e insted of 0x7000604e
[  303.659973] [pid:1994,cpu6,wpa_supplicant,3]AFTER: REG_RCR differs from regrcr: 0x700060ce insted of 0x700060ce
[  304.962829] [2023:04:28 11:14:43][pid:237,cpu7,kworker/u16:5,5]AFTER: REG_RCR differs from regrcr: 0x7000604e insted of 0x7000604e
[  305.818237] [pid:1994,cpu7,wpa_supplicant,6]AFTER: REG_RCR differs from regrcr: 0x700060ce insted of 0x700060ce
[  307.107818] [pid:216,cpu7,kworker/u16:2,8]AFTER: REG_RCR differs from regrcr: 0x7000604e insted of 0x7000604e
[  314.760284] [pid:1994,cpu6,wpa_supplicant,8]AFTER: REG_RCR differs from regrcr: 0x700060ce insted of 0x700060ce
[  316.032379] [2023:04:28 11:14:54][pid:95,cpu7,kworker/u16:1,9]AFTER: REG_RCR differs from regrcr: 0x7000604e insted of 0x7000604e
[  324.724700] [pid:1994,cpu6,wpa_supplicant,4]AFTER: REG_RCR differs from regrcr: 0x700060ce insted of 0x700060ce
[  324.757446] [pid:77352,cpu7,ifconfig,5]AFTER: REG_RCR differs from regrcr: 0x7000604e insted of 0x7000604e
[  325.891845] [pid:1994,cpu7,wpa_supplicant,0]AFTER: REG_RCR differs from regrcr: 0x700060ce insted of 0x700060ce
[  327.196166] [2023:04:28 11:15:05][pid:7,cpu7,kworker/u16:0,1]AFTER: REG_RCR differs from regrcr: 0x7000604e insted of 0x7000604e
[  327.199157] [pid:1994,cpu7,wpa_supplicant,2]AFTER: REG_RCR differs from regrcr: 0x700060ce insted of 0x700060ce
[  327.234588] [pid:7,cpu7,kworker/u16:0,5]BEFORE: REG_RCR differs from regrcr: 0x1830d33 insted of 0x7000604e
[  327.236968] [pid:1994,cpu7,wpa_supplicant,6]AFTER: REG_RCR differs from regrcr: 0x7000604e insted of 0x7000604e

The REG_RCR has been inexplicably modified to an different value, it is very strange on driver's perspective.

In fact, there is another driver rtl8192cu.ko (drivers/net/wireless/realtek/rtlwifi/), that can also match this device.
This driver also uses the saved value instead of reading from REG_RCR, when need to modify the REG_RCR.
And there will be no issue with authentication timeout, if using this rtl8192cu driver.

Thanks.

Yun Lu


^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re:Re: [PATCH] wifi: rtl8xxxu: fix authentication timeout due to incorrect RCR value
  2023-04-27 17:01 ` Bitterblue Smith
@ 2023-04-28  4:30   ` Yun Lu
  0 siblings, 0 replies; 16+ messages in thread
From: Yun Lu @ 2023-04-28  4:30 UTC (permalink / raw)
  To: Bitterblue Smith
  Cc: Jes.Sorensen, kvalo, davem, edumazet, kuba, pabeni,
	linux-wireless, netdev

At 2023-04-28 01:01:06, "Bitterblue Smith" <rtl8821cerfe2@gmail.com> wrote:
>On 27/04/2023 05:05, Yun Lu wrote:
>> From: Yun Lu <luyun@kylinos.cn>
>> 
>> When using rtl8192cu with rtl8xxxu driver to connect wifi, there is a
>> probability of failure, which shows "authentication with ... timed out".
>> Through debugging, it was found that the RCR register has been inexplicably
>> modified to an incorrect value, resulting in the nic not being able to
>> receive authenticated frames.
>> 
>> To fix this problem, add regrcr in rtl8xxxu_priv struct, and store
>> the RCR value every time the register is writen, and use it the next
>> time the register need to be modified.
>> 
>
>Can this bug be reproduced easily? Is it always the same bits which
>are mysteriously cleared from REG_RCR?

On the device(EDIMAX EW-7822UAn) we used, it can be reproduced easily.
And the changed bits is not always the same, as the log shows in my reply
to Larry.
It seems that the nic will modify the value of this register itself? I guess it.

Thanks.

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [PATCH] wifi: rtl8xxxu: fix authentication timeout due to incorrect RCR value
  2023-04-28  4:25   ` wo
@ 2023-04-28  8:25     ` Kalle Valo
  2023-04-28 18:30       ` Larry Finger
  0 siblings, 1 reply; 16+ messages in thread
From: Kalle Valo @ 2023-04-28  8:25 UTC (permalink / raw)
  To: wo
  Cc: Larry Finger, Jes.Sorensen, davem, edumazet, kuba, pabeni,
	linux-wireless, netdev, Ping-Ke Shih

wo  <luyun_611@163.com> writes:

> In fact, there is another driver rtl8192cu.ko
> (drivers/net/wireless/realtek/rtlwifi/), that can also match this
> device.

It's not good if there are two drivers supporting same hardware. Should
the support be removed from rtlwifi?

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

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

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [PATCH] wifi: rtl8xxxu: fix authentication timeout due to incorrect RCR value
       [not found]   ` <76a784b2.2cb3.187c60f0f68.Coremail.luyun_611@163.com>
@ 2023-04-28 17:06     ` Larry Finger
  2023-04-29  3:35       ` Yun Lu
  0 siblings, 1 reply; 16+ messages in thread
From: Larry Finger @ 2023-04-28 17:06 UTC (permalink / raw)
  To: wo
  Cc: Jes.Sorensen, kvalo, davem, edumazet, kuba, pabeni,
	linux-wireless, netdev

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

On 4/27/23 23:11, wo wrote:
> [  149.595642] [pid:7,cpu6,kworker/u16:0,0]BEFORE: REG_RCR differs from regrcr: 
> 0x1830613 insted of 0x7000604e
> [  160.676422] [pid:237,cpu6,kworker/u16:5,3]BEFORE: REG_RCR differs from 
> regrcr: 0x70006009 insted of 0x700060ce
 > [  327.234588] [pid:7,cpu7,kworker/u16:0,5]BEFORE: REG_RCR differs from 
regrcr: 0x1830d33 insted of 0x7000604e


My patch was messed up, but it got the information that I wanted, which is shown 
in the quoted lines above. One of these differs only in the low-order byte, 
while the other 2 are completely different. Strange!

It is possible that there is a firmware error. My system, which does not show 
the problem, reports the following:

[54130.741148] usb 3-6: RTL8192CU rev A (TSMC) romver 0, 2T2R, TX queues 2, 
WiFi=1, BT=0, GPS=0, HI PA=0
[54130.741153] usb 3-6: RTL8192CU MAC: xx:xx:xx:xx:xx:xx
[54130.741155] usb 3-6: rtl8xxxu: Loading firmware rtlwifi/rtl8192cufw_TMSC.bin
[54130.742301] usb 3-6: Firmware revision 88.2 (signature 0x88c1)

Which firmware does your unit use?

Attached is a new test patch. When it logs a CORRUPTED value, I would like to 
know what task is attached to the pid listed in the message. Note that the two 
instances where the entire word was wrong came from pid:7.

Could improper locking could produce these results?

Larry

[-- Attachment #2: log_data_2.patch --]
[-- Type: text/x-patch, Size: 1422 bytes --]

diff --git a/Makefile b/Makefile
index f5543eef4f82..6d985a175d78 100644
--- a/Makefile
+++ b/Makefile
@@ -1,8 +1,8 @@
 # SPDX-License-Identifier: GPL-2.0
 VERSION = 6
-PATCHLEVEL = 3
+PATCHLEVEL = 4
 SUBLEVEL = 0
-EXTRAVERSION =
+EXTRAVERSION = -rc0
 NAME = Hurr durr I'ma ninja sloth
 
 # *DOCUMENTATION*
diff --git a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
index 831639d73657..9d778400d2b9 100644
--- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
+++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
@@ -4864,6 +4864,10 @@ rtl8xxxu_bss_info_changed(struct ieee80211_hw *hw, struct ieee80211_vif *vif,
 	u32 val32;
 	u8 val8;
 
+	if (priv->regrcr != rtl8xxxu_read32(priv, REG_RCR)) {
+		pr_info("REG_RCR corrupted in %s: 0x%x insted of 0x%x\n",
+			__func__, rtl8xxxu_read32(priv, REG_RCR), priv->regrcr);
+	}
 	rarpt = &priv->ra_report;
 
 	if (changed & BSS_CHANGED_ASSOC) {
@@ -6504,6 +6508,10 @@ static void rtl8xxxu_configure_filter(struct ieee80211_hw *hw,
 	struct rtl8xxxu_priv *priv = hw->priv;
 	u32 rcr = priv->regrcr;
 
+	if (priv->regrcr != rtl8xxxu_read32(priv, REG_RCR)) {
+		pr_info("REG_RCR corrupted in %s: 0x%x insted of 0x%x\n",
+			__func__, rtl8xxxu_read32(priv, REG_RCR), priv->regrcr);
+	}
 	dev_dbg(&priv->udev->dev, "%s: changed_flags %08x, total_flags %08x\n",
 		__func__, changed_flags, *total_flags);
 

^ permalink raw reply related	[flat|nested] 16+ messages in thread

* Re: [PATCH] wifi: rtl8xxxu: fix authentication timeout due to incorrect RCR value
  2023-04-28  8:25     ` Kalle Valo
@ 2023-04-28 18:30       ` Larry Finger
  2023-04-29  5:16         ` Kalle Valo
  0 siblings, 1 reply; 16+ messages in thread
From: Larry Finger @ 2023-04-28 18:30 UTC (permalink / raw)
  To: Kalle Valo, wo
  Cc: Jes.Sorensen, davem, edumazet, kuba, pabeni, linux-wireless,
	netdev, Ping-Ke Shih

On 4/28/23 03:25, Kalle Valo wrote:
> wo  <luyun_611@163.com> writes:
> 
>> In fact, there is another driver rtl8192cu.ko
>> (drivers/net/wireless/realtek/rtlwifi/), that can also match this
>> device.
> 
> It's not good if there are two drivers supporting same hardware. Should
> the support be removed from rtlwifi?

Kalle,

I have just sent a patch removing rtl8192cu.

Larry



^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re:Re: [PATCH] wifi: rtl8xxxu: fix authentication timeout due to incorrect RCR value
  2023-04-28 17:06     ` Larry Finger
@ 2023-04-29  3:35       ` Yun Lu
  2023-04-30 10:36         ` Bitterblue Smith
  0 siblings, 1 reply; 16+ messages in thread
From: Yun Lu @ 2023-04-29  3:35 UTC (permalink / raw)
  To: Larry Finger
  Cc: Jes.Sorensen, kvalo, davem, edumazet, kuba, pabeni,
	linux-wireless, netdev

At 2023-04-29 01:06:03, "Larry Finger" <Larry.Finger@lwfinger.net> wrote:
>On 4/27/23 23:11, wo wrote:
>> [  149.595642] [pid:7,cpu6,kworker/u16:0,0]BEFORE: REG_RCR differs from regrcr: 
>> 0x1830613 insted of 0x7000604e
>> [  160.676422] [pid:237,cpu6,kworker/u16:5,3]BEFORE: REG_RCR differs from 
>> regrcr: 0x70006009 insted of 0x700060ce
> > [  327.234588] [pid:7,cpu7,kworker/u16:0,5]BEFORE: REG_RCR differs from 
>regrcr: 0x1830d33 insted of 0x7000604e
>
>
>My patch was messed up, but it got the information that I wanted, which is shown 
>in the quoted lines above. One of these differs only in the low-order byte, 
>while the other 2 are completely different. Strange!
>
>It is possible that there is a firmware error. My system, which does not show 
>the problem, reports the following:
>
>[54130.741148] usb 3-6: RTL8192CU rev A (TSMC) romver 0, 2T2R, TX queues 2, 
>WiFi=1, BT=0, GPS=0, HI PA=0
>[54130.741153] usb 3-6: RTL8192CU MAC: xx:xx:xx:xx:xx:xx
>[54130.741155] usb 3-6: rtl8xxxu: Loading firmware rtlwifi/rtl8192cufw_TMSC.bin
>[54130.742301] usb 3-6: Firmware revision 88.2 (signature 0x88c1)
>
>Which firmware does your unit use?

The firmware verion we used is 80.0 (signature 0x88c1)
 [  903.873107] [pid:14,cpu0,kworker/0:1,2]usb 1-1.2: RTL8192CU rev A (TSMC) 2T2R, TX queues 2, WiFi=1, BT=0, GPS=0, HI PA=0
[  903.873138] [pid:14,cpu0,kworker/0:1,3]usb 1-1.2: RTL8192CU MAC: 08:be:xx:xx:xx:xx
[  903.873138] [pid:14,cpu0,kworker/0:1,4]usb 1-1.2: rtl8xxxu: Loading firmware rtlwifi/rtl8192cufw_TMSC.bin
[  903.873474] [pid:14,cpu0,kworker/0:1,5]usb 1-1.2: Firmware revision 80.0 (signature 0x88c1)

>
>Attached is a new test patch. When it logs a CORRUPTED value, I would like to 
>know what task is attached to the pid listed in the message. Note that the two 
>instances where the entire word was wrong came from pid:7.
>
>Could improper locking could produce these results?
>
>Larry

Apply your new patch, then turn on/off the wireless network switch on the network control panel serverl loops.
The log shows:
[   85.384429] [pid:221,cpu6,kworker/u16:6,5]REG_RCR corrupted in rtl8xxxu_configure_filter: 0x70006009 insted of 0x700060ce
[  121.681976] [pid:216,cpu6,kworker/u16:3,0]REG_RCR corrupted in rtl8xxxu_configure_filter: 0x70006009 insted of 0x700060ce
[  144.416992] [pid:217,cpu6,kworker/u16:4,1]REG_RCR corrupted in rtl8xxxu_configure_filter: 0x70006009 insted of 0x700060ce

And if we up/down the interface serverl loops as follows:
ifconfig wlx08bexxxxxx down
sleep 1
ifconfig wlx08bexxxxxx up
sleep 10
The log shows:
[  282.112335] [2023:04:29 10:30:34][pid:95,cpu6,kworker/u16:1,3]REG_RCR corrupted in rtl8xxxu_configure_filter: 0x1832e13 insted of 0x7000604e
[  293.311462] [2023:04:29 10:30:45][pid:217,cpu7,kworker/u16:4,9]REG_RCR corrupted in rtl8xxxu_configure_filter: 0x1830e72 insted of 0x7000604e
[  304.435089] [2023:04:29 10:30:56][pid:217,cpu6,kworker/u16:4,9]REG_RCR corrupted in rtl8xxxu_configure_filter: 0x1830ed3 insted of 0x7000604e
[  315.532257] [2023:04:29 10:31:07][pid:95,cpu7,kworker/u16:1,8]REG_RCR corrupted in rtl8xxxu_configure_filter: 0x7000604e insted of 0x7000604e
[  324.114379] [2023:04:29 10:31:16][pid:221,cpu6,kworker/u16:6,7]REG_RCR corrupted in rtl8xxxu_configure_filter: 0x1832e14 insted of 0x7000604e

We also update the  firmware verion to 88.2, and the test results are the same as above.

Thank you for helping debug this issue, which seems to be related to specific devices.

Yun Lu





^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [PATCH] wifi: rtl8xxxu: fix authentication timeout due to incorrect RCR value
  2023-04-28 18:30       ` Larry Finger
@ 2023-04-29  5:16         ` Kalle Valo
  0 siblings, 0 replies; 16+ messages in thread
From: Kalle Valo @ 2023-04-29  5:16 UTC (permalink / raw)
  To: Larry Finger
  Cc: wo, Jes.Sorensen, davem, edumazet, kuba, pabeni, linux-wireless,
	netdev, Ping-Ke Shih

Larry Finger <Larry.Finger@lwfinger.net> writes:

> On 4/28/23 03:25, Kalle Valo wrote:
>> wo  <luyun_611@163.com> writes:
>>
>>> In fact, there is another driver rtl8192cu.ko
>>> (drivers/net/wireless/realtek/rtlwifi/), that can also match this
>>> device.
>>
>> It's not good if there are two drivers supporting same hardware. Should
>> the support be removed from rtlwifi?
>
> Kalle,
>
> I have just sent a patch removing rtl8192cu.

Awesome, thanks Larry.

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

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

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [PATCH] wifi: rtl8xxxu: fix authentication timeout due to incorrect RCR value
  2023-04-29  3:35       ` Yun Lu
@ 2023-04-30 10:36         ` Bitterblue Smith
  2023-05-04  7:39           ` Yun Lu
  0 siblings, 1 reply; 16+ messages in thread
From: Bitterblue Smith @ 2023-04-30 10:36 UTC (permalink / raw)
  To: Yun Lu, Larry Finger
  Cc: Jes.Sorensen, kvalo, davem, edumazet, kuba, pabeni,
	linux-wireless, netdev

On 29/04/2023 06:35, Yun Lu wrote:
> At 2023-04-29 01:06:03, "Larry Finger" <Larry.Finger@lwfinger.net> wrote:
>> On 4/27/23 23:11, wo wrote:
>>> [  149.595642] [pid:7,cpu6,kworker/u16:0,0]BEFORE: REG_RCR differs from regrcr: 
>>> 0x1830613 insted of 0x7000604e
>>> [  160.676422] [pid:237,cpu6,kworker/u16:5,3]BEFORE: REG_RCR differs from 
>>> regrcr: 0x70006009 insted of 0x700060ce
>>> [  327.234588] [pid:7,cpu7,kworker/u16:0,5]BEFORE: REG_RCR differs from 
>> regrcr: 0x1830d33 insted of 0x7000604e
>>
>>
>> My patch was messed up, but it got the information that I wanted, which is shown 
>> in the quoted lines above. One of these differs only in the low-order byte, 
>> while the other 2 are completely different. Strange!
>>
>> It is possible that there is a firmware error. My system, which does not show 
>> the problem, reports the following:
>>
>> [54130.741148] usb 3-6: RTL8192CU rev A (TSMC) romver 0, 2T2R, TX queues 2, 
>> WiFi=1, BT=0, GPS=0, HI PA=0
>> [54130.741153] usb 3-6: RTL8192CU MAC: xx:xx:xx:xx:xx:xx
>> [54130.741155] usb 3-6: rtl8xxxu: Loading firmware rtlwifi/rtl8192cufw_TMSC.bin
>> [54130.742301] usb 3-6: Firmware revision 88.2 (signature 0x88c1)
>>
>> Which firmware does your unit use?
> 
> The firmware verion we used is 80.0 (signature 0x88c1)
>  [  903.873107] [pid:14,cpu0,kworker/0:1,2]usb 1-1.2: RTL8192CU rev A (TSMC) 2T2R, TX queues 2, WiFi=1, BT=0, GPS=0, HI PA=0
> [  903.873138] [pid:14,cpu0,kworker/0:1,3]usb 1-1.2: RTL8192CU MAC: 08:be:xx:xx:xx:xx
> [  903.873138] [pid:14,cpu0,kworker/0:1,4]usb 1-1.2: rtl8xxxu: Loading firmware rtlwifi/rtl8192cufw_TMSC.bin
> [  903.873474] [pid:14,cpu0,kworker/0:1,5]usb 1-1.2: Firmware revision 80.0 (signature 0x88c1)
> 
>>
>> Attached is a new test patch. When it logs a CORRUPTED value, I would like to 
>> know what task is attached to the pid listed in the message. Note that the two 
>> instances where the entire word was wrong came from pid:7.
>>
>> Could improper locking could produce these results?
>>
>> Larry
> 
> Apply your new patch, then turn on/off the wireless network switch on the network control panel serverl loops.
> The log shows:
> [   85.384429] [pid:221,cpu6,kworker/u16:6,5]REG_RCR corrupted in rtl8xxxu_configure_filter: 0x70006009 insted of 0x700060ce
> [  121.681976] [pid:216,cpu6,kworker/u16:3,0]REG_RCR corrupted in rtl8xxxu_configure_filter: 0x70006009 insted of 0x700060ce
> [  144.416992] [pid:217,cpu6,kworker/u16:4,1]REG_RCR corrupted in rtl8xxxu_configure_filter: 0x70006009 insted of 0x700060ce
> 
> And if we up/down the interface serverl loops as follows:
> ifconfig wlx08bexxxxxx down
> sleep 1
> ifconfig wlx08bexxxxxx up
> sleep 10
> The log shows:
> [  282.112335] [2023:04:29 10:30:34][pid:95,cpu6,kworker/u16:1,3]REG_RCR corrupted in rtl8xxxu_configure_filter: 0x1832e13 insted of 0x7000604e
> [  293.311462] [2023:04:29 10:30:45][pid:217,cpu7,kworker/u16:4,9]REG_RCR corrupted in rtl8xxxu_configure_filter: 0x1830e72 insted of 0x7000604e
> [  304.435089] [2023:04:29 10:30:56][pid:217,cpu6,kworker/u16:4,9]REG_RCR corrupted in rtl8xxxu_configure_filter: 0x1830ed3 insted of 0x7000604e
> [  315.532257] [2023:04:29 10:31:07][pid:95,cpu7,kworker/u16:1,8]REG_RCR corrupted in rtl8xxxu_configure_filter: 0x7000604e insted of 0x7000604e
> [  324.114379] [2023:04:29 10:31:16][pid:221,cpu6,kworker/u16:6,7]REG_RCR corrupted in rtl8xxxu_configure_filter: 0x1832e14 insted of 0x7000604e
> 
> We also update the  firmware verion to 88.2, and the test results are the same as above.
> 
> Thank you for helping debug this issue, which seems to be related to specific devices.
> 
> Yun Lu
> 
> 
> 
> 
There was this bug report about phantom MAC addresses with
the RTL8188CUS:
https://lore.kernel.org/linux-wireless/a31d9500-73a3-f890-bebd-d0a4014f87da@reto-schneider.ch/

See the pcap file. I wonder if it's related?

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [PATCH] wifi: rtl8xxxu: fix authentication timeout due to incorrect RCR value
  2023-04-30 10:36         ` Bitterblue Smith
@ 2023-05-04  7:39           ` Yun Lu
  2023-05-11  2:29             ` Yun Lu
  0 siblings, 1 reply; 16+ messages in thread
From: Yun Lu @ 2023-05-04  7:39 UTC (permalink / raw)
  To: Bitterblue Smith
  Cc: Larry Finger, Jes.Sorensen, kvalo, davem, edumazet, kuba, pabeni,
	linux-wireless, netdev


在 2023-04-30 18:36:50,"Bitterblue Smith" <rtl8821cerfe2@gmail.com> 写道:
>On 29/04/2023 06:35, Yun Lu wrote:
>> At 2023-04-29 01:06:03, "Larry Finger" <Larry.Finger@lwfinger.net> wrote:
>>> On 4/27/23 23:11, wo wrote:
>>>> [  149.595642] [pid:7,cpu6,kworker/u16:0,0]BEFORE: REG_RCR differs from regrcr: 
>>>> 0x1830613 insted of 0x7000604e
>>>> [  160.676422] [pid:237,cpu6,kworker/u16:5,3]BEFORE: REG_RCR differs from 
>>>> regrcr: 0x70006009 insted of 0x700060ce
>>>> [  327.234588] [pid:7,cpu7,kworker/u16:0,5]BEFORE: REG_RCR differs from 
>>> regrcr: 0x1830d33 insted of 0x7000604e
>>>
>>>
>>> My patch was messed up, but it got the information that I wanted, which is shown 
>>> in the quoted lines above. One of these differs only in the low-order byte, 
>>> while the other 2 are completely different. Strange!
>>>
>>> It is possible that there is a firmware error. My system, which does not show 
>>> the problem, reports the following:
>>>
>>> [54130.741148] usb 3-6: RTL8192CU rev A (TSMC) romver 0, 2T2R, TX queues 2, 
>>> WiFi=1, BT=0, GPS=0, HI PA=0
>>> [54130.741153] usb 3-6: RTL8192CU MAC: xx:xx:xx:xx:xx:xx
>>> [54130.741155] usb 3-6: rtl8xxxu: Loading firmware rtlwifi/rtl8192cufw_TMSC.bin
>>> [54130.742301] usb 3-6: Firmware revision 88.2 (signature 0x88c1)
>>>
>>> Which firmware does your unit use?
>> 
>> The firmware verion we used is 80.0 (signature 0x88c1)
>>  [  903.873107] [pid:14,cpu0,kworker/0:1,2]usb 1-1.2: RTL8192CU rev A (TSMC) 2T2R, TX queues 2, WiFi=1, BT=0, GPS=0, HI PA=0
>> [  903.873138] [pid:14,cpu0,kworker/0:1,3]usb 1-1.2: RTL8192CU MAC: 08:be:xx:xx:xx:xx
>> [  903.873138] [pid:14,cpu0,kworker/0:1,4]usb 1-1.2: rtl8xxxu: Loading firmware rtlwifi/rtl8192cufw_TMSC.bin
>> [  903.873474] [pid:14,cpu0,kworker/0:1,5]usb 1-1.2: Firmware revision 80.0 (signature 0x88c1)
>> 
>>>
>>> Attached is a new test patch. When it logs a CORRUPTED value, I would like to 
>>> know what task is attached to the pid listed in the message. Note that the two 
>>> instances where the entire word was wrong came from pid:7.
>>>
>>> Could improper locking could produce these results?
>>>
>>> Larry
>> 
>> Apply your new patch, then turn on/off the wireless network switch on the network control panel serverl loops.
>> The log shows:
>> [   85.384429] [pid:221,cpu6,kworker/u16:6,5]REG_RCR corrupted in rtl8xxxu_configure_filter: 0x70006009 insted of 0x700060ce
>> [  121.681976] [pid:216,cpu6,kworker/u16:3,0]REG_RCR corrupted in rtl8xxxu_configure_filter: 0x70006009 insted of 0x700060ce
>> [  144.416992] [pid:217,cpu6,kworker/u16:4,1]REG_RCR corrupted in rtl8xxxu_configure_filter: 0x70006009 insted of 0x700060ce
>> 
>> And if we up/down the interface serverl loops as follows:
>> ifconfig wlx08bexxxxxx down
>> sleep 1
>> ifconfig wlx08bexxxxxx up
>> sleep 10
>> The log shows:
>> [  282.112335] [2023:04:29 10:30:34][pid:95,cpu6,kworker/u16:1,3]REG_RCR corrupted in rtl8xxxu_configure_filter: 0x1832e13 insted of 0x7000604e
>> [  293.311462] [2023:04:29 10:30:45][pid:217,cpu7,kworker/u16:4,9]REG_RCR corrupted in rtl8xxxu_configure_filter: 0x1830e72 insted of 0x7000604e
>> [  304.435089] [2023:04:29 10:30:56][pid:217,cpu6,kworker/u16:4,9]REG_RCR corrupted in rtl8xxxu_configure_filter: 0x1830ed3 insted of 0x7000604e
>> [  315.532257] [2023:04:29 10:31:07][pid:95,cpu7,kworker/u16:1,8]REG_RCR corrupted in rtl8xxxu_configure_filter: 0x7000604e insted of 0x7000604e
>> [  324.114379] [2023:04:29 10:31:16][pid:221,cpu6,kworker/u16:6,7]REG_RCR corrupted in rtl8xxxu_configure_filter: 0x1832e14 insted of 0x7000604e
>> 
>> We also update the  firmware verion to 88.2, and the test results are the same as above.
>> 
>> Thank you for helping debug this issue, which seems to be related to specific devices.
>> 
>> Yun Lu
>> 
>> 
>> 
>> 
>There was this bug report about phantom MAC addresses with
>the RTL8188CUS:
>https://lore.kernel.org/linux-wireless/a31d9500-73a3-f890-bebd-d0a4014f87da@reto-schneider.ch/
>
>See the pcap file. I wonder if it's related?

The bug in the link is a high retransmission rate during message transmission, but the problem we encountered is that
the nic cannot receive authentication frames, resulting in authentication timeout and inability to connect to WiFi. It seems
that these two issues are not related.

We also enabled monitor mode and found that the AP has replied to the authentication message, but the nic cannot receive
this reply message due to the incorrect RCR register value. Once the RCR register is modified to the correct value,
the authentication message can be received normally and the connection to WIFI can be normal.

Thanks.




^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [PATCH] wifi: rtl8xxxu: fix authentication timeout due to incorrect RCR value
  2023-05-04  7:39           ` Yun Lu
@ 2023-05-11  2:29             ` Yun Lu
  2023-05-11  2:45               ` Larry Finger
  2023-05-11 13:56               ` Bitterblue Smith
  0 siblings, 2 replies; 16+ messages in thread
From: Yun Lu @ 2023-05-11  2:29 UTC (permalink / raw)
  To: Bitterblue Smith, Larry Finger
  Cc: Jes.Sorensen, kvalo, davem, edumazet, kuba, pabeni,
	linux-wireless, netdev

Larry  and  Bitterblue:

Thank you for your reply,  are there any further questions or suggestions on this issue?
Could this patch be merged? There seems to be no other side effects.



在 2023-05-04 15:39:57,"Yun Lu" <luyun_611@163.com> 写道:
>
>在 2023-04-30 18:36:50,"Bitterblue Smith" <rtl8821cerfe2@gmail.com> 写道:
>>On 29/04/2023 06:35, Yun Lu wrote:
>>> At 2023-04-29 01:06:03, "Larry Finger" <Larry.Finger@lwfinger.net> wrote:
>>>> On 4/27/23 23:11, wo wrote:
>>>>> [  149.595642] [pid:7,cpu6,kworker/u16:0,0]BEFORE: REG_RCR differs from regrcr: 
>>>>> 0x1830613 insted of 0x7000604e
>>>>> [  160.676422] [pid:237,cpu6,kworker/u16:5,3]BEFORE: REG_RCR differs from 
>>>>> regrcr: 0x70006009 insted of 0x700060ce
>>>>> [  327.234588] [pid:7,cpu7,kworker/u16:0,5]BEFORE: REG_RCR differs from 
>>>> regrcr: 0x1830d33 insted of 0x7000604e
>>>>
>>>>
>>>> My patch was messed up, but it got the information that I wanted, which is shown 
>>>> in the quoted lines above. One of these differs only in the low-order byte, 
>>>> while the other 2 are completely different. Strange!
>>>>
>>>> It is possible that there is a firmware error. My system, which does not show 
>>>> the problem, reports the following:
>>>>
>>>> [54130.741148] usb 3-6: RTL8192CU rev A (TSMC) romver 0, 2T2R, TX queues 2, 
>>>> WiFi=1, BT=0, GPS=0, HI PA=0
>>>> [54130.741153] usb 3-6: RTL8192CU MAC: xx:xx:xx:xx:xx:xx
>>>> [54130.741155] usb 3-6: rtl8xxxu: Loading firmware rtlwifi/rtl8192cufw_TMSC.bin
>>>> [54130.742301] usb 3-6: Firmware revision 88.2 (signature 0x88c1)
>>>>
>>>> Which firmware does your unit use?
>>> 
>>> The firmware verion we used is 80.0 (signature 0x88c1)
>>>  [  903.873107] [pid:14,cpu0,kworker/0:1,2]usb 1-1.2: RTL8192CU rev A (TSMC) 2T2R, TX queues 2, WiFi=1, BT=0, GPS=0, HI PA=0
>>> [  903.873138] [pid:14,cpu0,kworker/0:1,3]usb 1-1.2: RTL8192CU MAC: 08:be:xx:xx:xx:xx
>>> [  903.873138] [pid:14,cpu0,kworker/0:1,4]usb 1-1.2: rtl8xxxu: Loading firmware rtlwifi/rtl8192cufw_TMSC.bin
>>> [  903.873474] [pid:14,cpu0,kworker/0:1,5]usb 1-1.2: Firmware revision 80.0 (signature 0x88c1)
>>> 
>>>>
>>>> Attached is a new test patch. When it logs a CORRUPTED value, I would like to 
>>>> know what task is attached to the pid listed in the message. Note that the two 
>>>> instances where the entire word was wrong came from pid:7.
>>>>
>>>> Could improper locking could produce these results?
>>>>
>>>> Larry
>>> 
>>> Apply your new patch, then turn on/off the wireless network switch on the network control panel serverl loops.
>>> The log shows:
>>> [   85.384429] [pid:221,cpu6,kworker/u16:6,5]REG_RCR corrupted in rtl8xxxu_configure_filter: 0x70006009 insted of 0x700060ce
>>> [  121.681976] [pid:216,cpu6,kworker/u16:3,0]REG_RCR corrupted in rtl8xxxu_configure_filter: 0x70006009 insted of 0x700060ce
>>> [  144.416992] [pid:217,cpu6,kworker/u16:4,1]REG_RCR corrupted in rtl8xxxu_configure_filter: 0x70006009 insted of 0x700060ce
>>> 
>>> And if we up/down the interface serverl loops as follows:
>>> ifconfig wlx08bexxxxxx down
>>> sleep 1
>>> ifconfig wlx08bexxxxxx up
>>> sleep 10
>>> The log shows:
>>> [  282.112335] [2023:04:29 10:30:34][pid:95,cpu6,kworker/u16:1,3]REG_RCR corrupted in rtl8xxxu_configure_filter: 0x1832e13 insted of 0x7000604e
>>> [  293.311462] [2023:04:29 10:30:45][pid:217,cpu7,kworker/u16:4,9]REG_RCR corrupted in rtl8xxxu_configure_filter: 0x1830e72 insted of 0x7000604e
>>> [  304.435089] [2023:04:29 10:30:56][pid:217,cpu6,kworker/u16:4,9]REG_RCR corrupted in rtl8xxxu_configure_filter: 0x1830ed3 insted of 0x7000604e
>>> [  315.532257] [2023:04:29 10:31:07][pid:95,cpu7,kworker/u16:1,8]REG_RCR corrupted in rtl8xxxu_configure_filter: 0x7000604e insted of 0x7000604e
>>> [  324.114379] [2023:04:29 10:31:16][pid:221,cpu6,kworker/u16:6,7]REG_RCR corrupted in rtl8xxxu_configure_filter: 0x1832e14 insted of 0x7000604e
>>> 
>>> We also update the  firmware verion to 88.2, and the test results are the same as above.
>>> 
>>> Thank you for helping debug this issue, which seems to be related to specific devices.
>>> 
>>> Yun Lu
>>> 
>>> 
>>> 
>>> 
>>There was this bug report about phantom MAC addresses with
>>the RTL8188CUS:
>>https://lore.kernel.org/linux-wireless/a31d9500-73a3-f890-bebd-d0a4014f87da@reto-schneider.ch/
>>
>>See the pcap file. I wonder if it's related?
>
>The bug in the link is a high retransmission rate during message transmission, but the problem we encountered is that
>the nic cannot receive authentication frames, resulting in authentication timeout and inability to connect to WiFi. It seems
>that these two issues are not related.
>
>We also enabled monitor mode and found that the AP has replied to the authentication message, but the nic cannot receive
>this reply message due to the incorrect RCR register value. Once the RCR register is modified to the correct value,
>the authentication message can be received normally and the connection to WIFI can be normal.
>
>Thanks.
>
>
>

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [PATCH] wifi: rtl8xxxu: fix authentication timeout due to incorrect RCR value
  2023-05-11  2:29             ` Yun Lu
@ 2023-05-11  2:45               ` Larry Finger
  2023-05-11 13:56               ` Bitterblue Smith
  1 sibling, 0 replies; 16+ messages in thread
From: Larry Finger @ 2023-05-11  2:45 UTC (permalink / raw)
  To: Yun Lu, Bitterblue Smith
  Cc: Jes.Sorensen, kvalo, davem, edumazet, kuba, pabeni,
	linux-wireless, netdev

On 5/10/23 21:29, Yun Lu wrote:
> Larry  and  Bitterblue:
> 
> Thank you for your reply,  are there any further questions or suggestions on this issue?
> Could this patch be merged? There seems to be no other side effects.
> 
> 
> 
> 在 2023-05-04 15:39:57,"Yun Lu" <luyun_611@163.com> 写道:
>>
>> 在 2023-04-30 18:36:50,"Bitterblue Smith" <rtl8821cerfe2@gmail.com> 写道:
>>> On 29/04/2023 06:35, Yun Lu wrote:
>>>> At 2023-04-29 01:06:03, "Larry Finger" <Larry.Finger@lwfinger.net> wrote:
>>>>> On 4/27/23 23:11, wo wrote:
>>>>>> [  149.595642] [pid:7,cpu6,kworker/u16:0,0]BEFORE: REG_RCR differs from regrcr:
>>>>>> 0x1830613 insted of 0x7000604e
>>>>>> [  160.676422] [pid:237,cpu6,kworker/u16:5,3]BEFORE: REG_RCR differs from
>>>>>> regrcr: 0x70006009 insted of 0x700060ce
>>>>>> [  327.234588] [pid:7,cpu7,kworker/u16:0,5]BEFORE: REG_RCR differs from
>>>>> regrcr: 0x1830d33 insted of 0x7000604e
>>>>>
>>>>>
>>>>> My patch was messed up, but it got the information that I wanted, which is shown
>>>>> in the quoted lines above. One of these differs only in the low-order byte,
>>>>> while the other 2 are completely different. Strange!
>>>>>
>>>>> It is possible that there is a firmware error. My system, which does not show
>>>>> the problem, reports the following:
>>>>>
>>>>> [54130.741148] usb 3-6: RTL8192CU rev A (TSMC) romver 0, 2T2R, TX queues 2,
>>>>> WiFi=1, BT=0, GPS=0, HI PA=0
>>>>> [54130.741153] usb 3-6: RTL8192CU MAC: xx:xx:xx:xx:xx:xx
>>>>> [54130.741155] usb 3-6: rtl8xxxu: Loading firmware rtlwifi/rtl8192cufw_TMSC.bin
>>>>> [54130.742301] usb 3-6: Firmware revision 88.2 (signature 0x88c1)
>>>>>
>>>>> Which firmware does your unit use?
>>>>
>>>> The firmware verion we used is 80.0 (signature 0x88c1)
>>>>   [  903.873107] [pid:14,cpu0,kworker/0:1,2]usb 1-1.2: RTL8192CU rev A (TSMC) 2T2R, TX queues 2, WiFi=1, BT=0, GPS=0, HI PA=0
>>>> [  903.873138] [pid:14,cpu0,kworker/0:1,3]usb 1-1.2: RTL8192CU MAC: 08:be:xx:xx:xx:xx
>>>> [  903.873138] [pid:14,cpu0,kworker/0:1,4]usb 1-1.2: rtl8xxxu: Loading firmware rtlwifi/rtl8192cufw_TMSC.bin
>>>> [  903.873474] [pid:14,cpu0,kworker/0:1,5]usb 1-1.2: Firmware revision 80.0 (signature 0x88c1)
>>>>
>>>>>
>>>>> Attached is a new test patch. When it logs a CORRUPTED value, I would like to
>>>>> know what task is attached to the pid listed in the message. Note that the two
>>>>> instances where the entire word was wrong came from pid:7.
>>>>>
>>>>> Could improper locking could produce these results?
>>>>>
>>>>> Larry
>>>>
>>>> Apply your new patch, then turn on/off the wireless network switch on the network control panel serverl loops.
>>>> The log shows:
>>>> [   85.384429] [pid:221,cpu6,kworker/u16:6,5]REG_RCR corrupted in rtl8xxxu_configure_filter: 0x70006009 insted of 0x700060ce
>>>> [  121.681976] [pid:216,cpu6,kworker/u16:3,0]REG_RCR corrupted in rtl8xxxu_configure_filter: 0x70006009 insted of 0x700060ce
>>>> [  144.416992] [pid:217,cpu6,kworker/u16:4,1]REG_RCR corrupted in rtl8xxxu_configure_filter: 0x70006009 insted of 0x700060ce
>>>>
>>>> And if we up/down the interface serverl loops as follows:
>>>> ifconfig wlx08bexxxxxx down
>>>> sleep 1
>>>> ifconfig wlx08bexxxxxx up
>>>> sleep 10
>>>> The log shows:
>>>> [  282.112335] [2023:04:29 10:30:34][pid:95,cpu6,kworker/u16:1,3]REG_RCR corrupted in rtl8xxxu_configure_filter: 0x1832e13 insted of 0x7000604e
>>>> [  293.311462] [2023:04:29 10:30:45][pid:217,cpu7,kworker/u16:4,9]REG_RCR corrupted in rtl8xxxu_configure_filter: 0x1830e72 insted of 0x7000604e
>>>> [  304.435089] [2023:04:29 10:30:56][pid:217,cpu6,kworker/u16:4,9]REG_RCR corrupted in rtl8xxxu_configure_filter: 0x1830ed3 insted of 0x7000604e
>>>> [  315.532257] [2023:04:29 10:31:07][pid:95,cpu7,kworker/u16:1,8]REG_RCR corrupted in rtl8xxxu_configure_filter: 0x7000604e insted of 0x7000604e
>>>> [  324.114379] [2023:04:29 10:31:16][pid:221,cpu6,kworker/u16:6,7]REG_RCR corrupted in rtl8xxxu_configure_filter: 0x1832e14 insted of 0x7000604e
>>>>
>>>> We also update the  firmware verion to 88.2, and the test results are the same as above.
>>>>
>>>> Thank you for helping debug this issue, which seems to be related to specific devices.
>>>>
>>>> Yun Lu
>>>>
>>>>
>>>>
>>>>
>>> There was this bug report about phantom MAC addresses with
>>> the RTL8188CUS:
>>> https://lore.kernel.org/linux-wireless/a31d9500-73a3-f890-bebd-d0a4014f87da@reto-schneider.ch/
>>>
>>> See the pcap file. I wonder if it's related?
>>
>> The bug in the link is a high retransmission rate during message transmission, but the problem we encountered is that
>> the nic cannot receive authentication frames, resulting in authentication timeout and inability to connect to WiFi. It seems
>> that these two issues are not related.
>>
>> We also enabled monitor mode and found that the AP has replied to the authentication message, but the nic cannot receive
>> this reply message due to the incorrect RCR register value. Once the RCR register is modified to the correct value,
>> the authentication message can be received normally and the connection to WIFI can be normal.

Yun Lu,

I have no objection to adding this patch. Although it looked a little ad-hoc at 
first, it seems to fix a hardware or firmware error for your device. It 
certainly does no harm other than taking up a bit of memory in the loaded driver.

Resubmit the patch with a new version number, and I will Ack it.

Larry


Larry



^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [PATCH] wifi: rtl8xxxu: fix authentication timeout due to incorrect RCR value
  2023-05-11  2:29             ` Yun Lu
  2023-05-11  2:45               ` Larry Finger
@ 2023-05-11 13:56               ` Bitterblue Smith
  1 sibling, 0 replies; 16+ messages in thread
From: Bitterblue Smith @ 2023-05-11 13:56 UTC (permalink / raw)
  To: Yun Lu, Larry Finger
  Cc: Jes.Sorensen, kvalo, davem, edumazet, kuba, pabeni,
	linux-wireless, netdev

On 11/05/2023 05:29, Yun Lu wrote:
> Larry  and  Bitterblue:
> 
> Thank you for your reply,  are there any further questions or suggestions on this issue?
> Could this patch be merged? There seems to be no other side effects.
> 

Your patch looks okay to me. I couldn't reproduce the bug and
I don't have any brilliant ideas, so that's it.

^ permalink raw reply	[flat|nested] 16+ messages in thread

end of thread, other threads:[~2023-05-11 13:56 UTC | newest]

Thread overview: 16+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2023-04-27  2:05 [PATCH] wifi: rtl8xxxu: fix authentication timeout due to incorrect RCR value Yun Lu
2023-04-27 17:01 ` Bitterblue Smith
2023-04-28  4:30   ` Yun Lu
2023-04-27 18:01 ` Larry Finger
2023-04-28  2:00 ` Larry Finger
2023-04-28  4:25   ` wo
2023-04-28  8:25     ` Kalle Valo
2023-04-28 18:30       ` Larry Finger
2023-04-29  5:16         ` Kalle Valo
     [not found]   ` <76a784b2.2cb3.187c60f0f68.Coremail.luyun_611@163.com>
2023-04-28 17:06     ` Larry Finger
2023-04-29  3:35       ` Yun Lu
2023-04-30 10:36         ` Bitterblue Smith
2023-05-04  7:39           ` Yun Lu
2023-05-11  2:29             ` Yun Lu
2023-05-11  2:45               ` Larry Finger
2023-05-11 13:56               ` Bitterblue Smith

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).