I am looking into speeding up the time it takes for my device to connect to an AP. A network packet capture is showing a delay of about 2.2 seconds between the active probe response from my AP, and the device sending the Authentication packet to start the connection process.

My device uses an STM32F412 MCU + CYW4343W Wi-Fi/BLE chip, and application is built using WICED Studio 6.6.1 with ThreadX/NetX Duo.

The application performs a Wi-Fi scan, finds the proper AP, updates the DCT with the appropriate channel, BSSID, security for the AP, and then calls wiced_network_up().

I have added debug to WICED, and narrowed down the delay inside of wwd_wifi_join_specific(). The delay is encompassed in the process of sending the JOIN command to the chip and waiting for it to finish –
Call to wwd_sdpcm_send_iovar( SDPCM_SET, buffer, 0, interface ) (where the buffer points to ext_join_params)...

to...

wwd_wifi_join_wait_for_complete( &join_semaphore, interface ) returning success.

I tried changing the parameters for dwell times (to very small values) and number of probes (to 1) in ext_join_params as they were set to use the default values, but this didn’t seem to change behavior.

I captured a network sniff from my Google Pixel of the same process and saw next to no delay between PROBE and AUTHENTICATE, so the delay doesn't seem to be required.

I don’t see where the PROBE to AUTHENTICATE is controlled anywhere in the WICED SDK, so I am assuming this is somehow baked into the chip/firmware?

Am I missing any type of configuration that would speed this up? Is there anything I can change in the SDK, or is this process controlled by the chip/firmware?

My network sniff can't see what is happening on all the channels. Is it possible that the process of traversing the channels during the active probe is the cause of the delay? Does anyone know if the channel traversal stops once it gets a probe response? In my case, the channel has either been 2 or 3. I can try changing this to a higher number to see if it changes the timing at all.

Hi.

I am trying to use mbedtls library with TLS 1.3 support in WICED studio.

I am looking for the BESL supplicant library source code in order to check the transition from phase1 to phase2. Is that available somewhere?

Thanks

We are evaluating the Murata Type 1GC Wi-Fi chip using WICED SDK and 43xxx_Wi-Fi project provided. 

ref: https://www.murata.com/-/media/webrenewal/products/connectivitymodule/asset/pub/rfm/data/n1-5002_type1gc_1ps-quick_start_guide.ashx?la=en&cvid=20211022010000000000

Building/downloading the sample application target in step 3F (target,snip.scan-MurataType1GC), results the following error:

Creating Filesystem BCM94390x_targets.mk ...
Downloading DCT ... build/snip.scan-MurataType1GC/DCT.bin @ SFLASH_DCT_LOC=0x00008000
./tools/common/Win32/mk_wicedfs32 build/snip.scan-MurataType1GC/filesystem.bin build/snip.scan-MurataType1GC/resources/Staging/
Creating Filesystem Done
WICED/platform/MCU/BCM4390x/BCM94390x_targets.mk:394: recipe for target 'download_dct' failed
make.exe[1]: *** [download_dct] Error 1
Makefile:351: recipe for target 'main_app' failed
make: *** [main_app] Error 2

Please advise as to what may be the cause.

I am looking into speeding up the time it takes for my device to complete a 2-way TLS handshake. A network packet capture is showing that this process takes about 2.5 seconds to complete.

My device uses an STM32F412 MCU + CYW4343W Wi-Fi/BLE chip, and application is built using WICED Studio 6.6.1 with ThreadX/NetX Duo.

I realize that this is a computationally expensive process, so it might just be the way it is. However, I wasn't sure if there were any WICED build/config flags that might help speed this up.

Screenshot of TLS network sniff attached where 192.x.x.x address is the device running code build in WICED.

Hi
we designed a custom board that contains the wifi module: EWB-STERLING,(453-00014R )
In my board, I routing the USART1 pins to FTDI chip (FT4232 with 4 Channels).
I search all over the laird guides and no one mentioned how to program the board if I have custom board.

all the guides talk about the DVK and thats all.
my pc has recognized the FTDI with a generic name when I'm looking in the device manager(without the WICED NAME SIGNATURE).
I don't have any JTAG header( if its must I need to do redesign and I hope its not the case)

so how do I program the EWB module in the first time with USART1 through the FTDI? 

WICED SDK 6.6.1.1

WLAN Firmware : wl0: Mar 31 2022 01:31:05 version 7.15.168.156 (4f1e919) (pulled from Modus)

I see references in the release notes and source code for WPA3-SAE. Is it supported? 

What about WPA3-OWE / Wi-Fi Enhanced Open Mode? I did not see this directly referenced in the code but maybe it is handled on the WLAN driver side. 

I assume WPA3-Enterprise is not supported.

I have a device that I'm testing against, which is broadcasting beacons at 1Mbps, and my application on CYW43907 is not receiving them. It's capturing beacons from all other sources that I've tried just fine, but capturing these in Wireshark, I can see that they're all transmitted at 6Mbps. The device I'm missing also shows up when I sniff it - so it does broadcast 🙂

I suspect that maybe my application is not setting up the chip to use 802.11b rates, but I can't figure out how to do this.

I've found APIs to enable/disable 802.11n, but nothing for b.

I experimented with wwd_wifi_set_legacy_rate(WWD_STA_INTERFACE, 2), but it didn't make a difference - and other posts in the forum indicate that this may be AP only.

Any suggestions? Both on how to check the current supported rates in my app, and how to change them.

Hi all -

I've been given the task of maintaining a very old application built upon WICED 2.4.1. I'd like to use the function wwd_wifi_abort_scan() to terminate a call to wiced_wifi_scan_networks(), but my IDE doesn't find it. Can someone tell me where to locate it, or alternatively, another way of terminating the scan?

Thanks...

Hi guys, in our project we use both cyw43907 and cyw54907 with the shared code. But we want to detect if current chip type is cyw43907 or cyw54907 to show in hardware info. So do we have API or something to get the current chip type and make sure if it is cyw43907 or cyw54907?