Skip navigation
Home > All Places > WICED Studio Wi-Fi/Combo > WICED Studio Wi-Fi/Combo Forums > Blog > Authors GauravS_31

The cryptography core in CYW43907, also known as crypto, is a dedicated hardware core present in the applications processor. It is used for performing cryptographic operations such as encryption and hashing in dedicated engines. The following operations are supported:

 

Encryption:
AES module which supports CBC, ECB, CTR, CFB modes
DES module to support DES and 3DES encryption with ECB and CBC modes

 

Hashing:
MD5, SHA1, SHA224, and SHA256 to support HMAC

 

Using hardware crypto in WICED

 

The hwcrypto is used in mbedTLS cryptographic operations as well as secure boot. By default, hwcrypto is enabled for mbedTLS operations. The macro PLATFORM_HAS_HW_CRYPTO_SUPPORT is used for enabling hwcrypto for mbedTLS and it is defined in BCM4390x.mk as shown below:

GLOBAL_DEFINES +=  PLATFORM_HAS_HW_CRYPTO_SUPPORT
$(NAME)_SOURCES += platform_crypto.c

To disable hwcrypto, the above statements should be commented out. The PLATFORM_HAS_HW_CRYPTO_SUPPORT effectively enables the following macros in mbedtls/config.h:

MBEDTLS_AES_ALT
MBEDTLS_DES_ALT
MBEDTLS_MD5_ALT
MBEDTLS_SHA256_ALT
MBEDTLS_SHA1_ALT

The above macros are used for enabling hwcrypto APIs defined in files marked with _alt.c in mbedtls_open/library. For instance, when MBEDTLS_AES_ALT is enabled, the APIs present in aes_alt.c are enabled which would call the driver functions such as hw_aes_crypt() in platform_tiny_crypto.c.

An SPU message is processed by the crypto core. Its contains the following:

 

           INPUT HEADER                       OUTPUT HEADER

     +-------------------------+         +------------------------+

     | Message Header (MH )    |         | Message Header (MH)    |

     +-------------------------+         +------------------------+

     | Extended Header (EH)    |         | Extended Header (EH)   |

     +-------------------------+         +------------------------+

     | SCTX Header 0  (SCTX0)  |         | Output data : Payload  |

     +-------------------------+         +------------------------+

     | SCTX Header 1  (SCTX1)  |         | Status                 |

     +-------------------------+         +------------------------+

     | SCTX Header 2  (SCTX2)  |

     +-------------------------+

     | BufferDescriptor (BDESC)|

     +-------------------------+

     | Buffer Data (BD)        |

     +-------------------------+

     | Input data : Payload    |

     +-------------------------+

     | Status                  |

     +-------------------------+

 

Where SCTX is the security context.

 

