search

gregtampa / coreemu

Automatically exported from code.google.com/p/coreemu
BSD 2-Clause "Simplified" License
0 stars 0 forks source link

Traceroute (udp) doesn't work properly #234

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
What steps will reproduce the problem?

1. Make a network with two end-devices and two routers, connect them all like 
device--router--router--device (n1-n2-n3-n4)
2. Run the simulation, wait for all routes to be established.
3. Open a shell on n1, do traceroute <ip of n4>

What is the expected output?

# The same as when running icmp traceroute (traceroute -I):
root@n1:/tmp/pycore.59638/n1.conf# traceroute -I 10.0.2.10
traceroute to 10.0.2.10 (10.0.2.10), 30 hops max, 60 byte packets
 1  10.0.0.1 (10.0.0.1)  0.116 ms  0.031 ms  0.024 ms
 2  10.0.1.2 (10.0.1.2)  0.085 ms  0.040 ms  0.036 ms
 3  10.0.2.10 (10.0.2.10)  0.078 ms  0.049 ms  0.047 ms

What do you see instead?

root@n1:/tmp/pycore.59638/n1.conf# traceroute 10.0.2.10
traceroute to 10.0.2.10 (10.0.2.10), 30 hops max, 60 byte packets
 1  10.0.0.1 (10.0.0.1)  0.201 ms  0.030 ms  0.032 ms
 2  10.0.1.2 (10.0.1.2)  0.256 ms  0.047 ms  0.042 ms
 3  * * *
 4  * * *
 5  * * *
 6  * * *
 7  * * *
 8  * 10.0.2.10 (10.0.2.10)  0.091 ms  0.030 ms

What version of the product are you using? On what operating system?

I verified this bug with the core 4.6 vmware image from here:
http://downloads.pf.itd.nrl.navy.mil/core/vmware-image/vcore-4.6.zip

Please provide any additional information below.

I did some debugging, it seems that icmp port unreachable packets are not sent 
for the first ~12 udp packets arriving at n4. Here is some data I collected via 
tcpdump on n4, while running traceroute from n1:

root@n4:/tmp/pycore.59638/n4.conf# tcpdump -i eth0 "icmp or udp"
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
01:43:38.896146 IP 10.0.0.20.44227 > 10.0.2.10.33440: UDP, length 32
01:43:38.900326 IP 10.0.0.20.43642 > 10.0.2.10.33441: UDP, length 32
01:43:38.900386 IP 10.0.0.20.35349 > 10.0.2.10.33442: UDP, length 32
01:43:38.900441 IP 10.0.0.20.60219 > 10.0.2.10.33443: UDP, length 32
01:43:38.900488 IP 10.0.0.20.33668 > 10.0.2.10.33444: UDP, length 32
01:43:38.900726 IP 10.0.0.20.40518 > 10.0.2.10.33445: UDP, length 32
01:43:38.900779 IP 10.0.0.20.47990 > 10.0.2.10.33446: UDP, length 32
01:43:38.900830 IP 10.0.0.20.34060 > 10.0.2.10.33447: UDP, length 32
01:43:38.900881 IP 10.0.0.20.33039 > 10.0.2.10.33448: UDP, length 32
01:43:38.901018 IP 10.0.0.20.49209 > 10.0.2.10.33449: UDP, length 32
01:43:38.902539 IP 10.0.0.20.45197 > 10.0.2.10.33450: UDP, length 32
01:43:38.902597 IP 10.0.0.20.46281 > 10.0.2.10.33451: UDP, length 32
01:43:38.902652 IP 10.0.0.20.49496 > 10.0.2.10.33452: UDP, length 32
01:43:38.902703 IP 10.0.0.20.52932 > 10.0.2.10.33453: UDP, length 32
01:43:38.902750 IP 10.0.0.20.46181 > 10.0.2.10.33454: UDP, length 32
01:43:38.902797 IP 10.0.0.20.43875 > 10.0.2.10.33455: UDP, length 32
01:43:43.908418 IP 10.0.0.20.47524 > 10.0.2.10.33456: UDP, length 32
01:43:43.908453 IP 10.0.2.10 > 10.0.0.20: ICMP 10.0.2.10 udp port 33456 
unreachable, length 68
01:43:43.908493 IP 10.0.0.20.55719 > 10.0.2.10.33457: UDP, length 32
01:43:43.908502 IP 10.0.2.10 > 10.0.0.20: ICMP 10.0.2.10 udp port 33457 
unreachable, length 68
01:43:43.908535 IP 10.0.0.20.48513 > 10.0.2.10.33458: UDP, length 32
01:43:43.908544 IP 10.0.2.10 > 10.0.0.20: ICMP 10.0.2.10 udp port 33458 
unreachable, length 68
01:43:43.908576 IP 10.0.0.20.53493 > 10.0.2.10.33459: UDP, length 32
01:43:43.908584 IP 10.0.2.10 > 10.0.0.20: ICMP 10.0.2.10 udp port 33459 
unreachable, length 68
01:43:43.908617 IP 10.0.0.20.35224 > 10.0.2.10.33460: UDP, length 32
01:43:43.908625 IP 10.0.2.10 > 10.0.0.20: ICMP 10.0.2.10 udp port 33460 
unreachable, length 68
01:43:43.908657 IP 10.0.0.20.35907 > 10.0.2.10.33461: UDP, length 32
01:43:43.908683 IP 10.0.0.20.40795 > 10.0.2.10.33462: UDP, length 32
01:43:43.908708 IP 10.0.0.20.34325 > 10.0.2.10.33463: UDP, length 32
01:43:43.908736 IP 10.0.0.20.53139 > 10.0.2.10.33464: UDP, length 32
01:43:43.908762 IP 10.0.0.20.57508 > 10.0.2.10.33465: UDP, length 32
01:43:43.908789 IP 10.0.0.20.51539 > 10.0.2.10.33466: UDP, length 32
01:43:43.908809 IP 10.0.0.20.39329 > 10.0.2.10.33467: UDP, length 32
01:43:43.908830 IP 10.0.0.20.59093 > 10.0.2.10.33468: UDP, length 32
01:43:43.908850 IP 10.0.0.20.49132 > 10.0.2.10.33469: UDP, length 32
01:43:43.908870 IP 10.0.0.20.35219 > 10.0.2.10.33470: UDP, length 32
01:43:43.908891 IP 10.0.0.20.33306 > 10.0.2.10.33471: UDP, length 32

37 packets captured
37 packets received by filter
0 packets dropped by kernel

Great software nonetheless, we've been using core in our routing labs for a 
number of years now and the students love it! Ah yes, this problem didn't 
appear before, with core 4.2.

Kind Regards,
Martin

Original issue reported on code.google.com by dban...@gmail.com on 4 Dec 2013 at 10:11

GoogleCodeExporter commented 9 years ago 
Hi, I'm going to mark this as WontFix, because it appears to be a Linux/Ubuntu 
issue and not something that CORE has done.
See e.g.:
http://www.binarytides.com/traceroute-command-not-working-on-ubuntu/

To get traceroute working in CORE, you can change the following kernel setting. 
If you do this often, you may consider adding this to the e.g. IPForward 
service:

1. click the Run Tool with a running session
2. in the "Command line" text box enter:
   sysctl -w net.ipv4.icmp_ratelimit=0
3. make sure all nodes are selected (press "all" button if needed)
4. click "Run"

This turns of ICMP rate limiting for all nodes. Now traceroute using UDP 
(traceroute's default behavior) should work.

Original comment by ahrenh...@gmail.com on 18 Dec 2013 at 10:20