This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

LAUNCHXL-CC3235S: CC3235S

Part Number: LAUNCHXL-CC3235S
Other Parts Discussed in Thread: CC3235S, UNIFLASH

We have been using the CC3235S as a Wi-Fi Client to Connect to an Access Point utilizing EAP-TLS (Enterprise Security) with the SDK 3.20.00.06 (28 Jun 2019) without issue.

Upon upgrading the SimpleLink SDK to 3.40.00.05 (30 Jan 2020) we are now receiving the following abort/error information upon attempting to establish a connection (sl_WlanConnect) via the callback "SimpleLinkFatalErrorEventHandler":

[ERROR] - FATAL ERROR: Abort NWP event detected: AbortType=2, AbortData=0x24c (588)

[Note: We have not changed the Application software (MCU image) or the certificates (/sys/cert/ca.der, /sys/cert/client.der, /sys/cert/private.key) only the underlaying SDK bin.]

1.) Can TI provide information on what the Abort Data is attempting to tell us

2.) What information can be shared in the handling of EAP-TLS between these SDK versions (i.e. can not see any change information indicating a non-backwards compatible EAP-TLS handling being introduced).

A breakdown between the last 4 SDK versions:

 

TI SDK

EAP-TLS : Connection

3.20.00.06 (28 Jun 2019)

Works – Successful Connection as designed

3.20.01.01 (11 Sept 2019)

Works – Successful Connection as designed

3.30.00.04 (4 Oct 2019)

Fails ([ERROR] - FATAL ERROR: Abort NWP event detected: AbortType=2, AbortData=0x24c (588))

3.40.00.05 (30 Jan 2020)

Fails ([ERROR] - FATAL ERROR: Abort NWP event detected: AbortType=2, AbortData=0x24c (588))

 

 

Thanks,

