connecting through dproxy2 on ioFTPD 3.3.0

[Tittof]

I dont know if it is a traceable bug but anytime I try to connect on the ioFTPD via dproxy2 only the half of the login message (ascii that I put into login.msg) is shown and the client is not loggin in completely. Breaking the connection (within the client) results in showing the rest of the ascii and after the part with "time is now" the connection break without the quit message. It does not matter how long u wait for the ascii to appear, its always the same case. Without dproxy2, everything is fine by the way. This behaviour now has been validated by 3 Friends of mine. I know this might be a prob within dproxy2 but since both programs were made by you.. I would be glad to see if this issue can be resolved

rgds

[darkone]

It's most likely issue with dproxy2. If possible, try connecting with some tls capable client and see if this resolves your problem (ie. pftp http://pftp.suxx.sk/pftp/)

[Tittof]

I tried pftp and flashfxp in tls mode and both succeed to login directly into ioFTPD but that does not solve the prob at all since I would love to let ppl using dproxy2 loggin into the server (a lot of ppl are using it by the way)

rgds

[Tittof]

Examining the problem in more detail I used other SSL/TLS capable servers to verify that those are workin with dproxy2 and neither serv-u nor ipswitch's ftpd shows the same problem that ioFTPD shows. ioFTPD sends 15 lines of the login.msg and gets stuck then. This leads me to the conclusion the the issue might aswell lay in ioFTPD and probably not in dproxy2 as you assumed a few days ago.

P.S. yes I tried the latest available version of ioFTPD

kind rgds

Tittof

[darkone]

I doubt that other server softwares are handling connections the way I do - nonblocking. It's very uncommon as handling non blocking sockets is much more difficult that handling plain blocking sockets (also dproxy is working in nonblocking mode, however implementation there might not be valid)... use of non blocking sockets gives quite a few advantages: you can handle several connections with one thread if needed, you're always aware how much data you've sent to socket... So far noone has reported any compatability problems with real clients. I will test the dproxy tonight to make sure that origin of this problem is not on the server-side.
There are some other known issues in dproxy2 as well.. I might fix them one day, but until then it's what it is.

[darkone]

I think I located the problem.. and it is in dproxy2 - this is what flashfxp logs show when connecting:

[18:00:09] 220 Welcome to ioFTPD server.
[18:00:12] 331 Password required for ioFTPD.

This is what it should show:

[02:46:16] 220 Welcome to ioFTPD server.
[02:46:16] USER ioFTPD
[02:46:16] 331 Password required for ioFTPD.
[02:46:16] PASS (hidden)

Looks like proxy was adding some character(s) ('\r') to buffer after AUTH TLS. If this was the only flaw in it, I would fix it. But it seems that it's using blocking sockets, which causes bouncer to start lagging when there are one or more users connected to with slow connections. (It's using global buffer, instead of per user buffer.. which is a very bad idea (and quite easy to fix), I just didnt understand it back then - and now I really dont have time for such)