In <list-11054999@2rosenthals.com>, on 09/30/24
at 06:23 PM, "Lewis G Rosenthal" <ecs-isp@2rosenthals.com> said:
Hi there,
>True, however, it won't reveal where along the line the connection is
>failing, which was Doug's question. telnet, like FTP, will only show
>whether a connection can be made, but not where (or why) it may be
>failing.
True, but if the problem is really some router in the middle of the path
there might be nothing that can be fixed or even identfied as the source
of the problem.
I was thinking that tracerte from both ends might be end might be an
interesting test. How useful it might be for providing additional
information, who knows?
>the far side), iptrace won't reveal much on the server side. If the SYN
>packets don't make it through, again, sadly, it won't reveal where the
>packets were dropped.
Agreed. I'm not smart enough to diagnose problems in stuff that is
effectively invisible. For example, if I try to access one of Dan's
servers with
tracerte dnacih.com
tracete hangs at 12.83.97.113, which appears to be an AT&T router. We
know that 12.83.97.113 is working fine in the sense that I can access any
of the services running on dnacih.com. However, attempting to access
12.83.97.113 by any the typical ports gets no response. However, if I
could not access the server, the tracerte results would tell me nothing
because the result are the same whether or not I can access Dan's server.
tilbake listen