CC3235MODASF: Cannot connect using WP2-Enterprise

Part Number: CC3235MODASF
Other Parts Discussed in Thread: UNIFLASH

Hi,

I haven't been able to connect to a WPA2-Enterprise network set for PEAP-MSCHAPv2..

I'm using the Network_Terminal example with the following modifications to the :cmdWlanConnectCallback() function:

1) Added code to flash the root certificate.

2) Added code to set the time.

The complete changes to the Network_Terminal examples are shown below:

//********** CA Certificate in PEM format *********************

const char TestCA[] =
"-----BEGIN CERTIFICATE-----\r\n"
"MIIDmTCCAoGgAwIBAgIQVtgg1/LEcY9N46LX/IxE2DANBgkqhkiG9w0BAQsFADBe\r\n"
"MRMwEQYKCZImiZPyLGQBGRYDY29tMRcwFQYKCZImiZPyLGQBGRYHZG9tYWluMTES\r\n"
"MBAGCgmSJomT8ixkARkWAmdsMRowGAYDVQQDExFnbC1XSU5TRVJWRVIwMS1DQTAg\r\n"
"Fw0yMTA0MDQxNzAzNTVaGA8yMDcxMDQwNDE3MTM1NVowXjETMBEGCgmSJomT8ixk\r\n"
"ARkWA2NvbTEXMBUGCgmSJomT8ixkARkWB2RvbWFpbjExEjAQBgoJkiaJk/IsZAEZ\r\n"
"FgJnbDEaMBgGA1UEAxMRZ2wtV0lOU0VSVkVSMDEtQ0EwggEiMA0GCSqGSIb3DQEB\r\n"
"AQUAA4IBDwAwggEKAoIBAQCxtTq1GWH77Bj+tarT7DV5NJV0xJLW3/T/uzxG5z4b\r\n"
"YSGddc0Wq7RRFQ6QcyCpNNeKoZ65PVetnMQl35BXRLvJLYCMhCNykSOPFtJ9K4Pq\r\n"
"QvPDWnwaw8eVl/40pB+TgNZtgKXY5iJjW6cqhXew4+feB4XMnUg0ghXiyD6ffP2g\r\n"
"F9XQ5cGoZTQd9h3JAuOfGgjyhl+m+RTjfRBPfAEVxB2lWKr0oRpf0p9B48lubjru\r\n"
"++w+cc24fPSZqD+9cRR5Y81DhgoBHNEPIdke6EQePPZOB5+He5ioHKgTDTqVP55J\r\n"
"4ezij2tjtgcpH63uCGDMAMl45fC7rfEZg/tpBj8StXTdAgMBAAGjUTBPMAsGA1Ud\r\n"
"DwQEAwIBhjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBT0VZ4XG1CexdRJsioN\r\n"
"jh5weuelHDAQBgkrBgEEAYI3FQEEAwIBADANBgkqhkiG9w0BAQsFAAOCAQEAqR99\r\n"
"eKiZR8Vl7spiCHss3oIK9JfVJXRmcenTHDF+OcLU1BcZr67zIyoXKRNSgwmLWiGq\r\n"
"/IBfcK4Ho0DC+sAlZAwmMqDMBDDB60oJXVXZrdvOUafaiykHcr6IV6eGGGNJdFrv\r\n"
"qifRW60bgEWerwNVWjyrgf8JRzqArfv5uNDzKWoZOozXoA+YBW9hk3P3MMM/UGZ+\r\n"
"zpeBqT4/gAe2U6itpi6aVt7d4pE9znpCEZBwTIrtRPu28AALaOSaTfCa/faVBTPl\r\n"
"wBV039mAnSCk/Bq6zzfV8lCaQx0GK2vDAkxak6DgZN0DHNQpfLm+8ApogyJubvbA\r\n"
"wykJOTysAdiTLjC++w==\r\n"
"-----END CERTIFICATE-----\r\n"
;

//******  Code to flash certificate  *********************
unsigned long g_tokens[4];
int16_t flashCerts(uint8_t *certName, uint8_t *buffer, uint32_t bufflen, uint32_t maxlen, bool overwriteCerts)
{
int ret = 0;
int16_t slStatus = 0;
SlFsFileInfo_t fsFileInfo;
int32_t fileHandle;

g_tokens[SL_FS_TOKEN_MASTER] = 0x12345678;

/* Check if the cert file already exists */
slStatus = sl_FsGetInfo(certName, 0, &fsFileInfo);

/* If the cert doesn't exist, write it (or overwrite if specified to) */
if (slStatus == SL_ERROR_FS_FILE_NOT_EXISTS || overwriteCerts == true)
{
fileHandle = sl_FsOpen((unsigned char *)certName,
SL_FS_CREATE | SL_FS_CREATE_SECURE | SL_FS_CREATE_VENDOR_TOKEN | SL_FS_CREATE_NOSIGNATURE
| SL_FS_CREATE_PUBLIC_READ | SL_FS_CREATE_PUBLIC_WRITE | SL_FS_OVERWRITE
| SL_FS_CREATE_MAX_SIZE(maxlen), &(g_tokens[SL_FS_TOKEN_MASTER]));
if (fileHandle > 0)
{
ret = sl_FsWrite(fileHandle, 0, (unsigned char *)buffer, bufflen);
sl_FsClose(fileHandle, NULL, NULL, 0);
}
}
return ret;
}

