ioFTPD General New releases, comments, questions regarding the latest version of ioFTPD. |
10-30-2009, 02:25 PM
|
#136
|
Member
ioFTPD Registered User
Join Date: Jul 2005
Posts: 43
|
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...
|
|
|
10-31-2009, 11:27 PM
|
#137
|
Too much time...
FlashFXP Beta Tester ioFTPD Administrator
Join Date: May 2005
Posts: 1,194
|
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.
|
|
|
10-31-2009, 11:32 PM
|
#138
|
Too much time...
FlashFXP Beta Tester ioFTPD Administrator
Join Date: May 2005
Posts: 1,194
|
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?
|
|
|
11-01-2009, 04:24 AM
|
#139
|
Member
FlashFXP Beta Tester ioFTPD Foundation User
Join Date: Jul 2005
Posts: 82
|
Hey Yil,
any news on ioYIL????????
/me want =)
|
|
|
11-01-2009, 07:04 AM
|
#140
|
Member
ioFTPD Registered User
Join Date: Jul 2005
Posts: 43
|
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
|
|
|
11-01-2009, 08:27 AM
|
#141
|
Senior Member
FlashFXP Beta Tester ioFTPD Foundation User
Join Date: Jan 2004
Posts: 301
|
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
|
|
|
11-01-2009, 04:38 PM
|
#142
|
Member
FlashFXP Registered User ioFTPD Foundation User
Join Date: Jul 2005
Posts: 43
|
ioYIL?
WHats that?
a lol almost forgotten it :P
|
|
|
11-02-2009, 04:17 PM
|
#143
|
Member
Join Date: Aug 2007
Posts: 37
|
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
|
|
|
11-02-2009, 07:42 PM
|
#144
|
Too much time...
FlashFXP Beta Tester ioFTPD Administrator
Join Date: May 2005
Posts: 1,194
|
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.
|
|
|
11-04-2009, 01:10 PM
|
#145
|
Senior Member
Join Date: Feb 2006
Posts: 138
|
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.
|
|
|
11-06-2009, 08:55 AM
|
#146
|
Junior Member
Join Date: Jul 2009
Posts: 16
|
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/
|
|
|
11-06-2009, 02:38 PM
|
#147
|
Senior Member
Join Date: Feb 2006
Posts: 138
|
It's a practial use of it, even if it's through a tunnel broker it's just as much ipv6
|
|
|
11-06-2009, 11:04 PM
|
#148
|
Junior Member
Join Date: Oct 2009
Posts: 24
|
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
|
|
|
11-09-2009, 04:10 PM
|
#149
|
Member
ioFTPD Registered User
Join Date: Jul 2005
Posts: 43
|
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!
|
|
|
11-10-2009, 03:16 AM
|
#150
|
Too much time...
FlashFXP Beta Tester ioFTPD Administrator
Join Date: May 2005
Posts: 1,194
|
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?
|
|
|
Thread Tools |
|
Display Modes |
Rate This Thread |
Linear Mode
|
|
Posting Rules
|
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts
HTML code is Off
|
|
|
All times are GMT -5. The time now is 06:55 PM.
|