Mailing List ecs-isp@2rosenthals.com Archived Message #888

Fra: "Lewis G Rosenthal" <ecs-isp@2rosenthals.com> Full Headers
Undecoded message
Emne: Re: [eCS-ISP] FTP problem
Dato: Mon, 30 Sep 2024 18:23:32 -0400
Til: eCS ISP Mailing List <ecs-isp@2rosenthals.com>

Hi...

On 09/30/24 05:36 pm, Steven Levine wrote:
In <list-11054921@2rosenthals.com>, on 09/30/24
    at 05:05 PM, "Lewis G Rosenthal" <ecs-isp@2rosenthals.com> said:

Hi all,

Surely. As good a place as any.
There's always Peter's FTPServer list, but it seems that almost everyone
is on all the lists and the lists are low traffic, so it really does not
matter, IMO.

Bear in mind that the Zeitgeist is that FTP is evil. It is quite possible
that a router along the way blocked your FTP traffic.
While it's possible, the failure's I've seen are typically something else.
Most often a firewall requires the client to toggle between active/passive
mode.  Another less likely case is that the ports specifed for use by
FTPServer don't match the open ports.  See Setup->Options->Restrict PASV
data port numbers.

If it's an active/passive thing, the server log should show a connection. Doug specifically said that he saw no connection whatsoever in the server log.

difficult to  determine which intervening hop is blackholing your
traffic. tracerte uses  UDP, so even specifying the port (tracerte -p 21)
may not get you reliable  results (timed out for me around hop 12, even
specifying a longer wait time).
My experience is that tracerte fails more often than not these days.  The
routers are not configured to support it.  My workaround is

   telnet ftp.foo.com 21

This tests if a connection is even possible.  It takes login issues and
data port issues out of the mix.


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.

If you want a bit more data, iptrace can provide some.  On the client end
it will show you if the SYN packet gets a response.  On the server side it
will show you if the SYN packet ever makes it to the server.


That is probably the best suggestion of all, at this point, but again, if the traffic is getting blocked in between (even at the edge firewall on 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.

--
Lewis
-------------------------------------------------------------
Lewis G Rosenthal, CNA, CLP, CLE, CWTS, EA
Rosenthal & Rosenthal, LLC                www.2rosenthals.com
visit my IT blog                www.2rosenthals.net/wordpress
-------------------------------------------------------------


Abboner: Feed, Digest, Index.
Stopp abbonement
E-post til ListMaster