wolfSSL has run on ThreadX and NetX for over a decade, and release 5.9.4 makes that integration noticeably better: NetX sockets now carry DTLS over UDP, and the NetX I/O layer reports “would block” and “connection closed” the way wolfSSL expects, so non-blocking applications work as designed.
What’s new in wolfSSL 5.9.4
Two changes in the 5.9.4 ChangeLog touch NetX directly.
- DTLS over NetX UDP sockets (PR 10408). wolfSSL can now run DTLS sessions on a NetX Duo NX_UDP_SOCKET. Previously the built-in NetX callbacks handled TCP only. The new callbacks, NetX_ReceiveFrom and NetX_SendTo, are installed automatically when you build with WOLFSSL_DTLS and WOLFSSL_NETX_DUO, and they handle the details DTLS needs:
- Retransmission timing. While a handshake or DTLS 1.3 retransmission timer is running, the receive wait comes from wolfSSL’s own DTLS timeout, so lost flights are resent on schedule. Otherwise your configured wait option applies.
- Peer filtering. If you give the destination address and port, datagrams from any other source are discarded. If you give none, the first datagram’s source becomes the peer. During the handshake, wolfSSL gives up on a flood of bad datagrams after 10 by default (DTLS_RECEIVEFROM_MAX_INVALID_PEER changes the limit), matching the behavior of the standard BSD-socket callbacks.
- Datagram semantics. Each read consumes one whole datagram. Zero-length datagrams are ignored, and an oversized datagram is truncated rather than split across reads, which keeps DTLS record framing intact.
- IPv4 and IPv6. Peer addresses are compared for both families, honoring your NX_DISABLE_IPV4 and IPv6 build settings.
- A corrected NetX I/O layer (PR 11287). The NetX status codes are now translated to wolfSSL’s I/O errors properly. Before this fix, transient conditions such as an empty receive queue, an exhausted packet pool, a full peer window or a full transmit queue could surface as fatal errors, so a non-blocking or short-timeout setup could not simply retry. The HAVE_NETX socket error aliases (SOCKET_EWOULDBLOCK, SOCKET_ECONNRESET and friends) were corrected at the same time.
Looking ahead
Teams planning around the Eclipse ThreadX transition may also want to look at wolfIP, wolfSSL’s embedded TCP/IP stack with a BSD-style socket API, which pairs natively with wolfSSL TLS. wolfSSL continues to support NetX Duo, so existing designs can upgrade in place.
Questions about NetX, DTLS or any other embedded port? Contact us at facts@wolfssl.com or +1 425 245 8247.