Hi Thomas,

-1 indicates that wolfSSL attempted to read from the socket and the read failed outright. Receive can return a non-read (0) which is not a failure, it is a successful read, but 0 bytes were waiting to be read. A -1 indicates an issue with the Receive methodology altogether, either the socket failed to be opened in the first place or there is a fundamental underlying error.

Have you registered your own IO callbacks or are you using our default "EmbedReceiveFrom" and "EmbedSendTo" functions?

Receive just calls whatever IOCallback Receive function was loaded with wolfSSL_SetIORecv API. If the user has not defined "WOLFSSL_USER_IO" and set their own callback function, then our default methods are loaded.

There are a number of reasons this could fail. What TCP/IP stack are you using? Are you checking all the return values when creating the socket? Are you confident the socket was successfully opened for TCP prior to calling wolfSSL_connect on the file descriptor?

Regards,

Kaleb

Hi Extremee,

IE checking the return codes on file descriptor/socket creation, something like this:

    /* internet address family, stream based tcp, default protocol */
    sockfd = socket(AF_INET, SOCK_STREAM, 0);
    if (sockfd < 0) {
        printf("Failed to create socket. errono: %i\n", errno);
        return EXIT_FAILURE;
    }

It looks like everything is working so I will assume the answer here is also yes, you are confident the socket was created prior to calling connect on it.

DTLS uses sequence numbers during the handshake due to the following reason:

When doing a handshake using an unreliable protocol such as UDP there still needs to be a way to guarantee all the handshake packets arrive. To that extent DTLS must send a sequence number when transmitting flights of the handshake. If a flight fails to arrive at the destination that flight will be re-transmitted similar to how TCP is a guaranteed protocol (guarantees all packets arrive or if dropped will re-send until all have arrived). DTLS has to mimick this behavior for the handshake portion of a connection only. To that end it checks if a flight arrives out of order. This is what you have encountered, a flight arrived out of order or with an incorrect sequence number.

Are you implementing the client or the server side?

Which end point are you connecting to? Is it a public endpoint that I could test myself to test interop with that endpoint and the wolfSSL DTLS implementation?

If it is not possible for me to test directly, could you capture a wireshark trace of the connection attempt and send me the pcap for analysis? (If the pcap will not attach to the forum post please email directly to support@wolfssl.com with your forum user name and a link to this post to identify which post the pcap belongs to)

Warm Regards,

Kaleb

Hi Extremee,

Review of the wireshark shows some DTLS 1.2 client Hello packets but no other udp traffic at all.

Honestly it looks like the server just does not have DTLS enabled. Can you confirm if "WOLFSSL_DTLS" is defined in your configuration anywhere?

Did you use a datagram socket (udp) on the server?

sockfd = socket(AF_INET, SOCK_DGRAM, 0);

Could you send your configuration settings?

For a simple DTLS server example please see this project: https://github.com/wolfSSL/wolfssl-exam … ver-dtls.c

This overview may also be helpful: https://github.com/wolfSSL/wolfssl-exam … dp-dtls.md

Warm Regards,

Kaleb

Hi Extremee,

I'm looking into the reasons you might be experiencing the UNKNOWN_RECORD_TYPE in header or SEQUENCE_ERROR but the wireshark is not revealing. All the header information in the capture you sent looks correct. Is there something that was stripped out when the capture was filitered? Is there some other data we're missing?

Could you provide some details on the project you are working on and the end goals?

Thanks,

Kaleb

Hi Extremee,

What changes were made during "configure the library new" (re-configure)? Did you add new defines or remove defines, a combination of both?

What are your settings now?

I apologize for answering your question with questions so often but it's difficult to address what the issue might be without all the information.

- Kaleb