- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi @Telesforo
Could you please share with us the complete Wireshark log from the joining process for both AES and TKIP?
Regards
vivek.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi @Telesforo , Any update on the issue? was the issue reproduced with DHCP running on the AP?
Regards
Vivek.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Vivek, at the moment I lack suitable equipment to sniff wireless packets through monitor mode.
Regards, Alessandro
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Vivek, any help will be appreciated.
Thank you and regards, Alessandro.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
-> 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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi @Telesforo , thank you for the reply! please let me know if you need more information from our side.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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