1. Messages
  2. Few questions regarding sockets/DTLS and net_offload

Re: Few questions regarding sockets/DTLS and net_offload

Benjamin Lindqvist
 

Hi Robert,

Thanks for a quick response :)

I don't have a strong preference regarding lazy handshaking, it's probably better the way you implemented it - I'd recommend elaborating the source code comment though, because the behavior differs from the net_app API.

Good info re: HOSTNAME. Would keeping it enable require working DNS? We haven't had time to verify that DNS works. Indeed we know that it was broken under net_app so we haven't really bothered.

Another thing that seemed slightly broken under net_app was re-initializing the DTLS handshake when we suspected a lost connection, do you know if this is still an issue?

On Tue, Mar 12, 2019 at 5:07 PM Lubos, Robert <Robert.Lubos@...> wrote:

Hello Benjamin,

 

I’ll try to address part of your questions:

 

  • First, regarding delayed handshakes. In sockets_tls.c:

 

    • if (net_context_get_type(ctx) == SOCK_STREAM) {
      • /* Do the handshake for TLS, not DTLS. */

 

This had our scratching our heads for a while today because net_app DTLS seemed to handshake immediately. Why does ztls_connect_ctx delay handshake for DTLS?

 

A `connect` call for DTLS socket is optional (same as for UDP sockets) therefore we perform the handshake during initial send (for DTLS client). If you find it beneficial to initiate the handshake during the `connect` call as well for the DTLS, we can consider adding such functionality. Please file an github issue for that.

 

  • The second question is regarding TLS HOSTNAME. I think I recall reading that this is required by default, but can be disabled. What's the proper way of doing this?

 

Yes, it is enforced by default due to security reasons. It can be disabled (though not recommended!) by explicitly setting `TLS_HOSTNAME` option to a NULL string.

 

  • Third, has anyone successfully verified sockets and DTLS with a driver using the net_offload API? Some of the asserts and backtraces we've been observing while trying to get it to work today has been sort of... suspicious. Just wondering if anyone can verify that nothing has been broken.

 

I won’t be much help here as I’ve not used net_offload API. Keep in mind though that networking stack in Zephyr has undergone very large rework recently, so perhaps there is some issue that has not been identified yet.

 

Best regards,

Robert

 

From: devel@... [mailto:devel@...] On Behalf Of Benjamin Lindqvist via Lists.Zephyrproject.Org
Sent: Tuesday, March 12, 2019 16:47
To: devel@...
Cc: devel@...
Subject: [Zephyr-devel] Few questions regarding sockets/DTLS and net_offload

 

First, regarding delayed handshakes. In sockets_tls.c:

 

               if (net_context_get_type(ctx) == SOCK_STREAM) {

                              /* Do the handshake for TLS, not DTLS. */

 

This had our scratching our heads for a while today because net_app DTLS seemed to handshake immediately. Why does ztls_connect_ctx delay handshake for DTLS?


The second question is regarding TLS HOSTNAME. I think I recall reading that this is required by default, but can be disabled. What's the proper way of doing this?

 

Third, has anyone successfully verified sockets and DTLS with a driver using the net_offload API? Some of the asserts and backtraces we've been observing while trying to get it to work today has been sort of... suspicious. Just wondering if anyone can verify that nothing has been broken.

 

Best regards,

Benjamin
Join devel@lists.zephyrproject.org to automatically receive all group messages.