ioFTPD v7.5.9 Released (Beta) - Page 10

o_dog · 08-28-2010, 10:53 AM

hmm sorry, it return the right uid and gid, but then it returns some wierd permission in 6 digits, 100755 for instance. [vfs read $path] where path is dir.

is this right?

Yil · 08-29-2010, 02:57 AM

Hmm... [vfs read] actually does return "uid gid mode" with the last 3 digits being the octal mode of the permissions. However, at some point in the past I started using higher order bits to reduce attribute lookups if the chattr value was known to not exist. I hemmed and hawed a bit and decided to let [resolve list], [vfs dir], and [vfs read] return the extra bits so that scripts could benefit as well. If the bit is set the value exists and you know it's a symlink, hidden dir, etc and if not set then you know it isn't. Saves having to do a [vfs chattr 1] to test for symlinks all the time. I updated the [resolve list] documentation but failed to do so for the [vfs] commands so that's why it's not making sense to you... Just OR the bits with 0777 to get just the permissions like before. The higher order bits are:

#define S_REDIRECTED 040000 // not currently used...
#define S_SYMBOLIC 020000 // ioFTPD symbolic link (chattr 1)
#define S_PRIVATE 010000 // Private/hidden dir (chattr 0)

o_dog · 08-29-2010, 03:43 AM

that seriously break compability with ALL scripts that uses that command doesn't it? for VERY little benefit.

Yil · 08-29-2010, 01:20 PM

I misspoke in the previous post with respect to [vfs read]. I changed [vfs write] to reject attempts to SET the high order bits a while ago, but that was because I was testing the [resolve list] function (which is supposed to expose those extra bits) and it was causing issues in the virtual dir test script I posted a while ago somewhere. That's when I decided to let the extra bits stay, but only for the [resolve list] function and documented that.

I do remember discovering that [vfs dir] also exposed those bits months later and figured nobody was using that new command yet so I just made a note to update the iTCL doc file so it would act the same as [resolve list], but I never did or the change was lost somehow because it's not in the file or in the Changelog.

On the other hand, I either never figured out [vfs read] needed updating (which is odd), or the trivial change to strip the bits got lost along with the note to update the [vfs dir] docs. I'm with you, changing [vfs read] behavior isn't something I'd want happening either but I can't figure out why I didn't update the docs OR revert the behavior since I do remember discovering the issue months after it went live...

PSA9 · 09-08-2010, 01:05 AM

Yil i been away from ioFTPD but about to do some upgrades and looking to try a much updated ioFTPD as it seems much has been done since i been gone!

I am totally new to NAS and in the process of purchasing one so bare with me on the questions i have!
I read that the NAS has FTP Sever but can i put ioFTPD as that FTP Server?

If not does ioFTPD work well with a NAS?

Any Knowledge u can help me with would be nice, i just want the site scripts like ioNiNJA to organize my items! By the way the NAS is for my RV and is important i have one in their!

o_dog · 09-08-2010, 01:08 AM

If the NAS runs windows home server maybe, otherwise no.

BoNeZz · 09-09-2010, 02:53 PM

i have a problem

i use 7.5.9 and when i try to download with ssl or tls for data, i have a slow speed

my max download is 500kb/s, and i take it 200kb/s with ssl

Flow · 09-12-2010, 03:52 PM

Yil!, you awake? - Whats cooking?

Yil · 09-14-2010, 06:44 PM

I actually haven't been around much lately with time off and stuff so no real progress the last month or so. I need a few solid full days in a row to work on the data transfer logic re-write because it's fragile code, so just waiting for that opportunity...

PSA9: The odds of running ioFTPD on your NAS are probably zero. Most use a linux kernel because it's free. On the other hand ioFTPD doesn't use fancy windows permissions, etc so there's a pretty good chance you could use a non-windows based file share. I don't know if anyone is mounting a network drive that is really Samba/linux but there's a good chance that would work.

BoNeZz: I don't see any reason that transfer speeds should vary just because SSL is enabled provided the machine doesn't have the CPU busy. Obviously if the machine is single cored and playing a game or something the CPU is busy and encryption might take longer and that would slow down the transfer. Even a 10 year old machine can probably encrypt faster than read it's disk provided it doesn't have anything else to do though... The actual transfer logic for reading/writing to disk/socket is the same either way which means encryption time is the only variable. Check the CPU % usage with encryption turned off and on and if the rest is idle. Do you get the full bandwidth of the network connection with it disabled? Sometimes slight differences in TCP packet timings can cause significant performance drops. Think of it as slightly different routes between hosts that in theory should be the same but aren't.

