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.

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.

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

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.

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.

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.

Thanks for the logs. I'll get back to this in about a week.

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.

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

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端口。