ioFTPD v7.0.3 Released - Page 10

paja1 · 10-30-2009, 02:25 PM

Quote:

Originally Posted by paja1

Is there any other way to create dump for you? I'll do anything to help make it more stable again.

Ok, i'we just installed Windows Debugging tools.. when it hangs again i'll start to send you minidumps...

Yil · 10-31-2009, 11:27 PM

win7 (at least on x64) update: It appears that "site makecert" works, but for whatever reason the newly created certificate cannot be found by the ftp server until you restart it. That's not the behavior on XP, etc... Since this is a one time thing anyway during setup, it's not a big deal, but did want to bring it to your attention.

Yil · 10-31-2009, 11:32 PM

Carpo: IPv6 support is actually a non-trivial change. I have little idea on how IPv6 works in practice. How do you implement user hostmasks like *@192.168.1.* or 1.2.3.* ? Do ISP's get contiguous ranges of addresses to hand out that vary at the end?

mr.babek · 11-01-2009, 04:24 AM

Hey Yil,
any news on ioYIL????????

/me want =)

paja1 · 11-01-2009, 07:04 AM

H Yil,

i'm experiencing another "ioftpd hang" 7.0.3 again... this time is debugger not able attach to process...

Code:

Break-in sent, waiting 30 seconds...
WARNING: Break-in timed out, suspending.
         This is usually caused by another thread holding the loader lock
(60c.860): Wake debugger - code 80000007 (first chance)
eax=001596f0 ebx=00000000 ecx=0000001e edx=00000000 esi=00000000 edi=00000058
eip=7c82860c esp=0012fbc8 ebp=0012fc30 iopl=0         nv up ei pl zr na pe nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00000246

ArtX · 11-01-2009, 08:27 AM

Quote:

Originally Posted by Yil

Carpo: IPv6 support is actually a non-trivial change. I have little idea on how IPv6 works in practice. How do you implement user hostmasks like *@192.168.1.* or 1.2.3.* ? Do ISP's get contiguous ranges of addresses to hand out that vary at the end?

ATM i was just messing about with it internally, as for the isp end, until they start using it it would be hard to say how they will do it. Internally ( direct, which is how im doing it) i don't think it would be an issue and im assuming you could use the shortened version of the ipv6 address *@fe80:

some long string)

eg : fe80:0:0:0:0:0:c0a8:101 becomes fe80::c0a8:101

As the ipv4 range of address's are running out and is expected to run out in 2010/2011 i think i would start looking at ipv6 now just so i understand it, and of course have my best ftpd app supporting it

http://www.subnetonline.com/pages/su...-converter.php - is what i have been using to try and work out what the correct address would be, hopefully it will help others

Mave · 11-01-2009, 04:38 PM

ioYIL?
WHats that?
a lol almost forgotten it :P

mantonio1965 · 11-02-2009, 04:17 PM

great job, yil. but could you please update the links to the faqs you mention in the entry description? they're all dead.

regards, mantonio

Yil · 11-02-2009, 07:42 PM

paja1: "This is usually caused by another thread holding the loader lock." HA! Since I don't believe it's possible to manipulate the loader lock directly and ioFTPD is not a dll with an initialize routine with strict restrictions on what can be done during initialization, I claim it shouldn't be ioFTPD's fault

Not sure what it is doing that is triggering the bug, but I'll keep on trying to squash it and re-writing the way it listens for incoming control connections is one of two ideas to try... [update: this is the classic lockup bug in all it's annoying glory... sad to see it's not gone as this is confirmation].

Which 3rd party scripts are you using? The other idea I've recently thought of is that I need to protect TCL's socket and process creation much like I do in the server itself. I'm guessing IMDB lookups, or calls to zip,rar executables might make the problem more likely so if you are using them it might make sense. If you have a simple server then it's most likely not that...

mantonio: Hmm, good point...

mave: pfft! I got sidetracked writing all these nifty TCL scripts to do resolving, etc and then started finding other people wanted these features for scripts and figured I'd best add them into the server

Good news for virtual dir coders. I'm 90% done on allowing you to enable an option to make ioFTPD preserve symlinks in paths. This is important because you can now link out of virtual dirs and CDUP will return you back to the virtual dir. PWD also reports the correct path for clients that query it after directory changes to track where you are. I'm not done testing the side effects of this, and will probably need some help there which is why this is an option. TCL [resolve]ing works as before, but new arguments to it allow you to get the new behavior. I'm still not sure what to do with $pwd though. I'm thinking I should force the path to be resolved completely as before, and add a new variable for people who want the preserved symlink'd path. I just don't know what scripts might break if the path can't be manipulated the way it was before or that multiple paths mean the same real directory...

pion · 11-04-2009, 01:10 PM

Quote:

Originally Posted by Yil

