Linux/WL1801MOD: The connection problem on WL1801MOD

Nomo,
Seems like deauthentication is due to inactivity. Also I see recovery due to tx stuck. Are you able to reproduce the issue consistently - especially following line : "wlcore: ERROR Tx stuck (in FW) for 5000 ms. Starting recovery"

Thanks
Saurabh

Hello Saurabh-san,

Thank you for your reply.
The issue ("wlcore: ERROR Tx stuck (in FW) for 5000 ms. Starting recovery") is found in high probability, but not always.
Could you tell me what points should I check first?

Best Regards,
Nomo

Hi Nomo-san,

Tx stuck is normally related to environmental issues, like interference in the air that prevents the firmware from transmitting for a long period of time.

This is normally very rare and we are hardly ever see that.

A couple of questions:

1. Can they try the same setup in a shielded room or an area with less wifi devices seen around?

2. Are they seeing this issue on all channels? Can they switch to another channel?

3. I assume this is their target hardware, right? Is this seen on all their boards or only on some?

4. Can they capture firmware logs from the uart_debug using firmware logger?

Best Regards,

Eyal

Hello Eyal-san,

Thank you for your comments.

There are two problems at my customer's site.
1.The connection between AP (WL1801MOD) and STA is more frequently disconnected than other APs.
2.After disconnection of (1), AP (WL1801MOD) often seems to be in abnormal status and cannot be recovered from the disconnection status.

I attach the new log file from uart_debug.
Could you comment for the log file?
They think the problem can be found around the line of 45482 in the file.

They are thinking the cause is in firmware.
If you have another notion, please let me know.

And I answer the following questions.

Eyal Reizer said:

1. Can they try the same setup in a shielded room or an area with less wifi devices seen around?

They tried at an area with less wifi devices seen around and the results are well.
However, the connection is obviously weaker than any other AP devices.
So, they feel difficulty to use WL1801MOD as AP in the real environment.

Eyal Reizer said:

2. Are they seeing this issue on all channels? Can they switch to another channel?

The issue can be seen on all channels.

Eyal Reizer said:

3. I assume this is their target hardware, right? Is this seen on all their boards or only on some?

Yes, the issue can be seen on all their custom board; however, they also tried on TI's EVM and they found the weakness of the connection between AP and STA.

Eyal Reizer said:

4. Can they capture firmware logs from the uart_debug using firmware logger?

The previous attached file is from the /var/log/messages, so I attach the firmware logs from the uart_debug.

Best Regards,
Nomo

glog_2018_06_21_161735.xlsx

Hi Nomo-San,

I am having issues looking at the log they have provided?

Have they used the same firmware file in gLogger that is also running on the target when they saved the capture file?

The log has a lot of invalid packets so they might have not used matching files?

Can they produce another file that is complete and doesn't show errors?

Best Regards,

Eyal

0

0

33:20.6

Invalid packet(s) received before the sync completed

80c39410058026798710423d9cbe02d5bc7b0580c394100580c00d951005042157367d800027841000040001278000f385100004000205806186100204800259841000d5bc7b80d5861004058043c11f000009b0bb7c0002fed48018dbb41101049306278043c11f00000940bd7c0002ffd48043c11f000009d0be7c000200d580

Hello Eyal-san,

I apologize to bother you.
I attach new logs which don't show error.

ap_conn_2018_06_25.xlsx is a log from uart_debug and AP_MODE_AP_20180625.txt is a log on the host (AM3352).
They connected four STAs, and one of them is disconnected and never recovered.

The disconnection appears from the line of 81 in AP_MODE_AP_20180625.txt and from the line of 98786 in ap_conn_2018_06_25.xlsx.
Please note the setting of time from the line of 98786 in ap_conn_2018_06_25.xlsx.

Could you comment for these logs?

Best Regards,
Nomo

ap_conn_2018_06_25.xlsx

AP_MODE_AP_20180625.txt

Hi Nomo-san,

I have asked our R&D firmware enginner to look into the log and see if he can understand why this station is disconnected and not able to re-connect.

I suggest two things to try in the meantime:

1. Once this station is disconnected, in case you manually try to re-connect to the AP again. Will it connect ok or not?

2. Can you check the station that got disconnected and see if it has put the WL1801 AP into it's black list, and this is the reason is doesn't reconnect to it?

3. In case it is in the black list and you clean the black list, does it connect again?

Best Regards,

Eyal

Hello Eyal-san,

Thank you for your reply and gentle support.
I answer the following questions.

Eyal Reizer said:

1. Once this station is disconnected, in case you manually try to re-connect to the AP again. Will it connect ok or not?

No, they have tried the reconnection manually but failed.
They can reconnect STA by rebooting of the driver and hostapd on AP (WL1801MOD).

