I am trying to send messages from a windows client to a linux server using the REQ/REP pattern with ZeroMQ. The server side code is the hwserver.cpp code from the examples of the 0MQ guide. And for the client side I also use the example code hwclient.cpp.
Now the problem at hand is the following. If I use a Linux server and client I am able to send messages, receive them and send a reply back which is also received. When the server and client are both run in Windows I also can receive and send messages. If the server is running in Windows and the client is running in Linux it also works. These tests make me think I have at least the correct IP adresses.
When I try to use a Linux server and a Windows clien, the messages that are send do not arrive at the server. And I don't know what could cause this, since the reverse with a Windows server + Linux client works perfectly. I found a similar question but the solution posted there did not work.
I use Fedora 20 with g++ 4.8.3 and Windows 8 with Microsoft Visual Studio 2013.
Is there an option that has to be flagged when doing this kind of 0MQ connection ?
Once ZeroMQ version numbers match, there need not be any further "magic-switch" for Window$
n.b.:
socket.connect ("tcp://<_aUbuntuHOST_IpADRESS_>:5555"); // Do W8 allow outbound tcp:5555 connection in the security policy in effect?
May you proof that the Win integrated firewall policies ( explicit security settings permit exceptions ) do allow a process to request + use an outgoing tcp connection on the specified port number?
May reverse .bind() / .connect() on REQ/REP sides to remain on the same situation as that was working once you had Ubuntu.REQ ( with .connect() ) and the W8.REP ( with .bind() ) so the W8.REQ would again .bind() ( which you reported that worked fine ) & Ubuntu.REP would .connect()
Related
we have a c++ Application with boost1.62 and libssl1.0, that opens a TLS connection to a lighttpd Webserver (remote).
This works fine on any device we already rolled out. Now we are trying to use this application inside a container. The application starts up and everything is fine but.
When the connection gets reset for any reason, the application attempts to reconnect by making a new TCP-Connection with the socket.
Creating a HTTPS-Connection with TLS over that socket fails with EOF. Then the application tries to reconnect and gets the same fault -> endless reconnection loop.
I recorded the traffic and have seen the following:
Everything is alright
A TLS-Alert is recorded, sometimes also a TCP RESET.
Client sends SYN
Server sends SYN ACK
Client sends ACK
Client sends FIN, ACK
Server sends ACK
Server sends FIN, ACK
Client sends ACK
Steps 3 to 7 occur in less than 3 ms.
as soon as Step 7 has passed, a new connection is made starting with step 3.
I'm using an ubuntu 18.04 on host and as base image. (Both x64)
Both host and container use the same libraries. Therefore i think its not an issue with used libraries.
The application runs in production for over a year on several arm32v7 and x64 devices. This error never occurred then.
Oddly, if the application is configured to use plain HTTP instead HTTPS, the error does not occur.
Any suggestions what this might be? Based on my knowledge i can rule out the following:
wrong dependencies
misconfigured Kernel (container and host use the same)
Thanks for your help
After a disconnect, we reused the old socket. This works flawless outside docker. Inside docker it produces the described behaviour.
Workaround: delete the broken socket and create a new one.
This is bad for performance though.
This is related to: Sending packets over UDP from Windows
I making simple UDP client using Boost ASIO. When I run the client on Ubuntu, it can send to the server (listener) the data correctly. However, when I am running it on Windows, the server can not parse the data correctly.
Since I do not have access to the server code. I can not be sure what is happening there.
I am sure that it is not Networking (such as firewall) problem because I tried the code on Ubuntu VM inside a Windows Host and it worked.
My question is: Should I encode the message I sent from Windows in different manner? (I am not sure but something like UTF-8, UTF-16 differences.. maybe..)
The sending code:
socket_.send_to(boost::asio::buffer(message, sizeof(*message)), endpoint_);
Where message is pointer to some struct that the server expecting. end_point_ is correct. I printed it and the address and port are correct.
I've been looking through the poco samples and documentation, but I couldn't find out how to use poco's websockets and SSL combined. I successfully connected a non-SSL websocket (based on the WebSocket class) to a server (the echoserver sample from Qt5.4, running on Ubuntu), but how to add SSL to the client eludes me. Poco's NetSSL_OpenSSL samples aren't all that helpful, because I don't need to know how to download, tweet, mail or write a time server. Also the latter is the only one that uses "SecureStreamSocket" objects at all (which is probably the class I need). But that sample just accesses the socket from the request object, it doesn't show how to create and configure one properly.
I just want an SSL websocket client to send and receive some simple messages, like "Hello World". Can anyone help me please?
I use Windows 7 64 Bit for the client's OS and Ubuntu 64 Bit on VirtualBox for the server's OS, but the server side is no problem. My poco version is 1.6.0 and I compiled it with Visual Studio 2013 Express. Also I use OpenSSL 1.0.1j.
Cheers
Alex
Look at WebSocket testcase. Use HTTPSClientSession (instead of HTTPClientSession).
ISSUE THAT I AM FACING:-
Select(..) API is throwing error when called with FD_SET set containing IPv6 and IPv4 sockets on Win7 Home premium but the same application is running fine on other win7 machine. But if i use only IPv6 or IPv4 socket in FD_SET then it runs fine. So i think, system support both IPv6 and IPv4.
I tried using the server from the link below :-
http://msdn.microsoft.com/en-us/library/windows/desktop/ms738639%28v=vs.85%29.aspx
Even this sample is same error from select call.
Anyone can please help me in getting the reason behind this error and solving this issue.
Thanks!!!
Unfortunately, Windows does not permit mixing sockets from different providers in the same call to select. This is because each provider is permitted to implement its own select handler.
The sockets contained within the fd_set structures must be associated with a single service provider. -- select function
Windows will pick a provider to send the select to (I believe the provider of the first socket in the set), and that provider will not recognize the other provider's sockets. Honestly, you shouldn't be using select anyway -- it's just provided for compatibility with the BSD sockets interface. It's definitely not the "Windows way".
There is a client/server application written using Boost's ASIO (Boost v.1.48) + OpenSSL (v.1.0.0d). Complete OpenSSL (dynamic/static libraries and binaries) is custom built, the after-build tests are passed correctly and it links to the client and the server statically. ASIO code works in asynchronous mode. All ASIO's SSL contexts use the boost::asio::ssl::context::sslv23
method. The problem description is the following.
Configuration 0
The server: works under Win7 Prof SP1 (Comp0). It uses a self-signed private key (PK0) and a public certificate (PC0) generated by the custom built OpenSSL binaries mentioned above. The server has a infinite timeout.
The client: works under WinXP Prof SP3 (Comp1). It uses the servers public certificate (PC0). The client has 20 secs timeout.
The clients connects successfully to the server but closes the connection by the 20 secs timeout in the SSL's handshake method (boost::asio::ssl::stream::async_handshake). FAIL.
Configuration 1
Both the server and the client run on the same Win7 Prof SP1 (Comp0), use the same ethernet interface and the same PK0/PC0 as in the configuration 0.
The clients successfully connects handshakes, sends/receives data and closes the connection. SUCCESS.
Configuration 2
The server: works under Win7 Prof SP1 (Comp0). It uses a self-signed private key (PK1) and a public certificate (PC1) generated by the custom built OpenSSL binaries BUT the PK1 and PC1 are generated a half of a year ago. PK0/PC0 are generated today. All the keys are generated by the same OpenSSL binaries (v.1.0.0d).
The client: works under WinXP Prof SP3 (Comp1). It uses the servers public certificate (PC1).
The clients successfully connects handshakes, sends/receives data and closes the connection. SUCCESS.
Configuration 3
Both the server and the client run on the same Win7 Prof SP1 (Comp0), use the same ethernet interface and the same PK1/PC1 as in the configuration 2.
The clients successfully connects handshakes, sends/receives data and closes the connection. Obviousely SUCCESS.
Changing the OpenSSL version to the latest stable release (v.1.0.0g) gives the same results.
The problem is not working configuration 0. Has anyone ever had such problem? Are there any ideas where can be the problem cause? In which direction is necessary to move to fix the problem?
Update #1. The code compiled using the tlsv1 method instead of the sslv23 one does not work in the Configuration 0 also.
Final Update. The problem is fixed. The cause is that the Comp1's system date was in the past, i.e. the PK0/PC0 are issued in future for this computer and OpenSSL fails in the handshake procedure. PC1 is issued in the past for the Comp1 and it works with it without problems. To diagnose the problem cause I used the following command executed on the client computer:openssl s_client -connect server_ip:server_port, where server_ip is the server address and server_port is the the server listening port. Now a task is to find a reason why handshake times out rather than returns an error. But it is another story. I hope my post will help someone in future.
The problem is fixed. The cause is that the Comp1's system date was in the past, i.e. the PK0/PC0 are issued in future for this computer and OpenSSL fails in the handshake procedure. PC1 is issued in the past for the Comp1 and it works with it without problems. To diagnose the problem cause I used the following command executed on the client computer:openssl s_client -connect server_ip:server_port
, where server_ip is the server address and server_port is the the server listening port. Now a task is to find a reason why handshake times out rather than returns an error. But it is another story. I hope my post will help someone in future.