LAUNCHCC3220MODASF: SL_SOCKET_ASYNC_EVENT type SL_SSL_ACCEPT with value -300

Hi again,

I'm still stuck on this, still seeing the -300 above with no ServerHello being TX'd.

I'm now setting

    --flags secure,nosignaturetest,publicwrite,publicread

for all three files and, given CN=foo-bar in self-signed-cert.der, I'm using

    --fs_path foo-bar

for it based on forum search results.

Is there a TI example demo which pulls a private key or server certificate off the external flash's filesystem? The ones I've found 'cheat' by having a PEM embedded in the C, avoiding all these hurdles.

Thanks, Ralph.

Hi Ralph,

-300 is SL_ERROR_BSD_ESEC_CLOSE_NOTIFY, which just tells us the socket is closing. Are you seeing any return values from the socket APIs? Are you calling sl_Accept?

I would expect to see a bad certificate error (-342) if that was the issue. The network_terminal example uses certificates from the file system with sl_SetSockOpt. There are also examples that use flashed certificates with the OTA library.

Can you capture NWP logs?

Best regards,

Sarah

Hi Sarah,

Sarah P said:

-300 is SL_ERROR_BSD_ESEC_CLOSE_NOTIFY, which just tells us the socket is closing.

Ah, SlSocketAsyncEvent_t's definition could do with some comments explaining where Val can be looked up for a particular Type.

Sarah P said:

Are you seeing any return values from the socket APIs?

Yes, the CALL() macro in the above listing errors verbosely if the return value is negative. None are.

Sarah P said:

Are you calling sl_Accept?

Yes, sorry, that's the next thing after the sl_Listen() above:

SlSockAddrIn_t const clientaddr;
SlSocklen_t clientlen;
DBG("sl_Accept next");
CALL(sl_Accept, (httpfd, (struct SlSockAddr_t *)&clientaddr, &clientlen)); /*lint !e740 */
DBG("sl_Accept ret: %"PRIi16, ret);
_i16 clientfd = ret;
HexDump(&clientaddr, clientlen, 0);

'sl_Accept next' appears, the call never returns. That sl_Accept() is being called is further re-inforced by

SimpleLinkSockEventHandler() is called with a SL_SOCKET_ASYNC_EVENT event where the Type is 0, SL_SSL_ACCEPT, and Value -300

as a Type of 0 implies sl_Accept():

/* possible types when receiving SL_SOCKET_ASYNC_EVENT*/
#define SL_SSL_ACCEPT                                        (0) /* accept failed due to ssl issue ( tcp pass) */

On the network, I see the normal TCP SYN, SYN/ACK, ACK with the client then Pushing its ClientHello. 12 ms later the NWP sends a FIN/ACK. That it should take so long may be significant.

Sarah P said:

The network_terminal example uses certificates from the file system with sl_SetSockOpt. There are also examples that use flashed certificates with the OTA library.?

Thanks, I'll try and alter my code more towards theirs until the behaviour changes.

Sarah P said:

Can you capture NWP logs?

No, sorry, that's not possible. I'm hoping an NWP path whereby it would close the socket after a delay and not return from sl_Accept() can be seen, especially with the long-time taken before FIN-ing the connection.

Thanks, Ralph.

Part Number: LAUNCHCC3220MODASF

Hi,

If a new sl_Socket(SL_AF_INET, SL_SOCK_STREAM, SL_SEC_SOCKET) does not have sl_SetSockOpt(SL_SO_SECMETHOD) used on it then what is the default value? Presumably one of the SL_SO_SEC_METHOD_SSLV3... list of macros?

Similarly, for certainty, if sl_SetSockOpt(SL_SO_SECURE_MASK) isn't used then is the default cipher-suite mask SL_SEC_MASK_SECURE_DEFAULT?

sl_SetSockOpt(SL_SO_SECURE_MASK) takes a mask. SlSockSSLConnectionParams_t.SecureCipherSuit filled in by sl_GetSockOpt(SL_SO_SSL_CONNECTION_PARAMS) is a single value. Is it the log-base-2 of the single mask bit which was chosen? (For which there are no macros nor enum.)

Given a set mask of cipher suites and a listening TLS socket, what determines the order the suites are offered by the NWP?

Thanks, Ralph.

Part Number: LAUNCHCC3220MODASF

Hi,

I'm seeing

    SimpleLinkSockEventHandler: event: 2=async_event  sd: 0  type: 0=ssl_accept  val: -348

-348 is missing from the SDK's source/ti/drivers/net/wifi/errors.h:

#define SL_ERROR_BSD_ESEC_CERTIFICATE_UNKNOWN                           (-346L) /* ssl/tls alerts */
#define SL_ERROR_BSD_ESEC_ILLEGAL_PARAMETER                             (-347L) /* ssl/tls alerts */
#define SL_ERROR_BSD_ESEC_ACCESS_DENIED                                 (-349L) /* ssl/tls alerts */