//******** modified cmdWlanConnectCallback ************

int32_t cmdWlanConnectCallback(void *arg)
{
int32_t ret = 0;
ConnectCmd_t ConnectParams;

/* Call the command parser */
memset(&ConnectParams, 0x0, sizeof(ConnectCmd_t));
ret = ParseConnectCmd(arg, &ConnectParams);

if(ret < 0)
{
FreeConnectCmd(&ConnectParams);
return(-1);
}

ret = flashCerts("/sys/cert/ca.der", (uint8_t *)TestCA, strlen(TestCA), 2048, 0);


/*
* Check to see if the NWP is in STA role,
* since it has to be in STA role in order to connect to an AP.
* If it isn't - set role and reset the NWP.
*/
if(app_CB.Role != ROLE_STA)
{
ret = sl_WlanSetMode(ROLE_STA);
ASSERT_AND_CLEAN_CONNECT(ret, WLAN_ERROR, &ConnectParams);

ret = sl_Stop(SL_STOP_TIMEOUT);
ASSERT_AND_CLEAN_CONNECT(ret, DEVICE_ERROR, &ConnectParams);

ret = sl_Start(0, 0, 0);
ASSERT_AND_CLEAN_CONNECT(ret, DEVICE_ERROR, &ConnectParams);

/* Here we are in STA mode */
app_CB.Role = ret;
}

/* Set static IP configurations, if needed - otherwise,
IP would be allocated by your network's DHCP server. */
if(ConnectParams.ip)
{
ret =
setStaticIPConfig((uint8_t*)(ConnectParams.ip),
(uint8_t*)(ConnectParams.gw),
(uint8_t*)(ConnectParams.dns));
ASSERT_AND_CLEAN_CONNECT(ret, CMD_ERROR, &ConnectParams);
}

/* Set device time and date before connection to ENT network, if needed */
if(ConnectParams.secParamsEnt.User != NULL)
{
ConnectParams.dateTime.tm_sec = 0;
ConnectParams.dateTime.tm_min = 0;
ConnectParams.dateTime.tm_hour = 0;
ConnectParams.dateTime.tm_day = 7; /* 1-31 */
ConnectParams.dateTime.tm_mon = 4; /* 1-12 */
ConnectParams.dateTime.tm_year = 2021; /* YYYY 4 digits */

ret =
sl_DeviceSet(SL_DEVICE_GENERAL, SL_DEVICE_GENERAL_DATE_TIME,
sizeof(SlDateTime_t),
(uint8_t *)(&ConnectParams.dateTime));
ASSERT_AND_CLEAN_CONNECT(ret, DEVICE_ERROR, &ConnectParams);

/* Connect to ENT AP */
ret =
sl_WlanConnect((const signed char *)(ConnectParams.ssid),
strlen(
(const char *)(ConnectParams.ssid)), 0,
&(ConnectParams.secParams),
&(ConnectParams.secParamsEnt));
ASSERT_AND_CLEAN_CONNECT(ret, WLAN_ERROR, &ConnectParams);
}
else
{
/* Connect to AP */
ret =
sl_WlanConnect((const signed char *)(ConnectParams.ssid),
strlen(
(const char *)(ConnectParams.ssid)), 0,
&ConnectParams.secParams, 0);
ASSERT_AND_CLEAN_CONNECT(ret, WLAN_ERROR, &ConnectParams);
}

/* Wait for connection events:
* In order to verify that connection was successful,
* we pend on two incoming events: Connected and Ip acquired.
* The semaphores below are pend by this (Main) context.
* They will be signaled once an asynchronous event
* Indicating that the NWP has connected and acquired IP address is raised.
* For further information, see this application read me file.
*/
if(!IS_CONNECTED(app_CB.Status))
{
ret = sem_wait_timeout(&app_CB.CON_CB.connectEventSyncObj,
WLAN_EVENT_TOUT);
if(ret == TIMEOUT_SEM)
{
UART_PRINT("\n\r[wlanconnect] : Timeout expired connecting to AP: %s\n\r",
ConnectParams.ssid);
FreeConnectCmd(&ConnectParams);
return(-1);
}
}

if(!IS_IP_ACQUIRED(app_CB.Status))
{
ret = sem_wait_timeout(&app_CB.CON_CB.ip4acquireEventSyncObj,
WLAN_EVENT_TOUT);
if(ret == TIMEOUT_SEM)
{
/* In next step try to get IPv6,
may be router/AP doesn't support IPv4 */
UART_PRINT(
"\n\r[wlanconnect] : Timeout expired to acquire IPv4 address.\n\r");
}
}

if(!IS_IPV6G_ACQUIRED(app_CB.Status))
{
ret = sem_wait_timeout(&app_CB.CON_CB.ip6acquireEventSyncObj,
WLAN_EVENT_TOUT);
if(ret == TIMEOUT_SEM)
{
UART_PRINT(
"\n\r[wlanconnect] : Timeout expired to acquire IPv6 address.\n\r");
}
}

if(!IS_IPV6G_ACQUIRED(app_CB.Status) &&
!IS_IPV6L_ACQUIRED(app_CB.Status) && !IS_IP_ACQUIRED(app_CB.Status))
{
UART_PRINT("\n\r[line:%d, error:%d] %s\n\r", __LINE__, -1,
"Network Error");
}

FreeConnectCmd(&ConnectParams);
return(0);
}

