Re: [exim] smtp timeouts / what to look for

Pàgina inicial
Delete this message
Reply to this message
Autor: Renaud Allard
Data:  
A: Zbigniew Szalbot
CC: Exim Mailing List
Assumpte: Re: [exim] smtp timeouts / what to look for


Zbigniew Szalbot wrote:

>
> I have eventually connected my box straight to the modem and:
> 1/ I am still getting timeouts to Yahoo (though they claim not to block us)
> 2/ I can at least use (tcp)traceroute and here are some logs. Can you
> help me interpret them? Am I right in thinking that the connection
> times out somewhere at yahoo border machines?
>
> If I remeber correctly, this one is from tcptraceroute a.mx.mail.yahoo.com 25:
>
> 1 cxw209.internetdsl.tpnet.pl (83.19.156.209) 9.729 ms 9.325 ms 9.994 ms
> 2 byd-ru1.idsl.tpnet.pl (213.25.2.164) 12.584 ms 86.020 ms 9.611 ms
> 3 z.byd-ru1.do.byd-r2.tpnet.pl (213.25.5.165) 9.702 ms 9.718 ms 9.981 ms
> 4 so-0-3-0.war-r4.tpnet.pl (194.204.175.221) 12.253 ms 12.686 ms 12.306 ms
> 5 po8-0.nykcr2.NewYork.opentransit.net (193.251.251.69) 126.360 ms
> 149.051 ms 351.378 ms
> 6 gi0-0-0.nykcr3.NewYork.opentransit.net (193.251.240.230) 119.395
> ms 120.847 ms 119.446 ms
> 7 po10-0.ashcr2.Ashburn.opentransit.net (193.251.243.1) 121.575 ms
> 121.886 ms 121.404 ms
> 8 ge-0-1-0-0.atlcr3.Atlanta.opentransit.net (193.251.243.178)
> 136.551 ms 136.275 ms 172.029 ms
> 9 pos0-0-2-0.daltr1.Dallas.opentransit.net (193.251.241.17) 158.566
> ms 158.634 ms 158.842 ms
> 10 so-3-0-0-0.dalcr2.Dallas.opentransit.net (193.251.241.18) 157.308
> ms !A 157.348 ms !A 156.995 ms !A
>


Is it all the input your tcptraceroute gives? I don't see any reason why
it stops at the 10th hop, except if you told tcptraceroute to do so. By
default it should use 30 hops.

The "normal" traceroute:
20  ge-8-1.bas-g2.mud.yahoo.com (68.142.193.215)  158.201 ms
    ge-9-1.bas-g2.mud.yahoo.com (68.142.193.223)  155.621 ms
    ge-8-1.bas-g1.mud.yahoo.com (68.142.193.213)  159.981 ms
21  * * *
22  * * *


This one doesn't help very much as this kind of output was expected
because their firewall is probably configured to block this kind of
traffic. Hence the need for the tcptraceroute on port 25.

By the output you gave it seems there is a routing problem in Dallas
opentransit, but as the "normal" traceroute passes it (although not
through the same routers), it seems that the output of your
tcptraceroute is not complete. I would at least have expected one line
of * * * * if there was a problem at opentransit.

Could you verify that you allowed more than 10 hops in your
tcptraceroute? And if not, try to do the test again allowing at least 30
hops.