ioFTPD v6.9.3 beta released - Page 3

DJZacharia · 05-19-2009, 06:05 PM

hello,

i was wondering if there is a native io ban command?

i have tried
'site ban <user> <time> <rsn>'
as well as
'site bans add <ip>'

what am i doing wrong?

thanks in advance.

Yil · 05-19-2009, 06:20 PM

Sorry, at the moment the only way to get on the auto-ban list is to be, well, auto-banned and it's based on your actual IP address. I.e. no hostmasks. You can list/delete IP bans via site bans and I don't see a reason why I couldn't add a site bans add command but it wouldn't do hostmasks. You can ban hostmasks via the Hosts.Rules file and rehash but there is no way to do that outside a script. This probably needs to be re-written as I don't like it either...

You can however "delete" a user and not purge them which will disable the account. As long as people don't go around doing purge * this will work. I've thought about adding an optional user flag to ban a user without the risk of them being purged which would use the delete message as the ban message to show a user. That shouldn't be too hard to do. As an optional measure you can use ioDELUSER script which does just this.

DJZacharia · 05-20-2009, 01:32 AM

thanks for the response,
to my knowledge ioDELUSER is no longer available, because site deluser/purge/bans was added to io.

Although, If you could somehow script something, into the next version of io, that would allow for a ban with a defined time and reason for ban, and an unban of course, without having to edit the config and host.rules, that would be great.

something like:
'SITE BAN <user> <time> <reason>'
(would ban user based on last used ip or something of that nature, and when they try to log in they would see '<reason>').
and
'SITE UNBAN <user>'

not sure if you would be willing to add this in the next version of io, i'm not sure about the demand for a feature like this, but as you mentioned: using the deluser flag is risky incase someone accidentally purges. In anycase, i hope to see it added, and if not, no worries.

thanks again for the reply

pion · 05-25-2009, 09:11 AM

426 Connection closed: Overlapped I/O operation is in progress.

How can this be avoided?

o_dog · 05-25-2009, 10:57 AM

people are trying to download a file that is beeing uploaded? if so, skip 0byte files and I think there is a setting in ioftpd that keeps the file size of the file to 0 until it's done, not sure about that one though, might be default behavior.

Yil · 05-25-2009, 02:04 PM

pion: The post explaining the "Overlapped I/O operation in progress" error message got lost in the server crash, but here's some info on it. When SSL negotiation fails ioFTPD forces the data connection closed and as a side effect that error message is generated. I really should find a way to have it spit out something SSL related...

I've attempted to examine a few instances where that error has occurred for me and here's the result. If ioFTPD is acting in a server role such as when you connect to the server, or it sends the SSL cert during fxp everything works fine. If however it acts as a client and receives a cert it may reject it because it's invalid (expired and/or name mismatch). To me that is perfectly valid behavior. However, lots of people setup drftp sites and install it's default "drftpd" cert which expired in 2004 and obviously doesn't match the host or slave IP/hostname and get this error as a result...

I originally configured the server to be picky to prevent spoofing and replay attacks. I haven't tested it yet, but I'm going to allow a configuration option to be more forgiving for data connections and hopefully that should solve the problem.

As a workaround you can configure "alternate fxp" methods in Flash or Rush to make ioFTPD act in the server role and that solves the problem. After changing the alternate fxp settings in Flash you will need to logout of BOTH sites before trying again since it won't issue another SSCN to change the roles.

pion · 05-28-2009, 11:36 AM

I'm aware of the "fix" - however having client fix a server generated error message isn't really an optimal behaviour :P

Another thing; the error message is really not explaining what is wrong..
Another example of weird error message is when client doesn't have ip added.. the error displayed then is "Invalid Password", even if there's a valid log entry. I suppose you could defend that one with avoiding attacks, but I'd love to have an option to use a more explaining error message.. I find it fairly unlikely that an attacker manages to get a valid username AND password without getting banned for hammering first...

Yil · 05-28-2009, 03:54 PM

pion: you can already do that...

Quote:

# Set this to True to display "Your IP/hostname is not authorized" instead
# of the generic "Invalid Password" error message if a user tries to login
# to an account but doesn't match any of the hostmasks.
;Show_HostMask_Error = True

Just uncomment it by removeing the ; to activate.

Mave · 06-15-2009, 06:08 AM

Any ETA at ioYiL script en new ioFTPD?

Did expect it months ago by now

Yil · 06-16-2009, 01:02 AM

6.10 isn't too far away. It will contain a whole lot of changes, and a bunch of non-visible support for the rest of the stuff that will end up in 6.11 which will finish up the requirements I wanted for ioYil in the server itself.

o_dog · 06-16-2009, 07:29 AM

plz make sure that the new changes don't break support for any older scripts.

Mave · 06-16-2009, 01:30 PM

Quote:

Originally Posted by Yil

6.10 isn't too far away. It will contain a whole lot of changes, and a bunch of non-visible support for the rest of the stuff that will end up in 6.11 which will finish up the requirements I wanted for ioYil in the server itself.

Sounds great to me

frankiben123 · 06-25-2009, 10:09 AM

thanks for the post.....

sales tracking software

Yil · 06-27-2009, 11:05 AM

Got some time and been working hard this week... Been working on tracking down memory leaks by trying to cleanup everything during shutdown so it's easy to spot the problems. While testing I had that annoying Overlapped I/O error hit me and decided to track it down... Turns out during the handshake the function that does all the work can return an empty token at one point and that's a valid possibility. Not sure why, but evidently Java's SSL implementation seems to trigger that case more often. Knowing that I think I fixed the problem and we can all rejoice soon.

Yil · 07-06-2009, 10:12 AM

I didn't get the next release out last week like I hoped, but that's because I stumbled across a few potentially severe problems and fixed them! I'm not sure, but it's possible this may solve the lockup bug... Good stuff. I'm writing up the latest changes / new features now and have a little more testing to do so keep an eye out for what I believe will be v7.0 based on all the file changes required and the TCL library upgrades as well.