CYW4343W slow to connect TKIP-encrypted network

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
Telesforo
Level 2
Level 2
First solution authored 10 replies posted 10 sign-ins

Hello everyone,
I'm customizing Android 6 to fit a SoC that comes with muRata LBEE5KL1DX (CYW4343W).
I successfully embedded Cypress Linux WiFi Driver Release (FMAC) [2022-03-31].
NVRAM file comes from muRata repository, firmware and clm_blob files come from the above archive.
If an access point uses (WPA2-PSK) either TKIP encryption only or its combination, Android sometime takes till 2~3 minutes sometime within few seconds to acquire a dynamic address and establish the connection.
If an access point uses (WPA2-PSK) AES encryption only, Android always connects it within few seconds.
I digged in calling kernel module in this way

     insmod /system/lib/modules/brcmfmac.ko debug=0x00108414

but I didn't achieve good results.
Using TKIP encryption, the board sometime has to receive several dozen of DHCP offers before establish a connection. Using AES encryption, radio quickly connects 10/10 times. The same behaviour using different access points (Sitecom, Digicom, Netgear).
What you think about ?

Thanks in advance for whatever help and best regards.
Alessandro

0 Likes
1 Solution
Telesforo
Level 2
Level 2
First solution authored 10 replies posted 10 sign-ins

Hi Vivek, I agree with you: this thread can be closed. As we will reproduce the issue with an AP sold in your country, we get in touch. Thanks for all and have a nice day.
Alessandro

View solution in original post

0 Likes
35 Replies
Vivek_gunapati
Moderator
Moderator
Moderator
250 replies posted 10 likes given 50 solutions authored

Hi Alessandro, 
Could you please let us know if you have patched the wpa_supplicant/hostapd with the patches available in the following path ..\cypress-fmac-v5.10.9-2022_0331\cypress-hostap_2_9-1 ?

Regards
Vivek.

0 Likes
lock attach
Attachments are accessible only for community members.
Telesforo
Level 2
Level 2
First solution authored 10 replies posted 10 sign-ins

Hello Vivek,
yes, I applied the patches you mentioned above.
I attach the messages coming from kernel module when I connect the subject network; debug level is 0x00108414.
I do not understand why the connection takes short using AES encryption, while it takes till few minutes using TKIP encryption.

0 Likes
Telesforo
Level 2
Level 2
First solution authored 10 replies posted 10 sign-ins

Option CONFIG_NO_TKIP lacks from both hostapd/android.config and wpa_supplicant/android.config . The TKIP-based connection is established although after long. I plugged my laptop via ethernet to the access point and launched Wireshark monitoring DHCP packets. I watch many DHCP Requests and as many Offers.

0 Likes

HI @Telesforo 
Thank you for the logs, TKIP encryption is an old encryption standard, and AES provides better security compared to TKIP. Could you please let us know the use case of this?

I tried to reproduce the issue with an IMX8 running Linux + (FMAC) [2022-03-31] + cyw4343w and successfully connected to my TP LINK Archer C5 router instantly with out any issues.

Could you please share us the wireshark air log? This will help us to understand the issue better.

Regards
Vivek.

0 Likes
lock attach
Attachments are accessible only for community members.

Hello Vivek,
most of our customers are small sized and have dated access points hence with TKIP-encryption yet.
We have to guarantee compatibility and good performance in all scenarios.
I attach the DHCP activity grabbed through Wireshark showing two attempts of connection using TKIP encryption and one attempt using AES. The difference is substantial.

0 Likes

Hi @Telesforo 

Could you please share with us the complete Wireshark log from the joining process for both AES and TKIP?

Regards
vivek.

0 Likes
lock attach
Attachments are accessible only for community members.

Hello Vivek, here the complete logs.
Thank you, Alessandro

0 Likes

Hi @Telesforo , Also could you please try with the older version of the firmware linked here -> https://community.infineon.com/t5/Wi-Fi-Bluetooth-for-Linux/Cypress-Linux-WiFi-Driver-Release-FMAC-2...

The difference between the above and the newer firmware is that the 4-way handshake is taken care by the firmware (-idsup-idauth- in the firmware build string ) & in the newer firmware the 4-way handshake is offloaded to the wpa supplicant. 

Please try and let us know if the issue persist with the older firmware too?

Regards

Vivek

0 Likes

I replaced firmware, kernel module backport as well hostap with the release you suggest. Unfortunately I have the same behaviour.
Does a debug level exist for the driver that maybe useful ?
Kind regards, Alessandro

0 Likes
lock attach
Attachments are accessible only for community members.

I attach debug messages coming from brcmfmac concerning Release 2021-10-20.
The subject network name is EVCO.Sitecom

0 Likes

Hi @Telesforo , 