opcode · 09-15-2010, 12:43 PM

@Yil: I changed the portranges to the ioFTPD defaults and never had a crash or anything else ever since.
I am trying to setup a traffic bouncer atm, but can't get it to work. I am using yatb233 for the bouncing, and it seems it sends IDNT command right ([-SYSTEM- - 7456,Wed Sep 15 17:35:59 2010] IDNT cmd: IDNT ident@user.real.ip.here:user.real.ip.here). I have added the bnc ip to ioftpd.ini in BNC_HOST_1 = bouncer.real.ip.here but when i try to connect trough it to ioFTPD but it rejects the connection. When i look into the log, ioFTPD reports that a user tried to connect from bouncer.real.ip.here, so it seems it didn't realize it was actually dealing with a bounced connection but thought it to be a regular one instead.

I tried forwarding the connection to a glftpd box and it works there, so it must be something on the ioftpd side.
Port 113 is open and forwared to the ioFTPD box and works when connecting without the bouncer.

Edit: Is there any way to have the correct path shown when CWDing into symlinks? E.g. i have a symlink called dump in / that points to /public/incoming/dump. When i cwd into the symlink, my ftl client claims that the current path is now /dump instead of /public/incoming/dump. I believe it was possible before, so maybe there is a way to revert back to that symlink resolving again via some config settings?

Yil · 09-16-2010, 12:05 AM

opcode: Interesting tidbit on the pasv port range info. I've never seen a config that didn't use a simple x-y range before, so it's possible there was some issue with 4 individual ports or the fact that it was so few meant way more port starvation problems with timeouts, etc that exposed some other rare behavior elsewhere. Glad you got it working, but I really should look into that a bit now that it's narrowed down to something easier to test locally.

Can you confirm which version you are using? I broke the IDNT command in v7.5.0 and fixed it in v7.5.1 after pion noticed it but maybe I missed something else. I suppose an option to record failed/rejected IDNT commands isn't a bad thing to add as a configurable option which might shed some light on what's going on so I might add that in the future. For now I'd double check that BNC_HOST_1 is actually defined for the service users are connecting through since it's service specific and you may have defined more that one service in the config file or put it in the wrong place when updating the file. If all else fails you could write a trivial TCL script or use something like "args" (included below, use "IDNT = EXEC ..\scripts\args.exe" under [FTP_Pre-Command_Events]) to log/view the actual command to make sure it looks correct...

NOTE: The server will reject otherwise valid IDNT commands from BNCs where the IP address provided is a non-routable address like 127.*, 192.168.*, etc. This is a security measure as these should always be able to connect directly and are often used in hostmasks of Master accounts.

The way symlinks are handled is controlled via the 'Keep_Links_In_Paths' option. If not enabled then PWD will always display the true path and not the symlink'd path. This also means that CDUP, CWD .., etc will work on the real path as well though so CWD /dump, CDUP, wont put you at / but /public/incoming. Not a big deal unless you browse /sorted type dirs and expect to end up back there after entering a subdir. I've made a note to look into allowing each symlink to control how it should be handled for the best of both worlds in the future...

opcode · 09-16-2010, 09:54 AM

Ok, thanks for the help with the symlinks. True that it makes browsing sorted symlink collections a pain in the ass, but i use them more to navigate quick into deep nested directory structures, so it bothered me more that i ended up again in / instead of the dir above when doing CDUP. But all is well now. Also i noticed some warnings in the logs, seems like some script got confused that a symlink reported /target/to/symlink as it's target, yet when cwd'ing into the actual path returned by io was /symlink instead. I don't really know what script it or the exact message was, because it didn't look serious so i never bothered. I guess it was either nxTools or ioNinja.

Back to the bouncer issue. I checked and the BNC_HOST is defined in the service section. Here's an excerpt from the ioftpd.ini

Code:

some other settings here...

#############
# FTP SETUP #
#############
[FTP_Service]
Type                    = FTP

# Name of "Device" configured above to bind to when listening for client
# connections.
Device_Name             = Any

