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>