I have several questions:

1) Can you provide guidance as to what I could be doing wrong?

2) The swru455 documentation states that the certificate should be in PEM format but then goes on to state that the file name should be /sys/cert/ca.der. Is the .der file extension correct?

3) In order to obtain  NWP logs, swru455 section 20 instruct to configure pin_62 as the UART pin. For the CC3235MODASF, pin 62 is a ground pad. Can you clarify?

Thanks.

  • Hi,

    1. The main thing to note is that for your cert file, you shouldn't put a \r\n for the final "-----END CERTIFICATE-----\r\n" line. That might be causing your issue.  Beyond that, seeing the NWP logs will be required to be able to effectively debug your issue - it's difficult to say without that output as well as the radius server output what might be going wrong during the connection.

    Something you can do is you can use Uniflash to flash the cert file directly to the CC32xx filesystem, without needing to perform the cert flashing in your code and thus eliminate this as a potential source of error.

    2. Yes, the info provided in www.ti.com/lit/swru455 is correct. You need to have the cert in PEM format, but named as a .der on the filesystem.

    3. The instructions specify the pin_62 signal should be used. This is in reference to the CC32xx IC devices, not the module. For the module you will need to use the pin that corresponds to the internal IC's pin 62. Pin 62 on the CC3235 IC is used for GPIO7. GPIO7 is brought out on pin 52 on the CC32xx modules, so that is the pin that you will need to connect your UART to PC adapter to. Do note that the actual code on the CC3235 that you run will still use pin_62.

    Regards,

    Michael

  • Hi,

    I removed the "\r\n" from the last line. That did not change the results.

    I have a NWP log. How do I attach a file to this thread?

    The attempt to connect did not generate a Server log. It is likely that the operation failed before the NWP reached out to the server.

  • Hi,

    I sent you a friend request, with a link to a shared folder. Please upload your NWP log file to that folder.

    Regards,

    Michael

  • Hi,

    I saw the friend request but I missed the link to the shared folder. 

  • Hi,

    I've downloaded the log provided in the shared folder, but it appears to be corrupt. Have you ensured that you are using the correct UART capture settings? Please also do ensure that you are capturing all binary data, and not just ASCII printable characters.

    There is also a sanity check you can perform on your collected logs before you provide them to me. If the NWP logs are captured successfully from cold boot, you should see some ASCII plaintext in the raw binary logs, most notably the /sys/servicepack.ucf NWP SP file. Furthermore, the 3 bytes of binary data preceding that string will be 0x27 0xCA 0x2F. If you check for the string + those 3 bytes and see it in your logs, and also see that there are null characters present, then it should be captured correctly and decodable by my tools.

    Please recapture the logs following the advice above and reupload them to the shared folder.

    Thanks,
    Michael

  • Hi Michael,

    file CC3235_Log_20210413.log was uploaded to the shared folder.

    Thanks.

  • Hi,

    Thanks for providing those new logs, I can successfully decode them.

    Looking through the logs, it appears that there is one failed EAP connection attempt:

    The logs indicate that the connection attempt failed somewhere during the EAP server handshake. In your previous post, you mentioned that there is no output from the EAP server. Can you double-check to ensure that is the case?

    Regards,

    Michael

  • Hi Michael,

    I uploaded WireShark logs to the shared folder. 

    For reference I also included captures from two other devices, a Windows PC and a smartphone. Both of these devices connected successfully.

    Thanks.

  • Hi,

    Thanks for providing those logs. Looking at the difference between the unsuccessful CC3235 log and the other device logs, it seems like the EAP connection process gets stuck right after the CC3235 responds to the EAP Identity packet. This is consistent with the NWP log data.

    Now, it seems like the logs only record the packets outgoing from the AP, and doesn't have the responses from the CC3235. Can you check your filter setting and provide me the logs with the CC3235 responses? Seeing what the CC3235 sends back to the AP is a key part of the debug, as looking at the logs above it appears that the CC3235 simply doesn't receive any further packets from the AP despite sending the correct response.

    Also, can you check the EAP server debug output to see if there is any reason that the server might perhaps decide to terminate the connection attempt and not send any response back to the CC3235?

    Regards,

    Michael