#-------------------------------------------------------------
# The port for people to connect to your FTP on.
# *** You MUST forward this port as well in your router!!! ***
#-------------------------------------------------------------
Port                    = 12345
# NOTE: Port-1 will be used for all active outgoing connections if you
# need to allow these explicitly in a router.

User_Limit              = 10
Allowed_Users           = *
Messages                = ..\text\ftp

#
# Encryption - See "Permissions" section below for syntax. The default
# allows anyone to connect to the server without TLS/SSL.
#
# To force everyone (a good idea!) to use secure connections except for
# the default ioFTPD account which is configured to only allow connections
# from the same machine as the server use
#    Require_Encrypted_Auth  = !-ioFTPD *
#    Require_Encrypted_Data  = !-ioFTPD *
#
Require_Encrypted_Auth  = *
Require_Encrypted_Data  = *

#                >>>>>>>>>>>> SSL CHANGE THIS <<<<<<<<<<<<<<
#
# Name of the SSL certificate to use for this service.  If at the very top
# use have a HOST= line that is anything other than 0.0.0.0 you don't need
# to explicitly set this as the server will try to load a cert with the
# specified HOST= name and if that fails it will try the default of "ioFTPD".
#
# NOTE: You can now use "site makecert" and "site removecert [name]" to 
# manipulate installed certificates.
;Certificate_Name        = ioFTPD

# If no certificate was found at all and this is 'True' then at startup
# try to create a new certificate automatically and load it for use.
# Default is False.
Create_Certificate = True

# If undefined or 'True' the server will respond with a clear text FTP
# greeting and users will send the 'AUTH TLS' or 'AUTH SSL' commands to
# enable encryption.  If set to 'False' then assume implicit encryption which
# means negotiate TLS/SSl immediately before any text sent.  You most likely
# want to leave this with the default 'True' setting.
Explicit_Encryption     = True

# You can limit the TLS/SSL negotiation method to: SSL2, SSL3, or TLS.
# I strongly suggest leaving this undefined (the default) to support all 3
# methods.  If you do modify this you should also consider passing the
# appropriate NO_SSLv2, NO_SSLv3, and/or NO_TLSv1 options to the library
# via the OpenSSL_Options feature below.
# WARNING: This also affects data connections to/from the service.
;Encryption_Protocol     = SSL3

# You can specify any v1.0 OpenSSL option flag to modify the encryption
# library's behavior.  Arguments are separated by "|" and the "SSL_OP_" prefix
# should be left off.  The complete list of options is available at:
#  http://www.openssl.org/docs/ssl/SSL_CTX_set_options.html
# The 2 suggested options are:
#   ALL       - enable all compatibility options to work around broken SSL
#               implementations.
#   NO_TICKET - Disable RFC4507bis tickets for stateless session resumption.
#               FlashFXP disabled this because of issues with some Java SSL
#               implementations so I figure we should do the same.
OpenSSL_Options = ALL|NO_TICKET

# You can control which ciphers are available.  Documentation is available at:
#   http://www.openssl.org/docs/apps/ciphers.html
# The default of "DEFAULT:!LOW:!EXPORT" excludes anything under 128 bits.
# NOTE: This affects both control and data connections!
OpenSSL_Ciphers = DEFAULT:!LOW:!EXPORT

# Active mode data transfers require the server to create connections to the
# user specified IP/Port.  For security reasons the server should be prevented
# from connecting back to itself or initiating connections to any machine
# behind a firewall.  By default the server will block access to the following
# non-routable private IP ranges: 10.* 172.16.* 192.168.* and the loopback
# interface 127.*.  To disable this feature entirely just specify 0.0.0.0
# as the host to block.  You may however specify a custom list of IP addresses
# or ranges using glob-style wildcards provided you don't skip any numbers
# when enumerating them via 'Deny_Port_Host_<num>'.  <num> starts at 1.
;Deny_Port_Host_1 = 127.*
;Deny_Port_Host_2 = 192.168.*.*
;Deny_Port_Host_1 = 0.0.0.0

# IDNT command restricted to use by these hosts.  You may list up to 10 IP
# addresses or hostnames (i.e. BNC_HOST_10) without skipping numbers.
# You may use wildcards.
BNC_HOST_1 = my.bouncer.ip.here

