Wi-Fi Combo

I just upgraded the version of Wiced we are using from 6.4 to 6.6.1.1. When the code tries to set wwd_wifi_fast_bss_transition_over_distribution_system the result is now WWD_WLAN_UNSUPPORTED.

The chip is a CY43012C0.

Any ideas why this no longer works?

Hi, 

We have used CYW43455 for connection test, and we were unable to get IP address to run iperf even the AP can get the MAC address.  the following is our FW version and command process. can you advise ?

Version: 7.45.189 (r714228 CY) CRC: bdd6d3f5 Date: Thu 2019-05-02 02:42:20 PDT Ucode Ver: 1043.2132 FWID 01-ee766038 DVID 01-e048c631

wl down

wl country DE

wl band “b” or “a”

wl 2g_rate –r 1 ->  For 2G

wl up

wl join <SSID>

Hi,

Could you please give some clarifications on the setting of the listen_interval (wiced_wifi_set_listen_interval and wiced_wifi_set_listen_interval_assoc) ?

The documentation states that the first function should communicates the listen_interval to the AP. This seems to be true, but only during the association. If I change the listen_interval after that, the function does not communicate the new value to the connected AP, even though the change is effective.

Why is that ? Is there a problem with updating the listen_interval while connected ? How can I let the AP knows that I want to change / changed the listen_interval without disconnecting ?

Thanks for your support.

Best regards,
Mehdi

Hi,

Is there a clear centralized exhaustive list (and history) of know vulnerabilities in the CYW4343W (or all chips) firmware ?

Browsing https://github.com/Infineon/wifi-host-driver commits to RELEASE.md (like that Upload wifi-host-driver 1.94.0.6931 · Infineon/wifi-host-driver@19968e1 (github.com)) I can see that there is a few changelogs related to the CYW4343W firmware.
--- 7.45.98.120 ---
Fix pmk caching
--- 7.45.98.117 ---
Security fixes
Memory usage reduction by disabling debug features
--- 7.45.98.110 ---
Fixed zero stall on UDP
Fixed Tx traffic too less then RX
--- 7.45.98.95 ---
Fixed zero stall on UDP
--- 7.45.98.92 ---
Security fix (KRACK all-zero-key)
--- 7.45.98.89 ---
Security fix(Dragonblood WPA3 attack)
TCP Keepalive Implementation
Security fix(CVE-2019-9501 / CVE-2019-9502)
--- 7.45.98.81 ---

This list is not easy to build and browse, the known vulnerabilities should be centralized.

Is this list exhaustive ?

How can we know what version exactly fixes a vulnerability ? This only show ranges...

Between 7.45.98.110 and 7.45.98.117, it is only mentioned "Security fixes"... Where can we get more details on this/these vulnerability(ies) ?

Looking at this blog post (Potential Fragmentation Vulnerabilities for Wi-Fi ... - Infineon Developer Community), it looks like the CYW4343W could by affected. How can we make sure whether it is or not ?

Any more information about firmware vulnerabilities is welcome.

Thanks and best regards

Hi,

We uses Murata Type1LD and recently found an issue with 'malloc'. 'malloc' fails to allocate space even though heap has plenty of space. We checked heap status and it shows as below,

sbrk heap size: 206916
sbrk current free: 163832
malloc arena: 43084
malloc allocated: 42300
malloc free: 784

It seems like malloc does not uses all the available heap space (163KB free). We would like to know whether there is any way to configure Wiced (via ld file or any other method) to use all available heap space in malloc. It seems like Wiced uses FreeRTOS 'heap_3' implementation. Any help on this is highly appreciated

regards

SR

Hi,

In my application I need to know what beacon period and DTIM interval are set for the AP that my device (CYW4343W in Type1DX with WICED 6.6) is connected to.

I'm calling wiced_get_bss_info to achieve that. Most of the time, it works fine, however, for some unknown reason it sometimes starts to fail and then fails continuously with the error code 2014 (Buffer too short).

What are the possible reasons for such error for this function ? How can I prevent that ? Is there any other way to get the beacon / DTIM information ?

Thanks for your support.

Best regards,
Mehdi

Test using SDK-5.1.0.

I tried below command but it fails.

> join_ent LAB-ENT-TEST peap testuser testpass wpa2␍␊

besl_supplicant_init OK␍␊

besl_supplicant_start OK␍␊

Joining : LAB-ENT-TEST␍␊

Supplicant received link event␍␊

Supplicant completed successfully␍␊

Failed to join : LAB-ENT-TEST␍␊

Joining : LAB-ENT-TEST␍␊

Failed to join : LAB-ENT-TEST␍␊

Joining : LAB-ENT-TEST␍␊

Failed to join : LAB-ENT-TEST␍␊

Join result 1007: ␍␊

wifi_join fails␍␊

Can someone confirm if BCM4343W and BCM43438 support enterprise security or not?

We have found an issue within WICED Studio 6.6 where GKI_find_buf_start() appears to be accessing an uninitized variable. We noticed that following a soft reset the RAM contents are not zeroed. Therefore GKI_find_buf_start() interpretation of the data leads to unpredicted behavior. The behavior tends to vary with changes to our application code, which is why we say it is unpredictable. However, the behaviour remains the same for each build. For example, in one case we found the BLE would not report the BTM_ENABLED_EVT following init.

Our temporary solution, given that fixing the GKI_find_buf_start() function is not an option (black box), the only solution available was to ensure the data is initialised. The solution is then to write zeros in RAM during the initialisation sequence (_start()), which fixes the issue.

    /* Enable CPU Cycle counting */
    CoreDebug->DEMCR |= CoreDebug_DEMCR_TRCENA_Msk; /* Global Enable for DWT */
    DWT->CYCCNT = 0;                                /* Reset the counter */
    DWT->CTRL |= DWT_CTRL_CYCCNTENA_Msk;            /* Enable cycle counter */

    // Reset whole RAM
    memset((uint8_t *)SRAM1_BASE, 0, SRAM1_SIZE_MAX);
    memset((uint8_t *)SRAM2_BASE, 0, SRAM2_SIZE);

We have used Wiced SDK for Type 1LD development. Wiced doesn't supports LWM2M protocol. We are trying to port an open source LWM2M implementation like Wakaama/Anjay to Wiced SDK. But it seems like the mbedtls module available with Wiced /type 1ld have been tweaked at many places (compared to open source version). This creates a lot of issues in the UDP/TCP layer. We know that Wiced /type 1ld uses mbedtls to support many built in modules (like WiFi). Hence it is not possible to tweak or replace the Wiced /type 1ld mbedtls version. At this point, we think that it might not be possible to port an open source LWM2M implementation to Wiced SDK.