Re: Few questions regarding sockets/DTLS and net_offload
Lubos, Robert
Hello Benjamin,
I’ll try to address part of your questions:
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.
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.
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?
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
|
|