DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 836CE206B6
Subject: Re: Problems and suggestions to the kernel module r8723bs
To:     Simon Beginn <simonmicro@simonmicro.de>,
        Bastien Nocera <hadess@hadess.net>,
        Hans de Goede <hdegoede@redhat.com>
Cc:     linux-wireless <linux-wireless@vger.kernel.org>
References: <83c86a2a-0d2a-8119-2831-e9cfab7a43d7@simonmicro.de>
 <f0b67da4-747a-08e3-9744-fce2c74aaddc@lwfinger.net>
 <6e27de67-739f-ee17-eb5f-efb079d1f37f@simonmicro.de>
 <7a47d05c-2f3b-e4d5-ccf1-5c2106d3c93d@lwfinger.net>
 <3a0468ee-e391-3b03-bfc5-36df484bce9d@simonmicro.de>
 <9a7105c0-fd23-c7ff-3e28-62533c24cdb9@lwfinger.net>
 <374c0f3a-aa89-18c5-cd53-0c395ff02a6d@simonmicro.de>
From:   Larry Finger <Larry.Finger@lwfinger.net>
Message-ID: <72ffad3d-1cdf-f93b-cefc-4ee06872926d@lwfinger.net>
Date:   Fri, 28 Sep 2018 10:59:15 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101
 Thunderbird/60.0
MIME-Version: 1.0
In-Reply-To: <374c0f3a-aa89-18c5-cd53-0c395ff02a6d@simonmicro.de>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Sender: linux-wireless-owner@vger.kernel.org
Precedence: bulk

On 9/28/18 5:02 AM, Simon Beginn wrote:
>> That value means that the signal strength is way too low. One other 
>> possibility is that the chip has retained the setting and is not obeying the 
>> antenna number command. To check that, create a file (as root) named 
>> /etc/modprobe.d/50-r8723bs.conf, and add a single line containing "options 
>> r8723bs rtw_ant_num=2" (without the quotation marks). After that file is 
>> ready, then do a cold boot so that the chip has been power cycled. Finally, 
>> redo the signal test. Note: If your patch is applied, the above will not work! 
> I've applied my patch and got the following results (btw good idea with the cold 
> boot!):
> 
> ***FILE CREATED***
> options rtl8723bs rtw_ant_num=1
> 
> ***POWEROFF + 2 MINUTES WAITING***
> 
> ***REBOOT + COMMAND***
> sudo iw dev wlan0 scan | egrep "SSID|signal"
> -> Desk
>      signal: -93.00 dBm
>      SSID: Gonzales
>      signal: -63.00 dBm
>      SSID: Gonzales
>      signal: -63.00 dBm
>      SSID: Gonzales
>      signal: -50.00 dBm
>      SSID: TPC_Install
> -> Place A
>      signal: -93.00 dBm
>      SSID: Gonzales
>      signal: -45.00 dBm
>      SSID: Gonzales
>      signal: -62.00 dBm
>      SSID: Gonzales
>      signal: -64.00 dBm
>      SSID: TPC_Install
> 
> ***FILE MODIFIED***
> options rtl8723bs rtw_ant_num=2
> 
> ***POWEROFF + 2 MINUTES WAITING***
> 
> ***REBOOT + COMMAND***
> sudo iw dev wlan0 scan | egrep "SSID|signal"
> -> Desk
>      signal: -85.00 dBm
>      SSID: Gonzales
>      signal: -64.00 dBm
>      SSID: Gonzales
>      signal: -65.00 dBm
>      SSID: Gonzales
>      signal: -48.00 dBm
>      SSID: Gonzales
>      signal: -48.00 dBm
>      SSID: TPC_Install
> -> Place A
>      signal: -79.00 dBm
>      SSID: Gonzales
>      signal: -45.00 dBm
>      SSID: Gonzales
>      signal: -63.00 dBm
>      SSID: Gonzales
>      signal: -63.00 dBm
>      SSID: TPC_Install
> 
>> ccepted. Even if it had been correctly done, I would have NACKed it.
> Sry, would you reformulate this, please? I just can't understand/determine what 
> the word "NACKed" means in this situation (Neither google or the raw translation 
> helps me).
> 

I do not think that changing rtw_ant_num made any difference. In each location, 
both tests had one AP with a signal greater than -50, which should be strong 
enough. We do not know if the driver is roaming correctly. At each location, is 
that AP with the strongest signal actually the one that is selected? To see 
that, change the scan command to

sudo iw dev wlan0 scan | egrep "associated|SSID|signal"

Check the output to see if the AP with the strongest signal is preceded by a BSS 
line.

Sorry about using jargon that you could not run through a translator. As Bastien 
explained, NACK means to reject a patch. You accept a patch by providing an 
"ACKed-by: name <email address>" line. Thus NACK is the opposite.

Larry