Unusual socket errno 122 when using NRF91 TLS-PSK

[matharman]

Hello,

We are using the NRF9160's built-in TLS client to connect to our server using PSK credentials. Occasionally after sending a request to our server, when we call poll() to do a timed-wait for the response, we get a POLLERR revent. If we ignore that flag and try to call recv() anyway, then errno is set to EMSGSIZE (122).

We have not yet determined what conditions reproduce this error, but we have observed it on the NRF9160DK as well as 2 different custom boards with the NRF9160 SOC.

When we simulate the same request-response sequence on a desktop version of our client, this error does not occur, so it does not seem to be a server-side issue. This leads us to believe that it could be a problem in the NRF9160's IP stack.

I have captured a modem trace from the NRF9160DK attached below, in hopes that Nordic support could shed some light or suggest other avenues of debugging.

Thank you in advance!

NCS Version: 2.0.0

MFW Version: 1.3.2

Toolchain: Reproduced with both GNUARMEMB and Zephyr SDK 0.14.2

Network Mode: LTE-M + GPS with eDRX enabled. NB-IOT is disabled.

Hardware Revision: NRF9160DK 0.9.0

5700.trace-2022-09-06T17-19-37.981Z.bin

[Didrik Rokhaug]

Hi,

The modem trace shows that the server sends a TLS fragment that is larger than what the modem is able to store in its internal buffers (and thereby decode).

This is what causes the connection to be closed, and EMSGSIZE to be returned.

For TLS, the fragments can be max 2kB, while for DTLS the limit is 1kB.

Best regards,

Didrik

[matharman]

Hi Didrik,

Thanks for your time analyzing the modem trace. Based on your advice, we were able to decrease the maximum TLS record size on the server to work around this constraint.

I do have one followup question / remark: One of my colleagues pointed out that RFC 6066 includes an extension to negotiate a "maximum_fragment_length" in the Client Hello.

Has the modem firmware team considered implementing this extension? 2kb is a tight constraint, and it would be useful to advertise that to servers support the extension.

[Didrik Rokhaug]

matharman said:

I do have one followup question / remark: One of my colleagues pointed out that RFC 6066 includes an extension to negotiate a "maximum_fragment_length" in the Client Hello.

Has the modem firmware team considered implementing this extension? 2kb is a tight constraint, and it would be useful to advertise that to servers support the extension.

At least last time we looked into it, it was not yet implemented in mbedTLS, which is the TLS stack used by the modem.

It is in our backlog though.

[Achim Kraus]

Just to mention:

In the meantime there is a alternative extension for the record size defined in RFC 8449.

> At least last time we looked into it,

Not sure, when that was, but I'm pretty sure, mbedTLS supports that feature (see MBEDTLS_SSL_MAX_FRAG_LEN_1024). Maybe someone opens an issue at Mbed-TLS Issues to ask for help.