Make brcmfmac repeat authentication requests

Make brcmfmac repeat authentication requests

[Daniel Drake]

Hi,

We are working with the Weibu F3C MiniPC which includes BCM43455 SDIO
wifi chip 0x004345(17221) rev 0x000006

Testing Linux 4.15, this wifi adapter is unable to authenticate with
the MF928 MiFi Access Point which is common in Africa. The STA sends
the authentication request, which is ACKed by the AP, but then the
conversation ends there (a timeout later bubbles up to userspace).
Windows 10 with broadcom driver version 1.605.1.0 is also unable to
connect.

My laptop with ath10k can authenticate and connect fine. There the
conversation is:

1. STA sends authentication request
2. AP sends ACK
3. After 0.1s timeout, STA sends another auth request
4. AP sends ACK
5. AP sends authentication response
6. etc.

Also confirmed the same pattern on a couple of smartphones, where the
delay seems to be 0.3s before repeating the authentication request.

Clearly this AP is not behaving correctly; the authentication request
should not have to be repeated. However of all the devices to hand,
unfortunately only this broadcom device is unable to connect.

Is there a way to adjust the driver/firmware to repeat the
authentication requests when they are not responded to? This would
match the behaviour of other devices and work around this issue.

Thanks
Daniel

Re: Make brcmfmac repeat authentication requests

[Arend van Spriel]

On 2/12/2018 3:04 PM, Daniel Drake wrote:
> Hi,
>
> We are working with the Weibu F3C MiniPC which includes BCM43455 SDIO
> wifi chip 0x004345(17221) rev 0x000006
>
> Testing Linux 4.15, this wifi adapter is unable to authenticate with
> the MF928 MiFi Access Point which is common in Africa. The STA sends
> the authentication request, which is ACKed by the AP, but then the
> conversation ends there (a timeout later bubbles up to userspace).
> Windows 10 with broadcom driver version 1.605.1.0 is also unable to
> connect.

I tried to find info about that access point equipment, but not getting 
any hits apart from a olivetti laser printer, but I doubt it is that. 
Can you provide more details.

> My laptop with ath10k can authenticate and connect fine. There the
> conversation is:
>
> 1. STA sends authentication request
> 2. AP sends ACK
> 3. After 0.1s timeout, STA sends another auth request
> 4. AP sends ACK
> 5. AP sends authentication response
> 6. etc.
>
> Also confirmed the same pattern on a couple of smartphones, where the
> delay seems to be 0.3s before repeating the authentication request.
>
> Clearly this AP is not behaving correctly; the authentication request
> should not have to be repeated. However of all the devices to hand,
> unfortunately only this broadcom device is unable to connect.

User-space (wpa_supplicant) would retry the connect attempt so I guess 
you are saying that the timing between the two auth requests is important?

> Is there a way to adjust the driver/firmware to repeat the
> authentication requests when they are not responded to? This would
> match the behaviour of other devices and work around this issue.

Is firmware not repeating at all or is the time between the two auth 
requests too long?

Checking firmware there is a 300ms timeout and it does a retry if the 
limit is not reached. However, that limit is initialized to zero :-p

Could you try the patch below?

Regards,
Arend

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c 
b/drivers
index 19686ef..af1ab00 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c
@@ -384,6 +384,9 @@ int brcmf_c_preinit_dcmds(struct brcmf_if *ifp)
                 goto done;
         }

+       /* allow join retry by firmware */
+       (void)brcmf_fil_iovar_int_set(ifp, "assoc_retry_max", 1);
+
         /* Enable tx beamforming, errors can be ignored (not supported) */
         (void)brcmf_fil_iovar_int_set(ifp, "txbf", 1);



> Thanks
> Daniel
>

Re: Make brcmfmac repeat authentication requests

[Daniel Drake]

Hi,

Thanks for the fast response.

On Tue, Feb 13, 2018 at 12:50 PM, Arend van Spriel
<arend.vanspriel@broadcom.com> wrote:
> I tried to find info about that access point equipment, but not getting any
> hits apart from a olivetti laser printer, but I doubt it is that. Can you
> provide more details.

The device itself is basically unbranded (just says "4G LTE"). It's an
access point and mifi bridge (so insert a sim card and it shares your
mobile data connection on the LAN). It comes as part of a solar home
solutions package.

MF928 is listed as the product name behind the battery. In the web UI
it says it is from the EV910 product family, hardware version
LR521_V1.0. I can't find info online about it.

> User-space (wpa_supplicant) would retry the connect attempt so I guess you
> are saying that the timing between the two auth requests is important?

Yes, the error goes up to userspace which then retries. However around
15 seconds pass before the authentication request is sent again, and
also as part of the retry it redoes the probe requests etc. Windows
does the same but there is only a 3 second delay. I haven't checked if
this device needs the authentication request resent in less than 3
seconds, or if the problem is that it needs to be sent twice in
consecutive frames (i.e. without another probe request in the middle).

