Re: [twsocket] 501 CannotRETR.Error-SocketwithicsFtpServ(V6forDelphi7)
Francois PIETTE wrote:
The server can't be sure the file has been sent properly before the
connection is properly closed.
That's true, however he knows that he sent all, he cannot know
whether it all received at the peer. So I think the response may be
sent after Data.ShutDown(1) at once, but not 100% sure.
Anyway that doesn't seem to be the problem in this case.
--
Arno Garrels [TeamICS]
http://www.overbyte.be/eng/overbyte/teamics.html
So it can't send the 226 answer before
the connection close is complete.
--
[EMAIL PROTECTED]
The author for the freeware multi-tier middleware MidWare
The author of the freeware Internet Component Suite (ICS)
http://www.overbyte.be
- Original Message -
From: Arno Garrels [EMAIL PROTECTED]
To: ICS support mailing twsocket@elists.org
Sent: Friday, April 20, 2007 6:05 PM
Subject: Re: [twsocket] 501 Cannot
RETR.Error-SocketwithicsFtpServ(V6forDelphi7)
Patrick Schmidt - STEP Software GmbH wrote:
Possibly G6 works around that, have you tried Serv-U as well as
FileZilla server? If they all handle your client correctly we have
to find a workaround.
I tried Filezilla Server and Serv-U. Both worked, see log.
Ohh, that's very interesting!
I logged two sequences with Ethereal, both Ftptst demo,
one against FtpSrv demo another against Serv-U.
(Only 1 byte was transfered, so each file has only 15 lines)
http://www.duodata.de/misc/ICSFtpSrv-DataClose1.pcap
http://www.duodata.de/misc/Serv-U-DataClose1.pcap
From these logs it seems that Serv-U doesn't wait for the
client until it closes the connection but sends 226 File sent ok
at once.
This might be the reason why your client fails with the ICS
server, though I guess that your client is not RFC conform.
Francois and all what do you think, should we tweak the TFtpSrv
to send the response earlier?
May i send you my captured .pcap - file (148 KB) ?
Yes, please send it.
--
Arno Garrels [TeamICS]
http://www.overbyte.be/eng/overbyte/teamics.html
best regards
Patrick Schmidt
- Original Message -
From: Arno Garrels [EMAIL PROTECTED]
To: ICS support mailing twsocket@elists.org
Sent: Friday, April 20, 2007 1:56 PM
Subject: Re: [twsocket] 501 Cannot RETR.
Error -SocketwithicsFtpServ(V6forDelphi7)
Patrick Schmidt - STEP Software GmbH wrote:
I bet the delay starts after the server called Data.ShutDown(1)
in FtpSrv.pas, TFtpServer.WMFtpSrvCloseData, can you please
set a breakpoint there and check whether that this is true?
I'm not shure, I set a breakpoint to this row:
Data.ShutDown(1); { Wilfried 24/02/04 }
but debugging goes on (leaves the procedure)
Can you confirm that the delay happens somewhere after
Data.ShutDown(1)? This meant that the FTP client doesn't handle the
shutdown sequence correctly but expects that the server will close
the data connection. Since that never happens the client
application drops the connection after its own timeout has expired.
A network sniffer like Ethereal (now WireShark) could prove that.
At the bottom of the page below you'll find a nice table that
explains the bidirectional socket shutdown sequence step by step:
http://msdn2.microsoft.com/en-us/library/ms738547.aspx
Note that in non-passive mode the server represents the client
side!
If I try other client (eg Filezilla) it
works and if i try other
server (G6 FTP Server) with the console it works, too! :-(
Possibly G6 works around that, have you tried Serv-U as well as
FileZilla server? If they all handle your client correctly we have
to find a workaround.
--
Arno Garrels [TeamICS]
http://www.overbyte.be/eng/overbyte/teamics.html
I also tried your Sample-Application (OverbyteIcsFtpSrv.dpr), it
behaves the same way.
snip
192.168.200.179 LIST
192.168.200.179 150 Opening data connection for directory list.
Here occurs the delay 192.168.200.179 501 Cannot RETR. Error -
Connection aborted (#10053)
! 192.168.200.179 Data session closed. Error #10053
192.168.200.179 PORT 192,168,200,179,4,128
192.168.200.179 200 Port command successful.
snip
If i use another FTP-Server the log looks like this:
snip
LIST
150 Opening data connection for directory list.
226 File sent ok.
PORT 192,168,200,179,4,145
200 Port command successful.
snip
Patrick Schmidt
- Original Message -
From: Arno Garrels [EMAIL PROTECTED]
To: ICS support mailing twsocket@elists.org
Sent: Wednesday, April 18, 2007 7:17 PM
Subject: Re: [twsocket] 501 Cannot RETR. Error - Socket
withicsFtpServ(V6forDelphi7)
Patrick Schmidt - STEP Software GmbH wrote:
Later you change to that directory and request a dir list. The
server somewhat hang creating the directory list. After 2
minutes the connection is
closed (probably an inactivity timeout at server side).
After this time (and error-message) the client gets the list and
loads every file in the list!
That's strange...
I bet the delay starts after the server
Re: [twsocket] 501 CannotRETR.Error-SocketwithicsFtpServ(V6forDelphi7)
however the server obviously didn't call Data.ShutDown(1)
for some reason?
One reason you could no see the shutdown packet is that the receiver stopped
to receive data and the TCP window is full.
btw: What do you use to format pcap data so that it is more readble ? (I
don't use Ethereal, I use LanWatch which nicely show data captured and
decoded headers).
--
Contribute to the SSL Effort. Visit http://www.overbyte.be/eng/ssl.html
--
[EMAIL PROTECTED]
http://www.overbyte.be
- Original Message -
From: Arno Garrels [EMAIL PROTECTED]
To: ICS support mailing twsocket@elists.org
Sent: Friday, April 20, 2007 7:04 PM
Subject: Re: [twsocket] 501
CannotRETR.Error-SocketwithicsFtpServ(V6forDelphi7)
May i send you my captured .pcap - file (148 KB) ?
Yes, please send it.
Got it, uploaded a filtered version so others can take
a look at it as well:
http://www.duodata.de/misc/Patric-Flt1.pcap
This log shows that after the LIST command data was sent,
however the server obviously didn't call Data.ShutDown(1)
for some reason? Subsequent RETR however worked fine, is
this with latest ICS-Beta download available?
--
Arno Garrels [TeamICS]
http://www.overbyte.be/eng/overbyte/teamics.html
Arno Garrels wrote:
Patrick Schmidt - STEP Software GmbH wrote:
Possibly G6 works around that, have you tried Serv-U as well as
FileZilla server? If they all handle your client correctly we have
to find a workaround.
I tried Filezilla Server and Serv-U. Both worked, see log.
Ohh, that's very interesting!
I logged two sequences with Ethereal, both Ftptst demo,
one against FtpSrv demo another against Serv-U.
(Only 1 byte was transfered, so each file has only 15 lines)
http://www.duodata.de/misc/ICSFtpSrv-DataClose1.pcap
http://www.duodata.de/misc/Serv-U-DataClose1.pcap
From these logs it seems that Serv-U doesn't wait for the
client until it closes the connection but sends 226 File sent ok
at once.
This might be the reason why your client fails with the ICS
server, though I guess that your client is not RFC conform.
Francois and all what do you think, should we tweak the TFtpSrv
to send the response earlier?
May i send you my captured .pcap - file (148 KB) ?
Yes, please send it.
--
Arno Garrels [TeamICS]
http://www.overbyte.be/eng/overbyte/teamics.html
best regards
Patrick Schmidt
- Original Message -
From: Arno Garrels [EMAIL PROTECTED]
To: ICS support mailing twsocket@elists.org
Sent: Friday, April 20, 2007 1:56 PM
Subject: Re: [twsocket] 501 Cannot RETR.
Error -SocketwithicsFtpServ(V6forDelphi7)
Patrick Schmidt - STEP Software GmbH wrote:
I bet the delay starts after the server called Data.ShutDown(1)
in FtpSrv.pas, TFtpServer.WMFtpSrvCloseData, can you please
set a breakpoint there and check whether that this is true?
I'm not shure, I set a breakpoint to this row:
Data.ShutDown(1); { Wilfried 24/02/04 }
but debugging goes on (leaves the procedure)
Can you confirm that the delay happens somewhere after
Data.ShutDown(1)? This meant that the FTP client doesn't handle the
shutdown sequence correctly but expects that the server will close
the data connection. Since that never happens the client application
drops the connection after its own timeout has expired.
A network sniffer like Ethereal (now WireShark) could prove that.
At the bottom of the page below you'll find a nice table that
explains the bidirectional socket shutdown sequence step by step:
http://msdn2.microsoft.com/en-us/library/ms738547.aspx
Note that in non-passive mode the server represents the client side!
If I try other client (eg Filezilla) it
works and if i try other
server (G6 FTP Server) with the console it works, too! :-(
Possibly G6 works around that, have you tried Serv-U as well as
FileZilla server? If they all handle your client correctly we have
to find a workaround.
--
Arno Garrels [TeamICS]
http://www.overbyte.be/eng/overbyte/teamics.html
I also tried your Sample-Application (OverbyteIcsFtpSrv.dpr), it
behaves the same way.
snip
192.168.200.179 LIST
192.168.200.179 150 Opening data connection for directory list.
Here occurs the delay 192.168.200.179 501 Cannot RETR. Error -
Connection aborted (#10053)
! 192.168.200.179 Data session closed. Error #10053
192.168.200.179 PORT 192,168,200,179,4,128
192.168.200.179 200 Port command successful.
snip
If i use another FTP-Server the log looks like this:
snip
LIST
150 Opening data connection for directory list.
226 File sent ok.
PORT 192,168,200,179,4,145
200 Port command successful.
snip
Patrick Schmidt
- Original Message -
From: Arno Garrels [EMAIL PROTECTED]
To: ICS support mailing twsocket@elists.org
Sent: Wednesday, April 18, 2007 7:17 PM
Subject: Re: [twsocket] 501 Cannot RETR. Error - Socket
withicsFtpServ(V6forDelphi7)
Patrick Schmidt - STEP Software GmbH wrote:
Later you change to that directory and request a dir list. The
server somewhat
