In traceroute, we know when destination (host) receives a packet with TTL=1, the host throws an error and does not delay.
So how can traceroute calculate distance (delay) between source and destination?
Traceroute sends probe packets towards the destination with increasing TTL. The node that the packets times out on is expected to return an ICMP Time exceeded message, which is then reported as hop.
The delay is simply the time between sending the probe and receiving the error message.
The last hop is either the destination's rejection (for UDP probes) or its echo reply (for ICMP echo probes).
For completeness: a packet with TTL=1 isn't forwarded (by a gateway) and more. It can still be replied to by the destination.
Related
I'm really confused on how traceroute works, I read online that Traceroute uses ICMP messages and TTL fields in the IP header for its operation and transmits packets with small TTL values.
I did
test 1: traceroute <"domain">
traceroute was never able to map the final destination
test 2: traceroute -I -IP icmp <"domain">
the final destination was mapped but the confusion in all this is WHY ?, I thought Traceroute already uses ICMP.
Different tracroute implementations use different packets. Typically, either UDP or ICMP, although TCP traceroute exists as well.
You were probably using some UDP implementation.
Traceroute works by taking advantage of a feature called time-to-live (TTL), which is the number of hops a packet can take before it stops being retransmitted. The TTL is decremented by 1 for each hop the packet traverses. When the TTL reaches zero, the router on which it reached zero will send back an ICMP Time Exceeded packet to the source, rather than retransmitting the packet. The source (i.e. you) will then receive this packet from the router at which the original packet's TTL reached zero, and thus you'll know the IP address at which the packet failed. Traceroute works by sending out packets towards the destination with successively larger TTLs. This way, you'll get ICMP Time Exceeded packets for each hop on the path between you and the destination, because you'll have a packet reaching a TTL of 0 at each hop.
Now notice that nowhere here do we mention the protocol you're using to send your packets. TTL is in the IP header, which encapsulates the packet for the protocol you're using. Thus, you can use whatever protocol you want when tracerouting.
As for why traceroute hops resolve for some protocols and don't for others, its likely firewalls as well as policies on the routers you're traversing. Some routers either de-prioritize responding to ICMP, or have ICMP disabled. There's all sorts of reasons why some protocols happen to work better than others in a given case.
Exam question (with no additional info):
When an bunch of IP datagram fragments are being sent over the network and only one of them does not get to it's destination, what will happen then?
I'm not sure if ICMP is involved here or not. Does ICMP send an error report reporting to the source that it needs to resend that same fragment (only this one fragment)?
The problem is here that I don't know if the IP fragments use UDP or TCP therefore I don't know the answer to the question.
(I've posted on the networkengineering.stackexchange but my question was rejected)
Points to cover:
After a timer triggered by the receipt of the first fragment has expired, the reassembling host will discard all the of fragments.
The reassembling host may generate an ICMP Time Exceeded (Fragment reassembly time exceeded).
The first fragment will need to have been received for the ICMP to include the first 8 bytes of the triggering payload. IPv6 will not generate the ICMP Time Exceeded unless the first fragment was received.
With IPv6 if the reassembled datagram would be larger than 1500 bytes then it may be silently discarded.
If a higher level protocol with reliable delivery was used (e.g. TCP), then the originating host should retransmit datagrams for which no acknowledgement has been received.
I'm filtering packets with libpcap with a filter like "tcp src localhost". It filters all the packets whose source is localhost (my host).
When localhost doesn't receive a TCP confirmation of an already sendt packet, localhost will forward the packet.
Not all the packets filtered by libpcap will arrive to its destination, and I need to identify when a packet is a "forwarded packet". Is there any way with libpcap to identify a forwarded packet?
By my understanding, you're looking for TCP retransmissions. These can be found by display fitters in wireshark after capturing. These two should help you:
Retransmitted packets can be found through the display filter tcp.analysis.retransmission (more such filters).
When the receiver gets an out-of-order packet (usually indicates lost packet), it sends a ACK for the missing seq number. This is a duplicate ACK and these can be found by using tcp.analysis.duplicate_ack (details).
I use raw socket to create TCP packets, with focus on the sequence number and TCP flags(SYN, ACK)
I used one machine S to send a tcp ACK packet (flag ACK is set to 1) and another machine R to receive it these two machines are in different subnets, all in my school
meanwhile, I used tcpdump to capture the packets.
Strange things happens! On machine S, the captured packet is as expected, it is an ACK packet however, on the receiving machine R, the packet becomes a SYN packet, and the sequence number is changed, the seq no is 1 smaller the expected and the ack_seq become 0!
what are potential problems?
my guess is that the router/firewall modified the ACK packet to a SYN packet because it never sees a SYN SYN/ACK exchange ahead of the ACK?
is it possible or not?
the two captured packets are:
https://docs.google.com/file/d/0B09y_TWqTtwlVnpuUlNwUmM1YUE/edit?usp=sharing
https://docs.google.com/file/d/0B09y_TWqTtwlTXhjUms4ZnlkMVE/edit?usp=sharing
The biggest problem you will encounter will be that the receiving TCP stack in each case will receive the packet and possibly reply to it. What you are attempting is really not possible.
I am sending HTTP requests from IP_ADDR1 to IP_ADDR2. I observed that HTTP requests are not reaching to application level. When I take wireshark logs I noticed some issue at TCP level. What are these issue? when this occurs ? How to get rid of this? Attaching the Wireshark snapshot here.
'TCP port number reused' means that it saw a successful connection handshake, then the client sent another SYN packet with the same port numbers. If the client hadn't already acknowledged the SYN-ACK, this would have been reported as a retransmission. But since it did acknowlege the SYN-ACK, it shouldn't need to retransmit the SYN. This could mean that something on your network is duplicating packets.
'TCP out-of-order' means that the packets aren't being received in the order that their sequence numbers indicate. It might be a side effect of the duplicate packet that's causing the reused port number error -- that may be resetting the sequence numbers back to the beginning of the connection. Because otherwise it looks like the packet is in order; an HTTP command should be the next thing after the connection handshake.