Hello,
I’m trying to adapt the WIZ5500 FTP server example in my project with a WI812Mj. The original FTP software did not sufficient work with the ALFTP (for me) so I moved to FileZilla. After some SW changes, I already can reliable connect the Filezilla client to my server . I get the directories and their contents also reliable. I’m also able to download short files from my server to the client. However, I’m not able to upload files from client to my server.
As soon as I setup the data path socket (SOCK_INIT with port 20, it was closed before) , I’m instantly getting state SOCK_CLOSE_WAIT , then SOCK_LAST_ACK and finally SOCK_CLOSED. With other words, I can’t reach state ESTABLISHED in case of upload. I have no idea why that happens.
I assume my information about the issue is not sufficient for analysis and I know it is a problem of my own SW exclusively. Neverthelss, does anybody have an idea what my problem with the socket states is ?
Does anybody know if there is a kind of flow diagram for FTP Server , similar to the WIZNET flow diagrams for TCP/IP Loopback or http server?
Does anybody know another working FTP server example ( in C) as for the WIZ5500
Before ESTABLISHED state, you must issue CONNECT command to the chip. I am sure you do it because CLOSE states you mention will not appear if you do not issue connect. It seems the issue is somewhere in the communication and one of the devices (WIZ or server) terminates the conneciton. The best way to see what is going on is to use Wireshark to capture packets and see what is being exchnaged within the respective TCP session. Install Wireshark on the server (if it is possible).
Sure I do CONNECT . I also watched the TCP/IP transfer with Wireshark, installed
on client.( My FTP server is located on a little board with an ARM7 CPU).
However, I (I’m just a hobbyist) can not see a basic difference between the
result in case request of LIST/MLSD and STORE by the client.
The green comments on top are debug information by my server. It shows the
instant disconnect of the Data socket.
It seem the client starts upload of the short file in this example (FTP-Data).
In the wireshark log picture (you’d better upload log itself) you can see that WIZ (19) connects to server (170), then server sends some data (211 bytes) and then server says that it has nothing more to say almost immediately. Am I mistaken that FTP data session requires two concurrent connections?
That’s right. Of cause, I’m using two sockets , one with port 21 (Command-Socket)and another with port 20 (Data-Socket). The basic example is the WIZ5500 Server example which uses the same settings.
The Command socket works correct and as expected. Just Data Socket makes problems in case of upload from client to server.
You will make one step further if look into the packet at port 20 to see what server actually says to client before closing the connection. I wonder if it says something like “authentication failed” and exits. I do not recall exact protocol (was implementing [writing code for] FTP once or twice), but you got the idea.
You indirectly gave me possibly a hint about my problem!
It seems, checking ESTABLISHED will not be done on time in my case. It is different
from the WIZ5500 example. So it seems in case of very short data transfers , I miss
this state. I found longer files can be transferred!
However, I still do not understand what causes socket to close without a command.
Could it be there is a kind of “auto close” after last FTP-Data transmission ? I don’t know.
I’ll now try to improve speed of checking socket states.
I do not understand. What is “on time”? If you talk about 15 seconds delay, then probably you are right, control connection may expire. But if you talk about milliseconds, then it should not be the cause.
So what server is saying in the packet before it closes the connection? Do not perform guesses, look into evidence given you already have them.
I do not talk about the Command Port 21 , I just talk about Data Port 20 connection.
Please refer to the first picture I sent. The Client (170) starts short Data transmission (line 10) on port 20 (FTP-D…) to the Server (19) and immediately ( line 11) the Client sends [FIN][ACK] to the Server (19) also on port 20. Port 20 connection for STOR ends with line 14 on TCP level . This happens within around 20ms , if I’m not wrong. At least that’s my interpretation.
I still “assume” the socket for port 20 will be closed anyhow in between or after line 12 and 14.
My apologies, it is me who messed the things. I thought that module is client, but in your case it is server.
So: .19 is FTP server (WIZ) and .170 is FTP client. And server (19) connects to the client (170), and then client (170) sends 211 bytes of data and almost immediately finishes (packet #11).
Am I correct here? Or I have again messed something?
But then it means that client closes the connection - without receiving anything material - within 26 microseconds! Maybe it has just sent all the data within these 211 bytes - what is the actual data size?
So literally the client sends the data required, thus does its job properly. And now it is server’s task to write this data into its file system. The server must catch the following events - through polling or through interrupts: connection establishment, data receive, and closure. I do not know how exactly your implementation does it, but in general it is achieved by reading data from socket and writing it to the file, even if socket is in close_wait there could still be data remaining in the RX buffer. Maybe it is actually your mistake - if you see that connection is not established (any more), you just close the socket? If yes, then it is incorrect approach - when you see connection not established any more, you must check for data once more to ensure there’s no more data in the buffer waiting to be flushed.
I absolutely understand what you are saying. BUT, I never see state ESTABLISHED. So there is no
implicite state “Not Established anymore”. Of cause, I could check if data are in input buffer as soon
as state SOCK_CLOSE_WAIT and STOR command is detected. Then I could read out and store data first before disconnect data socket. But I never saw such a request, even in the WIN5500 example.
This MAY happen because your application is slow. Established state only lasts for a couple of microseconds, and as soon as W5500 receives FIN, its state goes to FIN_WAIT.
In other words, you should look for state ESTABLISHED (0x17) as well as other states following it (>0x17). State 0x17 means that connection is established and you flush data until state changes to >0x17, but if you see state >0x17, then you just check for data and terminate. In any case state >0x17 means there WAS a connection established for some time, and you have had active TCP session. Check datasheet, it contains codes beyond 0x17 (SOCK_ESTABLISHED).
So in conclusion I must say that everything seems to work properly in your setup, the only mistake you made is thinking that FIN_WAIT (0x18), SOCK_CLOSE_WAIT (0x1c) is something extraordinary (and most probably was doing wrong things seeing it).
By the way, as a workaround to the speed problem - it is possible that if your MCU is very slow and socket goes in closed state when you arrive to checking it - use socket interrupt state bits. The appropriate bits of Sn_IR will get set (e.g. RECV and DISCON), and seeing these bits set means you had respective activity on the socket. But you must not forget to clear these bits when finishing with the session (and not forget to enable their operation).
Let me know if there’s still something unclear on how it works and what you should do.
