Go Back   FlashFXP Forums > > > >

ioFTPD General New releases, comments, questions regarding the latest version of ioFTPD.

Reply
 
Thread Tools Rating: Thread Rating: 2 votes, 3.00 average. Display Modes
Old 10-30-2009, 02:25 PM   #136
paja1
Member
ioFTPD Registered User
 
Join Date: Jul 2005
Posts: 43
Default

Quote:
Originally Posted by paja1 View Post
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...
paja1 is offline   Reply With Quote
Old 10-31-2009, 11:27 PM   #137
Yil
Too much time...
FlashFXP Beta Tester
ioFTPD Administrator
 
Join Date: May 2005
Posts: 1,194
Default

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 is offline   Reply With Quote
Old 10-31-2009, 11:32 PM   #138
Yil
Too much time...
FlashFXP Beta Tester
ioFTPD Administrator
 
Join Date: May 2005
Posts: 1,194
Default

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?
Yil is offline   Reply With Quote
Old 11-01-2009, 04:24 AM   #139
mr.babek
Member
FlashFXP Beta Tester
ioFTPD Foundation User
 
Join Date: Jul 2005
Posts: 82
Default

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

/me want =)
mr.babek is offline   Reply With Quote
Old 11-01-2009, 07:04 AM   #140
paja1
Member
ioFTPD Registered User
 
Join Date: Jul 2005
Posts: 43
Default

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
paja1 is offline   Reply With Quote
Old 11-01-2009, 08:27 AM   #141
ArtX
Senior Member
FlashFXP Beta Tester
ioFTPD Foundation User
 
Join Date: Jan 2004
Posts: 301
Default

Quote:
Originally Posted by Yil View Post
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
ArtX is offline   Reply With Quote
Old 11-01-2009, 04:38 PM   #142
Mave
Member
FlashFXP Registered User
ioFTPD Foundation User
 
Join Date: Jul 2005
Posts: 43
Default

ioYIL?
WHats that?
a lol almost forgotten it :P
Mave is offline   Reply With Quote
Old 11-02-2009, 04:17 PM   #143
mantonio1965
Member
 
Join Date: Aug 2007
Posts: 37
Default

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
mantonio1965 is offline   Reply With Quote
Old 11-02-2009, 07:42 PM   #144
Yil
Too much time...
FlashFXP Beta Tester
ioFTPD Administrator
 
Join Date: May 2005
Posts: 1,194
Default

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...

Last edited by Yil; 11-02-2009 at 07:47 PM.
Yil is offline   Reply With Quote
Old 11-04-2009, 01:10 PM   #145
pion
Senior Member
 
Join Date: Feb 2006
Posts: 138
Default

Quote:
Originally Posted by Yil View Post
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.
pion is offline   Reply With Quote
Old 11-06-2009, 08:55 AM   #146
newguy
Junior Member
 
Join Date: Jul 2009
Posts: 16
Default

Quote:
Originally Posted by pion View Post
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/
newguy is offline   Reply With Quote
Old 11-06-2009, 02:38 PM   #147
pion
Senior Member
 
Join Date: Feb 2006
Posts: 138
Default

It's a practial use of it, even if it's through a tunnel broker it's just as much ipv6
pion is offline   Reply With Quote
Old 11-06-2009, 11:04 PM   #148
dr.owned
Junior Member
 
Join Date: Oct 2009
Posts: 24
Default

Quote:
Originally Posted by Yil View Post
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
dr.owned is offline   Reply With Quote
Old 11-09-2009, 04:10 PM   #149
paja1
Member
ioFTPD Registered User
 
Join Date: Jul 2005
Posts: 43
Default

Quote:
Originally Posted by Yil View Post
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!
paja1 is offline   Reply With Quote
Old 11-10-2009, 03:16 AM   #150
Yil
Too much time...
FlashFXP Beta Tester
ioFTPD Administrator
 
Join Date: May 2005
Posts: 1,194
Default

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?
Yil is offline   Reply With Quote
Reply

Tags
commands, fixed, memory, new/modified, tcl

Thread Tools
Display Modes Rate This Thread
Rate This Thread:

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT -5. The time now is 09:55 AM.

Parts of this site powered by vBulletin Mods & Addons from DragonByte Technologies Ltd. (Details)