# List of "devices" configured above to use for data transfers, none means
# use Device_Name as data device.
;Data_Devices            =

# Traffic Balancing: use random or round robin among configured Data_Devices
;Random_Devices          = True



###############################################################################
#################################   NETWORK   #################################
###############################################################################

ioftpd.ini continues here...

i also tried adding your args.exe as pre-cmd script, but it never gets called for some reason, so something seems wrong here. I also tried another bouncer (f-ftpbnc-v1.6) and tried to put it infront of both glftpd and ioftpd. gl works fine, but ioftpd doesn't recognize it's a bounced connection, doesn't call the pre IDNT script and just refuses the connection, because the ip of the bouncer is obviously not added to the user trying to connect.

Yil · 09-16-2010, 01:11 PM

I just tested it locally and it seems to work fine for me manually entering things...

I changed 'Login_TimeOut' to 120 since I have to type the commands. Added BNC_HOST_1 as 127.0.0.1. Then used "telnet localhost <port>" to connect to the FTP. On Vista/win7 you'll need to the enable telnet client: Start -> Control Panel -> Programs And Features -> Turn Windows features on or off -> Check Telnet Client -> Hit OK.

Then just send a manual IDNT command followed by a USER/PASS command and see if you can get that to work. At the bare minimum see if the directions I gave you setting up a PRE event with "args" on the IDNT command trigger the popup window to show up (no running as a service!). That all worked for me. Since you aren't seeing that PRE event fire it's like that command isn't even being sent at all...

The server immediately throws you off if you enter a non-routable address as the real-IP so if you are seeing rejection messages in Error.log then my best guess is that something fishy like weird line termination, stray characters, etc may have gotten into the IDNT command string if you get to specify exactly how it should be sent. My money is on the command not even being sent at all since you didn't see the PRE event fire though...

opcode · 09-16-2010, 03:59 PM

I messaged you on LN, i hope i got the right guy :-) Either way, no matter what i do i always get "500 'I': Command not understood" whereas 'I' is always the first letter of the command i enter. E.g.

Code:

220 FTP Server ready.
USER opcode
500 'U': Command not understood
QUIT
500 'Q': Command not understood

I tried the same with ftp.microsoft.com:21 and it worked like a charm

Code:

220 Microsoft FTP Service
USER anonymous
331 Anonymous access allowed, send identity (e-mail name) as password.
PASS anon@mail.com
230-Welcome to FTP.MICROSOFT.COM. Also visit http://www.microsoft.com/downloads.
230 User logged in.
QUIT
221 Thank you for using Microsoft products.

So no idea what's broken here

BoNeZz · 09-16-2010, 05:41 PM

Quote:

Originally Posted by Yil

I actually haven't been around much lately with time off and stuff so no real progress the last month or so. I need a few solid full days in a row to work on the data transfer logic re-write because it's fragile code, so just waiting for that opportunity...

PSA9: The odds of running ioFTPD on your NAS are probably zero. Most use a linux kernel because it's free. On the other hand ioFTPD doesn't use fancy windows permissions, etc so there's a pretty good chance you could use a non-windows based file share. I don't know if anyone is mounting a network drive that is really Samba/linux but there's a good chance that would work.

BoNeZz: I don't see any reason that transfer speeds should vary just because SSL is enabled provided the machine doesn't have the CPU busy. Obviously if the machine is single cored and playing a game or something the CPU is busy and encryption might take longer and that would slow down the transfer. Even a 10 year old machine can probably encrypt faster than read it's disk provided it doesn't have anything else to do though... The actual transfer logic for reading/writing to disk/socket is the same either way which means encryption time is the only variable. Check the CPU % usage with encryption turned off and on and if the rest is idle. Do you get the full bandwidth of the network connection with it disabled? Sometimes slight differences in TCP packet timings can cause significant performance drops. Think of it as slightly different routes between hosts that in theory should be the same but aren't.

hi yil

i see this problem only in machines were installed ioftpd old version ( 5.8.5 )

i think that the problem is old ssl.

how can i clean old ssl certificate and other stuff(!) if there are other file or operation to clean old ssl

because if i try to download without ssl, speed is fast, with ssl is very slow.

and if i swith with old ioftpd, download in ssl is fast, so my theory is a conflict between old and new ssl.

thanks for the support