Topic "Couldn't Start A File Retrieve"

Author Message
Aker

Guest


When I use WinSCP to access a UNIX machine by FTP,
file retrieve can be performed normally, start by
a PASV command.

But when I use WinSCP to access my own Embedded
system by FTP, while the list command can be performed
normally but the file retrieve command can not. WinSCP
start to connect the 21(FTP)port through another port
as it already has a control link.In normal procedure,
it should send a PASV command instead of doing that.

Attachments below show the wireshark capture of the
two different behaviors.

I wonder what makes WinSCP do file retrieve in the two
different ways.

当我使用WinSCP访问标准Unix FTP服务的时候可以正常的使用下载功能下载文件
但是使用WinSCP访问我自己编写的嵌入式系统时,FTP的List指令正常执行了,但是下载功能没有正常执行。
本来下载功能会由客户端发起一个PASV命令然后紧接一个RETR命令,在Unix机器的通讯抓包中也可以看到这点
但是在WinSCP连接到我自己的嵌入式系统FTP服务之后,触发下载功能后WinSCP并没有发送PASV命令或者RETR命令或者PORT命令
而是使用了另一个TCP端口来连接已经于FTP控制套接字建立连接的服务器21端口。

这个行为很诡异,不知道哪位大神可以指点一下为什么WinSCP在下载操作时不发送PASV命令而是转而用另一个端口去连接21端口。
wrong2.PNG (63.78 KB)

Description: File retrieve do not happen

wrong2.PNG

normal.PNG (82.44 KB) [Download]

Description: A Normal List & File Retrieve

Advertisements
martin◆
[View user's profile]
Site Admin
Joined: 2002-12-10
Posts: 27059
Location: Prague, Czechia
Please attach a full session log file for both servers (using the latest version of WinSCP).

To generate the session log file, enable logging, log in to your server and do the operation and only the operation that causes the error. Submit the log with your post as an attachment. Note that passwords and passphrases not stored in the log. You may want to remove other data you consider sensitive though, such as host names, IP addresses, account names or file names (unless they are relevant to the problem). If you do not want to post the log publicly, you can mark the attachment as private.
Aker

Guest


martin wrote:
Please attach a full session log file for both servers (using the latest version of WinSCP).

To generate the session log file, enable logging, log in to your server and do the operation and only the operation that causes the error. Submit the log with your post as an attachment. Note that passwords and passphrases not stored in the log. You may want to remove other data you consider sensitive though, such as host names, IP addresses, account names or file names (unless they are relevant to the problem). If you do not want to post the log publicly, you can mark the attachment as private.


Here are the Log files and a compressed file of the WireShark capture files.

IP:172.16.214.190 is my own embedded system
IP:172.16.214.200 is a standard UNIX machine

Download without the "transfer in background" option gose well with my system
When the "transfer in background" option is checked, WinSCP start to connect my system port 21 through another port while the control link has already established with port 21.A tcp SYN frame is sent from client machine to my embedded system port 21.

In the log file of the standard UNIX machine, the background transfer also logged that WinSCP connected the machine fist, but I didn't see a tcp SYN frame sent from WinSCP to the machine port 21 in the capture of WireShark.
WireSharkCaptures.zip (5.76 KB) [Download]

Description: WireShark Capture files of the frames sent between WinSCP and the two systems

root@172.16.214.200.log (19.48 KB) [Download]

Description: WinSCP log file of connecting to a standard UNIX machine and download a file without the "transfer in background" option checked, and then download it again with the background option checked.

root@172.16.214.190.log (6.04 KB) [Download]

Description: WinSCP log file of connecting to my own embedded system and download a file without the "transfer in background" option checked, and then download it again with the background option checked.

martin◆
[View user's profile]
Site Admin
Joined: 2002-12-10
Posts: 27059
Location: Prague, Czechia
Thanks for the logs. I'll get back to this in about a week.
_________________
Martin Prikryl
martin◆
[View user's profile]
Site Admin
Joined: 2002-12-10
Posts: 27059
Location: Prague, Czechia
OK, so when the question is about background transfer actually, I'm not sure, what the supposed problem is.

Everything looks ok to me. Except that the embedded system refuses the second (background) connection. I cannot tell why.
Guest




martin wrote:
OK, so when the question is about background transfer actually, I'm not sure, what the supposed problem is.

Everything looks ok to me. Except that the embedded system refuses the second (background) connection. I cannot tell why.


There are 2 problems:

1. Why background transfer start to connect the embedded system port 21 since the control link have already taken port 21?

In the wireshark capture, timeline of the embedded system as follow:

1) WinSCP control port 2341 establish a control link to embedded system port 21
2) Some FTP commands to show the folder view
3)
3) When user start a transfer in background WinSCP use port 2344 send a SYN frame to embedded system port 21.

TCP ports can only establish a connection with one port a time. If port 2341 has connected to port 21, any SYN frame
will be refused naturally before 2341 end the link with port 21.

2. What makes the difference of WinSCP choose between 'send a PASV command' and 'connect port 21 again'?

When user start a transfer in background to download the UNIX system's file, WinSCP send a PASV command.
When user start a transfer in background to download the embedded system's file, WinSCP use port 2344 to connect port 21.

User takes the same activity, but WinSCP response it with different behavior.
martin◆
[View user's profile]
Site Admin
Joined: 2002-12-10
Posts: 27059
Location: Prague, Czechia
Anonymous wrote:
1. Why background transfer start to connect the embedded system port 21 since the control link have already taken port 21?

You cannot have multiple transfers (data connections) for one control connection with FTP. For each transfer, you need to have a dedicated control connection.
Aker

Guest


martin wrote:
Anonymous wrote:
1. Why background transfer start to connect the embedded system port 21 since the control link have already taken port 21?

You cannot have multiple transfers (data connections) for one control connection with FTP. For each transfer, you need to have a dedicated control connection.


Then what about the second question, really wonder what makes the difference.
Aker

Guest


martin wrote:
Anonymous wrote:
1. Why background transfer start to connect the embedded system port 21 since the control link have already taken port 21?

You cannot have multiple transfers (data connections) for one control connection with FTP. For each transfer, you need to have a dedicated control connection.


Figured out the first problem, the embedded system just implemented a RAW TCP stack, and have no SOCKET interface.
Multiple connections to port 21 is not achiveable since the RAW TCP stack only set one TCP port bind to 21, if one connection take the port, no port left to response to feather connections.
martin◆
[View user's profile]
Site Admin
Joined: 2002-12-10
Posts: 27059
Location: Prague, Czechia
Aker wrote:
Then what about the second question, really wonder what makes the difference.

In the session to *nix server, you have downloaded trdp_chan_conf.txt first on foreground session. There no such download in the session for embedded system.
Advertisements

You can post new topics in this forum

Search

What is WinSCP?

It is award-winning SFTP client, SCP client, FTPS client and FTP client integrated into one software program for file transfer to FTP server or secure SFTP server. [More]

And it's free!

Donate

About donations

$9   $19   $49   $99

About donations

Recommend

WinSCP Privacy Policy

WinSCP License