Bug#457638: confused by router that always responds as the destination host

2008-01-02 Thread Robert Woodcock
On Wed, Jan 02, 2008 at 04:01:18PM +0100, Rogier Wolff wrote:
> How traceroute decides that it reaches the destination I don't
> remember. Traceroute however takes ages: It sends out one packet, 
> waits for the result or times out, and then tries the next hop. 
> (after trying the same hop 3 times). 

Dunno about all versions of traceroute, but at least a couple of them send
out packets to the first hop to a high UDP port number, then the next hop to
that port number + 1, then the third hop to port number + 2, etc.

ICMP doesn't have port numbers, but you can tuck freeform data into the
echo request packet, which in theory makes it back in the reply. For most
routers. I think.
-- 
Robert Woodcock - [EMAIL PROTECTED]
"We would like to return to work with our writers. If we cannot, we would
like to express our ambivalence, but without our writers we are unable to
express something as nuanced as ambivalence."
-- Jon Stewart and Stephen Colbert



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]



Bug#457638: confused by router that always responds as the destination host

2008-01-02 Thread Rogier Wolff

On Mon, Dec 24, 2007 at 03:46:02PM -0500, Joey Hess wrote:
> Robert Woodcock wrote:
> > On Mon, Dec 24, 2007 at 10:07:47AM -0500, Joey Hess wrote:
> > > ICMP (-I) works, TCP SYN (-T) doesn't.

First, 

This router is completely broken. It foges packets from the
destination. As everybody else does it differently I'm pretty sure you
can find an RFC that tells you this is wrong. 

We can't program against all possible router faults. 


How traceroute decides that it reaches the destination I don't
remember. Traceroute however takes ages: It sends out one packet, 
waits for the result or times out, and then tries the next hop. 
(after trying the same hop 3 times). 

Mtr tries to do things a bit more parallel. This means that it sends
out request for multiple hops at once. It determins it's reached the
destination when at a certain hop, it gets back a reply from the
destination. This is exactly what you've seen. 

In practise, we COULD probably detect this situation: mtr sends out
requests for 5 hops further than it knows it is reasonable. So the
first round, it sends out a request for hops 1 through 5. If it then
gets a reply from hop 4, it will in the next round probe for 1 through
9. On the other hand, it concludes it reached the destination on the
reply to the first probe. This probably happens before the probe for
hop 2 goes out (at 200ms). 


Although you might want different results, mtr is behaving "as
designed", and the fact that you get odd results is the fault of
your odd network, and not mtr's. 



Roger.

-- 
** [EMAIL PROTECTED] ** http://www.BitWizard.nl/ ** +31-15-2600998 **
**Delftechpark 26 2628 XH  Delft, The Netherlands. KVK: 27239233**
*-- BitWizard writes Linux device drivers for any device you may have! --*
Q: It doesn't work. A: Look buddy, doesn't work is an ambiguous statement. 
Does it sit on the couch all day? Is it unemployed? Please be specific! 
Define 'it' and what it isn't doing. - Adapted from lxrbot FAQ



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]



Bug#457638: confused by router that always responds as the destination host

2007-12-24 Thread Joey Hess
Robert Woodcock wrote:
> On Mon, Dec 24, 2007 at 10:07:47AM -0500, Joey Hess wrote:
> > ICMP (-I) works, TCP SYN (-T) doesn't.
> > 
> > (That's probably the last time I'll be able to use this network.)
> 
> Well shoot. If it's not too late to run 'tcpdump -n -s 1500 -w dumpfile'
> while you do the tests

Sorry, too late. :-)

-- 
see shy jo


signature.asc
Description: Digital signature


Bug#457638: confused by router that always responds as the destination host

2007-12-24 Thread Robert Woodcock
On Mon, Dec 24, 2007 at 10:07:47AM -0500, Joey Hess wrote:
> ICMP (-I) works, TCP SYN (-T) doesn't.
> 
> (That's probably the last time I'll be able to use this network.)

Well shoot. If it's not too late to run 'tcpdump -n -s 1500 -w dumpfile'
while you do the tests, then do those (one for mtr and one for traceroute
-I) and email them to me - otherwise, we'll probably have to wait for
someone else to say "hey this happens to me too!"

-- 
Robert Woodcock - [EMAIL PROTECTED]
"We've worked with our purchasing team to bring in many companies to compete
on our main cabin tidbit item (pretzels). To date, no one has been able to
match our current cost, about 3 cents per package."
-- US Airways management



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]



Bug#457638: confused by router that always responds as the destination host

