Wi-Fi Combo

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.

Hi guys,

In our application, we connect to wifi AP and do stuffs. If we got some issues like request http error or disconnect with mqtt broker, we will retry to connect again. Incase retry not success we will disconnect with wifi AP and retry to connect current wifi AP again or connect the another wifi AP.

But sometime we got stuck forever in wiced_leave_ap.

I use CYW54907 with Wiced studio 6.6.

I am currently working a project that requires OTA functionality.  I am currently at a point where I have increased the sizes of the following buffers to account for the length of presigned URLs:

- WICED_OTA2_HTTP_QUERY_SIZE
- WICED_OTA2_HOST_NAME
- WICED_OTA2_FILE_PATH

Updating via OTA 2 has been tested via a locally hosted web server (non HTTPS) with long (2k) URLs.  This works as intended and ensures that the length itself is not resulting in any issues downloading the image.

The device has been loaded with the Starfield signer used to generate the signing information used in the presigned URLs using wiced_tls_init_root_ca_certificates(starfield_cert) prior to initializing OTA2, which should be significant for verifying the URLs.  However, when attempting to download via a presigned url, I get the following output (private info redacted):

-----------------------------------------------------------------------------------------------------------------------------------------------------------------

0047 00:02:20.488 OTA2: OTA2_EVENT_WORKER_START_DOWNLOAD!
0048 00:02:20.493 wiced_ota2_service_get_the_update() start!
0049 00:02:20.499 wiced_ota2_service_get_the_update() Use the ota2 list count:5!
0050 00:02:20.506 wiced_ota2_service_network_switchto_ota2_ap() already connected to: XXXXXXXX
OTA access point connect success!
0051 00:02:20.517 Connect to: host:XXXXXXXXXXXXX.s3.us-east-2.amazonaws.com path:/OTA2_image_file.bin?X-Amz-Security-Token=IQoJb3JpZ2luX2VjEAEaCXVzLWVhc3QtMiJHMEUCIQCcDTpP%2FgiQLzTjrRDDB5IkgekIXi7oeuWgpNXEpsiqtAIgcoNPiTDJ2weMhjX1eYsGpM9ZpN%2FLRqUCvJMtYz%2BqnbEq3QIIehACGgw2MTY0MTg2NjAwMTMiDOjAPtjf54GP2Krxzyq6Apn64H88uzj%2FaXhrHfYYrzs7VdgN%2F1zj6eEk%2F61p2j0RXtu83VzwNnMQOYA4Wh3JfBrpAqMfLeM3UvgFdSyU8ORikTjWcdL5Jcewa%2Bh0Ekse%2BQcLSPSYYUdNNloHds5Sewxd3Ib1PJW5frXwV1bp0A9%2FLjGlAeS5MMaQAPODeM0cpmKsvefG6Z9CR7pqjFXGyRPMpmROxZqqzq7qB7sile%2BHihl7pMWzJIosEsW4vUyDUpq2dRC3lK%2FB8IaVbhHGJ7Lg0h6ZGJ2olz5RsvNLylxlwyz0qI5JemrkGM02tBkTFYmLzJRRC1zGwW63CQTITQRNSjWhcabgnJglXuGHK%2FHyRZwjpDSBNGFugH3aaQj8WJp1hCGotJ439owjqy3BPTCvWcMV2VDKMvwk32rCvGA9r3KOI71Ti4dxMPTDq4QGOr8BsY2EB7Gi3qQ4NuORTmtjH3wTT5FC1cXr8RvrXRitUjOFA5QxtFkVvb4UVkP3AL3hOSGvVJZOBZQAiyGNrqSMl%2Bw9xcqbq6PKkjBJzMKo3f4sD9tat4JE1JFI6WeG87sX7fbnaExSb9sHvbPxQOJCNNpcU%2Bo%2BR9vkIPtD71RCU4fSdjP10BNezdo0kmMcsqs5KeKiUEbwyHdgFYfaVV95C2xS96xyL339eZn2W004mKAnqoae3fOcav3YJvptkVA%0052 00:02:20.616 Try 0 Connecting to XXXXXXXXXXXXX.s3.us-east-2.amazonaws.com 52.219.97.146 : 443 !
0053 00:02:20.653 Connected to 52.219.97.146 : 443 !
OTA server connect success!
0054 00:02:20.662 Send query for OTA file: [GET /OTA2_image_file.bin?X-Amz-Security-Token=IQoJb3JpZ2luX2VjEAEaCXVzLWVhc3QtMiJHMEUCIQCcDTpP%2FgiQLzTjrRDDB5IkgekIXi7oeuWgpNXEpsiqtAIgcoNPiTDJ2weMhjX1eYsGpM9ZpN%2FLRqUCvJMtYz%2BqnbEq3QIIehACGgw2MTY0MTg2NjAwMTMiDOjAPtjf54GP2Krxzyq6Apn64H88uzj%2FaXhrHfYYrzs7VdgN%2F1zj6eEk%2F61p2j0RXtu83VzwNnMQOYA4Wh3JfBrpAqMfLeM3UvgFdSyU8ORikTjWcdL5Jcewa%2Bh0Ekse%2BQcLSPSYYUdNNloHds5Sewxd3Ib1PJW5frXwV1bp0A9%2FLjGlAeS5MMaQAPODeM0cpmKsvefG6Z9CR7pqjFXGyRPMpmROxZqqzq7qB7sile%2BHihl7pMWzJIosEsW4vUyDUpq2dRC3lK%2FB8IaVbhHGJ7Lg0h6ZGJ2olz5RsvNLylxlwyz0qI5JemrkGM02tBkTFYmLzJRRC1zGwW63CQTITQRNSjWhcabgnJglXuGHK%2FHyRZwjpDSBNGFugH3aaQj8WJp1hCGotJ439owjqy3BPTCvWcMV2VDKMvwk32rCvGA9r3KOI71Ti4dxMPTDq4QGOr8BsY2EB7Gi3qQ4NuORTmtjH3wTT5FC1cXr8RvrXRitUjOFA5QxtFkVvb4UVkP3AL3hOSGvVJZOBZQAiyGNrqSMl%2Bw9xcqbq6PKkjBJzMKo3f4sD9tat4JE1JFI6WeG87sX7fbnaExSb9sHvbPxQOJCNNpcU%2Bo%2BR9vkIPtD71RCU4fSdjP10BNezdo0kmMcsqs5KeKiUEbwyHdgFYfaVV95C2xS96xyL339eZn2W004mKAnqoae3fOcav3YJvptkVA%3D&X-Amz-Algorithm=AWS4-HMAC-SHA2560055 00:02:21.750 ota2_get_OTA_file() wiced_tcp_receive() 2 timeout!
0056 00:02:22.755 ota2_get_OTA_file() wiced_tcp_receive() 2 timeout!
0057 00:02:23.760 ota2_get_OTA_file() wiced_tcp_receive() 2 timeout!
0058 00:02:24.765 ota2_get_OTA_file() wiced_tcp_receive() 2 timeout!
0059 00:02:24.770 ota2_get_OTA() wiced_ota2_write_data() Timed out received:0 of 0!
0060 00:02:24.778
ota2_get_OTA_file() Exiting 2
0061 00:02:24.782 wiced_ota2_service_get_the_update() wiced_ota2_service_wget_update(header) failed!
OTA update error!
0062 00:02:24.821 wiced_ota2_service_get_the_update() ota2_service_connect() failed (list)!
OTA server connect error!
0063 00:02:24.832 wiced_ota2_service_network_switchto_default_ap() already connected to: XXXXXXXX
OTA update complete!
0064 00:02:24.842 OTA2: wiced_ota2_service_get_the_update() FAILED check if timers started!
0065 00:02:24.850 OTA2: wiced_ota2_service_get_the_update() FAILED set flag START_RETRY_TIMER!
OTA update check!

-----------------------------------------------------------------------------------------------------------------------------------------------------------------

It seems to me that verification of the presigned URL is failing at some level, but I am struggling to see where.  This issue holds true with the standard OTA2 example, with the prementioned buffers increased to accommodate the URL in wiced_ota2_service.h .  Wondering if anyone has any ideas here, or any previous experience using AWS presigned URLs on the WICED platform.  Any ideas are greatly apprecieated.