I've been trying to access a TCP server from my 4g GSM Module via AT commands.I hosted a test tcp server in socket test application, add a new inbound rule regarding the tcp Port in Windows Firewall advanced setting and also i opened a virtual server allowing the tcp port which i configured as server in the modem menu also. The server is nowhere to seen in the gsm module. Then I checked the canyouseeme.org website. It says that the connection is refused.
Am I missing anything.Please Help
I am trying to send messages from my mac to a Google IoT Gateway running on a Google VM linux instance. Can't get the gateway server running in the linux instance to ack messages sent from scripts on my mac.
Set up Google VM linux instance and followed directions in:
https://codelabs.developers.google.com/codelabs/cloud-iot-core-gateways/index.html#0
I did try to read through https://cloud.google.com/community/tutorials/cloud-iot-gateways-rpi.
I setup GOOGLE_CLOUD_PROJECT to point to my project.
I updated the ADDR in the thermostat.py script to point to the address of the linux instance. But I am not quite sure which address to use.
The address obtained by running ifconfig on the linux instance isn't pingable from my mac. I used the static address assigned to the linux instance, and although I can ping that, I don't see the server running on the gateway ack the message send by the script.
On the linux instance I run the gateway server, and if I run thermostat.py on the same instance, I see the messages received by the gateway and the Google IoT console.
However I am having trouble running thermostat.py from my local machine (mac). I want to get this working before trying it on my embedded device. I can see the script attempt to send the message but I don't see any messages received on the server.
Which ip address should I be using to communicate with the gateway server on my linux instance ?
Other than setting the ADDR and GOOGLE_CLOUD_PROJECT, are there any other changes I need to make to thermostat.py?
The VMs in GCE (Google Compute Engine) have a locked down firewall by default. You need to open up the ports for the HTTP connection so the traffic to the gateway can get through.
Thanks in advance for the help.
Issue:
Unable to receive snmp-traps on udp 162 port.
Scenario: Trying to put a nexus 5672 in OpenNMS for monitoring
Pre-Checks done:
I am able to snmpwalk the nexus 5k from my linux node on which
OpenNMS is installed.
I am even able to do snmpgets.
I see snmp traffic on udp 161 but they are primarily because of the snmp-get's that opennms is doing.
UNABLE TO SEE ANYTHING WHEN I DO A TCPDUMP ON 162 PORT :(
I have checked if any ACLs are set locally but they are not, iptables as a service is stopped.
I have verified that the snmp-configs are properly pushed.
Configs are pushed on the loop-back interface and there are not acl-groups on the nexus 5k either and there is not firewall between the nexus 5k and the OpenNMS Hosted Linux System
Please help, i do not know what i am missing.
Ok, first of all, there are two concepts with SNMP, the first one is polling for data to get data from sensors or discover elements from your device. The monitoring application sends requests to your Nexus device. This is what you do when you issue a snmpwalk or snmpget command. The Nexus device has an SNMP agent running which is listening on port 161/UDP.
The second one is, your Nexus device can send messages to your monitoring application. Your monitoring application with OpenNMS needs to have a listener running on port 162/UDP, called SNMP Traps or SNMP Informs.
So trying to debug the problem not getting SNMP Traps with snmpget or snmpwalk does not help in the first place. The communication is initialized by the Nexus device and OpenNMS is the listener for the traps.
I would try to debug the problem with the following steps:
Ensure OpenNMS has Trapd enabled and is listening on the right interfaces, e.g. with ss -lnpu sport = :162
Make sure you don't have a firewall on your OpenNMS server which blocks traffic to 162/UDP, e.g. iptables -L
Use tcpdump to see if the SNMP trap from your Nexus arrives on the OpenNMS server by looking at traffic with target port 162 with protocol UDP.
If you're SNMP trap is received from the OpenNMS server, you can then start looking in trapd.log of your OpenNMS server and verify if community settings for the IP is correct. OpenNMS will use the community which is configured for the senders IP address to process the trap
In hope this helps
This got resolved. Everything from the Linux end, and the OpenNMS SNMP end was good. However, the network device had SNMP configs wrongly pushed. I changed it to use the default VRF rather than the loopback address, and it started working.
I am confused that if ports serve to distinguish the applications , so as to tell to which particular application data packet belongs , then if i have two browsers both downloading file using FTP , how would packet be distinguished to which brower it is going, as FTP uses port 21 ?
FTP is not the best example as it's behaviour change depending on Active/Passive mode.
Consider HTTP instead, which is simplier.
Browser_A initiates a TCP connection to ServerIP:80
PC assigns a random port, example HostIP:55123
TCP Connextion between HostIP:55123 and ServerIP:80 is established
Server receives a request and responds to HostIP:55123
PC knows every TCP packet from ServerIP:80 to 55123 should be delivered to Browser_A
First of all port 21 is COMMAND port, so when downloading file for sure FTP clients will not be connected to port 21.
Secondly, a connection is established from a high port (> 1024) to the FTP data port, so your browsers will open (in PASSIVE mode) a connection from a high port.
Answering to your question, if you open 2 browsers and start downloading data from FTP server, every browser will connect from a different port.
Can someone tell me what is the difference between active and passive FTP?
Which one is preferable?
Active and passive are the two modes that FTP can run in.
For background, FTP actually uses two channels between client and server, the command and data channels, which are actually separate TCP connections.
The command channel is for commands and responses while the data channel is for actually transferring files.
This separation of command information and data into separate channels a nifty way of being able to send commands to the server without having to wait for the current data transfer to finish. As per the RFC, this is only mandated for a subset of commands, such as quitting, aborting the current transfer, and getting the status.
In active mode, the client establishes the command channel but the server is responsible for establishing the data channel. This can actually be a problem if, for example, the client machine is protected by firewalls and will not allow unauthorised session requests from external parties.
In passive mode, the client establishes both channels. We already know it establishes the command channel in active mode and it does the same here.
However, it then requests the server (on the command channel) to start listening on a port (at the servers discretion) rather than trying to establish a connection back to the client.
As part of this, the server also returns to the client the port number it has selected to listen on, so that the client knows how to connect to it.
Once the client knows that, it can then successfully create the data channel and continue.
More details are available in the RFC: https://www.ietf.org/rfc/rfc959.txt
I recently run into this question in my work place so I think I should say something more here. I will use image to explain how the FTP works as an additional source for previous answer.
Active mode:
Passive mode:
In an active mode configuration, the server will attempt to connect to a random client-side port. So chances are, that port wouldn't be one of those predefined ports. As a result, an attempt to connect to it will be blocked by the firewall and no connection will be established.
A passive configuration will not have this problem since the client will be the one initiating the connection. Of course, it's possible for the server side to have a firewall too. However, since the server is expected to receive a greater number of connection requests compared to a client, then it would be but logical for the server admin to adapt to the situation and open up a selection of ports to satisfy passive mode configurations.
So it would be best for you to configure server to support passive mode FTP. However, passive mode would make your system vulnerable to attacks because clients are supposed to connect to random server ports. Thus, to support this mode, not only should your server have to have multiple ports available, your firewall should also allow connections to all those ports to pass through!
To mitigate the risks, a good solution would be to specify a range of ports on your server and then to allow only that range of ports on your firewall.
For more information, please read the official document.
Redacted version of my article FTP Connection Modes (Active vs. Passive):
FTP connection mode (active or passive), determines how a data connection is established. In both cases, a client creates a TCP control connection to an FTP server command port 21. This is a standard outgoing connection, as with any other file transfer protocol (SFTP, SCP, WebDAV) or any other TCP client application (e.g. web browser). So, usually there are no problems when opening the control connection.
Where FTP protocol is more complicated comparing to the other file transfer protocols are file transfers. While the other protocols use the same connection for both session control and file (data) transfers, the FTP protocol uses a separate connection for the file transfers and directory listings.
In the active mode, the client starts listening on a random port for incoming data connections from the server (the client sends the FTP command PORT to inform the server on which port it is listening). Nowadays, it is typical that the client is behind a firewall (e.g. built-in Windows firewall) or NAT router (e.g. ADSL modem), unable to accept incoming TCP connections.
For this reason the passive mode was introduced and is mostly used nowadays. Using the passive mode is preferable because most of the complex configuration is done only once on the server side, by experienced administrator, rather than individually on a client side, by (possibly) inexperienced users.
In the passive mode, the client uses the control connection to send a PASV command to the server and then receives a server IP address and server port number from the server, which the client then uses to open a data connection to the server IP address and server port number received.
Network Configuration for Passive Mode
With the passive mode, most of the configuration burden is on the server side. The server administrator should setup the server as described below.
The firewall and NAT on the FTP server side have to be configured not only to allow/route the incoming connections on FTP port 21 but also a range of ports for the incoming data connections. Typically, the FTP server software has a configuration option to setup a range of the ports, the server will use. And the same range has to be opened/routed on the firewall/NAT.
When the FTP server is behind a NAT, it needs to know it's external IP address, so it can provide it to the client in a response to PASV command.
Network Configuration for Active Mode
With the active mode, most of the configuration burden is on the client side.
The firewall (e.g. Windows firewall) and NAT (e.g. ADSL modem routing rules) on the client side have to be configured to allow/route a range of ports for the incoming data connections. To open the ports in Windows, go to Control Panel > System and Security > Windows Firewall > Advanced Settings > Inbound Rules > New Rule. For routing the ports on the NAT (if any), refer to its documentation.
When there's NAT in your network, the FTP client needs to know its external IP address that the WinSCP needs to provide to the FTP server using PORT command. So that the server can correctly connect back to the client to open the data connection. Some FTP clients are capable of autodetecting the external IP address, some have to be manually configured.
Smart Firewalls/NATs
Some firewalls/NATs try to automatically open/close data ports by inspecting FTP control connection and/or translate the data connection IP addresses in control connection traffic.
With such a firewall/NAT, the above configuration is not necessary for a plain unencrypted FTP. But this cannot work with FTPS, as the control connection traffic is encrypted and the firewall/NAT cannot inspect nor modify it.
Active mode:
-server initiates the connection.
Passive mode:
-client initiates the connection.
Active Mode—The client issues a PORT command to the server signaling that it will “actively” provide an IP and port number to open the Data Connection back to the client.
Passive Mode—The client issues a PASV command to indicate that it will wait “passively” for the server to supply an IP and port number, after which the client will create a Data Connection to the server.
There are lots of good answers above, but this blog post includes some helpful graphics and gives a pretty solid explanation: https://titanftp.com/2018/08/23/what-is-the-difference-between-active-and-passive-ftp/