Setup:
The user has two applications - one sender one receiver - running on the same host/server. The user sets it up such that the sender sends messages to its own IP address not 127.0.0.1. Lets say its IP and port is x:y for simplicity. The user then sets up the receiver to receiver messages on x:y. Again this is on the same host/server.
Questions:
From my understanding this is not possible since the port will already be reserved. Therefore I cannot use the same port to try and send packets out to myself. Can I have a port used for a sender and receiver on the same node?
Is this resolved if I use SO_REUSEADDR or does this only resolve the IP conflict and not the port reuse?
If the program is not setup with IP_MULTICAST_LOOP the host will not multicast the message to itself, correct?
With IP_MULITCAST_LOOP set, if I only wanted to send the message to myself can I use 127.0.0.1 or must I use another address? Additionally, how do the ports get resolved?
If I am not seeing messages on the same node, would the first best guess be that IP_MULITCAST_LOOP is not set?
Let's take it step by step:
The sending port does not matter at all. So you can choose an arbitrary port for the sender, and use the specific port number for your service just for the receiver.
No, SO_REUSEADDR/PORT does not solve this problem. Even if you manage to achieve it: Do not start multiple listeners on the same port. This will cause strange effects. The main purpose of SO_REUSEADDR/PORT is to allow servers to create a TCP (not UDP) socket when the previous server process just died, without waiting for a timeout of the TCP state machine of the stale socket.
Corrects, assuming you mean multicast rather than broadcast,
Yes and no: If you only want to send messages to yourself you can send the packets to 127.0.0.1, and then you message will be a normal unicast packet and no longer a multicast packet, and IP_MULTICAST_LOOP does not matter at all. Multicast packets are normal UDP packets which have a destination address in the multicast address range (i.e. 224.0.0.0-239.255.255.255). The receiving socket cannot easily tell whether a packet was sent via unicast or multicast.
IP routing on the same host between interfaces is far from trivial. There are a lot of mechanisms and routing rules involved which are not shown in the normal routing table, which is just for outgoing traffic. It also depends on by which means you try to observe the messages. There is not a single point where you can see all messages going through a node (unfortunately). This is usually all attached to interfaces, and there also to an ingress and egress side, and the latter is usually not documented and not configurable. Monitoring local traffic can be tricky and may require virtual network interfaces. Really messy.
In summary: You are trying to send messages from one process to another process on the same host. Use unicast UDP for this and you are done. No multicast involved.
Related
My question is that how the destination port address in UDP is chosen/given?
I mean what matters to set a destination port in a UDP packet?
Because when we send a packet, just the destination address(ip) is important and we want to send data to our destination.
It has nothing to do with the port!
Do we assign a random port?
Typically, whatever documentation tells you what to put in the UDP datagram you're sending should also tell you what port to send it to.
For example, if you're trying to talk to an NTP server, RFC5905 tells you what to put in the UDP datagrams you send. It also tells you, on page 16, to send it to port 123.
If you're writing a DNS resolver, RFC1035 is one place you might look for the information needed to know what to put in your UDP datagrams. It also tells you, in section 4.2, to send the datagrams to port 53.
So however you're figuring out what to put in the UDP datagrams you're going to send, that's typically what tells you either what port to send them to or, in some cases, how to determine what port to send them to.
For example, a media streaming protocol might start with the information about the stream being delivered by a web server. In that case, the information delivered by the web server to the client might include the destination port to send datagrams to.
Generally, there's either a well-known port that at least one side listens for datagrams on or there's some external method using a different protocol that tells whichever end sends the first datagram what port to send it to. The other end then just replies, sending its response datagrams to whatever port that first datagram was sent from.
Generally, the sending port is chose randomly for the ephemeral ports available.
The destination port is the port to which the destination application is listening. To facilitate this, IANA maintains the Service Name and Transport Protocol Port Number Registry for standard applications and protocols.
If you create your own application or protocol, there is a range for you to use, but you should always check the registry to make sure you will not step on some other application or protocol.
When you design your listening application or protocol, you choose a port on which it listens, and the sending application will need to send to that port.
I want to send packets to a client on a lan, say, the public address is:
15.15.15.15 and behind this, there are 3 machines:
192.168.0.10
192.168.0.11
192.168.0.12
How would format my packet so that, if I were to send it to this IP address, it'll be received, well, atleast redirected to say, 192.168.0.10.
I know that there's 192.168.0.10, since it's one of my machines and I was wondering if I can build a notification system for something using no sockets whatsoever, but just a client listening for these. (Using scapy to parse packets)
So, for example: I send a packet from outside saying "Alert!" to 15.15.15.15 and 192.168.0.12 picks it up. Wrote this just to provide some insight!
Made this image to portray the process:
Cheers.
You can also implement a UDP hole punching, but you need a public server with real IP address to do that.
Running on a Linux system, getting UDP packets from another computer address to let's say 192.168.0.2 from another address let's say 192.168.166.66, I can see the UDP packets coming in with tcpdump. However, if I use netcat I don't actually receive the packets.
If I create an interface on 192.168.166.XXX network, then netcat is able to receive the packets no problem.
What basic networking concept am I missing? Why do I need to have an interface on the network of the sending IP when I can see with tcpdump that they are being delivered correctly?
tcpdump per default puts the interface into promiscious mode, which lets you see all the packets arriving at your network interface. But, your operating system only processes packets destined for the local system, e.g. either having the local or a broadcast address as destination.
The final solution to this problem was to disable Reverse Path Forwarding (RPF) on the interface. There are security implications here, but after careful review this was the correct path forward in this particular case.
RPF was turned off by modifying /etc/sysctl.conf:
net.ipv4.conf.eth0.rp_filter=0
Some more information on RPF:
Wikipedia - Reverse path forwarding
Linux kernel rp_filter settings
So right now I'm using only TCP for my clients - they connect to the server, open socket and freely getting packets.
But what if I will decide to use also UDP in my game? Will they gonna have to open ports? For example, if they are using a regular WiFi, can I send UDP to the client without having opening ports problem?
Thanks.
TCP and UDP are just two examples of transport layer implementations. Both of them are using term 'port' to determine which app should receive incoming packet, but they could be routed/filtered differently by routers/switches/firewalls/etc.
So the answer is no. You will have similar problems with opening ports. Just except 'TCP port xxx should be opened' you have to demand 'UDP port xxx should be opened'.
In most home networks firewall rules allow outgoing packets (requests) to any remote port (on your server for example, where this port should be opened). And when such a packet goes through a router - it creates temporary rule to allow answers come back to the local port from which request packet.
So, normal scenario is like that:
Packet originated from home computer with IP 5.5.5.5. Lets say it has source UDP port 55555, source IP address 5.5.5.5 and destination port 8888.
Packet reaches home router. As it is going from inside - router allows it to pass through and creates rule say for 2 minutes to allow packets targeted to 5.5.5.5 to UDP port 55555.
Packet reaches corporate router before your server. It has rule to pass packets for port 8888 so packet is allowed to go.
Your server receives the packet and processes it. In response it creates packet for IP 5.5.5.5 and UDP port 55555.
Corporate router allows response to go.
Home router allows response to go according to temporary rule.
Your computer receives the response.
Corporate computers and routers often more restrictive to ensure security, so second point could restrict packet if your user (IP 5.5.5.5) is in corporate network.
It is very simplified as in reality there's almost always things like NAT and rules are more complex... But in general it gives the idea how it works internally.
From what I understand, each HTTP request uses its own TCP connection (please correct me if i'm wrong). So, let's say that there are two current connections to the same server. For example, client side javascript code triggering a couple of AJAX POST requests using the XMLHttpRequest object, one right after the other, before getting the response to the first one. So we're talking about two connections to the same server, each waiting for a response in order to route it to each separate callback function.
Now here's the thing that I don't understand: The TCP packet includes source and destination ip and port, but won't both of these connections have the same src and dest ip addresses, and port 80? How can the packets be differentiated and routed to appropriately? Does it have anything to do with the packet sequence number which is different for each connection?
When your browser creates a new connection to the HTTP server, it uses a different source port.
For example, say your browser creates two connections to a server and that your IP address is 60.12.34.56. The first connection might originate from source port 60123 and the second from 60127. This is embedded in the TCP header of each packet sent to the server. When the server replies to each connection, it uses the appropriate port (e.g. 60123 or 60127) so that the packet makes it back to the right spot.
One of the best ways to learn about this is to download Wireshark and just observe traffic on your own network. It will show you this and much more.
Additionally, this gives insight into how Network Address Translation (NAT) works on a router. You can have many computers share the same IP address and the router will rewrite the request to use a different port so that two computers can simultaneously connect to places like AOL Instant Messenger.
They're differentiated by the source port.
The main reason for each HTTP request to not generate a separate TCP connection is called keepalives, incidentally.
A socket, in packet network communications, is considered to be the combination of 4 elements: server IP, server port, client IP, client port. The second one is usually fixed in a protocol, e.g. http usually listen in port 80, but the client port is a random number usually in the range 1024-65535. This is because the operating system could use those ports for known server protocols (e.g. 21 for FTP, 22 for SSH, etc.). The same network device can not use the same client port to open two different connections even to different servers and if two different clients use the same port, the server can tell them apart by their IP addresses. If a port is being used in a system either to listen for connection or to establish a connection, it can not be used for anything else. That's how the operating system can dispatch packets to the correct process once received by the network card.