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.

CC3120MOD: PSK settings for WPA/WPA2

Part Number: CC3120MOD
Other Parts Discussed in Thread: CC3120, TEST2

Hi,

I have questions about PSK in WPA/WPA2.

Q1: The user guide described "8 to 63 characters".
       Is it possible to set 64 characters in HEX format?


Q2: When I connect the module to the AP as STA mode, I use "Profiles" to configure it. (Configured using the API "sl_WlanProfileAdd")
       In order to set a 64-character HEX values (256 bits), should I set the HEX values as 64-characters of ASCII in the "SlWlanSecParams_t" key and set the KeyLen to 64?

Q3: Is there a rule for setting Uppercase/Lowercase for A to F?


In the evaluation of the actual device, it seems that 64-character HEX values can be sent as ASCII, and lower-case characters are not a problem. For example, 0x1234 can be sent as a string of "1234".
However, it differs from the specification in the user guide mentioned above. So, I need TI's opinion on this.


Best Regards,
UNA

  • Hi UNA,

    I'm working on answering your questions, I will have an update for you tomorrow.

    Best regards,

    Sarah

  • Hi Sarah,

    I am looking forward to your reply.

    Best Regards,
    UNA

  • Hi UNA,

    Apologies for the delay.

    The API always expects a ASCII passphrase, it does not accept the 64 hex digits directly. That string is then hashed to generate the 256 bit key.

    Best regards,

    Sarah

  • Hi Sarah,

    Thank you for your reply.

    Does it mean that it will not accept a 64-character hexadecimal value specified in ASCII characters?
    Or that binary values directly transferred as a simple 256-bit value will not be accepted?

    As for the current behavior, it seems that the AP with the key set to 256 bits is able to connect to the CC3120MOD even when the ASCII code of 64 characters is sent to it.

    AP Key:
      111111111122222222223333333333444444444455555555556666666667777 (256bit)

    The password string to be set for the CC3120MOD:
      111111111122222222223333333333444444444455555555556666666667777 (ASCII)

    Best Regards,
    UNA

  • Hi UNA,

    Both of those strings are only 63 characters. Can you verify the format of your input?

    Best regards,

    Sarah

  • Hi Sarah,

    Is my understanding of the following correct?

     Only ASCII passphrases of up to 63 characters are supported.

     Direct transfer of binary values as 256-bit values will not be accepted.

    Best Regards,
    UNA

  • Hi UNA,

    Yes, that is correct.

    Best regards,

    Sarah

  • Hi Sarah,

    Let me check one thing.
    You say it supports up to 63 characters, but the software provided by TI seems to be able to set up to 64 characters as shown below.

    wlan.c(simplelink_sdk_wifi_plugin_4_20_00_1)

      #define MAX_KEY_LEN           (64)


    In addition, the AP Key and the password set for CC3120 presented in the previous section were incorrect, but in fact, I have sent 64 characters as shown below.

    AP Key:
      1111111111222222222233333333334444444444555555555566666666667777 (256bit)

    The password string to be set for the CC3120MOD:
      1111111111222222222233333333334444444444555555555566666666667777 (ASCII)

    Why is there a difference between the user guide and the software restrictions?
    As a software, it can be set up to 64 characters, but does this mean that it has not been verified?

    Best Regards,
    UNA

  • Hi UNA,

    That was my understanding, but I will double check.

    Are you connecting without any errors?

    Best regards,

    Sarah

  • Hi Sarah,

    Sarah P said:

    Are you connecting without any errors?

    Yes, The CC3120 and AP are connected without any problems.


    Best Regards,
    UNA

  • Hi Sarah,

    I would appreciate it if you could reply to us as soon as possible, as this issue affects the product specifications of our customer.
    Since the customer is already in the mass production stage, it may be necessary to revise the customer's product specifications.

    Best Regards,
    UNA

  • Hi UNA,

    I have verified that the NWP will accept and connect with 64 characters representing hex digits. The max key length allowed in the host driver changed between device generations, so the documentation may be reflecting the older version. Please give me another day to determine how this key is handled in the NWP.

    Best regards,

    Sarah

  • Hi Sarah,

    Thank you for your reply.

    The customer have allowed 64 characters representing hex digits in their product specifications.
    So, we hope that the product specification of the NWP will be changed accordingly.

    Best Regards,
    UNA

  • Hi Sarah,

    What is the status of this issue? We are in a hurry because the customer's mass production schedule is coming soon.

    Best Regards,
    UNA

  • Hi UNA,

    Providing the 64 hex digits as a string looks functional from my inspection, but it is not part of our quarterly test cycle. We can consider updating the documentation once this is added to testing, but I do not have a timeline on that.

    Best regards,

    Sarah

  • Hi Sarah,

    When is the next timeline to add the test item?

    In addition, the following strings did not work properly in the tests conducted by the customer.


    Test1: 0000000000000000000000000000000000000000000000000000000000000000
    Test2: 1000000000000000000000000000000000000000000000000000000000000000
    Test3: 1000000000000000000000000000000000000000000000000000000000000001

    Could you tell me if there is a range of values that can be entered?


    Best Regards,
    UNA

  • Hi UNA,

    I currently do not have a committed timeline, but we typically test at the end of each quarter. We recently completed testing for this quarter.

    Unfortunately, without testing or documentation, I do not know the limitations of this function. Since it is not documented, the customer would be using this at their own risk.

    Best regards,

    Sarah