426 error

[ArtX]

When trying to fxp from a friends pc to my own i always get the error

426 Connection closed: Incorrect function.

He uses drftpd and of course i use ioFTPD, now if i use filezilla ftp server, it works fine.

I have gone through ioftpd.ini many times reading and re-reading to see if i had missed something.

we both use ssl and i am behind a router, he can transfer directly to me and from me, as i can from him but if i try to fxp it fails with the above error.

All ports have been forwarded, am i missing anything, filezilla seems to be set exactly the same way as ioftpd and works.

[Yil]

Going to need a bunch more data... First, is ioFTPD giving that 426 error message or drFTPD? I have never seen a windows machine spit out that error before...

Pay particular attention to the IP being returned in PASV responses when dealing with a local machine. I often enable the "use local IP" option in clients when connecting via a 192.168 or 127.* style address because I only configured one device in ioFTPD and that uses the external IP/host so everyone else sees the external IP. I'm not sure what address your client may use when you try to FXP but it's possible it's giving out the non-routable 192.168 address or whatever.

Are you trying to SSL FXP? Was SSCP setup correctly? Tried setting the alternate up/down modes so it switches the port/pasv roles when transferring files to get things to work in the other direction?

Is this an older version of io? Pre v7 or whatever did that have annoying FXP SSL bug which some version of SSL (in particular the one used by java/drftpd) triggered more often but that came up as the annoying Overlapped issue not the error you mentioned, but it's worth a double check.

[ArtX]

Going to need a bunch more data... First, is ioFTPD giving that 426 error message or drFTPD? I have never seen a windows machine spit out that error before...

Yes it is ioFTPD giving that error

Pay particular attention to the IP being returned in PASV responses when dealing with a local machine. I often enable the "use local IP" option in clients when connecting via a 192.168 or 127.* style address because I only configured one device in ioFTPD and that uses the external IP/host so everyone else sees the external IP. I'm not sure what address your client may use when you try to FXP but it's possible it's giving out the non-routable 192.168 address or whatever.

I have tried every combination i can think of to get pasv working as it should, none seem to work

Are you trying to SSL FXP? Was SSCP setup correctly? Tried setting the alternate up/down modes so it switches the port/pasv roles when transferring files to get things to work in the other direction?

Yes i am trying to use SSL and i have already tried all you have suggested

Is this an older version of io? Pre v7 or whatever did that have annoying FXP SSL bug which some version of SSL (in particular the one used by java/drftpd) triggered more often but that came up as the annoying Overlapped issue not the error you mentioned, but it's worth a double check.

No this is the latest ioFTPD

I will try with a fresh install, and double and triple check the settings again

[ArtX]

[R] 227 Entering Passive Mode (xxx,xxx,xxx,xxx,195,88) obscured for obvious reasons
[R] Opening data connection IP: 192.168.0.1 PORT: 50008

[R] 150 Opening BINARY mode data connection for test.txt
[R] 426 Connection closed: Incorrect function.

does the same if its the internal address for both, ports are forwarded in the router, because as i said filezilla ftp server works, i can send you ioFTPD.ini in pm if you like to see if i haven't overlooked anything

[Yil]

I could be mistaken but I think you actually show the problem right there in the cut/pasted lines. You xxx'd out the external IP so I'm assuming it isn't the 192.168.0.1 shown just below it. Can you confirm that is the internal IP of the machine and not the router which often gets a .1 address?

If that is the case then you probably have a 'use site IP' or something option enabled in your FTP client. This may be required for things to work locally in your current configuration because not all routers forward internal packets using the external IP back to the internal one. Thus it appears you have no choice but to enable that option to get it to work.

If you disable the 'site IP' option and directory listings, etc break then setup a 2nd site for testing and using the same login/pass/etc but don't enable the 'use site IP' option and try to use 'STAT -l' for listings, and also disable PASV mode transfers. When using active mode you'll be giving the server your own local address and it won't have any trouble connecting back to you. That should allow you to list files over the command channel, FXP using the external IP, and transfer locally using active mode which is all you need :)

