Ftp issue with CSS11503

[rbatchu]

Recently we have upgraded our CSS from CSS11051(ver 5.0 build 45) to CSS11503 (ver 7.10 build 206).

Everything went smooth in the upgrade.

We have like 8 business clients. All the ftp servers work fine expect two of them.

when i try to tranfer the data on the ftp servers the tranfer goes fine upto 99% and then aborts saying that

remote server closed.

I tried bypassing the CSS. directly connecting to the ftp server and it works fine.

We are running proftd 1.2.6rc1 all the ftp servers.

Any ideas what could be wrong?

[Gilles Dufour]

Take a sniffer trace - look to see if the CSS or the server sends a TCP RST or FIN.

Look if the connection is idle for more than 16 seconds at one-time during the transfer.

Also, could you confirm that all data transfers are affected or is it just the long data transfers ?

Do you see the problem with both active and passive ?

Is it the same problem with any ftp client ?

Gilles.

[rbatchu]

Data tansfers are effected wheather its small or huge file, the transfer aborts at 99%. This problem seem to occur only in active and passive works fine.

I tried with multiple ftp clients. and the result is the same.

and i tried bypassing the CSS and it works fine with both active and passive modes.

[Gilles Dufour]

what's the software version you are using ?

Did you capture a sniffer trace to see what is going ?

Do a capture on the server and on the client.

See what is different.

Gilles.

[rbatchu]

i tried running etheral on the cleint. but it really didnt showup anything.

all i get on the client is connection closed by remote host.

[jfoerster]

Hi,

could you please paste parts of the trace? Which session is closed the data or the control session?

Could you take a trace as suggested by Gilles at the servers side?

Kind Regards,

Joerg

[rbatchu]

I dont see anything on the server side.

and its the data port which i getting closed NOT the control port.

This is what i see on the client side.

C:\>ftp ftpserver.xyz.com

Connected to ftpserver.xyz.com.

################################################################################

################################################################################

##################################

Connection closed by remote host.

[Gilles Dufour]

if you don't see anything with ethereal you either misconfigured it or it is not installed correctly.

Did you install WPCAP as required ?

Do you have another sniffer software running maybe ?

The trace is the most important. Without it it's impossible to know what's going on.

Gilles.

[rbatchu]

Ethereal is working fine. I can sniff the packets using ethereal. I dont see anything special.

It like normal ftp traffic.

As i told u. The active ftp traffic is having the problem. and that too active ftp goes fine upto 99% upload and fails at the last 1%.

I have the ethereal trace on client and server. but this of 20mb and 40mb. which i cant upload here.

[Gilles Dufour]

ok - send me the trace at gd@cisco.com

I'll see if I can find something.

Also send me your config, I'll try to reproduce the same issue.

Gilles.

[rbatchu]

Finally tac solved the issue.

Here the new defect logged for the documentation...

CSCec85284(cstbu,upd,care2ddts)Documentation for large ACTIVE ftp transfers

The CSS tears down the FTP control channel after 10 minutes of idle time.

This teardown may occur during a file transfer if the transfer exceeds 10

minutes. This timeout applies only to active FTP (that is, it does not apply

to PASV FTP). To increase the 10-minute timeout, use the

flow-timeout-multiplier number command in owner-content mode on the

associated content rule to configure the timeout to a value large enough to

accommodate the expected duration of FTP file transfers. This command

specifies the number of seconds for which an idle flow can exist before the

CSS tears it down. Enter an integer for the number variable from 0 to 65533.

The CSS multiplies the value you specify by 16 to calculate the flow timeout

in seconds.