2007-12-24 Thread Joey Hess
Robert Woodcock wrote:
> On Sun, Dec 23, 2007 at 09:36:32PM -0500, Joey Hess wrote:
> > I think mtr must optimise away the rest, which seems like a sort of bug in
> > this situation.
> 
> It's important to note that mtr, by design, sends out ICMP packets, and
> traceroute, by default, sends out UDP packets.
> 
> I suspect if you use the traceroute packages' traceroute command with the
> -I switch on a host behind such a router, you'll get identical results.

ICMP (-I) works, TCP SYN (-T) doesn't.

(That's probably the last time I'll be able to use this network.)

-- 
see shy jo


signature.asc
Description: Digital signature


Bug#457638: confused by router that always responds as the destination host

2007-12-23 Thread Robert Woodcock
On Sun, Dec 23, 2007 at 09:36:32PM -0500, Joey Hess wrote:
> I think mtr must optimise away the rest, which seems like a sort of bug in
> this situation.

It's important to note that mtr, by design, sends out ICMP packets, and
traceroute, by default, sends out UDP packets.

I suspect if you use the traceroute packages' traceroute command with the
-I switch on a host behind such a router, you'll get identical results.

If packets sent out with a TTL of, say, 30, come back with a TTL exceeded
message from the same host as packets with a TTL of 1, there is no software
method of determining the existence of the other hops. So I think this is a
case of garbage in, garbage out.

Let me know what you get.
-- 
Robert Woodcock - [EMAIL PROTECTED]
"We would like to return to work with our writers. If we cannot, we would
like to express our ambivalence, but without our writers we are unable to
express something as nuanced as ambivalence."
-- Jon Stewart and Stephen Colbert



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]



Bug#457638: confused by router that always responds as the destination host

2007-12-23 Thread Joey Hess
Package: mtr-tiny
Version: 0.72-2
Severity: normal

At the moment, I'm on a network where the router seems to always respond
to traceroutes as if it's the destination host:

traceroute to kitenet.net (80.68.85.49), 30 hops max, 40 byte packets
 1  wren.kitenet.net (80.68.85.49)  3.672 ms  3.915 ms  4.176 ms
 2  69-77-144-1.skybest.com (69.77.144.1)  27.488 ms  31.056 ms  32.551 ms
 3  host73.embarqnow.net (207.14.228.73)  34.936 ms  37.630 ms  39.313 ms
 4  165.166.133.57 (165.166.133.57)  54.685 ms  56.792 ms  61.700 ms
 5  gi4-3.ccr01.clt01.atlas.cogentco.com (38.104.168.9)  62.331 ms  64.015 ms  
66.463 ms
 6  te2-2.ccr02.dca01.atlas.cogentco.com (154.54.7.141)  162.628 ms  161.886 ms 
 163.362 ms
 7  te3-3.ccr04.jfk02.atlas.cogentco.com (154.54.6.14)  165.515 ms  42.146 ms  
118.178 ms
 8  gi13-0-0.core02.jfk02.atlas.cogentco.com (154.54.5.233)  101.473 ms  
101.673 ms  101.843 ms
 9  po2-0.core01.lon01.atlas.cogentco.com (66.28.4.190)  127.005 ms  130.158 ms 
 131.162 ms
10  te7-1.mpd01.lon01.atlas.cogentco.com (130.117.1.78)  134.613 ms  138.251 ms 
 141.777 ms
11  linx-226-gw.thdo.bogons.net (195.66.226.228)  145.628 ms  169.674 ms  
169.834 ms
12  cr0-G1-1.rbsov.bogons.net (193.178.223.218)  170.023 ms  170.327 ms  
170.434 ms
13  43-242.rbsov.bogons.net (85.158.43.242)  203.535 ms  203.637 ms  203.747 ms
14  gi1-0.core1.man.bytemark.co.uk (89.16.160.41)  203.976 ms  204.178 ms  
204.317 ms
15  gi0-23.agg1.man.bytemark.co.uk (89.16.160.58)  204.541 ms  204.729 ms  
124.986 ms
16  ppp.dh.bytemark.co.uk (89.16.161.184)  127.403 ms  130.764 ms  133.188 ms
17  wren.kitenet.net (80.68.85.49)  136.618 ms  140.763 ms  143.048 ms

At first I tried mtr and it was very confusing, seemed to be one hop to
anywhere:

 Host   Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. wren.kitenet.net 0.0%29   16.1  13.4   1.3  24.3   6.1

I think mtr must optimise away the rest, which seems like a sort of bug in
this situation.

-- System Information:
Debian Release: lenny/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental')
Architecture: i386 (i686)

Kernel: Linux 2.6.22-3-686 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages mtr-tiny depends on:
ii  libc6 2.7-5  GNU C Library: Shared libraries
ii  libncurses5   5.6+20071215-1 Shared libraries for terminal hand

mtr-tiny recommends no packages.

-- no debconf information

-- 
see shy jo


signature.asc
Description: Digital signature