I am new to PCAP file format. Does the file have the routing information regarding the routing from the src ip to the destination ip?
I am to know if routing is going through a specific route and how often?
Does the file have the routing information regarding the routing from the src ip to the destination ip?
Not in general.
The file has packets taken directly from the network, so, for example, if you captured an IP packet on an Ethernet, it would have the Ethernet source and destination addresses, which are the Ethernet address of the machine that sent the packet on that network and the Ethernet address of the machine on that network to which it was sent, and the IP source and destination addresses, which are the IP address of the machine that originally sent the packet and the IP address of the machine to which the packet is ultimately being sent.
The Ethernet addresses give the source and destination of one particular routing hop; the other routing hop information is not, in general, available.
The only way in which you'd have some routing information would be if the IPv4 header had the "record route" option, in which case each host that routed the packet would add its IP address to the list of IP addresses in that option. However, packets only very rarely have that option (and you'd probably have to modify the program sending the packet in order for it to have that option!) and, if the packet does have that option, it will only show the hosts through which the packet has already been routed, not the hosts through which the packet will next be routed on the path to the destination host.
If you want to know the routing path from a given IP address to another IP address, you'd need to use the traceroute command on UN*X, or the tracert command on Windows, on the source host, and hope that it works (the packets it sends might not cause the appropriate ICMP Time Exceeded Message message to be send back; traceroute and tracert depend on it being sent).
Related
In my class, we learned that a TCP socket is uniquely identified by the 4-tuple consisting of source IP, destination IP, source port, and destination port.
Now suppose I have a web server running on port 80. It has 2 TCP sockets established to two clients that have different IP addresses but somehow both use the same source port, say 12345.
We also learned in class that the transport layer header adds only the source/destination ports whereas the network layer adds the source/destination IP addresses.
Now suppose the web server receives two packets, one from each client. As mentioned, the source port, destination port, destination IP addresses are the same in these packets, so the only difference is the source IP address.
However, if demultiplexing is done by the transport layer, how can the source IP address be used to move the packet to the right socket? After all, the source IP address is only part of the network header and, as far as I understand, that header is already stripped off before the packet is passed from the network layer up to the transport layer on the receiving side.
When a server want to create a socket, it will use a combination of its IP address and some well-known port, let us say 80. So, when a packet arrived, both the server IP and port 80 will be used to decide whether the packet goes to that socket or not.
The question is why do we need to check the IP address of the server, since the packet (aka datagram) passed the network layer check and was certainly destined for this server. In other words, the network layer will not pass the packet to transport layer if the destination IP is not the server IP, so why do we use the IP address in the socket?
And if a host (a client or a server) created multiple sockets (network processes) using both its IP and some port numbers, is there any case where the IP could be different in these sockets?
Thanks in advance!
Why do we need to check the IP address of the server, since the packet (aka datagram) passed the network layer?
The Data Link Layer uses Media Access Control (MAC) addresses to direct packets. When a packet arrives at your computer operating system (OS), it arrived either because the MAC address matched the hardware address or it was a broadcast (ff:ff:ff:ff:ff:ff).
Once the packet is received, your OS determines if it is destined for an IP address assigned to the computer. At this point, the OS has several options:
If the IP address matches an assigned IP, deliver to any waiting applications or reject the packet and handle any needed Internet Control Message Protocol (ICMP) required.
Should the IP not match an assigned, your OS checks if IP routing is enabled. Then either rejects the packet issuing any required reply or forwards the packet to the destination IP in the routing table by creating a new packet targeting the MAC address of the destination router.
If a host (a client or a server) created multiple sockets (network processes) using both its IP and some port numbers, is there any case where the IP could be different in these sockets?
If your OS assigns more than one IP address to an interface, all of those IP addresses would be available to be used. You can open sockets using any available IP (usually INADDR_ANY or similar). In a listening context, your port will be available to every IP address assigned. In a transmitting context, your IP will be set depending on the outbound interface.
how does a socket finds my private ip address as public ip are different than private and inside a public network there can be many private ip addresses with listening to a particular port
In order for a remote machine to send packets to your computer, the remote machine must know it's "public" (from the view of the remote machine) IP address.
Most routers these days have only a single IP address assigned to them from the upstream service and so do Network Address Translation (NAT) for those machines behind it.
Every IP packet outbound from your machine to an outside server has it's address changed to the public address of the router and the router keeps an internal record with the destination address & port along with the true source that sent it. Every inbound packet has the originating address & port checked against those records to find out what internal machine should receive it; the destination address is set appropriately and the packet forwarded.
Neither side can generally tell (or care) that NAT is happening.
Note, however, that you can't initiate a connection from the outside to an internal machine because there is no record indicating where those initial packets should be sent; additional static configuration would be necessary.
According to "Computer networking: a top-down approach", Kurose et al., a UDP socket is fully identified by destination IP and destination port.
Why do we need destination IP here? I thought UDP only need the destination port for the demultiplexing.
The machine may have multiple IPs, and different sockets may be bound to the same port on different IPs. It needs to use the destination IP to know which of these sockets the incoming datagram should be sent to.
In fact, it's quite common to use a different socket for each IP. When sending the reply, we want to ensure that the source IP matches the request's destination IP, so that the client can tell that the response came from the same server it sent to. By using different sockets for each IP, and sending the reply out the same socket that the request came in on, this consistency is maintained. Some socket implementations have an extension to allow setting the source IP at the time the reply is being sent, so they can use a single socket for all IPs, but this is not part of the standard sockets API.
I think that you are confusing UDP with Mulitcast.
Multicast is a broadcast protocol that doesn't need a destination IP address. It only needs a port number because it is delivered to all IP's on the given port.
UDP, by contrast, is only delivered to one IP. This is why it needs that destination IP address.
Say you have a router with external ip 42.1.98.9, with the port 10443 set to forward all incoming TCP/UDP packets to host 192.168.1.200. The routers internal network address is 192.168.1.100.
say there are two NICs connected to the router, with internal IP 192.168.1.200 and 192.168.1.300.
I've noticed that packets sent to socket 42.1.98.9:10443 gets redirected to 192.168.1.200, which is the expected behaviour.
However, say the computer 192.168.1.300 sends a packet to socket 192.168.100:10443. In other words a computer from inside the network is sending a packet to the router, in a port that should theoretically redirect incoming packets.
On that scenario, I'm not noticing the packets being redirected to the proper host -- 192.168.1.200.
Why is that? Does port forward on the router occur only for packets being sent to its external IP address?
Thanks
Yes, generally port forwarding is only from the external address to internal addresses. I'm guessing a commercial-grade router could be programmed to do what you want, but not any home router I've ever seen.
You should be able to use the router's external address from inside the network though (i.e., send packets from 192.168.1.300 to 42.1.98.9:10443 and it should redirect to 192.168.1.200:10443).