> Is firmware not repeating at all or is the time between the two auth
> requests too long?

Firmware is not repeating at all.

> Checking firmware there is a 300ms timeout and it does a retry if the limit
> is not reached. However, that limit is initialized to zero :-p
>
> Could you try the patch below?

Thanks for looking into the firmware! Unfortunately the change does
not appear to make any difference. As before, the auth request is
ACKed by the AP but then the conversation halts until userspace steps
in on timeout a few seconds later.

Daniel


> Regards,
> Arend
>
> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c
> b/drivers
> index 19686ef..af1ab00 100644
> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c
> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c
> @@ -384,6 +384,9 @@ int brcmf_c_preinit_dcmds(struct brcmf_if *ifp)
>                 goto done;
>         }
>
> +       /* allow join retry by firmware */
> +       (void)brcmf_fil_iovar_int_set(ifp, "assoc_retry_max", 1);
> +
>         /* Enable tx beamforming, errors can be ignored (not supported) */
>         (void)brcmf_fil_iovar_int_set(ifp, "txbf", 1);
>

Re: Make brcmfmac repeat authentication requests

[Arend van Spriel]

On 2/14/2018 2:03 PM, Daniel Drake wrote:
> Hi,
>
> Thanks for the fast response.
>
> On Tue, Feb 13, 2018 at 12:50 PM, Arend van Spriel
> <arend.vanspriel@broadcom.com> wrote:
>> I tried to find info about that access point equipment, but not getting any
>> hits apart from a olivetti laser printer, but I doubt it is that. Can you
>> provide more details.
>
> The device itself is basically unbranded (just says "4G LTE"). It's an
> access point and mifi bridge (so insert a sim card and it shares your
> mobile data connection on the LAN). It comes as part of a solar home
> solutions package.
>
> MF928 is listed as the product name behind the battery. In the web UI
> it says it is from the EV910 product family, hardware version
> LR521_V1.0. I can't find info online about it.

Probably it is from ZTE although I could not find the MF928 specifically.

>> User-space (wpa_supplicant) would retry the connect attempt so I guess you
>> are saying that the timing between the two auth requests is important?
>
> Yes, the error goes up to userspace which then retries. However around
> 15 seconds pass before the authentication request is sent again, and
> also as part of the retry it redoes the probe requests etc. Windows
> does the same but there is only a 3 second delay. I haven't checked if
> this device needs the authentication request resent in less than 3
> seconds, or if the problem is that it needs to be sent twice in
> consecutive frames (i.e. without another probe request in the middle).
>
>> Is firmware not repeating at all or is the time between the two auth
>> requests too long?
>
> Firmware is not repeating at all.
>
>> Checking firmware there is a 300ms timeout and it does a retry if the limit
>> is not reached. However, that limit is initialized to zero :-p
>>
>> Could you try the patch below?
>
> Thanks for looking into the firmware! Unfortunately the change does
> not appear to make any difference. As before, the auth request is
> ACKed by the AP but then the conversation halts until userspace steps
> in on timeout a few seconds later.

Ok. Could you create a log with driver debugging enabled, ie. build 
driver CONFIG_BRCMDBG=y and load with module param 'debug=0x1416'. The 
problem is probably when the firmware is configured.

Regards,
Arend

> Daniel
>
>
>> Regards,
>> Arend
>>
>> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c
>> b/drivers
>> index 19686ef..af1ab00 100644
>> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c
>> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c
>> @@ -384,6 +384,9 @@ int brcmf_c_preinit_dcmds(struct brcmf_if *ifp)
>>                  goto done;
>>          }
>>
>> +       /* allow join retry by firmware */
>> +       (void)brcmf_fil_iovar_int_set(ifp, "assoc_retry_max", 1);
>> +
>>          /* Enable tx beamforming, errors can be ignored (not supported) */
>>          (void)brcmf_fil_iovar_int_set(ifp, "txbf", 1);
>>

Re: Make brcmfmac repeat authentication requests

[Daniel Drake]

On Thu, Feb 15, 2018 at 3:46 PM, Arend van Spriel
<arend.vanspriel@broadcom.com> wrote:
> Ok. Could you create a log with driver debugging enabled, ie. build driver CONFIG_BRCMDBG=y and load with module param 'debug=0x1416'. The problem is probably when the firmware is configured.

Logs from driver load at boot:
https://gist.github.com/dsd/7f9a7e8b0f8e20794aaed6298b2cb96a

Logs from interface up:
https://gist.github.com/dsd/13909ed821f7429e6be6a97ed91a61af

Logs from connection attempt:
https://gist.github.com/dsd/ae4a664c45e3d379d765231d96ae20d7

By the way, I noticed that the new parameter is called assoc_retry_max.
However here the problem is at the authentication stage. We do not
reach association.
Does assoc_retry_max also affect the authentication codepath, or is
there an equivalent parameter for retrying auth?

Thanks
Daniel