Thank you for the logs, However, from the logs (kaTNcR9.zip), we do not see why the connection is stalling for TKIP encryption. Could you please share the over-the-air log too? this is will help us to understand the issue better. 

 From the setup image, we see that the DHCP server and AP are separated, as a test could you please try the DHCP running on the AP and check if the issue persists?  

 

0 Likes

Hi @Telesforo , Any update on the issue? was the issue reproduced with DHCP running on the AP?

Regards
Vivek.

0 Likes
Telesforo
Level 2
Level 2
First solution authored 10 replies posted 10 sign-ins

Hello Vivek,
if DHCP runs inside the access point, the connection establishes within seconds.
Conversely if DHCP runs outside AP, the connection takes longer, till 3 minutes in the worst cases.
Our domain's DHCP is a service of Windows Server 2019.
I realize the problem happens in a particular case, but I fear it may not be as rare as believed.
If I connect a usual notebook running MS Windows to the same AP, there's no lag.
Can you suggest how accomplish over-the-air analysis?
Thanks, Alessandro

0 Likes

Hi @Telesforo
Thank you for the reply. 

To capture over-the-air packets you could use the following instructions from a different website -> https://linuxhint.com/capture_wi-fi_traffic_using_wireshark/

-> You could also try tcpdump tool on the host of 4343W during the connection and share us the logs. 

->Test)  After connecting to the AP in TKIP encryption + DHCP running out the AP does the ping from/to a different STA from 4343W in the network takes a longer time?  is it same as AES connection too?

Regards
vivek 

0 Likes
lock attach
Attachments are accessible only for community members.
Telesforo
Level 2
Level 2
First solution authored 10 replies posted 10 sign-ins

Hi Vivek,
unfortunately I cannot capture over-the-air packets through wireshark because Android build lacks of required utilities for debug.
Conversely I attach logs concerning ping and tcpdump.
The tests were performed with DHCP running out the AP: dynamic IPs are published by our domain gateway Windows Server 2019.

Regards, Alessandro

0 Likes

Hi @Telesforo , the over the air packets through wireshark need to be captured on a Linux laptop/pc not on the android platform itself.

I will go through the logs, Meanwhile could you please let us know if there was any delay in the first ping response in both TKIP and AES?

Regards
Vivek.

0 Likes
lock attach
Attachments are accessible only for community members.
Telesforo
Level 2
Level 2
First solution authored 10 replies posted 10 sign-ins

I attach ping responses as soon as the connection is established. I watch a longer delay for the first response compared to the next ones.
I am looking for capturing over-the-air packets. I hope to do something good.
Alessandro

0 Likes
Telesforo
Level 2
Level 2
First solution authored 10 replies posted 10 sign-ins

Hi Vivek, at the moment I lack suitable equipment to sniff wireless packets through monitor mode.
Regards, Alessandro

0 Likes
Vivek_gunapati
Moderator
Moderator
Moderator
250 replies posted 10 likes given 50 solutions authored

Hi @Telesforo , sorry for taking longer than usual to respond to the issue, currently i am unable to reproduce the issue and I am in contact with the internal team for more information/insight on the issue. 

Regards
Vivek.

0 Likes
Telesforo
Level 2
Level 2
First solution authored 10 replies posted 10 sign-ins

Hi Vivek, any help will be appreciated.
Thank you and regards, Alessandro.

0 Likes

Hi @Telesforo ,

-> from the Wireshark logs we see that the timestamp is not in sequence, Do you also see the same on your Wireshark tool? We need the timestamp to identify if the Request from the DHCP server is delayed or the ACK from the 4343W is delayed?

->Could you please try with the open network and check if the issue exists?

-> Based on the internal discussion the internal team requires the air log capture to understand the delay.
Could it be possible to use a Linux laptop as a sniffer to capture the air log?

Regards
Vivek.

0 Likes
lock attach
Attachments are accessible only for community members.
Telesforo
Level 2
Level 2
First solution authored 10 replies posted 10 sign-ins

Hi Vivek, I attach the configuration of access point and a capture of OTA packets operated by Wireshark in monitor mode. Android took long before connecting with TKIP encryption.
Access point is linked to the corporate network via ethernet cable, it has DHCP server disabled because dynamic IPs are offered by domain controller Windows 2019.

Regards, Alessandro

0 Likes
lock attach
Attachments are accessible only for community members.
Telesforo
Level 2
Level 2
First solution authored 10 replies posted 10 sign-ins

Hi Vivek, I attach a new capture through ethernet operated by Wireshark 3.6.2 running on Ubuntu. Here timestamp values seem in sequence.
When AP uses TKIP+AES encryption, radio takes long before connecting.
When AP uses no authentication, so open network, radio connects at once.

Regards, Alessandro

0 Likes

@Telesforo ,

