View previous topic :: View next topic |
Author |
Message |
mobiledude n00b
Joined: 03 Sep 2003 Posts: 9 Location: Switzerland
|
Posted: Mon Mar 08, 2004 1:42 pm Post subject: traceroute and UDP wierdness |
|
|
This question is not really gentoo related, but I thought someone might have some insight...
I have found some wierdness with how traceroute works on linux boxes with UDP datagrams. Here's what I do:
Code: | traceroute -q 10 -n my-linux-box-IP |
produces the following:
Code: | traceroute to 192.168.0.103 (192.168.0.103), 30 hops max, 40 byte packets
1 192.168.0.103 0.438 ms 0.262 ms 0.251 ms 0.253 ms 2.262 ms 0.293 ms * 0.306 ms 0.252 ms 0.252 ms |
The result is that there are *always* some packets lost by the linux box. On the first run, it is usually the 7th packet. On subsiquent runs, it's others, especially if you run serveral traceroutes in a row. This is true on 2.4 and 2.6 kernels. Oddly (to me) this does not happen when using ICMP packets (adding the -I option to traceroute).
I'm not at all a network guy, but it seems to me to be that there is some (UDP?) buffer that gets filled up and once that happens the following packets are dropped. I have run a tcpdump on the end machine and can see that the packets arrive at the machine, but the 7th packet is not responded to.
There is probably some simple config that needs to be tweeked, but i haven't been able to find it. If anyone has some suggestions or could explain why this happens, i would be more than happye to listen.
thanks in advance,
Nick |
|
Back to top |
|
|
adaptr Watchman
Joined: 06 Oct 2002 Posts: 6730 Location: Rotterdam, Netherlands
|
Posted: Mon Mar 08, 2004 2:07 pm Post subject: |
|
|
I don't see where any packets are being lost - could you try formatting the output properly ?
The most likely reason you don't get an answer is that the hop in question does not send ICMP messages at all. _________________ >>> emerge (3 of 7) mcse/70-293 to /
Essential tools: gentoolkit eix profuse screen |
|
Back to top |
|
|
mobiledude n00b
Joined: 03 Sep 2003 Posts: 9 Location: Switzerland
|
Posted: Mon Mar 08, 2004 2:44 pm Post subject: traceroute and UDP wierdness |
|
|
Code: | traceroute -q 10 -n my-linux-ip |
produces:
Code: |
traceroute to 192.168.0.103 (192.168.0.103), 30 hops max, 40 byte packets
1 192.168.0.103 0.438 ms 0.262 ms 0.251 ms 0.253 ms 2.262 ms 0.293 ms * 0.306 ms 0.252 ms 0.252 ms
|
The "*" indicates that there was no response to that particular probe.
The machine accepts both UDP datagrams and ICMP packets (no firewall). However, certain traceroute probes (the 7th in the above example) are lost when using UDP datagrams.
Can anyone explain why? |
|
Back to top |
|
|
adaptr Watchman
Joined: 06 Oct 2002 Posts: 6730 Location: Rotterdam, Netherlands
|
Posted: Mon Mar 08, 2004 2:59 pm Post subject: |
|
|
Erm.. again, why is the output all on one line ?
I don't recall ever seeing a traceroute result that's not split into one line per hop - it's hard to say what the numbers refer to in this case. _________________ >>> emerge (3 of 7) mcse/70-293 to /
Essential tools: gentoolkit eix profuse screen |
|
Back to top |
|
|
mobiledude n00b
Joined: 03 Sep 2003 Posts: 9 Location: Switzerland
|
Posted: Mon Mar 08, 2004 3:10 pm Post subject: |
|
|
There is only 1 hop.
I am on a local network (192.168.0.10) and so is the other machine (192.168.0.103). Therefore there is only 1 hop (directly to the machine) and 1 line of output. |
|
Back to top |
|
|
adaptr Watchman
Joined: 06 Oct 2002 Posts: 6730 Location: Rotterdam, Netherlands
|
Posted: Mon Mar 08, 2004 4:11 pm Post subject: |
|
|
Have you raised the maximum response time per hop ?
Default is 5 seconds - the dot does not mean there was no response, only that there was no response within 5 seconds.
Other than that, maybe there is an ICMP rate limiter on one of these boxes ? _________________ >>> emerge (3 of 7) mcse/70-293 to /
Essential tools: gentoolkit eix profuse screen |
|
Back to top |
|
|
mobiledude n00b
Joined: 03 Sep 2003 Posts: 9 Location: Switzerland
|
Posted: Mon Mar 08, 2004 4:31 pm Post subject: |
|
|
yes, i've tried it with up to 90 seconds (-w 90) response wait time with the same results.
and there is no icmp rate limiter. it is a base install. no firewall, iptables or protection of any kind between my machine and it.
I've tried this with serveral different linux boxes (gentoo, mandrake) and different kernels (2.4.x and 2.6.x) with the same results. I find it kind of odd that this is the "default" setting for linux, but it doesn't normally seem to cause any problems. It's only visible if you do more than the default number of probes. |
|
Back to top |
|
|
|