Carpo: IPv6 support is actually a non-trivial change. I have little idea on how IPv6 works in practice. How do you implement user hostmasks like *@192.168.1.* or 1.2.3.* ? Do ISP's get contiguous ranges of addresses to hand out that vary at the end?

You have one external part, and one local part of the address. If you have an external tunnel broken, or isp, you get an adress which is put in front of your local adressspace. The local adresses is generated at your local machine (often based on mac address), and broadcasted to the ipv6 advertisement daemon.

Example; You set up a gateway to an external tunnel broken, put up radvd or similar as router advertisement daemon. Then you get a prefix from the tunnel broker which will be the first part of the address. Then all external calls to that prefix first hit your router daemon, which then sends the data to the correct 'internal' adress.

newguy · 11-06-2009, 08:55 AM

Quote:

Originally Posted by pion

You have one external part, and one local part of the address. If you have an external tunnel broken, or isp, you get an adress which is put in front of your local adressspace. The local adresses is generated at your local machine (often based on mac address), and broadcasted to the ipv6 advertisement daemon.

Example; You set up a gateway to an external tunnel broken, put up radvd or similar as router advertisement daemon. Then you get a prefix from the tunnel broker which will be the first part of the address. Then all external calls to that prefix first hit your router daemon, which then sends the data to the correct 'internal' adress.

Well that's not real IPv6 imo but just faking stuff.
What is ment is real IPv6 http://www.ipv6.org/

pion · 11-06-2009, 02:38 PM

It's a practial use of it, even if it's through a tunnel broker it's just as much ipv6

dr.owned · 11-06-2009, 11:04 PM

Quote:

Originally Posted by Yil

Good news for virtual dir coders. I'm 90% done on allowing you to enable an option to make ioFTPD preserve symlinks in paths. This is important because you can now link out of virtual dirs and CDUP will return you back to the virtual dir. PWD also reports the correct path for clients that query it after directory changes to track where you are. I'm not done testing the side effects of this, and will probably need some help there which is why this is an option. TCL [resolve]ing works as before, but new arguments to it allow you to get the new behavior. I'm still not sure what to do with $pwd though. I'm thinking I should force the path to be resolved completely as before, and add a new variable for people who want the preserved symlink'd path. I just don't know what scripts might break if the path can't be manipulated the way it was before or that multiple paths mean the same real directory...

good news

thank you for your work

paja1 · 11-09-2009, 04:10 PM

Quote:

Originally Posted by Yil

paja1: "This is usually caused by another thread holding the loader lock." HA! Since I don't believe it's possible to manipulate the loader lock directly and ioFTPD is not a dll with an initialize routine with strict restrictions on what can be done during initialization, I claim it shouldn't be ioFTPD's fault

Not sure what it is doing that is triggering the bug, but I'll keep on trying to squash it and re-writing the way it listens for incoming control connections is one of two ideas to try... [update: this is the classic lockup bug in all it's annoying glory... sad to see it's not gone as this is confirmation].

Which 3rd party scripts are you using? The other idea I've recently thought of is that I need to protect TCL's socket and process creation much like I do in the server itself. I'm guessing IMDB lookups, or calls to zip,rar executables might make the problem more likely so if you are using them it might make sense. If you have a simple server then it's most likely not that...

Hi Yil, firstly thanks for your investigation.... but to the point.
Yes, I'm using http package.

Code:

package require http

proc get_url {url} {
  set h [http::geturl $url]
  set r [http::data $h]
  http::cleanup $h
  return $r
}

An http request is called after each login. But was called in version 6.* as well, without any problem at all.

The other thing i'm doing is calling "post-processing" executable like this:

Code:

iputs -nobuffer "Executing postprocessing..."
exec $cfg_postAction [string map {/ \\} $dir]
iputs -nobuffer "Done!"

... and yes, you are probably right, because ftp sometimes refuse to connect to http server.. or hangs after calling this external executable.

But i really don't think i;m doing something wrong... do i?

Do you won't more dumps from me? Or any additional files, info?

Thanks!

Yil · 11-10-2009, 03:16 AM

paja1: I don't think you are doing anything wrong. I'm just trying to determine what separates people who are seeing this problem from those who aren't. Earlier indications showed that multi-core/multi-cpu machines were far more likely to have this issue (which means a race condition) and that w2k3 seemed like to make it more likely as well. I'm trying to finish up a bunch of changes for the folks playing with virtual directories and then implement the few changes I mentioned which hopefully will fix/reduce the problem further.

I'm also going to have to go back and double check, but it's possible that the TCL socket code changed internally when the TCL libraries were updated. If that is so then it's possible this is just highlighting the flaw more... I'll have to check on that since you said v6 didn't seem to have this issue in your configuration. Any chance you could try disabling the HTTP and/or EXEC routines for a bit to see if that improves stability?