CC3235MODASF: Cannot connect using WP2-Enterprise

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

Michael,

I uploaded a new capture file. The file is dated 20210422. Also included is the Windows Server error log entry for the unsuccessful connection attempt.

Regards.

Hi,

Thanks for providing the latest set of logs. Having the new wireshark captures include the responses from the CC3235 is extremely helpful.

In fact, when combined with the info from the Windows Server, the cause of the issue seems pretty clear - there is no user identity provided to the EAP server by the CC3235.

Do you set the entUserName parameter when using the wlanconnect command in network terminal?

Looking through the network terminal code, there might actually be a bug in the command parser. In ParseConnectCmd() of cmd_parser.c, the wlanconnect command is parsed, and info such as the SSID, key, etc is extracted from the command string. In there is a

if(entUserName) check, which is supposed to copy the provided entUserName from the command string to the secParamEnt struct. However, it appears that the copy is not performed correctly. Please use this code instead:

if(entUserName)
    {
        ConnectParams->secParamsEnt.UserLen = strlen(entUserName);
        ConnectParams->secParamsEnt.User = calloc(
            sizeof(uint8_t), ConnectParams->secParamsEnt.UserLen);
        strcpy(ConnectParams->secParamsEnt.User, entUserName);
        ConnectParams->secParamsEnt.AnonUser = NULL;
        ConnectParams->secParamsEnt.EapMethod =
                SL_WLAN_ENT_EAP_METHOD_PEAP0_MSCHAPv2;
        ConnectParams->secParams.Type = SL_WLAN_SEC_TYPE_WPA_ENT;
        ConnectParams->dateTime.tm_year = DEVICE_YEAR;
        ConnectParams->dateTime.tm_mon = DEVICE_MONTH;
        ConnectParams->dateTime.tm_day = DEVICE_DATE;
    }

Let me know if that fixes your issue.

Regards,

Michael

Hi Michael,

The code you provided solved that problem. Unfortunately, the connection is still timing out. This time it times out further along the EAP authentication process. 

I downloaded the latest logs I've taken to the shared folder. I also attached the certificate that was exported from the Windows Server. As I have pointed out before, I've successfully tried the same certificate in other devices.

Thanks.

Gabino

Hi Gabino,

Thank you for providing the debug info.

Looking at the NWP logs and the Windows Server logs, there are a couple things to check:

1. Try to make the cert/ca.der file into an unsecured file. This is to eliminate the file security as a source of error

2. Does your server require a client certificate file? It is quite rare for this to be the case for PEAP_MSCHAPv2 setups, but want to make sure this is case.

3. There may be an authentication error at the RADIUS server causing your issues - have you double-checked to ensure that the username and password you're providing matches what's expected at your server?

Also, looking at the Windows server output, it seems like there is further logging data available, with the actual failure reason as described being written to another log file:

"An error occurred during the Network Policy Server use of the Extensible Authentication Protocol (EAP). Check EAP log files for EAP errors."

Can you find this log and check if there is a more concrete failure reason listed?

Regards,

Michael

Also, here is an E2E thread where I provide the full set of changes and instructions for how to use PEAP_MSCHAP through network terminal. I suggest you take a look and see if there is anything different compared to your setup.

https://e2e.ti.com/support/wireless-connectivity/wifi/f/wi-fi-forum/900299/compiler-cc3235s-how-to-config-cc3235s-enterprise-wifi/3329939#3329939

Regards,

Michael

Michael and all,

Customer is still working to get the WPA2-enterprise connection to work successfully.

 We have two questions: 

1. Is there any easy way for non-TI personnel to view the NWP logs?
2. Would like to step through the WiFi driver’s source code. We believe the TI projects are setup to use the precompiled .dll driver binaries. What do they need to do to change it to source code instead, if that is possible?

TY,
CY

Hi CY,

1. No, the NWP logs contain proprietary information, and so can only be decoded by TI engineers.

2. Is the customer referring to the NWP host driver source code? By default, you simply link against the pre-built libraries, but the source code is provided in the SDK, at source/ti/drivers/net/wifi/source. The customer can copy the source files into their project, and have them be built just like any other source file, if they wanted to be able to single-step through the NWP host driver code without the library's optimization affecting the debugger.

Regards,

Michael

Thanks Michael,

1. Understood on the proprietary nature of the logs.

2. Yes, Host driver source.  I think this is what we will concentrate on during our session tomorrow.

Hopefully Gabino has a chance to review your other comments on this thread prior.

Thanks all,

Chris