Eyal Reizer said:

2. Can you check the station that got disconnected and see if it has put the WL1801 AP into it's black list, and this is the reason is doesn't reconnect to it?

They didn't add the STA device into the black list.
Is there any case that firmware or driver add the STA devices into the black list automatically?

Best Regards,
Nomo

Hello Nomo-san,

Regarding the Black List I actually meant the other way around.

The station can add an AP to the black list in case it was unable to connect to it.

It is not the AP that is black listing the station.

See:

Search for "blacklist" command.

If they do see the AP in the blacklist, have them try to clear the blacklist and try to reconnect to the AP and see if it connects.

In addition, our R&D engineer has looked into the logs and there are a couple of things we would like them to try:

From the logs it seems there’s a lot of group key handshake completed (RSN) and we want to understand if the issue is related 

to security keys:

Can they try to reproduce the issue by configuring the WL1801 AP with:

1. Without security
2. Without 11n

Best Regards,

Eyal

Hello Eyal-san,

Thank you for your comment and advice.
I'll ask my customers to do it.

However, they mentioned the solution without security isn't accepted by them because they need the feature.

By the way, the problems are reproduced on WL1835MODCOM8B with the default firmware and settings from TI.
(The firmware version is PHY firmware version: Rev 8.2.0.0.242 and firmware booted (Rev 8.9.0.0.78))

Is this known issue of the latest firmware?
Is there any possibility to solve this problem by changing the firmware to old one?

Best Regards,
Nomo

Nomo-san,
"However, they mentioned the solution without security isn't accepted by them because they need the feature."
This is needed only for debugging. We are not suggesting disabling secured connection on the device

"Is this known issue of the latest firmware?"
We are not aware of this issue

"Is there any possibility to solve this problem by changing the firmware to old one?"
Customer may try older version of firmware and let us know if it makes any difference

Thanks
Saurabh

Hello Saurabh-san,

Thank you for your reply.
I've asked to them to try with older version of firmware and/or without security/11n, and they have been evaluating.
If these makes any difference, I'll tell you.

By the way, the issue can be reproduced by TI's EVM with the default software/firmware, they mentioned.
So, could you evaluate on your site?
If you need additional information, please let me know.

The followings are conditions:
-TMDXEMV3358+WL1835MODCOM8B are set to AP mode with security and some devices such as Android smartphones and tablets connect to the AP.
 (They connect more than two STA devices to AP)
-STA devices send PING to AP every one second.
-To reproduce the issue, you need leave the environment long time. (Some cases occur the issue in one hour, the others occur the issue more than one day)
-Software versions are below:
 -SDK on AM335x: PROCESSOR-SDK-LINUX-AM335X 04_00_00_04
 -Linux kernel version: 4.9.28-geed43d1050
 -WiLink driver version: wilink8-wlan-wl18xx-R8.7_SP3
 -firmware version: PHY firmware version: Rev 8.2.0.0.242 and firmware booted (Rev 8.9.0.0.78)
 -Hostapd version: hostapd v2.6-devel-R8.7_SP3+

Best Regards,
Nomo

Hi Nomo-san,
WiLink8 AP is a soft AP and it is not intended to run it for days unlike external dedicated Access Points. It is mostly used for provisioning etc. I had device connected to AP for an hr and did not see any disconnections . I did not see any watchdog related recoveries in firmware log . Can you pls ask customer to unload/load the driver modules and start AP again when they see this issue and re-test. Also please run the other tests to rule out if it is security related .

Thanks
Saurabh

Hello Saurabh-san,

Thank you for your reply.
We know WiLink8 AP is soft AP; However, we cannot find the information showing that "it is not intended to run it for days unlike external dedicated Access Points".

If you have any documentations which describe the above intent and the expected usage in case of the AP mode, could you tell us the source?

Best Regards,
Nomo

Hi Nomo-san,
I ran this test on 2 WiLink8 EVMs (one AP, one STA) for 1 day and did not see connection drop. What is the use case scenario of your customer ? Do you have an update on the tests we asked them to run ?

Thanks
Saurabh

Hello Saurabh-san,

Thank you for your cooperation.

Could you try the following condition?
They have concerns about not only disconnection but also never recovery.
Sometimes, after connection is disconnected, the connection is never recovered.

-AP is an EVM and STAs are two or three of Windows10 PC and Android smartphones.
-Please set using of only one 2.4GHz antenna by configuring wl18xx-conf.bin.
-Please place a metal panel near the environment.
-Could you make the environment which connection is likely disconnected and confirm never recovered?

Best Regards,
Nomo

We are not seeing such problems here.
You need to provide us logs (both sniffer logs as well as wpa_supplicant logs) that you capture during such a case if you want us to look into it.

Best Regards,
Eyal