After analyzing the above Over-the-air logs we were able to observe the following 
-> When the Key Index is 2 under the parameter "TKIP Parameters" of the 80211 frame from the AP we see that 4343w did not respond with a DHCP response. The Key index parameter is shown below 

Vivek_gunapati_0-1657726592266.png

-> When the key Index is 1 by the AP after a couple of minutes 4343w responds with DHCP request 

In all my experiments i was able to see key index as 1 in my AP's

Q) To confirm the above observation could you please share us the logs with DHCP running with in the same AP where the slow TKIP connection is seen? so that we can check if the key index is set as 1 or 2.

Regards
VIvek

0 Likes
lock attach
Attachments are accessible only for community members.
Telesforo
Level 2
Level 2
First solution authored 10 replies posted 10 sign-ins

Hi Vivek,
here the over-the-air capture when Android connects AP configured with encryption TKIP only and DHCP active.
The connection establishes briefly.
Regards, Alessandro

0 Likes
Vivek_gunapati
Moderator
Moderator
Moderator
250 replies posted 10 likes given 50 solutions authored

Hi @Alessandro, @Telesforo 
Thank you for the logs,  

Currently, I am not able to reproduce the issue and we are working on that, Since I don't have a setup we need you to perform additional tests on your setup. My apologies for asking you on multiple tests. The test results will help us to understand the issue better

Q1) Could you please let us know the exact Netgear AP model and firmware used?

Q2)In the TKIP when the slow connection is seen could you please try the following script and share the results i.e 10 seconds before successful TKIP connection and 10 seconds after TKIP successful connection.

while true
do
wl counters
wl reset_cnts
sleep 1
done 

Q3) From the Wireshark logs we see the AMPDU is enabled.  Could it be possible to disable AMPDU on the AP and test if the issue occur?

Regards
Vivek.

0 Likes
lock attach
Attachments are accessible only for community members.
Telesforo
Level 2
Level 2
First solution authored 10 replies posted 10 sign-ins

Hi Vivek

Q1)
Manufacturer: Sitecom
Model: WLM-3600 v1 001 | X3 N300
Software version: 1.40

Q2) Look at the attachment

Q3) 
The configuration panel hasn’t an entry called AMPDU or similar, so I cannot disable it.
Any test is welcome as long as understand the cause of the behaviour.

Regards, Alessandro

0 Likes

Hi @Telesforo , from the issue description 

"The same behaviour using different access points (Sitecom, Digicom, Netgear).


Could you please let us know the exact Netgear AP model and firmware used?
We have a couple of Netgear AP's here in office, checking if i could use the Same AP to reproduce the issue.

Regards
Vivek.

0 Likes
Telesforo
Level 2
Level 2
First solution authored 10 replies posted 10 sign-ins

Hi Vivek,
unfortunately I have no longer the model of Netgear AP in which I observed the malfunction.
Slow connection using TKIP encryption comes as well with

     Digicom model 8D5858
     Firmware version 1.1.5
     Kernel version 4.4.14

Conversely, I achieved fast connections using the followings

     Netgear model WNR2000
     Firmware Version V1.2.3.7

     Netgear model DG834Gv5
     Firmware Version V1.6.01.34

May be the problem is related to the AP's firmware.
Regards, Alessandro

0 Likes
lock attach
Attachments are accessible only for community members.
Telesforo
Level 2
Level 2
First solution authored 10 replies posted 10 sign-ins

Here the OTA capture and counters of two slow connections with TKIP encryption using Digicom as access point. The connected SSID is "EVCO.Digicom", the MAC address of muRata module is still D0:17:69:C4:44:89 .
Regards, Alessandro

0 Likes

Hi @Telesforo   Alessandro, 

We do not have the Digicom and Sitecom AP available in India or USA for us to reproduce the issue. 
Could you please let us know if you are able to reproduce the issue with any AP which is widely available like Netgear or ASUS AP? If not could it be possible to ship the Sitecom or Digicom AP to India?

Regards
Vivek.

 

0 Likes
Telesforo
Level 2
Level 2
First solution authored 10 replies posted 10 sign-ins

Hi Vivek, I will try to reproduce the issue as soon as I get such APs. Unfortunately we cannot ship the ones we use to develop.
Thanks for your help and regards, Alessandro

0 Likes

Hi @Telesforo , thank you for the reply! please let me know if you need more information from our side. 

0 Likes

Hi @Telesforo , Since we do not know the timeline on when you could reproduce the issue on the new AP's Could we close this issue? Once you were able to reproduce the issue successfully on the new AP you could create a new thread?

0 Likes
Telesforo
Level 2
Level 2
First solution authored 10 replies posted 10 sign-ins

Hi Vivek, I agree with you: this thread can be closed. As we will reproduce the issue with an AP sold in your country, we get in touch. Thanks for all and have a nice day.
Alessandro

0 Likes