DSM-G600, DNS-3xx and NSA-220 Hack Forum

Well - this is going to be a tough one to troubleshoot, and much more so to troubleshoot remotely - and frankly I think you're looking in the wrong direction.

You're establishing a connection, but it fails repeatedly every 20~40 seconds, and you're looking at a bunch of options & fiddling with them, apparently without taking the time or trouble to understand them, not a good idea in my opinion.

Why should the default idle time of 2 mins be the cause of a disconnection every 20~40 seconds?  Why would you think that increasing it to 10 mins would solve your problem?  What is the "idle time" anyway?  What does "NOOP" do and why should it solve your problem?

For starters - the "idle time" is pretty much what it suggests - after an idle (as in not being used) period of "x" minutes, the server will drop the connection - if the connection is not idle, the server will not disconnect the connection, this is not your problem - if the disconnect is occuring repeatedly at intervals shorter than the idle time, this is not your problem.  NOOP by the way is "no operation" - it's a command that basically says "do nothing" and it's used to keep the connection active, so that the server doesn't consider it "idle" and disconnect it - look elsewhere for your problem.

Now - you say that you are constantly disconnected .... every 20~40 seconds, and that implies that you are getting a connection.  If this is in fact so, then don't play with active & passive modes unless you're willing to do the research into what they are, why they exist and when to use them - just accept that because you get the initial connection that whichever mode you're using at the time works - if there is a problem with either mode and you need to use the other, you'll never get beyond establishing the control connection - look elsewhere for your problem.

Where should you look - that's the tough question.

If you are getting a connection and losing it every 20~40 seconds - then I would think you have a very sick network somewhere between the client and server - and that you should have seen other symptoms - so - for me the questions to consider are ...

Are you actually getting a connection?  Can you actually transfer data?  Or is it that you are establishing the control connection and never the data connection (in which case active/passive mode may hold the key)?

oxygen wrote:

I guess it's the NAT / Firewall who's destroying the eonnection after a timeout. Not the Server.

Just out of curiosity - why do you feel that a NAT/firewall would/should destroy an established connection, assuming it is active, after a timeout of 20~40 seconds.

I have been able to do ftp transfers from my DNS-323, behind a NAT/firewall to a Windows server also behind a NAT/firewall, separated by a "logical" distance of some 45,000 miles (one of them is on a satellite link) and the connection will stay up until I terminate it, or the 2 min idle disconnect elapses - oh - for clarity, the Windows server was the client and it was an "active mode" ftp connection.

If we move away from the DNS-323 to ftp in general, I've maintained ftp transfers for time spans exceeding sixteen (16) hours, with the client behind a NAT/firewall - this is a evaluation download from Microsoft, so I would assume that the server is behind a firewall of some sort, but it's not likely to be a NAT/firewall.

Yes - firewalls & especially NAT can be a significant issue for ftp - but in my experience they are more likely to prevent a connection from being made rather than destroy an established active connection, so unless there is evidence to point to the firewall, I don't think it should be a prime suspect.

ftp is unusual in that a transfer requires two connections - a control connection and a data connection.  With active ftp the control connection is created by the client and the data connection by the server - frequently the NAT/firewall at the client side cannot recognize the incoming data connection as belonging to the already established outgoing control connection and discards it - this is actually why passive ftp exists - with passive ftp, both the control and the data connection are established by the client, and are allowed by the client side NAT/firewall but the data connection ports are not "well known" ports and cannot be forwarded at the server side NAT/firewall with the same ease as the control connection, and the end result is essentially the same - control connection established but no data connection.

The crucial factor here is whether or not both the control and data connections are actually being made - if they are then the NAT/firewall is not likely to be the problem, if they're not, especially if only the control connection is being made, then there is a very strong probability, that one or the other (or both) NAT/firewall is responsible.

My point is that "guesses" are not a good way to troubleshoot connection problems - the first step is to establish what is or is not happening and then determine the cause, it is a multistep process and there may be mutliple things not happening and multiple causes, but it starts with the first step - defining what is not happening.

OK - a couple of things don't quite make sense here.

First ...

same problem in local than from internet access

What this says to me is that you have the same problem with a local connection - maybe I'm misunderstanding you - but if you're having this problem locally, then that immediately eliminates the firewalls and NAT.

Second - towards the bottom of your listing, the following line appears ....

[R] 421 Timeout (no new data for 600 seconds)

This suggests that the connection is being terminated by the ftp server for inactivity after 600 seconds and should not be happening every 20~40 seconds as originally stated, it would point to some sort of problem with the ftp server.

BUT .....

I brought up the ftp server on my DNS-323 and attempted to duplicate the problem and discovered that several of the commands in the list provided do not work - SYST, LIST, PASV, STOR - all return an invalid command message.  I was especially curious about SYST, since in the list provided it returned

[R] 215 UNIX Type: L8

which is not quite what I would have expected from the DNS-323 which runs linux.

Finally - I deliberately left the control connection to my DNS-323 open beyond the timeout and there was no error message - until I sent the next command, and the error message reads "421 Timeout - try typing a little faster next time", followed by "Connection closed by remote host"

I have to assume that either you are not connected to a DNS-323 or you are not connected to a DNS-323 running the standard firmware and ftp server.

bodhod

Trying to connect to a forwarded port from inside the same LAN can sometimes produce very puzzling results, and may or may not work, depending on the feature set and configuration of the router being used.

I was able to connect to your ftp server and downloaded the two smallest files, the idea being to see if it would boot me off in the 20~40 second time frame that you mentioned (it doesn't), and I successfully uploaded a small .pdf which took just less than 9 minutes - based on that I would say your problem is at the client side or in between, it's certainly not your DNS-323 or the DNS-323 side NAT/firewall or network.

Now - I'm just being curiosity here - there are a couple of hints in your posts that suggests a "french connection" - but - your physical location suggest otherwise.