• State TI Thinks Resolved
  • +1 person also asked this people also asked this
  • Locked Locked
  • Replies 6 replies
  • Answers 2 answers
  • Subscribers 42 subscribers
  • Views 840 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

LAUNCHCC3235MOD: WIFI enterprise and TLS 1.2

Sundaresan Thangeswaran1
Intellectual 410 points
Part Number: LAUNCHCC3235MOD
Other Parts Discussed in Thread: CC3200, CC3300

Hi All,

We are using CC3200 for our IOT devices from the year of 2017. This year we upgraded to CC3235, and we thought that it was going to support all kinds of updated networks. But still, the new version of CC3235 does not support EAP TLS 1.2.

We have received a few complaints from our clients for not supporting TLS 1.2.

We are going to lose many of the clients if we don't support EAP TLS 1.2 in the CC3235 chipset.

Do you have any ETA for resolving this issue.

Regards,

Sundar

  • 0
    Guru 79335 points

    Hi Sundar,

    We have same issue. Many big companies does not allow to use TLS 1.0 (regardless if is for sockets or EAP).

    I have discussion with TI about support TLS 1.2 for CC3220 / CC3235 many times. Their statement is that there are no plans for TLS 1.2 support for EAP. They said this is not possible due to lack memory for TLS 1.2 for EAP. We had discussion about technical details which I can't share here. As to be honest, they never convinced me about technical reasons. But I still think that main reason is that TI focusing development effort to new generation (CC3300, etc.) rather than development of current devices (CC3220 / CC3235). I think this my speculation confirming much lower release rate of new CC32xx SDK.

    Jan

  • 0 in reply to Jan D
    TI__Guru 63006 points

    The memory issue is a real one.

    The CC32xx NWP is ROM Based with patches in internal RAM (the patches makes the content of the service pack).

    The current service pack already consumes most of the available RAM (and patch entries) and after we made a deep investigation we found out that there won't be enough space for he TLS1.2 support.

  • 0 in reply to Kobi Leibovitch
    Guru 79335 points

    Hi Kobi,

    Why not create way to transfer TLS stack for EAP supplicant to application processor? As far I know that this should be possible.

    Jan

  • 0 in reply to Jan D
    TI__Guru 63006 points

    It can only be done by using transceiver mode (i.e. using wpa_supplicant entirely in the host). 

    If we want to use the supplicant in the NWP and use the app processor only for TLS - we will need to implement the extra interfaces in he NWP (and host) - this approach was also checked but it also require too much patch space (the issue is not just with regards to the RAM size but also to the number of patches the h/w supports).

  • 0 in reply to Kobi Leibovitch
    Intellectual 410 points

    Hi Kobi/Jan,

    Thank you so much for the reply. Our clients are expecting a solution in a short period of time. Would it be possible to remove a few functionalities from the existing service pack and release a new service pack that only supports the EAP-TLS 1.2 connection? 

    Is there any other workaround, like adding extra flash memory or some pre-programmed chip?

    If I go to the wlanconnect function, it takes me to the wlan.c file, but I cannot see any WIFI probe request response. Where can I see this, and is it possible to debug?

    Is it possible to develop our own code to handle TLS 1.2 from here?

    Regards,

    Sundar

  • 0 in reply to Sundaresan Thangeswaran1
    TI__Guru 63006 points

    In order to see wifi management packets (like probe request) you will need to switch to a transceiver mode (see chapter 13 in the programmer's guide). In this mode the entire 802.11 (Wi-Fi) stack will need to be implemented on the host. There is no short-time solution here.

    Unfortunately, in the NWP we don't have even a long term solution.