[openssl-users] OpenSSL Dragino Yun Issues

[Nikola Milev]

To whom it may concern,

I have been experiencing issues with OpenSSL and DraginoYun. If you are not
the person I should have contacted, please redirect me. Thank you!

Recently, I have tried using OpenSSL to establish a simple server
application on Dragino Yun version 2.4. First, I tested the code on my Acer
Aspire 5750ZG running Ubuntu 14.04 and it worked fine. Afterwards, I used
OpenWrt SDK to cross-compile the application. However, the application is
unable to bind the socket; the BIO_do_accept function fails. Here is the
error stack the code provided:
"2006783048:error:0200407C:lib(2):func(4):reason(124):NA:0:port='5354'
2006783048:error:20069076:lib(32):func(105):reason(118):NA:0:"

errstr returned these as answers:
"$ openssl errstr 0200407C
error:0200407C:system library:socket:Wrong medium type
$ openssl errstr 20069076
error:20069076:BIO routines:BIO_get_accept_socket:unable to create socket
"
I suppose that the second one is a product of the first one.

I have checked iptables and I have checked ports that are currently in use,
all seems to be in order.

However, the OpenSSL s_server (in combination with s_client on the other
side) works fine.
May this be an OpenSSL bug? If not, do you have any suggestions?

OpenSSL version on Acer is 1.0.1f 6 Jan 2014 and on Dragino 1.0.1h 5 Jun
2014.

In the attachment, I am providing the code(though I am not sure if it is
available on the list), mostly taken from O'Reilly "Network Security with
OpenSSL".

All the passkeys are "raspberry". (these certificates and keys were
generated for testing purposes)

Of course, should you need any additional information, I'd be happy to
provide it.

I originally addressed Matt Caswell regarding the issue and I am pasting
his response to my question and my response to that.

His response:
"Hello,

I'm not really the best person to ask about such low level stuff. The
best place to raise these questions is on the openssl-users email list.
It also means any questions/answers are publicly archived and available
for other users. Details are here:

https://mta.openssl.org

However, I did have a quick look and discovered the following. The code
that raises this error looks like this:

    s = socket(server.sa.sa_family, SOCK_STREAM, SOCKET_PROTOCOL);
    if (s == INVALID_SOCKET) {
        SYSerr(SYS_F_SOCKET, get_last_socket_error());
        ERR_add_error_data(3, "port='", host, "'");
        BIOerr(BIO_F_BIO_GET_ACCEPT_SOCKET, BIO_R_UNABLE_TO_CREATE_SOCKET);
        goto err;
    }

So this is a call to the non-OpenSSL networking function "socket". In
this context "server.sa.sa_family" has been set to AF_INET a few lines
above, and "SOCKET_PROTOCOL" is a macro defined at the beginning of the
file as follows:

# define SOCKET_PROTOCOL IPPROTO_TCP

In other words the function that is failing is doing this:

socket(AF_INET, SOCK_STREAM, IPPROTO_TCP)

This seems like a fairly fundamental failure, and might suggest that the
platform in question has no TCP/IP support available for some reason?"

My response to his:
"
Hi Matt,

The platform supports TCP/IP, if I deduced correctly. I have programmed an
application similar to the example in Unix Network Programming (a basic
TCP/IP echo server) and it works without any issues. Also, openssl s_server
works correctly; I tried using it with openssl s_client on the other
machine.
I will forward my question to the email list, including both of our
responses.
I am grateful for your quick response.

Best regards,
Nikola Milev

"

My original mail to him is almost the same as the first part of this mail.

I am thankful for you support!

Best regards,
Nikola Milev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160901/e4f1ae95/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: src.tar.gz
Type: application/x-gzip
Size: 12850 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160901/e4f1ae95/attachment-0001.bin>