I want to use mongodb c driver in my project, I'm on Windows 7 so built it with command :
scons --m32 --c99
My problem is I can't make the Connecting example work :
#include <stdio.h>
#define MONGO_HAVE_STDINT
#include "mongo.h"
int main() {
mongo conn[1];
int status = mongo_client( conn, "127.0.0.1", 27017 );
printf("status %d, err %d", status, conn->err);
mongo_destroy( conn );
return 0;
}
Whether mongod is running on my machine or not, the output of executing the exe is :
$ ./mongodb_example.exe
status -1, err 3
Error 3 corresponds to MONGO_CONN_ADDR_FAIL error code (An error occured while calling getaddrinfo()).
Any suggestion about how to connect successfully ?
Updates:
version is mongodb-mongo-c-driver-v0.8.1-0-g8f27c0f
So there are two things you need to do to make this work:
When building with scons, you need to make sure you that you enable the "standard-env" target like so:
scons --m32 --standard-env
Secondly in your code and in addition to the MONGO_HAVE_STDINT that you already have, make sure you call mongo_init_sockets() before establishing a connection. This is required on windows.
#include <stdio.h>
#define MONGO_HAVE_STDINT
#include "mongo.h"
int main() {
mongo_init_sockets();
mongo conn[1];
int status = mongo_client( conn, "192.168.2.7", 27017 );
printf("status %d, err %d", status, conn->err);
mongo_destroy( conn );
return 0;
}
So the first part resolves the issue with getaddrinfo() there is an implementation included in the "standard environment". And the second part is a necessary "winsock" initialization that is required on Windows platforms. In the test files this is implemented with a defined macro.
Also make sure you are using a Python 2.7 32bit (not 64bit) as well. Not too sure how valid that is on a current scons release, but it doesn't hurt to be sure.
Some of this is in the documentation you may have missed here, as is the fairly apt description of the mongo_init_sockets() function in the API documentation. Of course, looking at the test files in the distribution did not hurt.
And a little pain for me, as I don't normally build C programs on Windows.
You can get the exact reason of the mongo failure if you print
conn->errcode
conn->errstr
The errcode is the equivalent of errno in linux or GetLastError in Windows.
The errstr will contain the same as a string. So you shall see something like getaddrinfo failed with error <the return status of getaddrinfo>
There could be multiple reasons why getaddrinfo might fail in your system. You can get these values from the man page man gai_strerror (errstr should report this)
EAI_AGAIN temporary failure in name resolution
EAI_BADFLAGS invalid value for ai_flags
EAI_BADHINTS invalid value for hints
EAI_FAIL non-recoverable failure in name resolution
EAI_FAMILY ai_family not supported
EAI_MEMORY memory allocation failure
EAI_NONAME hostname or servname not provided, or not known
EAI_OVERFLOW argument buffer overflow
EAI_PROTOCOL resolved protocol is unknown
EAI_SERVICE servname not supported for ai_socktype
EAI_SOCKTYPE ai_socktype not supported
EAI_SYSTEM system error returned in errno
I haven't used the mongodb c driver, so this is just a guess. From the tutorial, it looks like you skipped the initialization step:
http://api.mongodb.org/c/current/tutorial.html
mongo conn[1];
mongo_init( conn );
...
mongo_client( conn, "127.0.0.1", 27017 );
Related
I'm using libwebsockets 2.0 and I'm having a few issues trying to connect to a server using it as a client.
According to the libwebsockets log, this is what happens when my fairly simple client tries to connect to echo.websocket.org:
[2016/09/25 19:22:56:9033] INFO: lws_header_table_attach: wsi 0x7fe32402a680: ah (nil) (tsi 0, count = 0) in
[2016/09/25 19:22:56:9034] INFO: lws_header_table_attach: wsi 0x7fe32402a680: ah 0x7fe3240078f0: count 1 (on exit)
[2016/09/25 19:22:56:9034] CLIENT: lws_client_connect: direct conn
[2016/09/25 19:22:56:9034] CLIENT: lws_client_connect_2
[2016/09/25 19:22:56:9034] CLIENT: lws_client_connect_2: address
[2016/09/25 19:22:56:9044] ERR: getaddrinfo failed
Callback LWS_CALLBACK_CLIENT_CONNECTION_ERROR (1)
Connection error: (25) getaddrinfo (ipv4) failed
According to this log, it appears to say that getaddrinfo failed, but the line above it (which is supposed to output the address which libwebsockets is connecting to) is returning an empty string.
Even weirder, when I run my test code through Valgrind, everything appears to work fine:
[2016/09/25 19:46:17:7566] INFO: lws_header_table_attach: wsi 0x6714970: ah (nil) (tsi 0, count = 0) in
[2016/09/25 19:46:17:7598] INFO: lws_header_table_attach: wsi 0x6714970: ah 0x65b35c0: count 1 (on exit)
[2016/09/25 19:46:17:7665] CLIENT: lws_client_connect: direct conn
[2016/09/25 19:46:17:7670] CLIENT: lws_client_connect_2
[2016/09/25 19:46:17:7680] CLIENT: lws_client_connect_2: address echo.websocket.org
[2016/09/25 19:46:17:9511] DEBUG: insert_wsi_socket_into_fds: 0x6714970: tsi=0, sock=6, pos-in-fds=1
All of the included examples/tests work just fine, so I'm really not sure where my problem is.
The code at fault is here - I'm not sure whether the issue is within my code or whether it's a library issue.
I was pondering over my code today, trying random things to see if it would fix the issue. Turns out a free in my code was causing issues with libwebsockets:
char* address_internal = malloc(strlen(address) + 1);
memcpy(address_internal, address, strlen(address));
/*...*/
free(address_internal);
Removing free(address_internal); allows the code to work correctly outside of Valgrind.
I'm guessing the problem is that lws_parse_uri doesn't create its own internal copy, which the docs don't clearly mention. What's weird is that Valgrind didn't pick up on this, and somehow allowed the memory to still be used.
I have little issue with XOpenDisplay function. In school I can run program and it works good when using XOpenDisplay("ip:0"), but on my local machine in home when I run program (changed ip on current) got "Segmentation fault (core dumped)", but with empy string XOpenDisplay("") it works fine. I need to be able to use ip. Used host +, but nothing changes.
My system is Kubuntu 14.04.1: 3.16.0-30-generic #40~14.04.1-Ubuntu SMP Thu Jan 15 17:43:14 UTC 2015
Here is code of program:
#include <X11/Xlib.h>
#include <X11/X.h>
#include <stdio.h>
Display *mydisplay;
Window mywindow;
XSetWindowAttributes mywindowattributes;
XGCValues mygcvalues;
GC mygc;
Visual *myvisual;
int mydepth;
int myscreen;
Colormap mycolormap;
XColor mycolor,mycolor1,dummy;
int i;
main()
{
mydisplay = XOpenDisplay("192.168.0.12:0");
myscreen = DefaultScreen(mydisplay);
myvisual = DefaultVisual(mydisplay,myscreen);
mydepth = DefaultDepth(mydisplay,myscreen);
mywindowattributes.background_pixel = XWhitePixel(mydisplay,myscreen);
mywindowattributes.override_redirect = True;
mywindow = XCreateWindow(mydisplay,XRootWindow(mydisplay,myscreen),
0,0,500,500,10,mydepth,InputOutput,
myvisual,CWBackPixel|CWOverrideRedirect,
&mywindowattributes);
mycolormap = DefaultColormap(mydisplay,myscreen);
XAllocNamedColor(mydisplay,mycolormap,"cyan",&mycolor,&dummy);
XAllocNamedColor(mydisplay,mycolormap,"red",&mycolor1,&dummy);
XMapWindow(mydisplay,mywindow);
mygc = DefaultGC(mydisplay,myscreen);
XSetForeground(mydisplay,mygc,mycolor.pixel);
XFillRectangle(mydisplay,mywindow,mygc,100,100,300,300);
XSetForeground(mydisplay,mygc,mycolor1.pixel);
XSetFunction(mydisplay,mygc,GXcopy);
XSetLineAttributes(mydisplay,mygc,10,LineSolid,CapProjecting,JoinMiter);
XDrawLine(mydisplay,mywindow,mygc,100,100,400,400);
XDrawLine(mydisplay,mywindow,mygc,100,400,400,100);
XFlush(mydisplay);
sleep(10);
XCloseDisplay(mydisplay);
exit(0);
}
I can only guess that need to set something, but have no idea where is that option.
You shall always check whether functions returned successfully, or not. It is not a Haskell, where all the checking done for you by monad, it is C. As for your particular case, the problem is that the function XOpenDisplay fails and returns null for you. In the next line you're trying to use DefaultScreen with the result. The DefaultScreen is defined as
#define DefaultScreen(dpy) ((dpy)->default_screen)
I.e. it just a macro, which using the first argument as a pointer. In your case it does ((0)->default_screen), i.e. it dereferencing the null pointer, and that leads to the segfault you see.
Also, about the XOpenDisplay("192.168.0.12:0"); — you didn't mentioned that you're trying to connect to another PC, so, if it's the same computer where the app running, try to call the function as XOpenDisplay("127.0.0.1:0");
UPD: okay, I tried to run the code at my PC, and the function doesn't work for me too. To find the reason I started the code under strace app, and saw
…
connect(3, {sa_family=AF_INET, sin_port=htons(6000), sin_addr=inet_addr("127.0.0.1")}, 16) = -1 ECONNREFUSED (Connection refused)
…
Aha! So, the app trying to connect to XServer, but Xserver refuses the connection. Actually, it have a security reason to disable it by default — so, that nobody would connect to your XServer from a network unless you specifically allowed it. For the function to work you need to launch your XServer with the option that allows such a connection. Right now DisplayManagers are the ones, who manages xsessions, so you need to set some option depending on your DM.
The solution for lightdm
Open the /etc/lightdm/lightdm.conf, and paste the line xserver-allow-tcp=true in the section [SeatDefaults](you will see it).
The solution for gdm
Edit the file /etc/gdm/gdm.schemas, you will find there something like
<schema>
<key>security/DisallowTCP</key>
<signature>b</signature>
<default>true</default>
</schema>
Change the true to false.
I am trying to understand basics of RPC using RPCGen. I followed a basic tutorial and wrote the follwing myrpc.x file
program MESSAGEPROG {
version EVALMESSAGEVERS {
int EVALMESSAGE(string) = 1;
} = 1;
} = 0x20000002;
I compile it by running
rpcgen -a -C myrpc.x
In the resulting server.c file, I added a printf statement as below
printf("Message is: %s,\n", *argp);
Then i run make -f Makefile.myrpc and start the server by running myrpc_server. Now when i run the client 'myrpc_client', I get the following message printed in the server
Message is: H���5�
Now my question is from where does this argument come from "H���5�" as this is not the argument which i am when running the client? Also can someone explain me how do i start running complex programs with rpcgen?
The garbage value is from code on line 15 in client.c, where is uninitialized variable used as an argument for your rpc call. My version of rpc show an error:
call failed: RPC: Can't encode arguments"
15 char * evalmessage_1_arg;
"How do I start running complex programs with rpc?" It' just on you. We cannot say when you need to use rpc. You probably have some reason for what you chose this implementation.
Some use case for rpc is thin client on slow computer, which needs some expensive computation. Client sends data to powerful server, that do the hard work and returns result.
We are using libwebsockets 1.3 in our ssl enabled web socket client program written in c, we are compiling on Centos 6.5 with openssl 1.0.1 installed, making a .so library which is later used in asterisk. The compilation goes fine but I'm getting this runtime error:
problem creating ssl context 336236705: error:140A90A1:lib(20):func(169):reason(161)
Going through libwebsockets code I spotted the part that is generating the error message (lib/ssl.c line 90):
/* basic openssl init */
SSL_library_init();
OpenSSL_add_all_algorithms();
SSL_load_error_strings();
openssl_websocket_private_data_index =
SSL_get_ex_new_index(0, "libwebsockets", NULL, NULL, NULL);
/*
* Firefox insists on SSLv23 not SSLv3
* Konq disables SSLv2 by default now, SSLv23 works
*/
method = (SSL_METHOD *)SSLv23_server_method();
if (!method) {
error = ERR_get_error();
lwsl_err("problem creating ssl method %lu: %s\n",
error, ERR_error_string(error,
(char *)context->service_buffer));
return 1;
}
context->ssl_ctx = SSL_CTX_new(method); /* create context */
if (!context->ssl_ctx) {
error = ERR_get_error();
lwsl_err("problem creating ssl context %lu: %s\n",
error, ERR_error_string(error,
(char *)context->service_buffer));
return 1;
}
Which according to examples I've seen on the web looks absolutely fine, I've been scratching my head, searching and trying everything for the past couple of days including reinstalling different versions of openssl, changing the code above, replacing SSLv23_server_method with other methods, etc... but can't get it to work, does anybody know where the problem might be?
Additional informaiton:
Using ERR_print_errors_fp() I get:
3077879544:error:140A90A1:lib(20):func(169):reason(161):ssl_lib.c:1802:
part of our code that calls libwebsocket_create_context looks like this:
int opts = 0;
const char *interface = NULL;
int listen_port;
memset(&wsInfo, 0, sizeof wsInfo);
listen_port = CONTEXT_PORT_NO_LISTEN;
wsInfo.port = listen_port;
wsInfo.iface = interface;
wsInfo.protocols = protocols;
wsInfo.extensions = libwebsocket_get_internal_extensions();
wsInfo.gid = -1;
wsInfo.uid = -1;
wsInfo.options = opts;
wsContext = libwebsocket_create_context(&wsInfo);
The program is compiled into an .so library and the library is used in our modified version of asterisk (which itself uses openssl as far as I know).
problem creating ssl context 336236705: error:140A90A1:lib(20):func(169):reason(161)
This may have helped:
$ openssl errstr 0x140A90A1
error:140A90A1:SSL routines:SSL_CTX_new:library has no ciphers
"library has no ciphers" is a sure sign the library was not initialized. See OpenSSL's wiki page on intializing the library at Library Initialization.
Since Asterisk is doing really clever things, you should check what else its doing. In particular, you should ensure its not using weak/wounded/broken protocols and cipher suites. An example of how to improve a security posture can be found at SSL/TLS Client. The sample ensure TLS 1.0 and above, and uses "strong" cipher suites.
I got this error too by using a library that used the boost asio.
The lib was compiled against openssl-1.0, while my binary was compiled against openssl-1.1.
Switching my binary to also use openssl-1.0 solved the issue for me.
The problem is asterisk overrides all openssl initialization functions including SSL_library_init() and OpenSSL_add_all_algorithms() in main\libasteriskssl.c and replaces them with dummy functions that do nothing, instead it defines an ast_ssl_init() which does all the initializations and is called once in main() in main/asterisk.c, my code happened to be before that call.
Too long for a comment, but:
First things first, let's eliminate your code. In the libwebsockets distribution, in test/test-server.c there is a test server that works with SSL. Does that work? If so, I'm guessing it's something you are doing in your code (in which case we are going to need some of your code). If not, I'm guessing it's your distribution.
Next, let's make that error message a bit more informative. Can you introduce ERR_print_errors_fp() to print SSL errors to stderr or similar, and tell us what it says?
I thought I would try out SDP on our infiniband hardware.
However, when I try to add AF_INET_SDP as the first argument to socket() I get the following error:
"Address family not supported by protocol".
Originally I had:
#define AF_INET_SDP 26
But after doing some reading, noticed a patch applied some time back to change this value to 27.
When set to 26 I get the error:
"Error binding socket: No such device"
Has anyone managed to get SDP working on Ubuntu 12.04? what did you do to get it up and running?
I have installed libsdp1 and libsdpa-dev
Using the LD_PRELOAD method on iperf I also get the first error:
LD_PRELOAD=libsdp.so iperf -s
dir: /tmp/libsdp.log.1000 file: /tmp/libsdp.log.1000/log
socket failed: Address family not supported by protocol
bind failed: Bad file descriptor
Therefore I assume 27 is the correct domain number.
SDP hasn't been accepted on the mainline linux kernel. On recent fedora, they don't ship it, neither the user space libsdp.
If you still want to experiment, Matt is right, the module in question is 'ib_sdp'.
try modprobe ib_sdp and run your example again.