Struggling with this for a couple of days. Unable to connect a desktop to a weave network. Error:
connection shutting down due to error during handshake: Unable to decrypt TCP msg.
Other instances are able to connect using the same command:
weave launch --ipalloc-init observer --ipalloc-range 10.36.0.0/16 --password something --trusted-subnets 10.1.1.0/16 ipToConnectTo
The desktop had been moved to another subnet 10.1.6.0 and used to have a reservation at 10.1.3.26. We changed the reservation to 10.1.6.23 and rebooted the desktop. I have a feeling this is more of a network issue rather than a problem with weave and could use some help from some network gurus.
OS - Mint 19, docker verson - 18.09.0, and weave - 2.5.0
Was the password...the hand written password lower 'k' looked like a 'K'.
Related
I am facing this issue for a couple of days and I am unable to reproduce it outside the Ubuntu Docker container.
Please refer to this simplified diagram of my architecture:
As you can see, I have everything running inside the Docker container.
This is not the typical issue of not being able to connect to inside the container, the whole application runs on the local network of the Docker container.
The Ubuntu Image is the official one with just some packages installed so that everything works (nothing too fancy, just python3 and some c++ tools).
It is running Mosquitto 2.0.15 with the following configuration:
listener 1883
protocol mqtt
allow_anonymous true
log_dest file /home/user/mosquitto.log
So, in summary, I am running an unsecured MQTT broker in the default port 1883. I also added a log file in an attempt to debug what is going on.
On my Python Client, the connection is made in the simplest way possible:
...
self.mqtt_client = mqtt.Client(client_id="Client Id")
self.mqtt_client.connect("localhost", 1883, 6000)
...
self.mqtt_client.loop_start()
...
This Client is able to connect to the broker with no issue at all.
Subscribe and Publish works perfectly too!
On my C++ Client, I try to keep it simple as well:
...
mqtt::async_client MQTTClient("tcp://localhost:1883", "Another Client Id");
MQTTClient.connect()->wait();
...
Yet, this Client fails every attempt to connect to the broker:
terminate called after throwing an instance of 'mqtt::exception'
what(): MQTT error [-1]: TCP/TLS connect failure
Aborted (core dumped)
Although it looks like a SSL/TLS error, this is actually the generic error for when the MQTT broker is not found (If I stop the broker on my local machine I get the same error).
Checking the MQTT broker logs (verbose ON), it does not record anything regarding the attempt to connect from C++ Client:
1672874968: mosquitto version 2.0.15 starting
1672874968: Config loaded from /etc/mosquitto/conf.d/default.conf.
1672874968: Opening ipv4 listen socket on port 1883.
1672874968: mosquitto version 2.0.15 running
(I do get log messages when connecting with Python Client)
On my own Linux machine I am unable to reproduce this issue. Both clients work fine.
I am using the same configuration for the Mosquitto broker and the Clients are exactly the same.
Already tried to play with the IP used to connect to the broker (localhost/127.0.0.1/0.0.0.0) and using different ports, the result is the same.
It is weird that the Python Client can connect with no issue at all.
At this point, I am fairly confident that the issue must be something Docker-specific and how it handles TCP sockets. But I am unable to find anything helpful online.
I can easily check that the port is open:
lsof -i -P -n | grep :1883
mosquitto 56 user 5u IPv4 1633274841 0t0 TCP 127.0.0.1:1883 (LISTEN)
Any ideas what is going on? Or debug tools ideas?
Thanks in advance!
I have tried:
Playing with IP and port of the broker;
Stating the preferable MQTT version (tried with every version);
Run Client with strace and try to find something unusual;
Verify if I am running the exact same Client as my Linux machine;
I finally found out what my issue was.
I had a HTTP proxy configured and Paho C will automatically use this proxy.
It is detecting by checking if "http_proxy" environment variable is set.
My solution was simply unset this variable:
unset http_proxy
Interestingly, the Python MQTT client does not have this behavior.
And for that reason, it worked perfectly!
I am using Docker for Desktop with version 20.10.17. Whenever I try to enable Kubernetes v1.24.2 from Docker Desktop and then click on apply and restart, it shows "Kubernetes failed to start". Moreover, when I type kubectl version in cmd, the version for client is shown but for server it displays "Unable to connect to server: EOF". I have tried a number of solutions including purging and resetting from troubleshooting option of docker desktop. I have disabled VPN, firewall but nothing is helping me. Can anyone help me overcome this problem?
I'm experiencing an issue with OpenSSL/DTLS server.
Environment: docker container based on CentOs7
OpenSSL version: OpenSSL-1.1.1d
A DTLS server (non-blocking) using DTLSv1_Listen having a UDP socket with SO_REUSEADDR is unable to accept a second
client connection when it has already been accepted a client connection and serving it.
When the first client has finished, the second client connection is accepted.
I have used the dtls_udp_echo.c (taken from http://web.archive.org/web/20150617012520/http://sctp.fh-muenster.de/dtls-samples.html ) to carry out the test and reproduce the issue.
The test application has been compiled and executed within a docker container, having CentOS7 as base image, but the behaviour has been noticed with other base images OS too (e.g. Redhat, Ubuntu, Debian, SLES).
The same application running on a bare metal works without any issue.
Is there any known compatibility issue between Docker and OpenSSL/DTLS?
Is there any specific configuration to be done to overcome this issue?
Best Regards
I worked on my computer (mac os High Sierra 10.13.4) for a Rails application. I had Postgres, Redis and ElasticSearch installed via Homebrew.
I recently started to dockerize the app on a new branch.
When I went back to my main branch, none of the brew services were working:
PG::ConnectionBad - could not connect to server: Connection refused
which I fixed thanks to https://dba.stackexchange.com/questions/75214/postgresql-not-running-on-mac
couldn't connect to redis
which I fixed by running redis-cli
Errno::ECONNREFUSED - Failed to open TCP connection to localhost:9200 (Connection refused - connect(2) for "::1" port 9200)
I tried stopping/starting, desinstalling/reinstalling elasticsearch and even desinstalling/reinstalling Homebrew. I'm considerating doing a clean reinstall of my computer.
I don't understand how working on docker could break services on my computer, I thought it was supposed to fix exactly that kind of problems.
Any help on getting elasticsearch to work would be really appreciated!
This answer is only a speculation. A little more information might help us figure out what’s really going on here.
Are the Docker containers still running?
If yes, do they use the same ports that these services do on your Mac?
If the answer to both the above questions was yes, then you’ve found your problem.
What I mean to say is that if the containers are running and one of them is mapped to the port 9200, which also happens to be the port on which the required services on your Mac listen to by default, then these services cannot run on that port as it is already being used by one of your containers.
Solution: If this is the case, stop the containers and try running your services again
Sometimes my ArangoDB is going down with next error:
Error message 'Could not connect to 'tcp://127.0.0.1:8529' 'connect() failed with #10061
I can't understand the reason. It's look like I am turning on my PC and nothing do not work.
Before I fixed this problem with reinstall, but is there any better solution?
OS Windows
ArangoDB 2.8.7
The V8 version used in the pre ArangoDB 3 had occasional troubles in the garbage collection which would make ArangoDB in term go down.
This is fixed with ArangoDB 3.
Please upgrade your installation, and report back whether the problem still persists.
You can use netstat to check whether ArangoDB is listening to its default port 8529:
netstat -a
Active Connections
Proto Lokale Adresse Remoteadresse Status
...
TCP 127.0.0.1:8529 meschenich:0 LISTEN
...
If thats not the case, your client has nothing to connect to.
This could be due to firewall of an antivirus.
In my case it was Avast antivirus that was blocking connecting to that port.
I disabled all the antivirus shields and checked loading arangodb web server
http://127.0.0.1:8529
It connects after few minutes.
Reference : No connection could be made because the target machine actively refused it
I fixed the problem by restarting Windows.