I'm trying to understand how routers behave to UDP and TCP packets.
I picked a website and used traceroute using UDP and TCP.
UDP output is as follows:
yilmazali@udemy:~$ traceroute -v -m 15 metu.edu.tr
traceroute to metu.edu.tr (144.122.145.153), 15 hops max, 52 byte packets
1 csp3.zte.com.cn (192.168.1.1) 60 bytes to 192.168.1.4 16.534 ms 1.281 ms 1.136 ms
2 host-212-57-0-245.reverse.superonline.net (212.57.0.245) 60 bytes to 192.168.1.4 9.552 ms 9.559 ms 10.065 ms
3 10.40.22.237 (10.40.22.237) 76 bytes to 192.168.1.4 6.070 ms 10.966 ms 6.093 ms
4 10.34.255.157 (10.34.255.157) 36 bytes to 192.168.1.4 7.869 ms 9.842 ms 6.538 ms
5 10.34.255.250 (10.34.255.250) 76 bytes to 192.168.1.4 7.474 ms 7.732 ms 11.364 ms
6 10.38.207.137 (10.38.207.137) 148 bytes to 192.168.1.4 8.746 ms 7.645 ms 5.906 ms
7 10.40.145.85 (10.40.145.85) 36 bytes to 192.168.1.4 7.223 ms 8.806 ms 8.685 ms
8 * * *
9 144.122.1.18 (144.122.1.18) 60 bytes to 192.168.1.4 20.426 ms 13.984 ms 15.184 ms
10 * * *
11 * * *
12 * * *
13 * * *
14 * * *
15 * * *
Using TCP traceroute, I could reach host destination in 12 hops:
yilmazali@udemy:~$ sudo tcptraceroute -p 80 metu.edu.tr
Selected device en0, address 192.168.1.4, port 80 for outgoing packets
Tracing the path to metu.edu.tr (144.122.145.153) on TCP port 80 (http), 30 hops max
1 192.168.1.1 1.215 ms 1.080 ms 1.316 ms
2 host-212-57-0-245.reverse.superonline.net (212.57.0.245) 4.183 ms 9.425 ms 10.032 ms
3 10.40.22.237 7.459 ms 7.782 ms 7.361 ms
4 10.34.255.157 6.455 ms 5.887 ms 14.849 ms
5 10.34.255.250 6.110 ms 10.768 ms 7.230 ms
6 10.38.207.137 7.604 ms 6.761 ms 9.247 ms
7 10.40.145.85 8.526 ms 8.942 ms 10.607 ms
8 * * *
9 144.122.1.18 15.320 ms 16.699 ms 14.010 ms
10 dng03.general.services.metu.edu.tr (144.122.145.153) [open] 17.520 ms 14.696 ms *
[Q1] I could not understand how router behaves in step [8] at TCP traceroute. I had a wild guess like that: The router received packet with TTL=1, and sees that it should return me the response "TTL expired". But it doesnt (Why doesnt it return me? Firewall rules?). In the next iteration, my computer sends same packet with TTL=9 and this time I get an "ttl expired" answer from 144.122.1.18. Does this mean that the router at Step[8] actually forwarded my packet, seeing that it was TTL=2 (and also decremented TTL while forwarding)? In 8th iteration, router dropped my packet and did not return response to me, but in 9th iteration, router forwarded my packet to next router. If my packet is defined as something droppable in 8th iteration, why does router forward it in 9th iteration?
I thought firewall configuration in routers does two things:
I'm unsure if these two things are done in practice.
[Q2] My second question is: In TCP traceroute we see that metu.edu.tr is reachable in 10 hops.
assuming that [B2] is false , i.e. considering that routers DO forward the packets with TTL>1, if metu.edu.tr was reachable in 10 hops, why my UDP packets in first traceroute session could not reach to host in 15 iteration (even with TTL=15). I expect routers to forward it to next router until I reach dng03.general.services.metu.edu.tr which hopefully returns me ICMP port unused error or sth like that.
Thanks a ton for your time!
If my packet is defined as something droppable in 8th iteration, why does router forward it in 9th iteration?
It is not the same packet. The packet dropped had a TTL of 8 and could thus not be forwarded. The packet not dropped had a TTL of 9.
... and also decremented TTL while forwarding
Yes, the router decrements the TTL when forwarding. That's the point of TTL in the first place: decrement TTL when forwarding and drop when TTL reaches zero.
Why doesnt it return me? Firewall rules?
Might be firewalls rules, router configuration, limits on ICMP messages per time ...
if metu.edu.tr was reachable in 10 hops, why my UDP packets in first traceroute session could not reach to host in 15 iteration (even with TTL=15
The output of traceroute you show does not mean that the host could not be reached in 10 hops. It means that the host at 10 hops did not respond to the packet, i.e. no ICMP TTL exceeded but not also anything else (like ICMP port unreachable). It might be that the server was actually reached at 10 hops but that it simply dropped your UDP packet without any further reaction. And this happened with all UDP probes reaching the server, i.e. no matter if original TTL 10, 11, 12, ... .
This is like knocking on a door and getting no response. It might be that somebody is not inside but it can also be that the knocking is simply ignored. Thus it cannot derived from "no response" that nobody is inside.