2010/3/26 Sai Pullabhotla sai.pullabho...@jmethods.com:
David,
I just re-read your comments towards the end of your previous email:
I wonder if we are suffering a similar problem in any other cases; if
it was so, we might need to delay the opening of the ServerSocket
until the LIST (or GET
Hi folks,
given that I started this interesting thread :-) I'll add a few
considerations:
1\ Priority of passive port sharing ehnancement: Niklas survey shows that we
are indeed in good company here, but it's problably worth having a better
look at this anyway, there might be good technical
On Fri, Mar 26, 2010 at 9:50 AM, Fred Moore fred.moor...@gmail.com wrote:
1\ Priority of passive port sharing ehnancement: Niklas survey shows that we
are indeed in good company here, but it's problably worth having a better
look at this anyway, there might be good technical reasons that led
The wait appears to be the culprit. I've opened a new case for the
quick fix (to error out immediately) and attached a patch. Could you
or Fred test this patch with the test case and let us know the result?
The JIRA issue/patch is available at
https://issues.apache.org/jira/browse/FTPSERVER-360.
2010/3/24 Niklas Gustavsson nik...@protocol7.com:
On Wed, Mar 24, 2010 at 6:03 PM, Fred Moore fred.moor...@gmail.com wrote:
we found an issue related to requestPassivePort() which may lead to an
unresponsive V1.0.4 FTP (or FTP/S) Server, this issue can be reproduced.
Just so we are all on the same page -
Do you think the issue is with the LIST command, or the code that
creates passive data connection? Could you briefly explain some of the
issues that made you think it should be rewritten, so everyone gets a
chance to evaluate?
Thanks.
Regards,
Sai
Interesting! Could you send the patch without whitespace/formatting
changes, would make it much easier to follow.
/niklas
On Thu, Mar 25, 2010 at 1:46 PM, David Latorre dvl...@gmail.com wrote:
hello Sai,
I didn't have time to fully review the code but i made these nearly
random changes in
I've not looked at the patch that supports concurrent data connections
on a single passive port, but I've some serious doubts as to if it is
even legitimate to have such support and if we can gracefully handle
such scenario. Here is an example scenario -
1. Client A has more than one session
On Thu, Mar 25, 2010 at 2:30 PM, Sai Pullabhotla
sai.pullabho...@jmethods.com wrote:
I've not looked at the patch that supports concurrent data connections
on a single passive port, but I've some serious doubts as to if it is
even legitimate to have such support and if we can gracefully handle
If we reject simultaneous data connections from a given source IP,
What would be the implications when connections are in fact from two
different clients, but they all go through the same router (in a
typical work/home network)? The FTP server would see the public IP of
the router, isn't it?
Not sure what you meant by -
In that case, we would basically get what we would have in 1.0.x.
1.0.x never sends the same port number to two different clients, isn't it?
Regards,
Sai Pullabhotla
On Thu, Mar 25, 2010 at 8:46 AM, Niklas Gustavsson nik...@protocol7.com wrote:
On Thu, Mar 25,
Yeah, it does makes sense. Just to make sure my understanding is correct -
The patch we have on file -
(1) would always first try to get an unused passive port. If it does,
everything is good and works the same old way.
(2) If (1) fails, it would try to get a port that is not shared by the
same
On Thu, Mar 25, 2010 at 3:26 PM, Sai Pullabhotla
sai.pullabho...@jmethods.com wrote:
(1) would always first try to get an unused passive port. If it does,
everything is good and works the same old way.
(2) If (1) fails, it would try to get a port that is not shared by the
same source/client
I think so. Overall, the idea is pretty cool, but too scary. You
mentioned that most FTP servers support this feature, but I could find
any servers highlighting this feature. The Miscrosoft IIS
documentation specifically says to pick a port range that matches with
the number of concurrent data
On Thu, Mar 25, 2010 at 7:42 PM, Sai Pullabhotla
sai.pullabho...@jmethods.com wrote:
I think so. Overall, the idea is pretty cool, but too scary. You
mentioned that most FTP servers support this feature, but I could find
any servers highlighting this feature.
I should not have said most since
Hmmm, if that's the case, it should be a low priority task for sure.
Regards,
Sai Pullabhotla
On Thu, Mar 25, 2010 at 2:06 PM, Niklas Gustavsson nik...@protocol7.com wrote:
On Thu, Mar 25, 2010 at 7:42 PM, Sai Pullabhotla
sai.pullabho...@jmethods.com wrote:
I think so. Overall, the idea
Niklas, All,
we found an issue related to requestPassivePort() which may lead to an
unresponsive V1.0.4 FTP (or FTP/S) Server, this issue can be reproduced.
http://issues.apache.org/jira/browse/FTPSERVER-359 contains full description
of the symptoms and a minimalist java client and server to
On Wed, Mar 24, 2010 at 6:03 PM, Fred Moore fred.moor...@gmail.com wrote:
we found an issue related to requestPassivePort() which may lead to an
unresponsive V1.0.4 FTP (or FTP/S) Server, this issue can be reproduced.
http://issues.apache.org/jira/browse/FTPSERVER-359 contains full description
18 matches
Mail list logo
