From: "Lewis G Rosenthal" Received: from [173.72.248.214] (account lgrosenthal@2rosenthals.com HELO [192.168.201.140]) by 2rosenthals.com (CommuniGate Pro SMTP 5.4.10) with ESMTPSA id 11054998 for ecs-isp@2rosenthals.com; Mon, 30 Sep 2024 18:23:34 -0400 Subject: Re: [eCS-ISP] FTP problem To: eCS ISP Mailing List References: Organization: Rosenthal & Rosenthal, LLC Message-ID: <66FB24E4.3090707@2rosenthals.com> Date: Mon, 30 Sep 2024 18:23:32 -0400 User-Agent: Mozilla/5.0 (OS/2; Warp 4.5; rv:38.0) Gecko/20100101 Firefox/38.0 SeaMonkey/2.35 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hi... On 09/30/24 05:36 pm, Steven Levine wrote: > In , on 09/30/24 > at 05:05 PM, "Lewis G Rosenthal" 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 -------------------------------------------------------------