Can and will an operating system reuse a source port number for a connection to a different destination address/port combination?
If I connect() to enough hosts, and keep those connections open, eventually I'll run out of unique source ports, exhausting the ephemeral range, the non-root range (1025-65,535; assuming non-root) or the absolute range (0-65,535). I want to know if those represent real limits to the number of hosts I can simultaneously have a connection to. I'm interested in what the standards promise (or don't), as well as the reality on Linux (Windows would be a bonus).
I know that opening that many connections will likely run into a number of other limits; that's a different issue and question. If it matters, this massive number of connections would be divided among a similarly large number of processes. I'm interested in the case where I'm requesting an ephemeral port, not manually bind()ing one. If under "normal" circumstances ports won't be reused, are there ways of changing that behavior from user-space (at which point bind()ing to a specific point becomes an option)?
By default, the kernel will not reuse any in-use port for an ephemeral port, which may result in failures if you have 64K+ simultaneous ports in use.
You can explicitly reuse a port by using the SO_REUSEADDR socket option and explicitly binding to the same port. This only works if none of the ports are listening (you can't reuse a listening port), and if you connect each socket to a different remote address.
In theory yes. In practice no, because bind precedes connect, and so it can't see what you're connecting to, so can't see that the 4-tuple would be unique, so won't let you reuse an ephemeral port.
Related
I am trying to find out whether the machines in a network are running a certain app. More like, I am trying to resolve addresses of nodes in a network.
I built a small code based on ARP, but it works only on a local network(same subnet). What I want to do is resolve addresses out of the subnet i.e. all other nodes.
I read these answers: UDP broadcast packets across subnets
and Broadcast on different subnets
But they all talk about changing router setting or creating a multicast network.
From what I read for multicasting to work, I need to create a multitask network beforehand. Is it really necessary?
And for changing router setting, does it really have to be a "special" router?
This is all for a college assignment and would be demonstrating it probably on an ad-hoc network or something like that.
I am open to ideas to solve the original problem.
PS:
1. I am a beginner in networking so do excuse me for any fault or misinterpretation.
I am using sockets and C(No other option).
Edit 1:
I am well aware ARP is useless outside the subnet. I mentioned it because I used it and it helped explaining the problem.
Edit 2:
The original problem is:
Building a chat application, nothing fancy sending messages from one point to another, without using a central server of any kind. Not even a hybrid network with a central store is allowed.
i.e. if A and B are two clients, A should directly connect to B and vice versa.
I did some research and decided to use P2P architecture. And now I am stuck to how will A discover address of B. If I know the subnet of B, I can brute force and locate B but since I don't have such information what do I do?
ARP is not intended to be routed outside the local network, where in IPv4, the "local network" typically corresponds to a subnet. You should not expect ARP traffic to transit routers from inside to outside or vise versa.
Similarly, UDP broadcasts generally do not propagate outside the local network, and it's a good thing that they don't, for reasons related to both security and traffic volume.
From what I read for multicasting to work, I need to create a multitask network beforehand. Is it really necessary?
Basically, yes. Your routers need to be configured to support multicasting (which may be their default). All participants need to agree on and join the same multicast group. There might not be a need for any new networking hardware, but multicast communication has its own protocols and network requirements; it is not merely a broadcast that can traverse network boundaries.
And for changing router setting, does it really have to be a "special" router?
If you mean changing router settings so that UDP broadcasts are routed between networks, you do indeed need a router that exposes this capability. But I urge you not to do this, as it will let broadcasts from all other sources, for all other reasons transit the router, too. At minimum, this will significantly increase the noisiness of all networks involved, but it could produce bona fide misbehavior of applications and services other than yours.
The Limited Broadcast (255.255.255.255, which is used by ARP requests as the destination address, and ARP only works for IPv4 on the local LAN) cannot cross a router, and a Network Broadcast (last network address, where the host is all ones) by default cannot cross a router (Directed Broadcast) because it is a security risk (see RFC 2644, Changing the Default for Directed Broadcasts in Routers).
Some routers can be configured to forward directed broadcasts, but this can be dangerous.
Multicast is a form of broadcast. Multicast routing is very different than unicast routing, and every router in a path must be configured for multicast routing. Also, hosts must subscribe to a multicast group before they will even listen for packets from a multicast group. Additionally, there are some multicast groups that all hosts listen for, but those are link-local multicasts that cannot be forwarded off the local LAN.
Adding to what other answers have provided:
ARP is not useful for a system in another subnet. Even if you were able to send an ARP request to a system in the other subnet, and receive its response somehow -- providing you with that system's MAC address -- you could not use it to send a packet to that system because Ethernet does not provide a routing mechanism, and so the system will never see any Ethernet packet you address to it.
If you are simply trying to identify which systems within another IP subnet are live, you can probably do this by other means. Take a look at the nmap command, for example. It supports a wide variety of IP communications methods that will be routed to the other subnet and can often detect what machines are present and which services are available on the machines found.
And you can of course duplicate what nmap does yourself. For example, if you want to find out which systems in subnet 192.168.10.0/24 are listening on TCP port 80, one way is to simply attempt to connect to port 80 on each system in that subnet. In general, there are four answers you may receive back:
Connection success (No error: the machine is present and there is a program listening to that port)
Connection refused (errno ECONNREFUSED: the machine is present but there
is no program listening to that port)
No route to host (EHOSTUNREACH: there is no machine answering to
that IP address)
No response (ETIMEDOUT: several reasons why this can happen; for example, the system could have firewall settings causing it to simply ignore the request)
(And there are other less likely possibilities as well.) Using other IP access methods (ICMP/ping, UDP packets) will have a different matrix of possible results.
As others have explained, multicast mechanisms would only be helpful for discovering a set of cooperating machines that are pre-configured to join a multicast group.
I've been reading lately about DNS cache-poisoning attacks. Essentially they are possible simply because an attacker can guess the DNS message transaction ID, since it is only a 16-bit integer. Even if the integer is random, it's still possible for a flurry of DNS packets to coincidentally match 1 of 2^16 packets in a short time window.
So a second security measure is port randomization. If the UDP source port is random, an attacker would have to guess both the source port and the transaction ID in a short time window, which is usually not feasible. But I read that older versions of DNS software such as BIND versions before 9 did NOT perform port randomization, and are therefore vulnerable.
This brings me to the question: don't most UNIX OS's like Linux and BSD automatically assign random ports when a SOCK_DGRAM is used without a prior call to bind? I thought that was the whole idea with ephemeral ports. Why does an application (like BIND) have to go out of it's way to perform port randomization?
My understanding is that, essentially, an OS like Linux will have a RANGE of ephemeral ports available for use with each process. A process can call bind() to bind a UDP socket to a specific port. But if a UDP socket is used (i.e. send is called) without first calling bind, the OS will lazily assign a random ephemeral port to the socket. So, why were older versions of BIND not performing port randomization automatically?
This brings me to the question: don't most UNIX OS's like Linux and BSD automatically assign random ports when a SOCK_DGRAM is used without a prior call to bind? I thought that was the whole idea with ephemeral ports.
The main idea of ephemeral ports is not to be random in a secure way, but just to pick some unused port fast. Different OS use different strategies, some do it a bit random, some use a stronger random generator and some assign the ports even in a sequential way.
This means not on all OS ephemeral ports are unpredictable enough for use with DNS.
For more details I would recommend to study RFC 6506 "Port Randomization Recommendations" and the overview about port selection strategies at https://www.cymru.com/jtk/misc/ephemeralports.html.
I'm writing a program in C in which the server listens on a well known port, waits for client to connect, and then creates a random port for the client to use and send this port number back to the client. My main difficulty is how to create a "random" port. Should I just be using srand and create a random 4 digit port is the usable range? Or is there a better way to do this? I know that if I use port 0 a port will be chosen for me but the problem here is the fact that I don't think i can "get/see" the actual value of the port so that I can send this port number back to the client.
Thanks...
Binding port 0 is the solution. It gives you an arbitrary port, not a random port, but this is what many applications do (e.g. FTP etc).
After binding, you can use getsockname to figure out which port you got.
What you do is bind() with port set to 0. The system will assign one. Then use getsockname() to discover what port the system assigned. Send that back to the client. That way there is no race condition and you follow any system rules for port assignment.
A random 4-digit port checked to make sure it's not in use is OK for that purpose..
Technically speaking, it sounds like you're trying to implement this for added security (some kind of primitive port knocking routine)? It might be worth mentioning that this approach is generally not considered too secure. It also imposes some artificial constraints on how many clients you can serve at a time and actually adds unnecessary load on the server. Why not just listen on the single well-known port for all clients?
I'm guessing TCP considering your description of listening and automatic port assignment by the OS. In this case, you don't need to worry about it. Once you accept the TCP connection, the OS on both sides takes care of all that you're trying to do and you're left with a working connection, ready for use. Unless you have a particular reason for doing any of this yourself, it's already done for you.
Currently, I'm working on TCP client/server implementation in C. In that, I found that I can give any random number as a port number for my PC. Is it correct procedure? Or is there any standard port number for my PC?
I don't know the standard, but I say it's not. At least, I don't like to do it like that.
You can check occupied ports by parsing the outputs of programs like netstat and avoid using those. You can also use the method that attempts connecting on one port, and upon failure, tries another port. Unless you're really really unlucky, you should get a valid port on second try.
You should use ports within the ranges of 49152–65535. Ports below 49152 are reserved/registered.
Basically, you can use any port (given sufficient access rights). But server and client have to agree on the port, and it should not be already used by another application.
Hence, many ports are already reserved for special applications. 80 is for HTTP, 22 is for SSH and so on. The file /etc/services gives more detailed information.
Port numbers 0-1023 are called Well Known Ports, numbers 1024-49151 are called Registered Ports (not all of them are, but you get the idea).
If your question is whether you can give any port number to have your server listening to,
then you are thinking wrong, TCP/IP port numbers below 1024 are special in that normal users are not allowed to run servers on them, you can use non-privileged ports(ports > 1024). just make sure that any other application is not already using that port (above 1024) using netstat
The Tcp server need to serve many clients, If one client one server port and one server thread to listen the port, I want to know weather it is faster ?
If one port is good, could someone explain the different between one port and multiple ports in this case, thanks!
The problem with using multiple ports to achieve this is that each of your clients will each have a specific port number. Depending on the number of clients there could be a tremendous amount of bookkeeping involved.
Typically, for a tcp server that is to serve multiple clients, you have a "main" thread which listens to a port and accepts connections on that port. That thread then passes the connected socket off to another thread for processing and goes back to listening.
For a wealth of Unix network programming knowledge check out "The Stevens Book"
Generally speaking* the server will allocate it's own outgoing sockets for each connected client (and you don't need to be aware of those numbers). Each client connection handle will hold it's port references.
When defining the servers connection port, you will allocate a socket for incoming clients to connect to. There is no performance benefit using multiple sockets, in fact allocating additional sockets will show a performance hit (although for each port it will be tiny.)
update...
By the way, assigning multiple incoming ports (particularly a large range) for clients to connect to is also insane. From the perspective of making the service usable and maintainable.