/David

  • Hi David,

    AbortType 2 indicates that the fatal error was a SL_DEVICE_EVENT_FATAL_DRIVER_ABORT. This usually indicates something went wrong in the host driver. Often this is due to bad porting of the host driver to a non-TI platform, or some memory corruption that causes the host driver to misbehave, but this seems less likely in your case since you say that you did not change the MCU binary at all.

    To clarify, is the only file that you've changed on your setup the NWP servicepack that you provide to your system through Uniflash?

    There have been two main changes to the EAP handling of the NWP. The first is support for RSA 4096bit keys, and the second is a bugfix to allow the CC3235 to handle rekeying the EAP connection. Neither of those two should result in the abort you're seeing though.

    Could you please collect NWP logs from the CC3235 so I can review them and debug this issue from the NWP side and ensure there isn't an issue due to the two changes above? You can find instructions for how to collect those logs in my post here: https://e2e.ti.com/support/wireless-connectivity/wifi/f/968/p/874487/3241971#3241971

    Collecting a set of logs as you run the NWP servicepack from the 3.20.x.x SDK and another set with the latest servicepack would be helpful, to allow me to see what differences there are between the working case and the abort case.

    Regards,

    Michael

  • Hello Michael:

     Regarding -

    >> To clarify, is the only file that you've changed on your setup the NWP servicepack that you provide to your system through Uniflash?

    That is correct - all we change is the Service Pack File as identified within UniFlash and move between the two SDKs (sp_4.3.0.5_3.1.0.5_3.1.0.18.bin and sp_4.5.0.11_3.1.0.5_3.1.0.25.bin)

    >> Collecting a set of logs as you run the NWP servicepack from the 3.20.x.x SDK and another set with the latest servicepack would be helpful, to allow me to see what differences there are between the working case and the abort case.

    This first log attached is while using the SDK simplelink_cc32xx_sdk_3_20_00_06 -> sp_4.3.0.5_3.1.0.5_3.1.0.18.bin:

    /cfs-file/__key/communityserver-discussions-components-files/968/sp_5F00_4.3.0.5_5F00_3.1.0.5_5F00_3.1.0.18_5F00_nwp.log


    Next log attached is while using SDK simplelink_cc32xx_sdk_3_40_00_05 -> sp_4.5.0.11_3.1.0.5_3.1.0.25.bin

    /cfs-file/__key/communityserver-discussions-components-files/968/sp_5F00_4.5.0.11_5F00_3.1.0.5_5F00_3.1.0.25_5F00_nwp.log

    Note: We see the mobile station setup a physical connection to the Access Point and begin the exchange of EAP messages but never progresses to exchanging certificates.

    Thanks,
    /David

  • Hi David,

    Looking at your logs, it does seem like there is a fatal NWP error in your 4.5.0.11 logs, but not in your logs using the 4.3.0.5 logs. It looks like it is related to something in the TLS handshake during the initial connection between the CC3235 and the EAP radius server.

    I will need to investigate this and see if I can replicate this on my end in order to debug further. To help me with that, could you please describe your EAP setup in detail? Like what device you are using as your AP, what you have as your radius server and how that is configured, everything that could help me setup my EAP setup to match what you have.

    Regards,

    Michael

  • Hello Michael:

    Regarding - 

    >> I will need to investigate this and see if I can replicate this on my end in order to debug further. To help me with that, could you please describe your EAP setup in detail? 

    Behavior has been observed on an MicroTik Wi-Fi router and our own product which present a Wi-Fi Access Point.

    Wi-Fi Access Point software components, running on a Linux OS:

    hostapd                     v2.9
    freeradius                  3.0.17-r1  (i.e. RADIUS Server)

    The hostapd configuration file is attached below - of course align the hostapd "auth_server_shared_secret" and "acct_server_shared_secret" configuration to the radius clients.conf client "secret" configuration).


    Abort behavior is observed with the default RADIUS eap configuration, which has been included for completeness (i.e. not exposing any of our settings).


    In the test environment we are managing our own certificates (ca, clients, server) using the tools provided by freeradius (see raddb/certs).

    Thanks,
    /David

  • Hello:

    Currently any/all of our posts with attachments are failing with:

    "An error occurred. Please try again or contact your administrator."

    Is there an email address that we can send the hostapd.conf and eap configuration files to you directly.


    Thanks,
    /David 

  • Hello Michael:

    Any comment about TI's ability to reproduce or need for additional information?


    Thanks,
    /David

  • Hi David,

    To send me the config files, uploading the files to google drive or a similar file storage system would work, assuming that you are still unable to attach the files to E2E posts.

    I currently no longer have access to my WPA-EAP capable router, but have been looking at the differences between the servicepacks and checking to see what may be causing the issue. The config settings would still be useful though as I can provide them to a coworker with a setup to reproduce and see what adjustments are needed to the NWP to fix this issue.

    Regards,

    Michael

  • Hello Michael:

    We have reproduced this issue using a Raspberry Pi 3B+, running:

     

    Hostapd v2.8

    FreeRadius v. 3.0.17

     

    Do you have access to a Pi to reproduce the situation on.

     

    [main - 3794803215] [ERROR] - FATAL ERROR: Abort NWP event detected: AbortType=2, AbortData=0x24c

    [main - 3794803215] Error [0] at line [123] in function [SimpleLinkFatalErrorEventHandler]

     

    Thanks,

    /David

     

     

     

  • Hello:

    Below are two links to access the hostapd configuration file and the complete /etc/freeradius/3.0/ directory used on the Pi.

    We have removed our self signed certificates (ca.pem and server.pem), located at freeradius/3.0 based on mods-available/eap configuration file.  You will need to create your own aligned certificates for the device (Wi-Fi client) and radius server.

    https://www.dropbox.com/s/mxuaxmy77c4h1nn/hostapd_wlan0.conf?dl=0

    https://www.dropbox.com/s/mt13bhkngydd4mw/freeradius.zip?dl=0


    These are pretty much default (out-of-the-box) configuration files for hostapd and freeradius.

    Thanks,
    /David

  • Hi David,

    Thanks for providing me those config files. I do have a set of certs for use with my radius server setup so I should be good to go there.

    Unfortunately, I do not currently have access to a raspberry pi or another EAP-capable AP. I will work on getting a setup running and replicate your results. This may take a while due to current public health circumstances and I appreciate your patience.

    Regards,

    Michael