Problems with WIZ812MJ FTP implementation

Question

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 Thank you very much. Regards Robert

Eugeny · Answer

roty: 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. 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).

Eugeny · Answer

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?

roty · Answer

Eugeny: 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? Thank you again for looking at the problem. 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. Regards Robert

Eugeny · Answer

roty: 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.

roty · Answer

Eugeny , 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. Thank you very much for your help. Robert

Eugeny · Answer

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.

roty · Answer

Excuse me if I’m not as precise as I should be. 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. Regards Robert

Eugeny · Answer

roty: Excuse me if I’m not as precise as I should be. 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?

roty · Answer

Eugeny: Am I correct here? Or I have again messed something? That’s absolutely correct. I’m not an expert and it could be I burk up the wrong tree! But don’t waste your time with me. Robert

Eugeny · Answer

roty: That’s absolutely correct. 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?

roty · Answer

Eugeny: what is the actual data size? File is just 211 byte long! Longer (maybe > 2000 byte) seems to work!

Eugeny · Answer

roty: File is just 211 byte long! Longer (maybe > 2000 byte) seems to work! 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.

roty · Answer

Eugeny: 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. Thanks for explaining. 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. I’ll do that if it is a required procedure.

Eugeny · Answer

roty: I never see state ESTABLISHED 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.

roty · Answer

Great answer. I’ll follow your advice and I’ll modify my code as soon as possible according your decription. Thanks a lot. I really appreciate you share your knowledge with novice. Best regards Robert