I am trying to find a way to regularly export backup files from my router (5.16) to a server on the LAN the router is connected to.
The server has a working FTP server installed, and I have tried the router FTP client, but that seems quite broken because it always responds with “Unrecognized FTP server response” to valid connection announcements from the FTP server.
Is there some trick to getting the FTP client to work properly, or is there some other method I can use to have the router initiate an upload to the server?
Yes, you would think that would work, but fetch with mode=ftp and upload=yes is not robust and does not appear to deal properly with valid ftp server connect response texts. It gives “Unrecognized FTP server response” each time. I suspect it is not waiting for the 220 user name prompt and/or the 331 password prompt, but that is just a guess.
There is nothing “wrong” with the ftp server in question. It has been running perfectly as a public access ftp server for many years. Every other ftp client tried with it, and there have probably been hundreds over the years, all happily connect to it without complaint.
I managed to get fetch to logon by disabling the connect announcement on the ftp server. That is not something I want to do permanently, but at least it proves that fetch is being confused by the connect announcement.
Now fetch logs on OK but wont upload the file. It creates the file OK, but the file remains with a 0 size, and the ftp server just times the connection out because it sees no upload activity.
I suspect fetch is insisting on an active connection, or there is some problem with the passive configuration that stops the router seeing valid addr/port PASV information. I will look into the latter more deeply.
I said that “something is wrong” with your FTP server, because these few lines I have posted were tested this morning with my “test router” and FTP server at my provider (some kind of Linux probably…) and there were no problems. I would be happy to help with FTP server details, but unfortunately it is out of my control.
I can see how you would think there was sometning wrong with the ftp server, but it is also possible that fetch only works with ftp servers that behave in a certain way, using only a subset of the ftp protocol. Ftp servers are allowed to do connect announcements, and many do, but clearly fetch doesnt always like that.
As you can see from my other post, I was able to get fetch to logon by dumbing down the ftp server. Something other clients dont need.
I am still working on the actual transfer component though.
It seems the transfer problem is as a result of the ftp server being on the LAN that the router routes.
The router will ftp using fetch to an external (extranet) ftp server, but not to the internal (LAN based) one.
I can ftp transfer to/from my ftp server from outside (extranet) and from inside (on the LAN) but not from the router. It logs in OK but wont transfer a file.
I suspect it has something to do with the NAT entries in the router itself set up for external ftp access for both PORT and PASV modes, and the settings on the ftp server to deal with NATted access.
This is a whole new can of worms. Not sure if I really want to go playing with something it took me a while to get right back then.
Mikrotik has a number of instances in which it tends to select the wrong source IP for communications.
A prime example is when you poll the router on SNMP on 1 IP it then responds to that query with a different source address to the one you requested it on…Maybe the initial FTP connect uses one IP but the data session being opened uses another IP?
A quick tcpdump on the ftp server could reveal the issue and bugfix RouterOS
I have a NAT line in place which rewrites source IP addresses for internal IPs accessing LAN resources through the router by using the WAN address. I have found this necessary to make e.g. web server log files report the correct target and source addresses. Before this it treated accesses via the WAN address differently depending on whether the access was from internal or external IPs, which isnt good enough.
So it was screwing with the ftp because of the rewrite. I simply excluded the router IP from the rewrite source range and it now behaves just fine.
There is still the login issue, but I suspect that isnt going to be fixed any time soon …
P.S. I love that someone like yourself who has been on the forum since 2007 is classified as “just joined”
for communications.
