I want to establish a TLS connection from ESP8266 to a mosquitto MQTT Server.
I'm using the Adafruit example INO with WiFiClientSecure, which successfully connects to my Wifi works fine with other MQTT Servers (e.g. iot.eclipse.org:8883)
Just when I'm trying to connect to my own mosquitto instance, it fail
In the mosquitto log shows:
OpenSSL Error: error:1408A10B:SSL routines:SSL3_GET_CLIENT_HELLO:wrong version number
My mosquitto.conf looks like this
pid_file /var/run/mosquitto.pid
persistence true
persistence_location /var/lib/mosquitto/
log_dest file /var/log/mosquitto/mosquitto.log
include_dir /etc/mosquitto/conf.d
allow_anonymous false
listener 51883
password_file /etc/mosquitto/pwfile
conf.d contains:
cafile /etc/letsencrypt/live/<my-domain>/fullchain.pem
certfile /etc/letsencrypt/live/<my-domain>/fullchain.pem
keyfile /etc/letsencrypt/live/<my-domain>/privkey.pem
The certificates are generated using let's encrypt- Connection from MQTT-Dash (Adnroid App) works perfectly.
I couldn't figure out which TLS Version the WiFiClientSecure is using or how defne it.
Looking at this question asked today it seems you may have to specify a tls_version after all to get things to work
listener 8883
certfile /etc/letsencrypt/live/home.kamidesigns.be/cert.pem
cafile /etc/letsencrypt/live/home.kamidesigns.be/chain.pem
keyfile /etc/letsencrypt/live/home.kamidesigns.be/privkey.pem
tls_version tlsv1.2
Related
I've configured shadowsocks system by running ss-server on VPS and ss-local on my client machine.
Then I made a simple SOCKS5 client which connects to ss-local and resolve SOCKS request using C.
All work well, when I run ss-tunnel instead of ss-local, my SOCKS5 client can't connect to ss-tunnel.
TCP connection terminates as soon as it established.
I'm not sure what is the proper reason.
ss-tunnel -c config.json -L <destaddr:port>
But it does when I run ss-local instead.
ss-local -c config.json
Below is my config file.
{
"server":"xxx.xxx.xxx.xxx",
"server_port":443,
"local_address": "127.0.0.1",
"local_port":10800,
"password":"xxxxxxxxxx",
"timeout":60,
"method":"chacha20-ietf-poly1305",
"workers":8,
"plugin":"obfs-local",
"plugin_opts":"obfs=tls;obfs-host=www.google.com"
}
Is there any difference between protocols of ss-local and ss-tunnel? I know it's false, but anyway can't get it how they go wrong.
Thanks.
ss-tunnel establishes a complete tunnel with ss-server, all traffic to ss-tunnel is directly relayed to ss-server without any SOCKS request/resolve processes.
After I've removed SOCKS handshake in my client program, it worked properly.
I am trying to connect to a windows machine in my local network from ubuntu with samba client. To send a message I type :
smbclient -M 192.168.1.10
But I get
Connection to 192.168.1.10 failed. Error NT_STATUS_IO_TIMEOUT
This is most likely because the box your trying to do smbclient uses an outdated (and insecure) version of SMB such as SMBv1.
You'll need to edit the smb.conf in your machine and specify the client min protocol into CORE. You'll also need to specify the client max protocol into SMB3.
More information here: https://www.samba.org/samba/docs/current/man-html/smb.conf.5.html
Steps:
On your host machine:
sudo nano /etc/samba/smb.conf
Add the following settings under Global Settings:
client min protocol = CORE client max protocol = SMB3
Write (Ctrl + O) and Exit (Ctrl + X) nano text editor.
Retry smbclient
I am trying to run this docker file https://gitlab.com/snippets/1713665
consoles
I have running iroha container as you can see in right console on 50051 port, but on running the above docker file for web GRPC then you can see in left console it is unable to make connection. as i have also tried with enabling and disabling the firewalls and also with opening the 50051 withudo ufw allow 50051 sudo ufw allow 50051 ...But in the end i have the same results
"Err: connection error: desc = "transport: Error while dialing dial tcp 127.0.0.1:50051: connect: connection refused". Reconnecting... system=system"
I have also posted this issue month ago but no once gave me any response, Thats why i am reposting with further elaboration
Try running the grpc web proxy, with the backend address as localhost, instead of whatever is default in the gitlab post.
ex. ./grpcwebproxy-v0.13.0-osx-x86_64 --backend_addr=localhost:50051 --run_tls_server=false
From the console logs, it looks like it is trying to connect to dev.localdomain:50051
I have a virtual machine that is supposed to be the host, which can receive and send data. The first picture is the error that I'm getting on my main machine (from which I'm trying to send data from). The second picture is the mosquitto log on my virtual machine. Also I'm using the default config, which as far as I know can't cause these problems, at least from what I have seen from other examples. I have very little understanding on how all of this works, so any help is appreciated.
What I have tried on the host machine:
Disabling Windows defender
Adding firewall rules for "mosquitto.exe"
Installing mosquitto on a linux machine
Starting with the release of Mosquitto version 2.0.0 (you are running v2.0.2) the default config will only bind to localhost as a move to a more secure default posture.
If you want to be able to access the broker from other machines you will need to explicitly edit the config files to either add a new listener that binds to the external IP address (or 0.0.0.0) or add a bind entry for the default listener.
By default it will also only allow anonymous connections (without username/password) from localhost, to allow anonymous from remote add:
allow_anonymous true
More details can be found in the 2.0 release notes here
You have to run with
mosquitto -c mosquitto.conf
mosquitto.conf, which exists in the folder same with execution file exists (C:\Program Files\mosquitto etc.), have to include following line.
listener 1883 ip_address_of_the_machine(192.168.1.1 etc.)
By default, the Mosquitto broker will only accept connections from clients on the local machine (the server hosting the broker).
Therefore, a custom configuration needs to be used with your instance of Mosquitto in order to accept connections from remote clients.
On your Windows machine, run a text editor as administrator and paste the following text:
listener 1883
allow_anonymous true
This creates a listener on port 1883 and allows anonymous connections. By default the number of connections is infinite. Save the file to "C:\Program Files\Mosquitto" using a file name with the ".conf" extension such as "your_conf_file.conf".
Open a terminal window and navigate to the mosquitto directory. Run the following command:
mosquitto -v -c your_conf_file.conf
where
-c : specify the broker config file.
-v : verbose mode - enable all logging types. This overrides
any logging options given in the config file.
I found I had to add, not only bind_address ip_address but also had to set allow_anonymous true before devices could connect successfully to MQTT. Of course I understand that a better option would be to set user and password on each device. But that's a next step after everything actually works in the minimum configuration.
For those who use mosquitto with homebrew on Mac.
Adding these two lines to /opt/homebrew/Cellar/mosquitto/2.0.15/etc/mosquitto/mosquitto.conf fixed my issue.
allow_anonymous true
listener 1883
you can run it with the included 'no-auth' config file like so:
mosquitto -c /mosquitto-no-auth.conf
I had the same problem while running it inside docker container (generated with docker-compose).
In docker-compose.yml file this is done with:
command: mosquitto -c /mosquitto-no-auth.conf
I've got a remote server on eapps.com that I'm using as my "production" server. I have my own computer at home that I'm using as my "development" server. I'm trying to use JNDI over HTTP to do some batch processing. The following works at home, but not on the eapps machine.
I'm connecting to some EJBs (stateless session), and have my jndi.properties set to this:
(this is for the eapps machine)
java.naming.factory.initial=org.jboss.naming.HttpNamingContextFactory
java.naming.provider.url=http://my.prodhost.com:8080/invoker/JNDIFactory
java.naming.factory.url.pkgs=org.jboss.naming.client:org.jnp.interfaces
# timeout is in milliseconds
jnp.timeout=15000
jnp.sotimeout=15000
jnp.maxRetries=3
(this is for my machine at home)
java.naming.factory.initial=org.jboss.naming.HttpNamingContextFactory
java.naming.provider.url=http://localhost:8080/invoker/JNDIFactory
java.naming.factory.url.pkgs=org.jnp.interfaces
java.naming.factory.url.pkgs=org.jboss.naming.client
# timeout is in milliseconds
jnp.timeout=15000
jnp.sotimeout=15000
jnp.maxRetries=3
As I said, it works at home, but when I try it remotely, I get:
Can not get connection to server. Problem establishing socket connection for InvokerLocator [socket://my.prodhost.com:4446//?dataType=invocation&enableTcpNoDelay=true&marshaller=org.jboss.invocation.unified.marshall.InvocationMarshaller&socketTimeout=600000&unmarshaller=org.jboss.invocation.unified.marshall.InvocationUnMarshaller]
...
Caused by: java.net.ConnectException: Connection timed out: connect
Am I doing something wrong here, or is it possibly a firewall issue? To the best of my knowledge, port 4446 is not blocked.
Are the differences in the jndi.properties intentional (at the java.naming.factory.url.pkgs property level)?
Also, can you run a netstat -a | grep 4446 on both machines and update the question with the output?
Update: If the netstat command didn't return anything for port 4446 (JBoss was running, right?), then the JBoss Remoting Connector for the UnifiedInvoker service is very likely not listening on your eApps host, hence the connection timeout. Maybe this service has been disabled by eApps, you should contact the support and discuss this with them.
Just in case, a sample Connector configuration can be found in the jboss-service.xml under the server node's conf directory. Maybe compare the remote one (if you have access to it) with your local file to confirm this (but if it's disable, there must be a reason, discuss it with the support).
And by the way, this is what I get when I run the netstat command with JBoss 4.2.3.GA started on my GNU/Linux machine (default configuration):
$ netstat -a | grep 4446
tcp 0 0 localhost:4446 *:* LISTEN