There are two reasons that setup might not work as you want. You aren't actually reporting your external IP correctly in the PASV replies which means HOST= needs updating, or the server doesn't have the ability to create outbound TCP connections because of a firewall. Both should be somewhat easy to verify aren't the case.

Which FTP client are you using if that doesn't work? I'll see if I can get the exact client settings for you. Feel free to PM/FTP me a cut of the logfile from login to an attempted file transfer and the .ini file and I'll see what I can make of it.

[ArtX]

I could be mistaken but I think you actually show the problem right there in the cut/pasted lines. You xxx'd out the external IP so I'm assuming it isn't the 192.168.0.1 shown just below it. Can you confirm that is the internal IP of the machine and not the router which often gets a .1 address?

The one i crossed out is my external ip address, 192.168.0.1 is internal, i can set it so that it shows external for both but then i cant connect

If that is the case then you probably have a 'use site IP' or something option enabled in your FTP client. This may be required for things to work locally in your current configuration because not all routers forward internal packets using the external IP back to the internal one. Thus it appears you have no choice but to enable that option to get it to work.
]If you disable the 'site IP' option and directory listings, etc break then setup a 2nd site for testing and using the same login/pass/etc but don't enable the 'use site IP' option and try to use 'STAT -l' for listings, and also disable PASV mode transfers. When using active mode you'll be giving the server your own local address and it won't have any trouble connecting back to you. That should allow you to list files over the command channel, FXP using the external IP, and transfer locally using active mode which is all you need :)

I think i tried the setup you mention, but i will double check, might have to wait a day or so as im in bed with flu like symptoms - so the doctor says

There are two reasons that setup might not work as you want. You aren't actually reporting your external IP correctly in the PASV replies which means HOST= needs updating, or the server doesn't have the ability to create outbound TCP connections because of a firewall. Both should be somewhat easy to verify aren't the case.

HOST = atm has my external ip address, is that correct ?

Which FTP client are you using if that doesn't work? I'll see if I can get the exact client settings for you. Feel free to PM/FTP me a cut of the logfile from login to an attempted file transfer and the .ini file and I'll see what I can make of it.

FTP client is flashfxp, have tried it with 3.6 , 3.7x betas and the 4.x betas, i was wondering, because drftpd sends files from different machines, could this be the issuse? Either flash or ioFTPD is expecting a connection from the machine i originally connected to, but the information is comming from a different ftp ip?

As i say i will try what you suggested in a day or so, not feeling to good atm

edit: think i may have found something, i must be ill because i went looking at the system logs, everytime i get an error, i get these two alerts in the logs

Log Name: System
Source: Schannel
Date: 03/01/2010 20:28:18
Event ID: 36874
Task Category: None
Level: Error
Keywords:
User: SYSTEM
Computer: VashTheStampede
Description:
An TLS 1.0 connection request was received from a remote client application, but none of the cipher suites supported by the client application are supported by the server. The SSL connection request has failed.

and

Log Name: System
Source: Schannel
Date: 03/01/2010 20:28:18
Event ID: 36888
Task Category: None
Level: Error
Keywords:
User: SYSTEM
Computer: VashTheStampede
Description:
The following fatal alert was generated: 40. The internal error state is 1204.

i have verified that this happens when transfering as i matched the times of the errors to when i did test transfers

[ArtX]

soredt now, seems it was an oversight on my part, don't put min cypher over 168bit if your using drftpd sites, it doesn't like it ;)

Thanks to Yil for helping me find the very simple solution :D

[djb61]

As I am a drftpd developer I thought I'd comment on the problem with ciphers over a certain length. As you probably know drftpd is written in Java, the standard Java runtime/SDK downloads from Sun ship with limitations to the encryption strength they support (due to US government export controls if I remember correctly).

I expect the site(s) you were testing were running a standard Java runtime for the drftpd daemon, if the site installed the export cryptography addon into their Java runtime then I would expect to find that that the key length restriction disappears and higher strength ciphers are now permitted.