lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <c21206d6-eb4b-2e7d-eb2e-cab9f3b06c62@lwfinger.net>
Date: Wed, 10 May 2023 21:45:37 -0500
From: Larry Finger <Larry.Finger@...inger.net>
To: Yun Lu <luyun_611@....com>, Bitterblue Smith <rtl8821cerfe2@...il.com>
Cc: Jes.Sorensen@...il.com, kvalo@...nel.org, davem@...emloft.net,
 edumazet@...gle.com, kuba@...nel.org, pabeni@...hat.com,
 linux-wireless@...r.kernel.org, netdev@...r.kernel.org
Subject: Re: [PATCH] wifi: rtl8xxxu: fix authentication timeout due to
 incorrect RCR value

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@....com> 写道:
>>
>> 在 2023-04-30 18:36:50,"Bitterblue Smith" <rtl8821cerfe2@...il.com> 写道:
>>> On 29/04/2023 06:35, Yun Lu wrote:
>>>> At 2023-04-29 01:06:03, "Larry Finger" <Larry.Finger@...inger.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



Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