The DMA descriptors to SPU-M have the following format:

     INPUT DMA Descriptors                           OUTPUT DMA Descriptors

    +--------------------------+                    +--------------------------+

    | Header                   |                    | Header                   |

    | (MH + EH + SCTX0 + SCTX1 |                    | (MH + EH + BDA )         |

    |  SCTX2 + SCTX3)          |                    +--------------------------+

    +--------------------------+                    | start_aligned_buffer@    |

    | Payload 1                |                    | (PLATFORM_L1_CACHE_BYTES |

    | (MAX_DMA_BUFFER_SIZE)    |                    +--------------------------+

    +--------------------------+                    | Payload 1                |

    | Payload 2*               |                    | (MAX_DMA_BUFFER_SIZE)    |

    | (MAX_DMA_BUFFER_SIZE)    |                    +--------------------------+

    +--------------------------+                    | Payload 2*               |

    | Payload 3*               |                    | (MAX_DMA_BUFFER_SIZE)    |

    | (MAX_DMA_BUFFER_SIZE)    |                    +--------------------------+

    +--------------------------+                    | Payload 3*               |

    | Payload 4*               |                    | (MAX_DMA_BUFFER_SIZE)    |

    | (MAX_DMA_BUFFER_SIZE)    |                    +--------------------------+

    +--------------------------+                    | Payload 4*               |

    | STATUS                   |                    | (BYTES_IN_WORD)          |

    | (BYTES_IN_WORD)          |                    +--------------------------+

    +--------------------------+                    | end_aligned_buffer@      |

                                                    | (MAX_DMA_BUFFER_SIZE)    |

                                                    +--------------------------+

                                                    | HASH_OUTPUT#             |

                                                    | (BYTES_IN_WORD)          |

                                                    +--------------------------+

                                                    | STATUS                   |

                                                    | (BYTES_IN_WORD)          |

                                                    +--------------------------+

    *
    * * : Payload2/3/4 only required if Payload1/2/3 > MAX_DMA_BUFFER_SIZE
    * # : Hash output present only if cmd.hash_output is Not NULL
    * @ : Start/end aligned buffer is needed to ensure that the Start address and size of DMA is
    *     PLATFORM_L1_CACHE_BYTES aligned
    */

The following macros are defined in platform_tiny_crypto.c:

 

MAX_DMA_BUFFER_SIZE: This is the maximum size of DMA descriptor buffer which is 16kB. If the DMA payload size exceeds MAX_DMA_BUFFER_SIZE, it is split into chunks of MAX_DMA_BUFFER_SIZE. This is implemented in hwcrypto_split_dma_data() called in populate_input_descriptors().

 

MAX_TX_DMADESCRIPTOS: This is the maximum size of input DMA descriptors as shown in the format above. Its value is 1 (header) +  4 (payload) + 1 (padded hash input) + 1 (status)

 

MAX_RX_DMADESCRIPTOS: This is the maximum size of output DMA descriptors as shown in the format above. Its value is 1 (header) +  4 (payload) + 2 (aligned payload buffers) + 1 (hashoutput) + 1 (status)

 

HWCRYPTO_MAX_PAYLOAD_SIZE: This is the maximum hwcrypto payload size that the SPU-M can handle at a time during cryptographic operation.

 

Other macros specific to encryption and hashing have been listed in crypto_api.h.

 

A sample WICED code for testing AES-CBC using hwcrypto has been attached.

GauravS_31

STM32F469 porting in WICED

Posted by GauravS_31 Moderator Oct 10, 2018

Scope

 

The purpose of this document is to enable the WICED community to support a new MCU device using existing WICED Wi-Fi Driver (WWD) supported in WICED Studio. It allows user to use the MCU of their choice to achieve required system performance and cost goals. Though this document describes how to use a different MCU, Cypress community provides support only on the platforms/MCUs that are officially supported in WICED Studio. To learn more about the platforms/MCUs supported in WICED Studio, please refer to the WICED Studio Technical Brief. If you need support while porting to a different MCU, we recommend you to reach out to our partners.

 

This document covers the porting instructions with an example of Cypress’s Wi-Fi and Bluetooth combo device CYW4343W and ST MCU STM32F469.  Example leverages STM32F469-DISCO board as it has an SD card interface that makes it easy to access SDIO lines.

 

 

Disclaimer

 

This document assumes that you have basic understanding of WICED Studio and WICED Software Stack. The following document is a set of instructions / guidelines, which could vary based on the MCU chosen. The resultant platform files have not gone through the standard validation or testing done on platforms which are part of standard WICED Studio release.

 

 

Modifications required in WICED Studio

 

Steps involved in supporting a new MCU update existing files available in WICED that are used for other MCUs/Platforms.

 

1. Creating your own platform directory

The platform folder “CYW94343WWCD3” is placed in 43xxx_Wi-Fi/platforms as shown in Figure 1.

 

 

Figure 1 Platform directory

CYW94343WWCD3 folder.jpg

It would contain the files necessary to access the host processor peripherals, their configuration, Wi-Fi NVRAM settings, platform makefile.

 

a. platform.h: Declaration of GPIOs, LEDs, peripherals and corresponding IRQs are provided here. It is a good practice to first create a platform pin definitions table in platform.h. This table would map the WICED pin name to the exact pin name of the STM32 host processor. It is basically provided in commented form. For instance, the WICED pin name WICED_GPIO_1 is mapped to STM32 port pin G10 as shown in Figure 2.

 

Figure 2 Platform pin definitions

CYW4343WWCD3 platform pin definitions image.jpg

This will help us determine the total number of WICED pins which in turn would help us to define the enum wiced_gpio_t. This enum basically contains the list of WICED pin names which would be mapped to STM32 port pins in platform.c. Likewise peripheral pins such as SPI, I2C, UART are defined using the enums wiced_spi_t, wiced_i2c_t, wiced_uart_t. The total pins to be defined must be known before defining an enum.

 

To allow UART terminal printing, we would need to assign the STDIO_UART used for UART standard I/O to the appropriate WICED UART pin defined above.

 

b. platform.c: source file describing the GPIO organization which includes the Wi-Fi control pins, strapping options, essential peripherals like debug UART initialization. Customer also needs to be careful about defining the structures specific to their peripheral requirement. They can refer to the expected structure format in existing WICED supported platforms; e.g for STM32F4xx host MCU: 43xxx_Wi-Fi/WICED/platform/MCU/STM32F4xx/peripherals/platform_mcu_peripheral.h. This structure format is also dependent on the host MCU and peripheral choice.

 

This is where we define the mapping of WICED pin names to the corresponding STM32 port pins as shown in Figure 3.

 

Figure 3 GPIO pin table

GPIO pin table.jpg

Similarly, the Wi-Fi control pins and Wi-Fi SDIO pins are as shown in Figure 4

 

Figure 4 Wi-Fi control pins and SDIO pins

Wi-Fi control pins and SDIO pins.jpg

It is important to note that the WWD enums shown above have already been defined in the WWD driver and they are used during Wi-Fi initialization.

Next the WICED peripheral structure would need to be defined so that it captures all the information required for its initialization and subsequent operation. This would typically include the WICED pin names defined earlier, peripheral driver constants, register flags. The peripheral driver library is specific to a host processor, in this case, it is available in stm32f4xx.h. For instance, a typical UART peripheral is defined in Figure 5 for STM32F4XX.

Figure 5 UART peripheral configuration

UART peripherals and runtime drivers.jpg

As shown above, the WICED pin name WICED_UART_1 is defined above. The UART tx and rx pins have been mapped to the appropriate WICED GPIO pins defined earlier. The UART port is mapped to USART3 which is defined in stm32f4xx.h as a register address. The DMA configuration shown above was found from the TRM of STM32F469.

The hardware connections should be strictly made as per the mapping defined above.

The external devices such as LED, buttons, STDIO UART need to be initialized using the function platform_init_external_devices(). This function is called during MCU initialization.

The interrupt handler for a peripheral is defined using WWD_RTOS_DEFINE_ISR() and mapped to ISR using WWD_RTOS_MAP_ISR().

 

c. wifi_nvram_image.h: This is the nvram file for the WLAN module. This is supplied by the module partner. Since we are using the same Murata module used in NEB1DX_01platform, the nvram file can be interchangeably used.

 

d. platform_config.h: Clock configuration for the host MCU is provided here. For the host processor, the CPU clock frequency (CPU_CLOCK_HZ), crystal source (HSE_SOURCE), system clock divider constants (AHB_CLOCK_DIVIDER, APB1_CLOCK_DIVIDER, APB2_CLOCK_DIVIDER), PLL constants (PLL_SOURCE, PLL_M_CONSTANT, PLL_N_CONSTANT, PLL_P_CONSTANT, PLL_Q_CONSTANT, PLL_R_CONSTANT), system clock source (SYSTEM_CLOCK_SOURCE), systick clock source (SYSTICK_CLOCK_SOURCE), internal flash constants (INT_FLASH_WAIT_STATE, PLATFORM_STM32_VOLTAGE_2V7_TO_3V6), watchdog (DBG_WATCHDOG_TIMEOUT_MULTIPLIER) are used for configuring the host STM32F469. For the STM32F469 MCU, STM32CubeMX (https://www.st.com/en/development-tools/stm32cubemx.htmlSTM32CubeMX - STM32Cube initialization code generator - STMicroelectronics ) software was used. Using the STM32CubeMX tool, customers can select the target host MCU and the peripherals required for their use-case. The interactive tool also provides the option to correctly configure the clock based on the clock configuration in STM32CubeMX. The macros for Wi-Fi options WICED_WIFI_USE_GPIO_FOR_BOOTSTRAP_1, WICED_WIFI_OOB_IRQ_GPIO_PIN, WICED_USE_WIFI_POWER_PIN, WICED_USE_WIFI_32K_CLOCK_MCO and WICED_USE_WIFI_POWER_PIN_ACTIVE_HIGH need to be correctly defined as they would be used during WICED initialization. Please make sure to remove or comment out USES_RESOURCE_FILESYSTEM macro as we are putting all the resources in internal flash.

 

e. <platform_name>.mk: This is the platform makefile which contains information on the WLAN chip and host processor as well as Wi-Fi bus interface used which is SDIO for this module. Since the internal flash is enough to accommodate both Wi-Fi FW and clm blob, we have treated the memory resources as DIRECT RESOURCES (RESOURCES_LOCATION?= RESOURCES_IN_DIRECT_RESOURCES) which will build the WLAN FW and CLM blob along with the main application and put it in internal flash. The HSE_VALUE is the external crystal frequency used for clocking the host processor which is 8 MHz.

 

Creating these platform files require thorough knowledge of the host MCU. It is strongly advised to go through the datasheet and Technical Reference Manual (TRM) of the host MCU first.

 

We have interfaced the STM32F469 MCU to the Murata Type1DX through SDIO interface for which platform files should provide the correct pin mapping. To ease up the debugging, one UART port was used for which the DMA configuration, correct clock configuration, crystal selection, PLL settings need to be taken care of in platform files.

 

Essential points:

 

a. Wi-Fi control pins: These pins are used during initialization of WICED (43xxx_Wi-Fi/WICED/platform/MCU/wwd_platform_separate_mcu.c); hence the created platform file(s) should mention these pins.

 

b. Wi-Fi SDIO bus pins: For 4-bit SDIO transfer, data transfer lines (D0-D3), SDIO_CMD, SDIO_CLK along with the provision for OOB_IRQ should be provided in the platform definition. (43xxx_Wi-Fi/WICED/platform/MCU/STM32F4xx/WWD/wwd_SDIO.c).

 

Points to Check:

 

If the UART port is not working as expected, check the HW pins, PLL settings, crystal selection made in platform.config.h. To understand the clock organization better, the user can check-out 43xxx_Wi-Fi/WICED/platform/MCU/STM32F4xx/peripherals/libraries/system_stm32f4xx.c.

 

2. Creating the Memory map

The memory map for the host MCU can be generally found in 43xxx_Wi-Fi/WICED/platform/MCU/STM32F4xx/GCC as shown in Figure 6.

 

Figure 6 Memory map STM32F469

Memory map STM32F469.jpg

The user can create their own linker-script based on the memory organization of the host MCU. (STM32CubeMx software can be used to check the memory organization, but proper modification to the linker script is up-to user’s competence).

 

3. Modifying the common platform structure

 

The user must add the number of UART ports, number of SPI ports (if used) etc. for the target platform in 43xxx_Wi-Fi/WICED/platform/MCU/STM32F4xx/peripherals/platform_mcu_peripheral.h.

 

The number of flash sectors for the host MCU need to be specified separately as well in 43xxx_Wi-Fi/WICED/platform/MCU/STM32F4xx/WAF directory. The macro PLATFORM_APP_END_SECTOR needs to be defined because it would be used during the process of loading a new program and DCT into internal flash. For STM32F469, the macro was defined as per the information specified in the TRM.

 

As the source files for STM32F4xx series is already present in WICED Studio, we have enabled the platform_name macro (STM32F469_479xx) in 43xxx_Wi-Fi/WICED/platform/MCU/STM32F4xx/peripherals/libraries/stm32f4xx.h.

 

TP1: At this point, the compilation with WICED build system should pass for the created platform. The build statement should be snip.<test_basic>-<platform_name>

 

4. Adding the SDIO interface

 

If the compilation is successful, you can build and download scan application using snip.scan-CYW94343WWCD3 download run. We did not use download_apps in the build statement because we have placed our resources including WLAN firmware and CLM blob in internal flash memory. If you have used ST-Link, you can refer to the post Adding ST-Link support in WICED to enable ST-Link support in WICED. After the programming is successful, you can check the UART terminal output. If the terminal does not print the WLAN MAC address, WLAN firmware and WLAN CLM details, it means that WLAN interface was not initialised. A typical scenario is as shown in Figure 7.

 

Figure 7 WLAN interface not working

Stuck at creating packet pools.jpg

Check where the execution is getting stuck. You can enable the macro WPRINT_ENABLE_WWD_DEBUG to enable WWD debug prints. If SDIO bus does not initialize (check comment in WWD), make sure WL_REG_ON pin on the Murata module is connected to the pin defined by the index WWD_PIN_POWER in platform.c. Check SDIO clock control register for further debugging. Use SLOW_SDIO_CLK and SDIO_1_BIT in <platform_name>.mk file. 

 

If it is stuck at waiting on HT clock, the LPO has not been configured correctly. The LPO_IN pin needs to be connected to external source defined by the index WWD_PIN_32K_CLK defined in platform.c.

 

If you are getting stuck in F2, FIFO underflow could be a probable cause. Check the SDIO_STA (interrupt status) register to debug the issue. You can check wwd_sdio.c and wwd_bus_protocol.c. You can consider disabling the interrupt received flag SDIO_MASK_SDIOITIE from the SDIO mask register in STM32F4xx/WWD/wwd_sdio.c. In that case, the function wwd_bus_packet_available_to_read() would have to be commented out because this function would check for interrupt by reading the IntStatus register of the WLAN chip.

 

The patch file “WWD_changes.patch” contains the specific changes made to WWD driver discussed above which can be applied.

 

 

Test & Debug

 

a. Debugging and testing the SDIO interface

The WWD contains debug prints to indicate error or failure in function execution inside WWD. To enable WWD debugging, go to wiced_defaults.h and enable the following macros:

 

#define WPRINT_ENABLE_WWD_INFO         /* Wiced Wi-Fi Driver prints */

#define WPRINT_ENABLE_WWD_DEBUG

#define WPRINT_ENABLE_WWD_ERROR

 

Whenever the host processor needs to initialize or access the WLAN interface, it uses the SDIO interface and SDIO packets are transmitted/received across the interface. It is possible to evaluate the WWD and SDIO bus TX/RX statistics at any WWD function call to understand if there were any issues in the WWD and SDIO bus transactions. It basically provides us two types of statistics:

 

WWD Stats: This is encapsulated in the structure wwd_stats_t and it captures the TX/RX stats at WWD driver.

 

typedef struct

{

uint32_t tx_total;      /* Total number of TX packets sent from WWD */

uint32_t rx_total;      /* Total number of RX packets received at WWD */

uint32_t tx_no_mem;     /* Number of times WWD could not send due to no buffer */

uint32_t rx_no_mem;     /* Number of times WWD could not receive due to no buffer */

uint32_t tx_fail;       /* Number of times TX packet failed */

uint32_t no_credit;     /* Number of times WWD could not send due to no credit */

uint32_t flow_control;  /* Number of times WWD Flow control is enabled */

} wwd_stats_t;

 

Bus stats: This is encapsulated in the structure wwd_bus_stats_t and it contains information on SDIO TX/RX packet stats at the interface.

 

typedef struct

{

uint32_t cmd52;             /* Number of cmd52 reads/writes issued */

uint32_t cmd53_read;        /* Number of cmd53 reads */

uint32_t cmd53_write;       /* Number of cmd53 writes */

uint32_t cmd52_fail;        /* Number of cmd52 read/write fails */

uint32_t cmd53_read_fail;   /* Number of cmd53 read fails */

uint32_t cmd53_write_fail;  /* Number of cmd53 write fails */

uint32_t oob_intrs;         /* Number of OOB interrupts generated by wlan chip */

uint32_t sdio_intrs;        /* Number of SDIO interrupts generated by wlan chip */

uint32_t error_intrs;       /* Number of SDIO error interrupts generated by wlan chip */

uint32_t read_aborts;       /* Number of times read aborts are called */

} wwd_bus_stats_t;

 

The function wwd_print_stats ( wiced_bool_t reset_after_print ) evaluates the WWD packet stats and SDIO bus stats at the interface. To enable this function, enable the macro WWD_ENABLE_STATS in wiced_defaults.h. As an example, the wwd_print_stats(WICED_FALSE) is called inside SDIO/wwd_bus_protocol.c after WLAN firmware download wwd_bus_sdio_download_firmware( ) and before waiting for F2 to be ready.

 

Figure 8 Testing WWD stats

testing WWD stats.jpg

The results are shown below:

 

Working interface

 

WWD Stats..

tx_total:0, rx_total:0, tx_no_mem:0, rx_no_mem:0

tx_fail:0, no_credit:0, flow_control:0

Bus Stats..

cmd52:151, cmd53_read:0, cmd53_write:29

cmd52_fail:0, cmd53_read_fail:0, cmd53_write_fail:0

oob_intrs:0, sdio_intrs:151, error_intrs:0, read_aborts:0

 

Non-working interface

WWD Stats..

tx_total:0, rx_total:0, tx_no_mem:0, rx_no_mem:0

tx_fail:0, no_credit:0, flow_control:0

Bus Stats..

cmd52:151, cmd53_read:0, cmd53_write:29

cmd52_fail:0, cmd53_read_fail:0, cmd53_write_fail:0

oob_intrs:0, sdio_intrs:30, error_intrs:0, read_aborts:0

 

We can see that in a non-working interface, the number of sdio_intrs is far less than those in a working interface. So basically, the WWD packet stats would help us in characterizing the SDIO interface.

 

b. Testing i-perf statistics

To test the network performance of the added platform, a basic i-perf throughput test was done in normal environment between the WICED platform and a WIN 10 PC. The WIN 10 PC was set up as TCP server and the test.iperf_app was used to set up a TCP client in the WICED side (WICED board TX and PC is the RX here).

 

PC Side:

 

Run the command prompt in the i-perf directory and use the following command

 

iperf -s -w 655k

 

WICED Setup:

Build and download the test.iperf_app with the following packet pools settings in the iperf_app.mk

 

GLOBAL_DEFINES := TX_PACKET_POOL_SIZE=200 RX_PACKET_POOL_SIZE=200

GLOBAL_DEFINES += PBUF_POOL_TX_SIZE=100 PBUF_POOL_RX_SIZE=100

GLOBAL_DEFINES := WICED_TCP_WINDOW_SIZE=65535

 

iperf -c <ip_address of server> -w 655k

 

The throughput number we achieved for TCP client-server architecture is 5.66 Mbits/sec as shown in Figure 9.

 

Figure 9 I-Perf throughput

The help article for iperf set-up in WICED platform can be found at 43xxx_Wi-Fi/apps/test/iperf_app/README-Iperf.pdf.

 

General bringup issues

 

HT Avail Timeout

  • Caused due to wrong nvram.txt or the firmware.
  • Check the firmware matches the chip revision.
  • Check the LPO_IN connection.

 

Interrupt's not working/IOCTL timeout

  • Disable OOB and try with in band interrupt first.
  • For OOB, make sure that the GPIO number is provided correctly

 

Throughput Issues

 

  • Check whether we have enough bus level throughput.
  • Check whether the connection is made with proper capability. [11ac, 11n..80MHz, 40MHz etc]
  • Open air congestion might be a problem. Try it in a RF chamber.
  • Check the operating rate [wl rate].
  • Check the rssi value to see whether Antenna is proper [wl rssi].
GauravS_31

Debugging TLS in WICED

Posted by GauravS_31 Moderator Mar 12, 2018

This blog post shows how to use macros in WICED to debug TLS (Transport Layer Security) data. The mbedTLS library provides debug macros MBEDTLS_DEBUG_C, MBEDTLS_SSL_DEBUG_ALL and MBEDTLS_DEBUG_LOG_LEVEL defined in /WICED/security/BESL/mbedtls_open/include/mbedtls/config.h and they are disabled by default. You can enable those macros and define MBEDTLS_DEBUG_LOG_LEVEL as per the level of debugging required. Higher the level, more details can be captured in the logs. The log levels are defined as shown below:

 

0 No debug

1 Error

2 State change

3 Informational

4 Verbose

 

In addition, you also need to enable WPRINT_ENABLE_SECURITY_DEBUG in /include/wiced_defaults.h. Please note that debug printing consumes a lot of memory so you need to allocate at least 4 kB to the stack of every thread that uses debug printing.

This blog post demonstrates how to use Enterprise security protocols in WICED SDK with FreeRADIUS server. This was tested on WICED version Wiced_006.000.001.005, FreeRADIUS version 2.2.9 and ThreadX-NetX_Duo.

 

  1.   Ensure that you have installed freeRADIUS in your Linux PC. Log in to the system as root.
  2.   In the Linux PC, open raddb/users file and create username and password for 802.1X authentication.
  3.   Open raddb/clients.conf and add the IP address of access point which is the RADIUS client for Freeradius and shared secret. This will be used in AP configuration.
  4.   Place your root CA (Certificate Authority) and server certificates along with server private key raddb/certs folder. The same CA shall be used in /libraries/utilities/command_console/wifi/certificate.h.
  5.   Modify the raddb/eap.conf file to include the correct filenames of server private key, server certificate and CA as well as the correct certificate and CA directory. The default certificate directory is raddb/certs.
  6.   Configure the AP to include the radius server IP address and shared secret configured in clients.conf.
  7.   Write the command radiusd -X. If configuration settings are correct, you will see “Ready to process requests” in the end.
  8.   Follow the instructions in the WICED path doc/WICED-Enterprise-Security-User-Guide.pdf to configure your WICED device for enterprise security connection.

  The output would look like

join_ent prints.jpg

 

This blog post has been created to track all issues related to WICED Wi-Fi security from WICED Studio 5.x onwards. This blog will be updated regularly.

 

Unresolved:

 

Can't receive the data larger than 1447 bytes in Websocket(tls mode)?-https://community.cypress.com/message/33065#33065

TLS and azure mqtt broker-https://community.cypress.com/message/31466#31466

How to use AES-CCM APIs provided in SDK?-https://community.cypress.com/message/33044#33044

every mqtt connection consume about 8k ram-https://community.cypress.com/message/31119#31119

wiced_tcp_stream_read issues in WICED 5.2

sdk-5.2.0: snip.https_client test failure

sdk-5.2: mbedtls_open library bug

CYW4307 Cryptography Core

sdk-5.2: wiced_tls_init_identity assertion bug

console: join_ent test peap failure

debugging EAP-TLS on Wiced 3.7.0-3, server-hello failing

Handshake TLS download cert

Open source SSL/TLS Library support for WICED-SDK-3.1.2

 

Resolved:

 

Failing Client Authentication with .Net application-https://community.cypress.com/message/31617#31617

ssl_handshake_client_async freeze at state SSL_CLIENT_CERTIFICATE-https://community.cypress.com/message/32024#32024

Error: 5035 while TLS connection ?-https://community.cypress.com/message/32141#32141

TLS Support for both ECC and RSA Certificate/Key pair-https://community.cypress.com/message/33117#33117

How to change default TLS elliptic curve-https://community.cypress.com/message/33196#33196

AES_256_GCM CIPHER-https://community.cypress.com/message/33118#33118

How to know eap_type of enterprise security AP via the scan result?

How correct wifi exploit in sdk3.7 or others?

Snip.websocket_client worked without TLS but doens't work with TLS

DTLS client handshake with WICED Studio 5.0

 

 

If there are any other threads on WICED security or BESL library that have remained unresolved, kindly let me know and I will update this blog. Similarly blog posts on other issues will be created if necessary.

This snip demonstrates how a WICED device can be configured to work simultaneously as an access point and station.

 

Testing the snip step by step

Launch WICED Studio and open the apsta.c file. It is available at 43xxx_Wi-Fi/apps/snip/apsta as shown below.

apsta location.jpg

When the WICED device would work as STA, it will join the access point configured in the Wi-Fi configuration DCT. Change the Client AP SSID and Client AP passphrase so that they match with your access point as shown below. The Wi-Fi DCT configuration file wifi_config_dct.h is available at 43xxx_Wi-Fi/include.

apsta dct.jpg

We will run this snip on the platform BCM943438WCD1. Create a new make target and write the target name “snip.apsta- BCM943438WCD1 download run” without the double quotes as shown below.

Modify make target.jpg

To build and run the target, double click on the target name that we just made as shown below.

select make target.jpg

WICED will build the project and display the various steps that it is executing during the build process in the console window. The apsta snip will start running after the console displays the “Target running” message.

apsta target running.jpg

Open a UART terminal such as Tera term and select the COM port of the BCM943438WCD1 platform and configure the baud rate to 115200. The following output will be displayed on the UART terminal.

apsta terminal output.jpg

As shown above, the STA pings the gateway periodically using its IP address.

 

We shall test the WICED SoftAP interface. Connect the Wi-Fi of your computer to the SSID of the SoftAP interface configured in wifi_config_dct.h. By default, the SSID is "WICED Soft AP" and the passphrase is "abcd1234" without quotes. Open a web browser and type www.wiced.com. The server should redirect you to a page with the extension "/apps/apsta/ap_top.html" as shown below.

apsta web page.jpg

This completes the testing of the apsta snip. We shall try to understand the application code written in apsta.c.

 

Understanding the application code

In the application code, the function wiced_init() is used for initializing the RTOS, platform, WLAN radio of the WICED device.

The STA interface is brought up using wiced_network_up(WICED_STA_INTERFACE, WICED_USE_EXTERNAL_DHCP_SERVER, NULL); The last field is basically used for configuring the IP settings of the WICED device. It is assigned “NULL” because we configured the network to use external DHCP server. This uses the Dynamic Host Configuration Protocol (DHCP) to assign IP address to the STA. The STA attempts to join the AP configured in wifi_config_dct.h under the Client AP settings. If the join is successful, it obtains the IPv4 address for the STA using DHCP protocol.

 

The IPv4 address of the gateway to which the STA had connected to is then obtained using wiced_ip_get_gateway_address( WICED_STA_INTERFACE, &ping_target_ip ); This address will be used by the STA to ping the gateway.

 

An RTOS event is registered using wiced_rtos_register_timed_event( &ping_timed_event, WICED_NETWORKING_WORKER_THREAD, &send_ping, PING_PERIOD, 0 ); with a callback function send_ping( void *arg ). This callback will be triggered every PING_PERIOD ms and the function wiced_ping( WICED_STA_INTERFACE, &ping_target_ip, PING_TIMEOUT, &elapsed_ms ); will be called to ping the gateway with timeout equal to PING_TIMEOUT ms. This callback will be executed in the networking worker thread.

 

Subsequently the SoftAP interface is brought up using wiced_network_up(WICED_AP_INTERFACE, WICED_USE_INTERNAL_DHCP_SERVER, &ap_ip_settings); The ap_ip_settings contains the IP address, gateway address and netmask settings for the SoftAP. The SoftAP settings in DCT are read and the AP is started using these settings. The NetX API nx_ip_create() is used for creating an IP instance during the bring-up. Specifically the IPv4 settings, packet pools, softAP interface driver, memory, network object and priority of the IP thread are defined by the API. An RTOS thread is created to start a DHCP server and then NetX determines whether the IP address has been resolved or not. If it has been successfully resolved, NetX obtains the IPv4 address and it is displayed on UART terminal. The function wiced_dns_redirector_start( &dns_redirector, WICED_AP_INTERFACE ); is used for redirecting the URL www.wiced.com to www.wiced.com/apps/apsta/ap_top.html in the HTTP page database. Subsequently the function wiced_http_server_start ( &ap_http_server, 80, max_sockets, ap_web_pages, WICED_AP_INTERFACE, DEFAULT_URL_PROCESSOR_STACK_SIZE ) starts an HTTP webserver. The instance ap_web_pages of struct wiced_http_page_t encapsulates the redirect link "/apps/apsta/ap_top.html" which is basically found in 43xxx_Wi-Fi/resources/apps/apsta/ap_top.html. It also contains the HTTP MIME type; for instance the MIME type for "/apps/apsta/ap_top.html" is "text/html". WICED_RESOURCE_URL_CONTENT in the structure specifies that the http page ap_top.html is provided by WICED resource. It provides a resource handle structure specifying the location (whether it is in memory, filesystem or external storage), the appropriate resource handle depending on location.

Filter Blog

By date:
By tag: