tcp sendmsg() EAGAIN handling

[dpf]

we have a 'long lived' tcp connection w/ regular data sends (1hz of 256 bytes for mqtt publishes) where sendmsg() sometimes returns EAGAIN. when trying again it usually works but sometimes we get the poll() read event and this indicates that the peer reset the connection.

 i interpret this as there being an erro w/ the retry, an unexpected resend should be ok but only if it matches the previous send. are there conditions that the device-side where it could resend something different?

[Carl Richard]

Hi dpf!

Thanks for reaching out.

Could you give me some more details about your implementation? Specifically: your nRF Connect SDK version, your modem firmware version and whether you are using TLS or not.

Also, can you explain how you handle the retries in the application? If you don't want to share implementation data we can make the ticket private.

Best regards,
Carl Richard

[dpf]

>Could you give me some more details about your implementation? Specifically: your nRF Connect SDK version, your modem firmware version and whether you are using TLS or not.

we're using tls + v2.0.0.4 on the nrf9151-laca, and getting to sendmsg() via the zephy'rs offload.

>Also, can you explain how you handle the retries in the application? If you don't want to share implementation data we can make the ticket private.

basically we try twice like:

for (tries = 0; tries < 2; tries++) {

rv = sendmsg((s, msg, flags);

if (rv < 0) {

if (errno == EAGAIN && tries < 1)

continue

return -errno;

}

... udate message iovec .. 

}

[Carl Richard]

Hello again!

Thanks for the details. Can you verify that you are retransmitting the exact same data when retrying? There is a strict requirement for TLS connections that retries contains the same data. The EAGAIN error indicates that this may not be the case. 

The requirement is documented here.

Best regards,
Carl Richard