I'll put this in OS4 software but it's a bit of both really...
I'm trying to get an FTP client on my A1200 (OS 3.2.2) to talk to an FTP server on my X5000 (OS4.1FE). Try as I might, one won't connect to the other. Am I missing some magic step? I'm trying to do this so I have a means to transfer Amiga files without going via a non Amiga native file system.
The OS3 machine (172.16.5.17) is using Roadshow since I own it, but I did also try Miami and it made no difference. The machine can happily browse the internet and more importantly can ping and FTP connect to my NAS server (172.16.5.3) and also ping the NAS. So on the face of it, everything's working OK there.
The OS4 machine (172.16.5.19) can of course connect to the internet. It can also PING and FTP to my NAS. As the server I've tried both Zeta FTP (trial) and a-FTP Server from OS4 Depot. My Mac (172.16.5.21) can connect to it just fine. So again, everything seems to be A-OK here.
And yet, I can't seem to find any way that the OS3 machine and the OS4 machine can ping each other, FTP to each other, or connect via HTTP to each other (for the web interface of ZitaFTP). I spent a couple of hours this evening and am getting nowhere. Roadshow has a firewall but not only does it say it's not enabled by default, and only enabled for PPPoE connections (this is WiFiPi), but I believe it shouldn't impact outbound connections anyway (if it was enabled then maybe there needs to be a "allow established" type rule?)
Any pointers appreciated here. Hopefully I'm just overlooking something obvious.
Default route is set to 172.16.5.1 on both machines, which is my router.
The two machines are now communicating. I had to disable ARP caching in the SSID settings of my wireless. This is OK because the A1200 is the only machine connecting to that wireless.
I have different problems now, but at least they are talking to each other!
Another alternative - but still of course depending on the network to let the two machines communicate (which you say is solved now):
I use NetFS (AmigaNetFS) to see and transfer files between all my AmigaOS machines. Currently only OS4, but I'm pretty sure it used to work fine also on OS3 back in the day.
It lets you see the remote filesystem as if it were local, so e.g. files' timestamps and amigaish attributes are kept intact.
There are no error logs. I just lose the comments against the files. I thought the comments were held in the info files but they’re not which explains it. I’ll look into NetFS but otherwise I’m now just using lha on the files before transfer. I’d rather not though
Apparently this is more of a common misconception than I knew of. You can edit the file comments in the Info window of the icon. But the comments are stored with the file itself and not the icon.
I thought something more had to be going on with the FTP. Remotely I could see issues. But on the local network there should be no issues.
I could only think of passive and active FTP but again locally there shouldn't be blocked ports unless it was intentional. I hadn't heard of this ARP caching so that's rather specific. Good to be aware of it.
To make matters worse, the comment must be stored in some file system attribute or metadata because if it was actually in the file (like a header or something) then you shouldn't be able to lose the comments when you do a binary mode transfer.
ARP caching could be something specific to my Access Point (a Ubiquiti one), but I doubt it. The setting is applied per SSID (this probably is specific to Ubiquiti?) and it was an SSID that I setup just to test the WiFi on the A1200 since it refuses to connect to my main SSID. I don't know in detail what the setting does (beyond caching ARP requests!). It could be a conincidence but I disabled the setting yesterday afternoon and when I tested again in the evening, the two machines could talk to each other so I guess it was the problem. The note in the UI of the SSID did say the option could cause connection problems for clients that don't support it so I think it's safe to assume it was the cause.
Once communication was working, finding a happy client / server pair was no easy task.
If I used Zita Server I couldn't find a client that was happy with the SSL certificate. I could have disabled encryption, but then why use Zita Server? RnoXfer has an option to ignore the certificate validation but it did nothing for me. Almost like it wasn't saving the option even though it appeared to be.
A-FTP seemed to work well when it would start. But that was only about 50% of the time, the other 50% it threw a DSI error.
RC-FTPd worked, but when the client tried to do a directory listing, it threw an error so I could never get anywhere with that server. I think at that point the client was RNOXfer
In the end I ended up using ftpd from aminet. It's a bit simple and doesn't have any encryption but it works.
I'm sure there will have been other combinations I tried too!
Ultimately, since FTP didn't solve the problem I'll probably go back to Samba anyway, or look into the NetFS mentioned earlier.
@MartinW AmigaOS specific attributes like the protection bits, user/group ID and comment are stored in the directory entry of the file. It's the same on other OSes as well, for example protection bits and user/group on Unix. The difference between binary and text mode in FTP is just that the binary mode doesn't modify the file and you get an exact copy of the contents, while text mode replaces <CR><LF> by <LF>, or the other way round, destroying binary files. But neither mode can copy meta data from the directory entries like protection bits or comments, independent of the OSes used.
MartinW wrote: If I used Zita Server I couldn't find a client that was happy with the SSL certificate. I could have disabled encryption, but then why use Zita Server? RnoXfer has an option to ignore the certificate validation but it did nothing for me. Almost like it wasn't saving the option even though it appeared to be.
Did RNOXfer open a requester asking if you want to disable certificate verification? And you clicked Yes on it? You could also run RNOXfer from the shell with the -debug option to see more if it fails.
Quote:
RC-FTPd worked, but when the client tried to do a directory listing, it threw an error so I could never get anywhere with that server. I think at that point the client was RNOXfer
In this case it usually helps if you toggle the passive mode switch ("Pasv" in the RNOXfer GUI).
The FTP protocol uses two separate connections, one for control commands (established from client to server) and other for data like directory listings and file transfers. The latter can be established from server to client (active) or from client to server (passive). Firewall/ftpd/network setup affects to which way it works in each case.
Quote:
Ultimately, since FTP didn't solve the problem I'll probably go back to Samba anyway, or look into the NetFS mentioned earlier.
If you want to preserve Amiga filesystem attributes (protection bits and comments for files/dirs), you'll have to use an Amiga specific protocol. FTP, Samba, etc. originate from other platforms and don't know a thing about Amiga specific features.
I recommend NetFS, or rather NetFS Revised (http://aminet.net/package/comm/net/NetFS-revised), which is totally Amiga original protocol and preservers all Amiga's filesystem related attributes. The Revised version is really a cool face-lift for the old NetFS.
Another option that comes in my mind is Envoy, but it's old and clumsy to setup by nowadays standards.
I could only think of passive and active FTP but again locally there shouldn't be blocked ports unless it was intentional.
It could be that server gives the outer IP address instead of local IP address to establish a passive data connection and that might mess things up if you don't have port forwardings properly set for outside connections. So it could very well be the issue still. Passive is better for outside connecitons, but active may work better on LAN.
The comment would be stored in the file header somewhere. But it wouldn't be in the binary data transfer just as the file name or attributes are also not sent inside the transfer. Unless it specially sends them across. I'm not aware of any other information being sent or checked apart from dates. And nothing relevant turned up for FTP transferring this information after a search. If it's part of the protocol then it's up to the client and server to support it if so.
Given ARP maps IP addresses to MAC addresses it seems like a reasonable idea. But I do wonder if being static or dynamic affects it? One thing does come to mind now I think of it. In the past it was common to use static IP or configure the router to assign a specific IP to a machine using DHCP. I don't recall how it was specified apart the physical interface it used. But I do recall that host names were set. Did you assign host names to any machines?
Was that the A-ftp on OS4Depot? Not much experience with RNOXfer. There is also PFTP for OS4 that I used years ago.
I used RC-FTPd on my A1200. And I also used it on OS4 years ago with success. But that was before OS4.1 came about.
I also know of some other Amiga cross platform file sharing software. I'm not sure of the name. I looked up RNOXfer but that didn't stand out as being the one.
The comment would be stored in the file header somewhere.
As told, comments aren't stored in actual files or their headers. Files just aren't touched in any way and their size doesn't change when you modify comments. It's a filesystem specific feature and filesystem stores it somewhere where it stores other metadata about files. It would end up with horrible mess if comments would be stored in the actual files.
Quote:
But it wouldn't be in the binary data transfer just as the file name or attributes are also not sent inside the transfer. Unless it specially sends them across. I'm not aware of any other information being sent or checked apart from dates.
FTP only sends binary data of the file, no dates or any other info, and client asks for a file by its filename. The FTP protocol really isn't designed to be used with automated (graphical) clients. It's up to client to parse a human readable text based directory listing to get whatever info is provided in that. Practically all FTP servers (including Amiga servers) send the directory listing in UNIX standard listing format nowadays, which is the same as you get with the "ls -l" command in *nix systems. So, what clients are able to parse about the list is *nix protection bits (not Amiga), user and group (not much use in Amiga), file size, date, and filename. It's up to client what information of these it uses, filename is the only one really needed to retrieve files.
Nothing stops writing an FTP client and server that would support Amiga's file attributes, but they would only work between themselves and no other client or server would understand them. There have been tens of different listing formats in the past and it's been a mess.. luckily there's kind of de-facto standard nowadays.
If I used Zita Server I couldn't find a client that was happy with the SSL certificate. I could have disabled encryption, but then why use Zita Server? RnoXfer has an option to ignore the certificate validation but it did nothing for me. Almost like it wasn't saving the option even though it appeared to be.
That's disappointing. RnoXfer used to work with ZitaFTP, and I thought it worked again with the latest version (at least, on AmigaOS 4).
I had (and still have) plans to create both a file syncing tool (ZitaSync), and a tool to browse and mount FTP servers as a network drive (ZitaFS). ZitaFS would preserve dates, AmigaOS-specific meta-data, etc. (when used with ZitaFTP Server).**
Unfortunately, interest in these tools was low. I tried to drum up interest in ZitaSync outside of the Amiga world, and met only passive-aggressive "you must open-source and give it away for free" types (and some other snarky individuals). Being unable to get enough interest, I was forced to put it aside, and focus instead on something that's more likely to help me pay the bills in the near to medium term.
If you're interested in these projects, then you really should sign up to the waitlists (use the links above). That's the only indication I get that people are interested. And, if nobody is interested then they may never happen.
Hans
** File meta-data is a filesystem property, and isn't uniform across all OSes or file-systems. This is why you might get warnings on Windows when copying files to a USB stick.
If I used Zita Server I couldn't find a client that was happy with the SSL certificate. I could have disabled encryption, but then why use Zita Server? RnoXfer has an option to ignore the certificate validation but it did nothing for me. Almost like it wasn't saving the option even though it appeared to be.
That's disappointing. RnoXfer used to work with ZitaFTP, and I thought it worked again with the latest version (at least, on AmigaOS 4).
For me RNOXfer seems to work still with ZitaFTP, and I don't have issues when listing files etc. If I click on the requester to continue after the certificate verification failure (self-signed), the filelist appers. And it also works if I disable verification from the settings. Maybe his issue is somewhere else, like with that passive mode.
I tried it successfully with several combinations: - From RNOXfer/OS4 to ZitaFTP/Windows - From RNOXfer/OS4 to ZitaFTP/OS4 - From RNOXfer/OS3 to ZitaFTP/Windows - From RNOXfer/MorphOS to ZitaFTP/Windows
Sorry, people - not been checking in the last day or two as a deadline has come up that I need to meet for a private project.
So, yeah, basically, I already tried everything mentioned in the replies as I'm far from new to FTP. My copy of RNOXfer at least, appears to be buggy in that no matter how many times I told it to ignore the SSL errors and continue, it still complained. Also if I enabled the setting in options, it carried on like I never did, regardless of whether I tried to force the matter or not by toggling other settings too.
It's quite possible that my copy of RNOXfer is incomplete or buggy because I just pulled it from another partition which was "Caffeine OS". Maybe for completeness I'll try installing it properly on my 3.2 partition.
Anyway, I've found a workaround for now and moved on. Thanks for the help.
I had (and still have) plans to create both a file syncing tool (ZitaSync), and a tool to browse and mount FTP servers as a network drive (ZitaFS). ZitaFS would preserve dates, AmigaOS-specific meta-data, etc. (when used with ZitaFTP Server).**
Hello Hans,
i like ZitaSync very much and you have a quick solution to transfer photos under AmigaOs4.1 directly from your cell phone. I also watched your video - it's great I would be interested in such a solution!
I didn't understand exactly how it works, does the client that receives the data/photos run under AmigaOs4.1 ? How is a connection established?
I also like ZitaFS and I will soon be faced with the problem of having to transfer data from my A1222plus to MacStudio and vice versa. I already have ZitaFTP, but it is too complicated for me to make FTP connections available on both sides, it should run automatically and be available when I need it quickly as I can currently do with SMB2Fs.
ZitaFS works similar to SMB2Fs?
Maybe you can write a little more about how it works and how it is set up and what requirements need to be met. In the end I always opt for the simplest variant that is available under AmigaOs4.1.
MacStudio ARM M1 Max Qemu//Pegasos2 AmigaOs4.1 FE / AmigaOne A1222plus AmigaOs4.1 FE
News feed
OS4 Feedback forum
OS4Depot Feedback forum
Amigabounty forum
OpenAmiga forum
AmiCygnix forum
ABC shell forum
AmiKit forum
Cinnamon Writer forum
CodeBench forum
Digital Universe forum
Dopus 5 forum
E-UAE forum
Gnash forum
Ibrowse forum
JAmiga forum
Odyssey forum
OWB forum
Qt forum
SmartFileSystem forum
Timberwolf forum
TouchDevice forum
TuneNet forum
Unsatisfactory Software forum
Donate
I would be interested in such a solution! 