• State TI Thinks Resolved
  • Locked Locked
  • Replies 7 replies
  • Answers 1 answer
  • Subscribers 43 subscribers
  • Views 581 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

CC3220R: % character in SSID or password not supported?

Wolfgang Wendler TI
Intellectual 2240 points
Part Number: CC3220R

Hi,

Asking on behalf of a customer:

We have an issue that makes provisioning fail if % character is present in SSID or password. I have investigated the problem and it is located in the provisioning functions supplied in the TI SDK.

 It is quite easy to reproduce the bug with the Out-of-Box demo supplied with the SDK. The SSID "W&ifi%2BSerial" becomes "W&ifi+Serial" in the TI demo. (I used the demo to illustrate the problem since the software library used in the demo is the same as we use in final product).

 Some in depth details from my analysis that can be useful:

The password and SSID are posted as x-www-form-urlencoded, '%' is encoded as '%25' in this format. When decoded on the cc3220 '%25' gets messed up and the result depends on the characters following '%25'.
Ex. if the SSID is 'Hi%2B' then it ends up as 'Hi+', this would have been the correct result if the SSID acutally were 'Hi+' since the encoding for 'Hi+' is 'Hi%2B'.

Another example, 'Hi%25' becomes 'Hi%'.

Thanks,

/ Wolfgang

  • 0
    TI__Guru 63006 points

    Hi Wolfgang,

    If I understand correctly, the value "Hi%252B" should work  in this case(I can't test this today).

    If this is true, then you can update the app code to go over the user input and replace "%" with "%25" before the string is sent to the cc32xx.

    Br,

    Kobi

  • 0 in reply to Kobi Leibovitch
    Prodigy 50 points

    Hi Kobi, thanks for the reply.
    I'm the customer :)

    You are right, it is possible to replace "%" with "%25" in the string before encoding and sending (i.e. "%" will then be encoded as "%2525").

    But I don't think this is the way to go. It is not according to standard and it stop to work if/when the SDK library is updated.

    Best regards
    Jonas

  • 0 in reply to Jonas Lundberg
    TI__Guru 63006 points

    Hi Wolfgang,

    Why do you need to use "%2525" (rather than just "%25") to replace a "%"? I thought the string is only encoded (once) by the HTTP server.

    I dont see any better short term solution and I dont understand why it will stop working upon an SDK update (unless you meant the Starter Pro Code release)

    We raised the issue internally and will fix it in one of the next Starter Pro releases (but the fix will probably be similar). I can't commit to a date for such release.

    Br,

    Kobi

  • 0 in reply to Kobi Leibovitch
    Prodigy 50 points

    Hi Kobi,

    I mean the SDK, we are using the provisioning functions in the SimpleLink library in the product FW.

    Let me explain a bit more.

    Provisioning is done with an mobile app that connects to the device in AP mode.
    The user enters WiFi credentials and they are sent to the HTTP provisioning server supplied with the SimpleLink library.

    Lets say that the password is MyPwd%2B,

    then the happy path would be:
    1. User enters MyPwd%2B
    2. Encoded by APP as MyPwd%252B
    3. Sent to device
    4. Decoded by device as MyPwd%2B

    due to invalid decoding in the SimpleLink library the actual outcome is:
    1. User enters MyPwd%2B
    2. Encoded by APP as MyPwd%252B
    3. Sent to device
    4. Decoded by device as MyPwd+

    the suggested workaround with custom encoding in the app would be:
    1. User enters MyPwd%2B
    2. Special encoding by APP as MyPwd%25252B
    3. Sent to device
    4. Decoded by device as MyPwd%2B

    the workaround will fail once the SimpleLink library is corrected:
    1. User enters MyPwd%2B
    2. Special encoding by APP as MyPwd%25252B
    3. Sent to device
    4. Decoded by device as MyPwd%252B

    If the workaround is added to the app then we eventually will end up in a situation where the SSID and pwd will have to be encoded differently depending on which version of the FW the app is communicating with. These kind of dependencies should be avoided.

    Best regards
    /Jonas

  • 0 in reply to Jonas Lundberg
    TI__Guru 63006 points

    Ok. I still don't understand why the %2525 is needed. I thought the %25 is decoded as % by the HTTP server and that's it (to my understanding, this is how the HTTP server should behave). I'll need to debug which component is responsible for the 2nd decoding... A fix in such case won't be immediate and will probably require an SP update in one of our future SDK releases,

    You are right that assuming the SDK causes the issue and we decide to fix it - then you will need to update both the SDK and the mobile APP (or ignore the SDK fix). 

    If we find that there is no obvious issue with the behavior of the device, we will just fix the app code (exactly as we recommend you to do now).

    Br,

    Kobi

  • 0 in reply to Kobi Leibovitch
    Prodigy 50 points

    Hi Kobi, thanks for your support.

    Yes, %25 should be decoded as % by the HTTP server but it is not, that´s the whole problem. As you say, the string appears to be decoded twice.

    Please keep me posted on the progress

    BR
    /Jonas

  • 0 in reply to Jonas Lundberg
    TI__Guru 63006 points

    Hi Jonas,

    This issue will be reported as a bug.

    A fix will be added to one of the future SDK (or mobile app) releases.

    I'm closing this thread for now and will update once the fix is released.

    Br,

    Kobi