When I publish and subscribe at localhost its work fine.
When I try from my PC at home I just can't connect to the broker.
open TCP port in/out at security group - 1883 8883 8080
open the ports also at my ec2 instance firewall...
what is the problem? I use the public DNS by amazon as I think I should...
This is an exercise at diagnosing network problems:
1) netstat -a -n | grep 1883
will tell you whether your broker is configured correctly
2) wireshark packet capture will tell you whether your system is receiving packets at the specific port
You will not get an answer until you at least do those.
Related
I am having some problems with my Mosquitto MQTT broker which I do not understand. I had setup another Mosquitto broker in a Google Cloud Ubuntu 20.04 VM and it was working properly. I have moved to a self-managed Ubuntu 20.04 VM in my university and have not been able to connect to the broker ever since. A little background on the current setup:
netfilter-persistent firewall (am unsure of the exact name of the firewall, this is the name of th service) has port 1883 open
ufw is inactive
the university has 2 levels in the firewall, one in the VM and one external. I have asked for the opening of ports 1883 (I am aware that only port 8883 should be open but this is temporary until I solve my issue)
the VM is accessible from outside the LAN of the university, as checked in https://www.yougetsignal.com/tools/open-ports/
I have an Apache webpage running and it is also accessible externally
I have NodeRED using port 1880 and it is also accessible externally
My Mosquitto conf file looks like the following. For the time being, I am not using TLS authentication, as I first need to solve the issue with the connection.
allow_anonymous false
password_file /etc/mosquitto/passwd
listener 1883 0.0.0.0
However, I have not been able to enable the communication when using either the server IP or the domain name. If I attempt to connect using localhost, everything works:
~$ mosquitto_sub -h localhost -t test -p 1883 -u "XX" -P "XX" -d
Client (null) sending CONNECT
Client (null) received CONNACK (0)
Client (null) sending SUBSCRIBE (Mid: 1, Topic: test, QoS: 0, Options: 0x00)
Client (null) received SUBACK
Subscribed (mid: 1): 0
If I attempt to connect with the domain name, I never receive an acknowledgment and the connection is never established:
~$ mosquitto_sub -h domain.com -t test -p 1883 -u "XX" -P "XX" -d
Client (null) sending CONNECT
Client (null) sending CONNECT
Client (null) sending CONNECT
Client (null) sending CONNECT
Client (null) sending CONNECT
Mosquitto seems to be properly bound when running the lsof -i command in the console:
mosquitto 2177304 mosquitto 5u IPv4 10127120 0t0 TCP *:1883 (LISTEN)
mosquitto 2177304 mosquitto 7u IPv4 10127251 0t0 TCP localhost:1883->localhost:47236 (ESTABLISHED)
I would appreciate it if anyone could guide me into what could be the root of my issue. If more information is needed regarding my setup, I will gladly provide it.
Thanks in advance to all!
I'm struggling with exposing Mosquitto that I setup on my Centos7 homeserver to the outside internet through my router.
Mosquitto runs fine on my localhost and post 1883 on the homeserver. I am able to pub/sub, and it is listening on the port as 127.0.0.1:1883 (tcp)
My home router has a dynamic IP (for now), say 76.43.150.206. On the router I port forwarded 1883 as both internal/external ports to my home server, say 192.168.1.100.
In the mosquitto.conf file, I have one simply line "listener 1883 76.43.150.206".
When I then attempt to pub/sub using a python client on an external computer as mqttc.connect("76.43.150.206", 1883), it says connection refused.
Any hints on what I'm doing wrong or how to get it working? BTW, my understanding of this setup is very basic and I've pretty much been going off blogs.
Here's how it will work:
1.) Setup mosquitto.conf as
listener 1883 0.0.0.0
#cafile <path to ca file>
#certfile <path to server cert>
#keyfile <path to server key>
#require_certificate false
0.0.0.0 binds the server to all interfaces present.
You can uncomment the code to enable TLS for better security. But you'll have to configure the client to use the same as well..
2.) Port forward router's 1883 port number to port 1883 of IP of machine running the broker.
3.) Start the broker and test your client!
You should not put the external address into the mosquitto config file.
You should probably not even have a listen line at all as mosquitto will bind to all available IP addresses on the machine it's running with the default port (1883).
If you really must use the listen directive (e.g. in order to set up SSL) then it should be configured with the internal IP address of the machine running the broker, in this case 192.168.1.100 and with a different port number so it does not clash with the default
listen 1884 192.168.1.100
I have the Contiki web demo running on a CC2650 and I'm trying to troubleshooting MQTT and want to make sure I'm properly pointing the node to a local MQTT broker (Mosquitto). Is there anything else I need to do but change the broker IP on the node to the bbbb:: IPv6 address of the broker? I've tested publishing and subscribing between Linux machines using the bbbb:: IPv6 address and it is working. Is there anything I need to do with the Org Id or auth token? I've done an exhaustive search but can't seem to find any specific documentation. Here is the link to the TI tutorial for reference http://processors.wiki.ti.com/index.php/Cc26xx_sw_examples Thanks in advance.
I am now able to answer my question on this and yes you can just point a node a local MQTT broker by pointing to the IPv6 address of the Mosquitto broker. I'm troubleshooting some 6LowPAN packet loss issues which was making the reception of published messages take a long time. Subscribing to the broker for all topics with mosquitto_sub -h localhost -v -t “#” and doing a tcpdump on port 1883 (tcpdump -i eth0 -v -X port 1883) were both helpful in seeing that there was activity.
How I can say a port is open or closed. What's the exact meaning of Open port and closed port.
My favorite tool to check if a specific port is open or closed is telnet. You'll find this tool on all of the operating systems.
The syntax is: telnet <hostname/ip> <port>
This is what it looks like if the port is open:
telnet localhost 3306
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
This is what it looks like if the port is closed:
telnet localhost 9999
Trying 127.0.0.1...
telnet: connect to address 127.0.0.1: Connection refused
telnet: Unable to connect to remote host
Based on your use case, you may need to do this from a different machine, just to rule out firewall rules being an issue. For example, just because I am able to telnet to port 3306 locally doesn't mean that other machines are able to access port 3306. They may see it as closed due to firewall rules.
As far as what open/closed ports means, an open port allows data to be sent to a program listening on that port. In the examples above, port 3306 is open. MySQL server is listening on that port. That allows MySQL clients to connect to the MySQL database and issue queries and so on.
There are other tools to check the status of multiple ports. You can Google for Port Scanner along with the OS you are using for additional options.
A port that's opened is a port to which you can connect (TCP)/ send data (UDP). It is open because a process opened it.
There are many different types of ports. These used on the Internet are TCP and UDP ports.
To see the list of existing connections you can use netstat (available under Unix and MS-Windows). Under Linux, we have the -l (--listen) command line option to limit the list to opened ports (i.e. listening ports).
> netstat -n64l
...
tcp 0 0 0.0.0.0:6000 0.0.0.0:* LISTEN
...
udp 0 0 0.0.0.0:53 0.0.0.0:*
...
raw 0 0 0.0.0.0:1 0.0.0.0:* 7
...
In my example, I show a TCP port 6000 opened. This is generally for X11 access (so you can open windows between computers.)
The other port, 53, is a UDP port used by the DNS system. Notice that UDP port are "just opened". You can always send packets to them. You cannot create a client/server connection like you do with TCP/IP. Hence, in this case you do not see the LISTEN state.
The last entry here is "raw". This is a local type of port which only works between processes within one computer. It may be used by processes to send RPC events and such.
Update:
Since then netstat has been somewhat deprecated and you may want to learn about ss instead:
ss -l4n
-- or --
ss -l6n
Unfortunately, at the moment you have to select either -4 or -6 for the corresponding stack (IPv4 or IPv6).
If you're interested in writing C/C++ code or alike, you can read that information from /proc/net/.... For example, the TCP connections are found here:
/proc/net/tcp (IPv4)
/proc/net/tcp6 (IPv6)
Similarly, you'll see UDP files and a Unix file.
Programmatically, if you are only checking one port then you can just attempt a connection. If the port is open, then it will connect. You can then close the connection immediately.
Finally, there is the Kernel direct socket connection for socket diagnostics like so:
int s = socket(
AF_NETLINK
, SOCK_RAW | SOCK_CLOEXEC | SOCK_NONBLOCK
, NETLINK_SOCK_DIAG);
The main problem I have with that one is that it does not really send you events when something changes. But you can read the current state in structures which is safer than attempting to parse files in /proc/....
I have some code handling such a socket in my eventdispatcher library. Only it still has to do a poll to get the data since the kernel does not generate events on its own (i.e. a push is much better since it only has to happen once when an event actually happens).
I'm looking at ZeroMQ Realtime Exchange Protocol (ZRE) as inspiration for building an auto-discovery of peers in a distributed application.
I've built a simple prototype application using UDP in Python following this model. It seems it has the (obivious, in retrospect) limitation that it only works for detecting peers if all peers are on other machines. This due to the socket bind operation on the discovery port.
Reading up on SO_REUSEADDR and SO_REUSEPORT tells me that I can't exactly do this with the UDP broadcast scheme as described in ZRE.
If you needed to build an auto-discovery mechanism for distributed applications such that multiple application instances (possibly with different versioN) can run on the same machine, how would you build it?
You should be able to bind each server instance to a different address. The entire subnet 127.0.0.0/8 should resolve to your localhost, so you can set up - for example - one service listening on 127.0.0.1, another listening on 127.0.0.2, etc. Anything from 127.0.0.1 to 127.255.255.254.
# works as expected
nc -l 127.0.0.100 3000 &
nc -l 127.0.0.101 3000 &
# shows error "nc: Address already in use"
nc -l 127.0.0.1 3000 &
nc -l 127.0.0.1 3000 &