What does -348 mean? And can it please be added given it's reaching the Host CPU.

Thanks, Ralph.

Hi Ralph,

I've numbered your questions to avoid missing anything in discussion:

1. "On the network, I see the normal TCP SYN, SYN/ACK, ACK with the client then Pushing its ClientHello. 12 ms later the NWP sends a FIN/ACK. That it should take so long may be significant."
   1. The sniffer captures may be helpful, can you share them? Unfortunately I'm not sure how to determine what that delay might mean without the NWP logs.
2. If you do not have pin 62 available for NWP logs, do you have 18, 53, or 60?
3. "If a new sl_Socket(SL_AF_INET, SL_SOCK_STREAM, SL_SEC_SOCKET) does not have sl_SetSockOpt(SL_SO_SECMETHOD) used on it then what is the default value?"
   1. What are you trying to debug with the default value? Are you seeing different behavior depending on the cipher suite you use? The default is a mask of all of the cipher suites.
4. "SlSockSSLConnectionParams_t.SecureCipherSuit filled in by sl_GetSockOpt(SL_SO_SSL_CONNECTION_PARAMS) is a single value. Is it the log-base-2 of the single mask bit which was chosen?"
   1. Yes, all of the cipher mask defines are in source/ti/drivers/wifi/sl_socket.h
5. "Given a set mask of cipher suites and a listening TLS socket, what determines the order the suites are offered by the NWP?"
   1. The selected cipher suite will be the highest common cipher advertised by both the server and client.

6. Error -348 is UNKNOWN_CA, which means a valid certificate chain or partial chain was received, but the certificate was not accepted because the CA certificate could not be located or couldn't be matched with a known, trusted CA. What changed when you saw this error?

Best regards,
Sarah

Thanks for the reply, Sarah. I'll picked through each one later.  Note I didn't put my previous two posts on this thread, but created each with its own subject and thread as they're distinct issues rather than tied into this thread's original problem. (I've asked how they ended up here with https://e2e.ti.com/support/wireless-connectivity/wifi/f/968/t/913150 ) Sorry if that's confused things when you were answering.

Thanks again, Ralph.

Hi Sarah,

Alterations for a second revision of the product board are being collected at the moment so...

Sarah P said:

If you do not have pin 62 available for NWP logs, do you have 18, 53, or 60?

I'm aware of 'Capture NWP Logs' on page 287 of SWRU455J which says MUX pin 62 to mode 1 for outputting NWP logs.

1. Can you confirm that's CC3220SF pin 62, GPIO 7, so CC3220MODASF pin 52.

2. Are the other possible pins for NWP logging documented anywhere? Including what mux mode they each need.

3. Is this a complete list of possible NWP-logging device pins: 18, 53, 60, and 62?

We'll be sure to make an NWP-logging pin available within our existing mux requirements.

Thanks, Ralph.

Hi again,

I've been surveying E2E forum posts, trying to scavenge this information. So far, regarding the CC3220SF in a CC3220MODASF, I've:

    Dev  GPIO  MODA  Function
     18   28    19   ?
     53   30    42   ?
     60    5    50   MAC log
     62    7    52   NWP log

Corrections/additions welcome as part of answering 1-3 above.

Cheers, Ralph.

Hi Ralph,

You can sub one of the following commands into the instructions from the Programmer's Guide for NWP logs:

MAP_PinTypeUART(PIN_18, PIN_MODE_3);
MAP_PinTypeUART(PIN_53, PIN_MODE_5);
MAP_PinTypeUART(PIN_60, PIN_MODE_3);

These pins are not documented because they have not been extensively tested. I do not recommend you leave them muxed in this mode for your final product, but they should be fine for debug. We do emphasize in the hardware design review that you should leave pin 62 available as an external test point.

Best regards,

Sarah

Hi Sarah, thanks for the three mux modes, and I acknowledge the lack of testing in comparison to 62.

So now I have

    Dev  GPIO  MODA  MUX  Function
     18   28    19    3   ?
     53   30    42    5   ?
     60    5    50    3   MAC log
     62    7    52    1   NWP log

What are the two missing functions? Just in case the hardware folks might be able to pick a MAC and an NWP pair.

Thanks, Ralph.

Hi Ralph,

The pin modes I gave you are all for NWP logging. I would have to check on MAC logs, but I'm not sure they're necessary at this point. Pin 60 is typically used for MAC logs.

Best regards,

Sarah

Hi Sarah, Thanks, I missed your earlier point about them all being NWP substitutes. So I've ended up with

    Dev  GPIO  MODA  MUX  Log
     18   28    19    3   NWP
     53   30    42    5   NWP
     60    5    50    1   MAC
     60    5    50    3   NWP
     62    7    52    1   NWP  (Design review suggestion)

I agree MAC logs probably aren't necessary now, I'm just wanting to supply the PCB designers with the options so a problem in the months ahead which does need MAC logs can get them.

Thanks, Ralph.