When a client connects to a server using TCP, a new socket is created for the TCP stream. Does the connection remain on the same port the connection was made or does it get changed to some other port?
The new socket is an application-level concept introduced because each established connection needs a unique file descriptor (also distinct from the listening file descriptor), which maps to, but isn't the same as, a TCP session. The session itself is identified by the combination of source and destination address and port. The source (client) port is usually chosen at random, while the destination (server) port is the listen port. No additional port is allocated.
The server use the same port to listen and accept new connection, and communicate to the remote client.
Let's me give you an example, (in linux system):
First, start a http server by python：
xiongyu#ubuntu:~$ sudo python -m SimpleHTTPServer 500
Serving HTTP on 0.0.0.0 port 500 ...
Second use nc command to connect to the http server, here we start two client by:
xiongyu#ubuntu:~$ nc 0.0.0.0 500
Use netstat to see the netstate of port 500:
xiongyu#ubuntu:~$ netstat -natp |grep ':500'
tcp 0 0 0.0.0.0:500 0.0.0.0:* LISTEN 54661/python
tcp 0 0 127.0.0.1:51586 127.0.0.1:500 ESTABLISHED 57078/nc
tcp 0 0 127.0.0.1:51584 127.0.0.1:500 ESTABLISHED 54542/nc
tcp 0 0 127.0.0.1:500 127.0.0.1:51586 ESTABLISHED -
tcp 0 0 127.0.0.1:500 127.0.0.1:51584 ESTABLISHED 54661/python
You can see, the http server use port 500 to LISTEN for the client, after a new client connected to the server, it still use the port 500 to communite with the client, but with a new file descriptor .
The socket associated with the new descriptor returned by accept on the server will use the same port on the server side of the connection as the original socket (assuming "normal" definitions where the client initiates the connection). The new socket will have a different client port number (the remote port from the server's point of view).
Related
This is just a conceptual question that I have been thinking about recently.
Say I'm running an Nginx container on Docker on a host. Normally, for this to work, we have to map ports like 80 and 443 to host container. This is because these are listening ports, and connections from the outside world to port 80 should be forwarded to port 80 of the container. So far so good.
But also: port 80 is just the listening socket, right? The listening socket only accepts the connection; after this any communication done between a client and the Nginx server is supposedly done on a different socket with a random port number (on the server side). This is to allow multiple connections, and to keep the listening port free to establish more connections, etc. This is where my issue comes in.
Say I'm a client and I connect to this Nginx server. As far as I understand, I first send TCP packets to port 80 of the host that is hosting this Nginx Docker container. But during the establishment of the connection, the server changes their port to another number, say 45670. (Not sure how, but I am guessing the packets that are sent back suddenly mention this port, and our client will continue the rest of the exchange with this port number instead).
But now as I send packets (e.g. HTTP requests) to the host on port 45670, how will the Nginx docker container see those packets?
I am struggling to understand how server processes can run on Docker with only one port exposed / published for mapping.
Thanks!
But also: port 80 is just the listening socket, right? The listening socket only accepts the connection; after this any communication done between a client and the Nginx server is supposedly done on a different socket with a random port number (on the server side).
Nope. When a connection is established, the client side is a random port number (usually) and the server side is the same port that the server listens on.
In TCP there aren't actually listening sockets - they're an operating system thing - and a connection is identified by the combination of both the port numbers and both the IP addresses. The client sends a SYN ("new connection please") from its port 49621 (for example) to port 80 on the server; the server sends a SYN/ACK ("okay") from its port 80 to port 49621 on the client.
I have Mosquitto running on a local server, and my aim is to have 3 listeners:
all local network clients to connect without TLS on port 1883 (port 1883 is closed by router to public)
External clients to connect using TLS on port 8883
External client to connect without TLS on port 8880
which using this config works fine;
# Local MQTT
listener 1883
# End Local MQTT
# Insecure MQTT
listener 8880
# End Insecure MQTT
# Secure MQTT
listener 8883
## This is standard and should always be this
cafile /etc/ssl/certs/DST_Root_CA_X3.pem
## These are from your installation of LE
certfile /home/pi/.node-red/certs/fullchain.pem
keyfile /home/pi/.node-red/certs/privkey.pem
## Force all clients in this listener to provide a valid certificate, change th$
require_certificate true
## Stop all unauthorised connections
allow_anonymous false
## Use password file
password_file /etc/mosquitto/passwordfile
and which results in healthy Mosquitto log entries;
1575720819: Opening ipv4 listen socket on port 1883.
1575720819: Opening ipv6 listen socket on port 1883.
1575720819: Opening ipv4 listen socket on port 8883.
1575720819: Opening ipv6 listen socket on port 8883.
1575720819: Opening ipv4 listen socket on port 8880.
1575720819: Opening ipv6 listen socket on port 8880.
1575720820: New connection from 140.238.70.128 on port 8880.
1575719390: New client connected from 140.238.70.128 as telegraf (c1, k60, u'raspPi').
BUT... I want to ensure that only the client at 140.238.70.128 is able to connect on port 8880 (TLS isn't an option) so I added the IP address to the config;
# Insecure MQTT
listener 8880 140.238.70.128
# End Insecure MQTT
but that causes Mosquitto to stop, and the log shows;
1575720699: Opening ipv4 listen socket on port 1883.
1575720699: Opening ipv6 listen socket on port 1883.
1575720699: Opening ipv4 listen socket on port 8883.
1575720699: Opening ipv6 listen socket on port 8883.
1575720699: Opening ipv4 listen socket on port 8880.
1575720699: Error: Cannot assign requested address
I would be grateful for any advice as to why this doesn't work, or an alternative solution.
Edit. I also tried restricting the listener to ipv4, but that gave exactly same result;
# Insecure MQTT
listener 8880 140.238.70.128
socket_domain ipv4
# End Insecure MQTT
The listen directive can only take a address that is local to the machine the broker is running on. This is used to bind a socket to that address on the required port.
You can not use it as a filter for a remote machine, in fact there is no way to configure a port to only accept connections from a specific IP address in mosquitto* (or any other broker that I am aware of).
The only way to achieve what you want to do is to use the machines firewall to drop any packets from other IP addresses addressed to that port. You can use iptables to do this. Something like
iptables -A INPUT -p tcp --dport 8880 ! -s 140.238.70.129 DROP
This should drop any TCP packet destined for port 8880 that is not from 140.238.70.129
While this will work it will only block ipv4 clients, so if your networks has a properly routed IPv6 setup you will need to block access with ip6tables as well (and block access to port 1883).
* you might be able to write a custom auth plugin to do this, but I'm not sure if you get the remote IP address in the details about the user connecting. Also I don't think you can bind authentication to just one listener.
I need to be able to read/write to an Azure Service Bus Queue and for that, the hostname and ports need to be white-listed by my IT team.
The connection string is: "Endpoint=sb://[myappname].servicebus.windows.net;...".
I have tried the hostname with port 443 (assuming here), but that hasn't worked after white-listing. So now I tried writing to queue while capturing the traffic from Wireshark, but I am getting lost in all the network packet details there.
Can anyone please help me with this?
Thank you
TCP port is used by default for transport operations. Please have a try to open the port 5671 and 5672. We could get more information from AMQP 1.0 in Azure Service Bus and Event Hubs protocol guide.
Azure Service Bus requires the use of TLS at all times. It supports connections over TCP port 5671, whereby the TCP connection is first overlaid with TLS before entering the AMQP protocol handshake, and also supports connections over TCP port 5672 whereby the server immediately offers a mandatory upgrade of connection to TLS using the AMQP-prescribed model. The AMQP WebSockets binding creates a tunnel over TCP port 443 that is then equivalent to AMQP 5671 connections.
If you use a library, please have a try to set the ConnectivityMode to https (443 port)
ServiceBusEnvironment.SystemConnectivity.Mode = ConnectivityMode.Https
I m new to contiki and try to connect client ip 127.0.0.1 and port 502 to tcp server which is listening on 502 port but it always shows hostname not found or connection time out error. i tried contiki/example/http-socket. I want to send cc1310 launchpad sensor data on ipv4 server. can any one help me?
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).