Gary: > I have been having problems receiving files via FTP from another computer, > and I wonder whether anyone has had this experience: I've used FTP between Windows NT and Linux systems for years and my exper- ience has been that the Linux system is going to be the more reliable & consistent of the two systems. You should try to use the FTP.EXE command-line program that Windows NT comes with to diagnose problems. I assume you are using a scriptable FTP program like WS_FTP or else you wrote your own application using some third-party FTP libraries. You can tell a lot more about what's going on with the system using the command-line tools. > I am running a program on a Windows NT computer which is automatically > receiving files from my Linux computer, processing them, then sending files > via FTP back to the Linux computer. Periodically, the process "hangs" on a > "put" when the sending computer (the NT) does not receive verification from > the Linux computer of completion of file transfer (even though it has > completed). The FTP documentation says that this can happen if the receiving > computer violates the FTP protocol. The only way to continue the program > without restarting is to "kill" the demon from the Linux side. Also, at some > times, I suddenly start getting a message back from the Linux machine which > says "connection refused". I then have to abort the program and I can't send > anything to the Linux machine from anywhere for several minutes, after which > it will usually clear itself. I am running Redhat version 6.2 on an HP > Visualize PL-class workstation. If you can duplicate this problem, including the "connection refused" stuff that would be spiffy. The best time to check things out would be while the Linux system is refusing connections. (Or while you believe this to be the case, at least.) On your Linux system you should do "netstat -an | grep LIST" to see if anything is listening on port 21 (ftp) while the Linux system is refusing FTP connections. You should then, on the Linux system, try to FTP to 127.0.0.1 and see if you get in. You could also check your DNS since the TCP wrappers (tcpd using /etc/hosts.deny & /etc/hosts.allow) could be blocking FTP during a DNS temporary outage or problem. If you can get through to 127.0.0.1 from the Linux system then the problem is not the Linux system or your Linux FTP daemon. I bet that the command-line FTP would work even during the "connection refused" time period if this is the case also. Perhaps there's a proxy server or masquerading server in between these systems causing problems. Hope this helps. -- Jim Ockers (ockers@ockers.net) Contact info: please see http://www.ockers.net/ Fight Spam! Join CAUCE (Coalition Against Unsolicited Commercial Email) at http://www.cauce.org/ . Received: from tummy.com (IDENT:DdEsq2AwrsWvw/8TOB5kgSoFTLYt07L7@secure.tummy.com [216.17.150.2]) by clue.denver.co.us (8.9.3/8.9.3) with SMTP id XAA07358 for ; Sun, 24 Mar 2002 23:28:13 -0700 Received: (qmail 20803 invoked by uid 10); 25 Mar 2002 06:38:43 -0000 Received: (qmail 8029 invoked by uid 500); 25 Mar 2002 06:38:41 -0000 Date: Sun, 24 Mar 2002 23:38:41 -0700 From: Sean Reifschneider To: clue-tech@clue.denver.co.us Subject: Re: [CLUE-Tech] OT: DSL QoS Revisited Message-ID: <20020324233841.B7663@tummy.com> References: <3C9E3400.77E00E00@americanisp.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from rrarabie@arabie.org on Sun, Mar 24, 2002 at 10:05:44PM -0700 Sender: clue-tech-admin@clue.denver.co.us Errors-To: clue-tech-admin@clue.denver.co.us X-BeenThere: clue-tech@clue.denver.co.us X-Mailman-Version: 2.0beta2 Precedence: bulk Reply-To: clue-tech@clue.denver.co.us List-Id: CLUE technical discussions, questions and answers. On Sun, Mar 24, 2002 at 10:05:44PM -0700, Randy Arabie wrote: >> If my ISP started dropping my DSL link after inactivity, and only brought it back up when there was outgoing traffic it might cause >> similar problems. Like I said, I haven't tested that specifically but it seems not to be the case. > >Hmm. Maybe I'll check that out. Wasn't there a version of DSL they were rolling out here that was not "always on", and you'd get kicked off after some inactivity? You effectively had to dial back in when you were ready to use it again? Of course, think "ISDN" instead of "Analog modems sniffing each others butts" when I speak of dialing. When I last had ISDN, it took 2 seconds for the connection to dial and PPP to do it's negotiation... IIRC, this DSL that you had to dial was only available with the internal cards though. I may be wrong, but that's what I thought... Sean -- I'd rather write programs to write programs than write programs. -- Dick Sites Sean Reifschneider, Inimitably Superfluous tummy.com - Linux Consulting since 1995. Qmail, KRUD, Firewalls, Python